RE: proposal to resolve AMS - SystemVerilog logic conflict

I have since thought of a slight ammendment to the proposal that will
make it more backward compatable by taking advantage of verilog escape
naming mechanism.

The section on escaped names says;

(from LRM2.2, 2.7.1 Escaped Names)

Neither the leading back-slash character nor the terminating white space
is considered to
be part of the identifier. Therefore, an escaped identifier \cpu3 is
treated the same as a
non-escaped identifier cpu3.

Based on this we can change logic in disciplines.vams to be defined as
an escaped definition. We would then discourage its usage and promote an
alternative. This approach would not require users to change their
existing Verilog-AMS netlists at all!

Hence the modified proposal is;

Solution:

We need to change definition of logic in disciplines.vams so that it is
escaped. This will mean that disciplines.vams will parse in
SystemVerilog-AMS but without causing requiring Verilog-AMS netlists
that use logic to be changed at all in order to use the redefined
disciplines.vams.

i.e. change;

discipline logic
     domain discrete;
enddiscipline

to 

discipline \logic 
     domain discrete;
enddiscipline

Although this will solve the problem of the existing disciplines.vams
not being parsable in SystemVerilog-AMS, it does NOT solve the problem
of existing Verilog-AMS modules which use logic as a discrete discipline
being parsable in SystemVerilog-AMS.

It also doesn't solve the problem of users in the future writing a
module with mixed SystemVerilog and AMS features that uses the standard
Verilog-AMS discrete discipline.

Therefore the Verilog-AMS LRM should encourage the use of a new discrete
discipline as the standard discrete discipline called d_logic and
encourage users to change over time i.e.;

discipline d_logic
     domain discrete;
enddiscipline

All examples/text in the LRM that use logic should be changed to
d_logic.

The LRM should note that usage of logic as a discrete discipline is
discouraged as it will be a problem to reuse netlists when AMS and
SystemVerilog are combined.

The LRM should also note that new keywords that were added to
SystemVerilog and discourage their usage as identifiers in Verilog-AMS
netlists for the same reason.
 
Thanks,
--Martin

-----Original Message-----
From: Jonathan Sanders 
Sent: Monday, August 15, 2005 10:30 PM
To: Martin O'Leary; Kevin Cameron
Cc: verilog-ams@eda.org; Steven Sharp
Subject: 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
***********************************************************