RE: proposal to resolve AMS - SystemVerilog logic conflict

Kevin,
I started this thread looking for feedback on my proposal in the hope I
would get constructive feedback on it - instead it was there was a
counter proposal (which was already rejected by a standard that we meant
to merge and be compatable with) and now you bemoaning the fact that you
are not getting constructive/technical feedback on your proposal! (which
is a point that I don't accept).
 
The logic conflict is IMHO a relatively small issue when trying to merge
SV and AMS and based on this thread I am very concerned about moving
forward with this merger unless we establish a clear and practical
approach for getting this done.
Part of such an approach would be 1) the degree to which SV precedences
should be accepted 2) what type of issues should be passed to the SV
committee instead of being kept with the AMS committee 3) a procedure
for submitting, reviewing and approving/rejecting proposals.
 
Thanks,
--Martin

________________________________

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

		 
		> 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

	As I said before the proposal is a general solution to the
type/keyword clash problem that is 100% backward compatible with SV
code, and facilitates reuse of any code with type-name clashes in design
flows using old methodologies.
	
	If anyone at Cadence has a technical objection to the propsal
(i.e. some reason that it won't work) that might be a useful discussion.
Claiming precedence is specious, I proposed other things at the SV
committees that were initially rejected and then reappeared later.
	
	Generally I throw out proposals as a starting point, if people
have technical problems with them I will attempt to fix the problems and
improve the proposals. Whether or not the final proposal is adopted
should be a democratic decision by the committee.
	
	Kev.
	

		 


________________________________

			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