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