Re: proposal to resolve AMS - SystemVerilog logic conflict

Martin O'Leary wrote:

>Kevin,
>I read over you proposal and it sounds like what you are proposing is
>handled by the 'begin_keywords feature of SV.
>
>  
>
Not really, it only addresses a subset of the  problem - i.e.  data-type 
names - but
it's a general mechanism rather than a specific mechanism, so you can 
use it when
you have a type-name clash for other reasons e.g. just mixing code from 
different
sources.

Very little progress seems to have been made on making [SystemVerilog] 
compilation
modular like C/C++, so it is still the case that Verilog input in 
multiple files is treated as
one single input stream, so it is desirable to have mechanisms that 
limit the scope of
definitions within the stream (like reaching the end of a file in C/C++) 
- untypedef  makes
that possible.

>....
>
>However you say; "I don't like that much since it requires editing old
>code to make it work with the new language."
>
>This is not correct - with the proposal I made users can do this to get
>old VAMS code to work;
>
>`define VAMS_DISCRETE_DIS logic
>`include "old.vams"
>
>  
>
Not seeing how that works in a mixed language context.

>Concerns I have with the proposal you sent are
>
>1. Also behind this proposal is that users will want to be able to
>create modules with both AMS AND SV functionality.
>
>Using typedefs to switch on and off the keyword logic is going to make
>such modules pretty confusing and gross.
>
>  
>
If you are writing new stuff you aren't going to need to use untypedef - 
you can pick
names that don't clash -  you'll only have to define them once. It's 
main use is for
patching typename clashes futher down the design flow when mixing 
descriptions
from different sources (some legacy).

>2. The SV committee have decided to make logic a keyword not a typedef
>and they are in the process of balloting on this.
>
>  
>
"logic" doesn't need to be a keyword. Keyword status can be deprecated  
for all the
current SV data-types if they are replaced by typedefs of other (less 
clashing) names.

You could generalize the functionality of untypdef with somethig like a 
"forget <name>",
which will allow you to forget definitions for AMS types too so that you 
can do:

    forget logic; // forget any definition of logic
    `include "old_analog.va"
    forget logic; // forget any definition of logic from AMS code
    `include "new_digital.sv"

Or if you only want temporary amnesia:

    forget logic begin
    `include "old_analog.va"
    endforget
    // previous logic definition reinstated

You could probably use `forget/`endforget instead if you prefer.

Kev.

>Thanks,
>--Martin
>
>-----Original Message-----
>From: Kevin Cameron [mailto:kevin@sonicsinc.com] 
>Sent: Friday, August 12, 2005 4:04 PM
>To: Martin O'Leary
>Cc: verilog-ams@eda.org
>Subject: Re: proposal to resolve AMS - SystemVerilog logic conflict
>
>Martin O'Leary wrote:
>
>  
>
>>Here is my proposal to resolve AMS - SystemVerilog contradictory uses 
>>of logic declarations Thanks, --Martin
>> 
>>
>>    
>>
>I don't like that much since it requires editing old code to make it
>work with the new language.
>Since the same problem applied to old digital Verilog I proposed a
>different solution a long time ago
>(http://www.eda.org/sv-ec/hm/1193.html). Basically all the standard
>types are renamed to something unlikely to clash, and when the
>compiler/parser starts it
>(automatically) reads a header
>file that typedefs the new types as the old e.g.:
>
>    typedef  __sv_digital_logic logic;
>
>Then if at a later time you want to read some old stuff you can do an
>untypedef to forget that meaning of logic:
>
>    untypedef logic;
>     `include "old.v"
>    typedef  __sv_digital_logic logic;
>
>This shouldn't cause any problems for existing SV code, and doesn't
>require old code to be changed (just wrapped by some untypedef/typedef
>includes).
>
>If you want to use the SV "logic" type with the current AMS logic type
>you can use the built-in (__sv_digital_logic above) or typdef it to
>something shorter.
>
>It shouldn't take more than a few hours for someone with a SV parser to
>try that out.
>
>Kev.
>
>  
>
>>Problem: 
>>AMS and SystemVerilog both use 'logic' in a contradictory way.
>>
>>This prevents people for mixed AMS and SystemVerilog in the same parse 
>>stream.
>>
>>It also is going be a serious roadblock for creating SystemVerilog-AMS.
>>
>>In AMS, logic is discipline defined in the standard discipline header 
>>file; disciplines.vams;
>>
>>	discipline logic
>>	domain discrete;
>>	enddiscipline
>>
>>To make declare a net called n as having logic discipline in AMS one 
>>does;
>>
>>	logic n;
>>
>>SystemVerilog adds another 4-value data type, called logic (see 
>>Sections
>>3.3.2 and 5.6 of the SystemVerilog 3.1a LRM).
>>
>>To create a logic variable called n, one does;
>>
>>	logic n;
>>
>>Note logic is almost exactly identical to 'reg' except logic can be 
>>declared inside other things (like a struct).
>>
>>
>>Solution:
>>
>>We need to deprecate logic as a identified defined in disciplines.vams;
>>
>>In AMS, the definition of logic as a discrete discipline in 
>>disciplines.vams should be removed.
>>
>>Also the following should be added the disciplines.vams to promote a 
>>new standard discrete discipline called d_logic (short for discipline 
>>logic) but allow users to switch back to using logic by putting 
>>"'define VAMS_DISCRETE_DIS logic" before the include to 
>>disciplines.vams in their sourcefiles.
>>
>>`ifdef VAMS_DISCRETE_DIS
>>`else
>>`define VAMS_DISCRETE_DIS d_logic
>>`endif
>>
>>discipline `VAMS_DEFAULT_DISCRETE_DIS
>>    domain discrete;
>>enddiscipline
>>
>>All examples/text in the LRM that use logic should be changed to 
>>d_logic.
>>
>>
>> 
>>
>>    
>>
>
>
>
>
>  
>