Jonathan David wrote: > 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? > The name difference may be sufficient. Whether the discipline is discrete or continuous is fairly irrelevant since you are trying to apply a design rule rather than set simulation behavior; it doesn't matter whether the drivers and receivers are on different power rails for a net you can still build and simulate it (it's just likely it won't do what you want). The proposal was to help avoid creating lots of resolution rules for similar types - ones with the same set of attributes but with differing attribute values. The other advantage would be that the error message could be more specific e.g. "Can't connect disciplines 'logic_cmos' and 'cmlogic' because attribute Vdd is not resolvable". Generally you want to make it easy to plug modules (IP) from different origins together, but avoid stupid mistakes. With the current scheme a user could easily create a bad resolution rule at the level of disciplines, doing the resolution at the level of attributes is clearer and less error-prone - it also encourages people to use a standard attribute set. Kev. > 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 expect.. (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 >> >> >> > > >Received on Fri Sep 8 11:58:07 2006
This archive was generated by hypermail 2.1.8 : Fri Sep 08 2006 - 11:58:22 PDT