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

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