Re: proposal to resolve AMS - SystemVerilog logic conflict

Martin O'Leary wrote:

> 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).

Since only a few people from the AMS committee attended the 
SystemVerilog committees and new people have joined since the original 
discussion there, I feel it's fair enough to repost the my original 
proposal. I reposted it because your proposal required legacy code to be 
modified (i.e. logic needs to be renamed in the AMS code), and my 
proposal doesn't  require that. I feel that is more positive than just 
saying I didn't like your proposal.

I'm bemoaning the fact that Cadence generally (from my AMS experience, 
since they didn't get involved with SV until rather late) don't offer 
reasonable technical criticism of proposals that they just don't want to 
implement (usually because they have already implemented something 
dysfunctional that they don't want to change).

> 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.

If you take the SV precedence of how Vera was integrated, all you do is 
get the AMS-LRM pasted it into the SV-LRM as a new chapter and then see 
how much clean-up you can do before the next DAC.

There are not enough people involved in AMS to run an SV sub committee 
and the existing committee and make much progress. As I said before I 
think the Accellara committee should change focus to developing standard 
libraries/models and the language development should move to the IEEE.

Kev.

>  
> 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>
>>>>    
>>>>
>>>>>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
>>>
>>>
>>>  
>>>
>>
>