Re: support for multiple supplies

 Kevin, what about discrete / discrete? connections. 
If we have NO connect module, wouldn't it be OK just to disallow connection if the discipline NAME is different?

In my BMAS paper, I use logic_cmos for 1.5v rail-to-rail cmos and cmlogic for both sides of a 1.5v to 1.2v current mode logic signal. 
Naturally, since the signal is either "positive" or "Negative" (potential difference on the pair) I want to use event type models - but if this is accidentally connected to a cmos logic input, or these inputs are driven by a cmos logic output, that should be a connection error. 

What attributes of _discrete_ disciplines would be different in your proposal? And why would a difference in name not be enough?


My recollection of my simulations were that if I didn't not have one of the compatible disciplines, I wound up getting an electrical net where I did not exect.. (because I did have a connect module for that case. ) But maybe not an error.. 

Jonathan

----- Original Message ----
From: Kevin Cameron <dkc@grfx.com>
To: Verilog-AMS LRM Reflector <verilog-ams@eda.org>
Cc: Ken Kundert <ken@designers-guide.com>
Sent: Friday, September 8, 2006 12:40:32 AM
Subject: Re: support for multiple supplies

Ken Kundert wrote:

>All,
>    I saw the article in the EE-Times insert "EDA Tech Forum" by Strahle
>and Gossman from Infineon on using VHDL-AMS to find issues in designs
>that stem from having multiple power supplies. Their approach seemed a
>bit crude, so I thought I would try using the Verilog-AMS natures and
>disciplines to try to provide a more elegant solution. What I wanted at
>a minimum was to prevent from connecting gates that operate at one
>supply voltage from being connected gates that use another supply
>voltage. So I tried to define new disciplines as follows ...
>
>discipline logic1p2
>    domain discrete;
>enddiscipline
>discipline logic1p5
>    domain discrete;
>enddiscipline
>
>module inv1p2 (out, in);
>    output out;
>    input in;
>    logic1p2 out, in;
>
>    assign out = !in;
>endmodule
>
>module inv1p5 (out, in);
>    output out;
>    input in;
>    logic1p5 out, in;
>
>    assign out = !in;
>endmodule
>
>module testbench;
>    logic1p2 n1;
>    logic1p5 n2;
>
>    inv1p2 I1 (.out(n2), .in(n1));
>    inv1p5 I2 (.out(n1), .in(n2));
>endmodule
>
>Verilog-AMS then allowed me to connect together ports with two different
>disciplines because apparently they are compatible. So question number
>one ...
>
>Q1: Is there a way of explicitly declaring that two disciplines are
>incompatible? Perhaps ...
>    connectrules multisupply;
>        connect logic1p2, logic1p5 resolveto error;
>    endconnectrules
>or
>    connectrules multisupply;
>        connect logic1p2, logic1p5 resolveto error("you must connect
>1.2v logic to 1.5v logic");
>    endconnectrules
>
>
>So then I tried using connect modules, by adding the following to the
>above example ...
>
>connectmodule logic1p2to1p5 (out, in);
>    output out;
>    input in;
>    logic1p5 out;
>    logic1p2 in;
>
>    initial $stobe("ERROR: %M: 1.2v logic driving 1.5v logic");
>    assign out = 1'bx;
>endmodule
>
>connectmodule logic1p5to1p2 (out, in);
>    output out;
>    input in;
>    logic1p2 out;
>    logic1p5 in;
>
>    initial $stobe("ERROR: %M: 1.5v logic driving 1.2v logic");
>    assign out = 1'bx;
>endmodule
>
>connectrules multisupply;
>    connect logic1p2to1p5;
>    connect logic1p5to1p2;
>endconnectrules
>
>But this does not work because connect modules must have exactly one
>discrete port and one continuous port. So question number 2 ...
>
>Q2: Why have this restriction. Why can't we support connect modules that
>have two discrete ports or two continuous ports?
>  
>
The reason for using modules is that  you may need to maintain some 
state information for the conversion if it spans time, connect modules 
are therefore probably unnecessary for discrete/discrete connection; all 
that is required is a cross-type resolution scheme, but since there are 
no user-defined signal types in Verilog (all you have is 0,1,x,z and 
some strengths) about all you can usefully do is tweak the strength so 
it's probably not worth the effort.

Connect modules for continuous/continuous are redundant if the 
disciplines match, and if they don't match then the implication is that 
the connect module represents a transducer (actual hardware) rather than 
a simulation artifact.

... and connect modules shouldn't be bound to ports anyway, they need to 
bound to the driving and receiving processes.

>Does anybody have any suggestions on how to prevent logic gates from
>different supply domains from being connected together?
>  
>
I proposed a discipline attribute resolution scheme a while back whereby 
you can connect  disciplines without a specific resolution rule if you 
supply individual attribute resolution 
(http://www.eda-stds.org/verilog-ams/htmlpages/tc-docs/issues/0014/index.html). 

An extension of that proposal could be to explicitly disallow multiple 
values for a specific attribute (e.g. Vdd).

Kev.

>Thanks,
>-Ken
>  
>


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