Re: proposal to resolve AMS - SystemVerilog logic conflict

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


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

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

Steven Sharp
sharp@cadence.com