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

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
<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 <http://www.grfx.com/> 
mailto:dkc@grfx.com <mailto:dkc@grfx.com>