RE: proposal to resolve AMS - SystemVerilog logic conflict

It should be noted that "logic" in Verilog-AMS is not really a true keyword 
in the normal definition of keywords.  Keywords are reserved and cannot be 
changed by users yet the default digital discipline can be whatever users 
set it to be, unfortunately most use the value we provided in our example 
disciplines.vams file and LRM examples.

So the problem in the case of logic is the example we provide is causing a 
conflict so the simple answer is do what any user can do, change the 
default discipline for digital to something other than logic.  But so many 
AMS users are using logic, only a handful of power user have gotten to the 
point of defining their own digital discipline names, that we must address 
this.  The good news is that most solutions are solving the default 
discipline by methods that don't require every source file to be edited.

Let's change our examples and provide a method for backwards compatibility 
and move on to high value issues :)

Jon


At 09:43 PM 8/15/2005, 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.
>
>(as FYI to others on the reflector) This macro directive allows users to
>switch in and out different keyword sets and so enables users to avoid
>keyword clashes in old legacy Verilog code.
>
>e.g.;
>
>`begin_keywords "1364-1995"
>
>Changes the keyword set to be V1995.
>
>Therefore users can do;
>
>`begin_keywords "1364-1995"
>`include "old.v"
>`end_keywords
>
>to import old verilog without the risk of keyword clashes;
>
>Aside: I believe that AMS should leverage this functionality. I will
>file an request in the database on this later.
>
>
>
>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"
>
>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.
>
>2. The SV committee have decided to make logic a keyword not a typedef
>and they are in the process of balloting on this.
>
>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.
> >
> >
> >
> >

***********************************************************
Jonathan L. Sanders
Product Engineering Director
Custom IC Solutions
Cadence Design Systems, Inc.
555 River Oaks Pkwy
San Jose, CA. 95134
  INTERNET:jons@cadence.com    Tel: (408) 428-5654      Fax : (408) 944-7027
***********************************************************