RE: proposal to resolve AMS - SystemVerilog logic conflict (v2.0)

Kev, and all,

You're right. I think your proposal meets the 3 requirements I have stated
earlier:
(a) resolve the clash in names (logic type vs. logic discipline),
(b) remain backwards compatible with existing code,
(c) make a step towards integration of AMS and SV.

So count me in as a supporter :-)

As I've scanned the SV website in the meantime, I saw that my earlier
conjecture that there are no SV tools out yet is completely off the mark.
In that case, changing the effect of the import statement (shadowing
i.s.o. define only once) would not be an easy step to make.

Do we have an overview of the uses of logic? As far as I can see its main
purpose is to provide a discipline to existing Verilog-D blocks. So most
of its use would be in a statement

`defaultdiscipline logic

In the examples provided in the AMS LRM I only see it appearing explicitly
in the treatment of connectmodules, and also there it could be solved
using the `defaultdiscipline directive. It is of course possible to create
an internal net that has to be declared with logic, but is that a likely
kind of use? Are there any other uses that I haven't thought of?

What I'm trying to get at is how much impact a break in backwards
compatibility would have on our current users.

Regards,
Marq

 
<>
<> Marq Kole Competence Leader Analog
Simulation
<> Philips ED&T/AS Consultant Circuit Optimization
<> Building WAY 3.069 phone: +31 40 27 44875
<> Professor Holstlaan 4 fax: +31 40 27 44700
<> 5656 AA Eindhoven e-mail: marq.kole@philips.com
<> The Netherlands
<>

"Kevin Cameron" <KCAMERON@altera.com>
Sent by:
owner-verilog-ams@eda.org
30-11-2004 19:00
 
        To: Marq Kole/EHV/RESEARCH/PHILIPS@PHILIPS
        cc: <Verilog-AMS@eda.org>
        Subject: RE: proposal to resolve AMS - SystemVerilog logic
conflict (v2.0)
        Classification:

Marq,
 
What I was suggesting is not really ?late binding? since the type is both
(rather than either) and doesn?t complicate elaboration much: port
connections can be typed, but generally that isn?t important since all you
need to know (particularly for AMS) is how many physical wires are
involved (i.e. the width).
 
The root problem (as I see it) is that folks like to consider a wire as
being one thing in one context and something else in another context, when
really it is many things simultaneously. The context where it matters is
the process (analog/always/initial etc.) and not the module (which is just
structural).
 
The solution I proposed requires only a change to the disciplines.vams
header and a small syntax/semantic extensions, user code should not have
to change. The other proposals (while perfectly reasonable) still require
the user code to change so are not backward compatible.
 
An even simpler option is to drop ?logic? from the disciplines.vams file,
make it a predefined type for AMS (as it is in SV) and just go by usage.
 
Kev.
 
-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
Behalf Of marq.kole@philips.com
Sent: Tuesday, November 30, 2004 6:34 AM
To: verilog-ams@eda.org
Subject: Re: proposal to resolve AMS - SystemVerilog logic conflict (v2.0)
 

Kevin, Martin,

In the light of what has been discussed at the last conference call, I've
had a look at the way packages are defined in SV. It looks like we could
use those as a way to (a) resolve the clash in names (logic type vs. logic
discipline), (b) remain backwards compatible with existing code, (c) make
a step towards integration of AMS and SV.

If AMS were to support packages as described by the SV 3.1a standard
(section 18.2), and we were to extend the possible contents of packages
with disciplines and natures, then an existing AMS model could be
supported. Consider that we would put the contents of disciplines.vams in
the package AMS, then the following lines would make the logic discipline
available:

`include "disciplines.vams"
import AMS::*;

module (nin, nout);
in nin;
out nout;
electrical nin;
logic nout;
endmodule

or if logic is never explicitly used:

`include "disciplines.vams"
`default_discipline AMS::logic

module (nin, nout);
in nin;
out nout;
electrical nin;
endmodule

To use the logic discipline in SV 3.1a, one would have to reference the
logic (and everything else) from the AMS package as

`include "disciplines.vams"

module (nin, nout);
in nin;
out nout;
AMS::electrical nin;
AMS::logic nout;
endmodule

As this would essentially be new code and new use (there are no SV tools
around yet, right?) we don't have an issue.

Together with the concept of compilation units to be restricted to one
file (the default in SV 3.1a section 18.3) would make that the logic
discipline could be imported from the AMS package and used as though
defined in the current package. That would essentially make the import of
the logic discipline only last for the length of the file, i.e.
compilation unit.

There is one little snag at the moment: in section 18.2.1 of the SV 3.1a
LRM it says:

"An explicit import shall be illegal if the imported identifier is
declared in the same scope or explicitly imported from another package."

and

"A wildcard import makes each identifier within the package a candidate
for import. Each such identifier is imported only when it is referenced in
the importing scope and it is neither declared nor explicitly imported
into the scope."

Meaning that an imported declaration does not shadow an existing
identifier, but exactly opposite: an existing identifier cannot be
redefined by means of an import statement. Given the large number of
keywords (or reserved identifiers) in both SV and AMS this is something
that would be worth discussing with the SV community. This is of course
assuming that the SV community is also interested in aligning with the AMS
community. And we should keep the 1364 guys in the loop as well.

In a similar way we can reduce the number of keywords in AMS by moving
them to specialized packages (for instance, all the algebraic functions to
a package Math)

Alternatively, as Kevin suggested, late binding would be required, i.e.
only attribute a type or discipline to an identifier once it can
determined from its usage whether it is a type or a discipline. That would
very much complicate elaborator implementation for a SV-AMS system; not my
choice for an emerging standard to be.

Regards,
Marq

<>
<> Marq Kole Competence Leader Analog
Simulation
<> Philips ED&T/AS Consultant Circuit Optimization
<> Building WAY 3.069 phone: +31 40 27 44875
<> Professor Holstlaan 4 fax: +31 40 27 44700
<> 5656 AA Eindhoven e-mail: marq.kole@philips.com
<> The Netherlands
<>

Kevin Cameron <dkc@grfx.com>
Sent by:
owner-verilog-ams@eda.org
30-11-2004 09:43
        
        To: verilog-ams@eda.org
        cc: "Martin O'Leary" <oleary@cadence.com>
(bcc: Marq Kole/EHV/RESEARCH/PHILIPS)
        Subject: Re: proposal to resolve AMS - SystemVerilog logic
conflict (v2.0)
        Classification:

Martin O'Leary wrote:
Kevin,
Comments below;
Thanks,
--Martin
  
 

From: Kevin Cameron [mailto:KCAMERON@altera.com]
To: Martin O'Leary; Verilog-AMS LRM Committee
  
Does it help if you allow the SV definition of logic in AMS and add some
new syntax to bind it to a discipline e.g. something like:
  
discipline type logic
      domain discrete;
enddiscipline
  
  or
  
discipline digital_01XZ
      domain discrete;
enddiscipline
  
discipline type logic : digital_01XZ;
  
  
You could apply that to other types like bit, or to user defined types.
  
Oleary>This is an interesting idea and gives users a way put a default
discipline on particular types. However this is not the problem I am
trying to get addressed in the short term.
  
Seems to me that logic could do both jobs simultaneously, since the
discipline aspect is orthogonal to the SV value.
Oleary>Think that getting logic mean different things in different
contexts is going to cause endless confusion so I don?t think we should
even try to do this.
  
Basically it comes down to what does this mean;
  
module foo;
logic n; // is this a discipline declaration or a type declaration?
endmodule
Does it matter in that particular case? - you have a wire named `n', it's
behavior is determined by the drivers and receivers attached to it. Since
the analog assignments are distinguishable from the digital by the
operators used you know which aspect you are interested in for the
drivers, for receivers analog uses access functions (e.g. V(n)) and
digital does not. If there are no drivers (or receivers) of a net its
discipline or digital type are somewhat irrelevent.
SV and AMS have very different interpretations and AMS and SV users are
currently producing modules that cannot be compatible with the other
language because of this ambiguity.
  
Do you have a case where there is actual ambiguity?
The sooner we address this issue, the better off users will be.
  
I know of users who want to use SV and AMS in the same design.
  
I'm sure everybody does, but I don't think we actually have to obslete the
existing AMS usage to make that happen.

Also, taking the approach I suggested possibly solves another SV problem:
identifying what is a wire type vs. an abstract type since binding a type
to a discipline implies that it is on a single wire (node) rather than a
bunch of wires.

Kev.
  
Kev.
  
  
-----Original Message-----
From: Martin O'Leary
Sent: Monday, November 29, 2004 12:01 PM

Here is my proposal to resolve AMS - SystemVerilog contradictory uses of
logic declarations.
  
Note: The replacement name for logic in AMS is different than what I
proposed earlier this year because from playing around with example
usages, I feel it is important that the replacement name is more distinct.

  
Thanks,
--Martin
  
  
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:
  
In AMS, the logic discipline defined in disciplines.vams should be removed
and replaced by a definition for a discrete discipline that is;
      1. compatible with System Verilog
      2. will stand out in some way because in SystemVerilog, users can
define new types.
  
To this end I propose;
ddiscrete (short for discipline discrete)
  
Because;
1. wire types in Verilog start with 'w' - this makes them easy to
recognise. Why not apply a similar conventions to at least digital
disciplines?
2. The ddiscrete makes more sense than say dlogic because the discipline
is for a discrete types not for logic types (which maybe in the future,
users may be able define a continuous logic type using SV-AMS).
  
A disciplines2.2.vams file == to the disciplines.vams file in LRM2.2
should be supported for backward compatability.
  
All examples/text in the LRM that use logic should be changed to
ddiscrete.
  
      discipline ddiscrete
      domain discrete;
      enddiscipline
  
  

-- 
http://www.grfx.com
mailto:dkc@grfx.com