RE: proposal to resolve AMS - SystemVerilog logic conflict

 
> This is a different committee and we're considering proposals for the
same problem (most
> of the folks doing AMS have not been involved in SystemVerilog
development), so I'm
> reiterating my proposal - feel free to reiterate yours.

Kevin,
the goal is the merge AMS and SV so we need to take System Verilog
precedences into account and IMHO as much as possible comply with them -
otherwise we are only adding more conflicts and issues that will impact
meeting our goal.
 
Thanks,
--Martin
 


________________________________

	From: Kevin Cameron [mailto:kevin@sonicsinc.com] 
	Sent: Wednesday, August 17, 2005 11:46 PM
	To: Steven Sharp
	Cc: Martin O'Leary; verilog-ams@eda.org
	Subject: Re: proposal to resolve AMS - SystemVerilog logic
conflict
	
	
	Steven Sharp wrote: 

			From: Kevin Cameron <kevin@sonicsinc.com>
<mailto:kevin@sonicsinc.com> 
			    

				As Martin has already noted, the
built-in types in SV are keywords rather
				than predefined typedefs.  This means
that an "untypedef" would not help
				in avoiding name conflicts with them.
There was resistance within the SV
				committees to the suggestion of using a
less common name for the built-in
				types, with typedefs to get backward
compatibility with code using the
				older names.  So I wouldn't count on
getting that changed.
				      

			The proposal was to rename the built-in types to
something wordy e.g. *__sv_logic*,
			(which can be a keyword), and then have an
initial typedef of that to *logic* (not a keyword)
			which can be "forgotten" if necessary with an
untypedef. As far as I can tell this should not
			change the behavior of SV at all with respect to
existing code.
			    

		
		Which is substantially the same as what I wrote, except
with the
		addition of untypedef instead of just not including the
standard
		typedef if you didn't want logic pre-defined.
		
		A number of variations on this theme were brought up in
the Accellera
		and IEEE committees.  I know you suggested some, as did
I.  But they
		were all rejected, so there is no reason to expect that
to change.
		
		  

	This is a different committee and we're considering proposals
for the same problem (most
	of the folks doing AMS have not been involved in SystemVerilog
development), so I'm
	reiterating my proposal - feel free to reiterate yours.
	

		

			As I said before the mechanism I proposed is a
general purpose way of limiting the
			scope of various types. There is plenty of
opportunity for users to create data-types that
			will clash with other designers' types,
disciplines or natures etc. which are likely to
			make the source descriptions ambiguous (and
unparsable).
			    

		
		Your mechanism is not general, since it doesn't deal
with types that
		are defined with reserved words rather than typedefs.
In particular,
		it doesn't deal with the type in the subject: logic.

	I'll repeat: If you rename the keyword logic to (say) __sv_logic
and then typedef __sv_logic to logic, then logic does not  need to be a
keyword. You can do the same for all the predefined types, and if you
can think of a name for the predefined types that can't be a user
defined type or an AMS keyword all the better (e.g. $sv$logic). 
	

		  You can argue
		that your mechanism would be more general in a different
language where
		these types were defined with typedefs.  However, we are
talking about
		SystemVerilog, where they weren't.  Nor is there any
guarantee that
		this will change.
		
		  

	If you know any reason why my proposal isn't 100% backward
compatible I'll be glad to hear it.
	

		Meanwhile, the mechanisms of `begin_keywords and
file-based compilation
		unit scopes are already part of the P1800 standard.
		
		  

	Draft standard.
	
	Kev.
	
	

		Steven Sharp
		sharp@cadence.com