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

Kevin,

Comments below;

Thanks,

--Martin

________________________________

From: Kevin Cameron [mailto:KCAMERON@altera.com]
Sent: Monday, November 29, 2004 5:02 PM
To: Martin O'Leary; Verilog-AMS LRM Committee
Subject: RE: proposal to resolve AMS - SystemVerilog logic conflict (v2.0)

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

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.

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.

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

 
Received on Mon Nov 29 21:09:33 2004