help-gnucap
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnucap] Re: [Help-gnucap] Flip-flop RS


From: al davis
Subject: Re: [Bug-gnucap] Re: [Help-gnucap] Flip-flop RS
Date: Tue, 8 Aug 2006 21:19:08 -0400
User-agent: KMail/1.9.3

On Tuesday 08 August 2006 10:40, Jose Roberto B. de A. Monteiro 
wrote:
> al davis wrote:
> > The voltage is generated by a conversion based on the
> > parameters in the .model statement.  In particular "vmax". 
> > Since you didn't say, it is 5 volts.
>
> Ok... I understand... but, IMHO the digital simulator would
> be wonderfully flexible if it took its high voltage output
> level from its VCC pin, and it LOW voltage output level from
> its GND pin. Otherwise, since its uses a "hardcoded" output
> voltage, VCC and GND pins are useless, for output, at least.
> How does it determine input levels? From VCC and GND pins
> potential?
>
> The use of VCC and GND pins voltage potentials would be
> useful in applications were logics are connected in different
> GNDs and VCCs. It is the case for some analog/digital mixed
> circuits, as in cmos analog switches for data aquisition
> systems (analog channel multiplexes).

You have a good point.  I will leave it as it is for now.  
Here's why:

First, I am working on changes to support full Verilog-AMS.  
When this is done, you will have the capability of defining 
things like this.  I think this is much more important than 
issues with the present format.  With a standard language, that 
has a real document defining it, points like this are 
pre-determined.  Gnucap will operate according to the published 
standard.

I am trying to avoid spending time on parts of the program that 
will be replaced, because they delay the real goals.

Second, it doesn't work technically.  Logic nodes do not follow 
Kirchoff's laws.  Modern simulators often have a "conservative" 
mode, and a "signal flow" mode.  Some nodes are in one more, 
some in the other.  Spice is a "conservative" mode simulator, 
always.  Gnucap does digital in "signal flow" mode.  That is, 
the value at a node is determined completely by something being 
placed there.  No solution occurs there.  For example, in this 
case, the output of the gate is a logic state.  Period!..   If 
you want a voltage, it look up the correspondence from that 
logic state to a voltage and tells you that is the voltage.  
There is no Kirchoff's law equation to solve for it.  This is 
the way signal flow simulators work.

The distinction between these modes is made per node, not per 
device.

Suppose I have ...

U1 (out1 0 vsmall enable in) cmos inv
U2 (out2 0 vbig enable out1) cmos inv
Vb (vbig 0) DC 20
Vs (vsmall 0) DC 2
.model cmos logic (vmax=5)

...

ok .. it's not the whole circuit, but I hope there is enough to 
make the point.

The output of the first inverter drives the second.  Obviously, 
the two inverters act like a non-inverting buffer.  (but maybe 
not)

Both gates are identical, except for their power supply.  Since 
they are digital, with no analog model, the node "out1" has 
only a logic value.   There is no such thing as voltage there. 
That logic value is applied to the second inverter..  No 
voltage ever appears.

The circuit would appear to work, even though it shouldn't.


If the gates were different, for example:

U1 (out1 0 vsmall enable in) cmos1 inv
U2 (out2 0 vbig enable out1) cmos2 inv
Vb (vbig 0) DC 20
Vs (vsmall 0) DC 2
.model cmos1 logic (vmax=5)
.model cmos2 logic (vmax=5)

(ack!!!)  See the difference between cmos1 and cmos2?  They have 
different names.  This is enough to tell the simulator to do an 
analog signal flow evaluation at the interface node.  The 
output of U1 is converted to analog according to cmos1 rules, 
then back to digital according to cmos2 rules.  You probably 
would not see the difference.

Now if we do...
.model cmos1 logic (vmax=2)
.model cmos2 logic (vmax=10)

Now, with the analog conversions, you would see that U1 never 
crosses the threshold, and it would correctly show you the 
problem.

Ok, you say,  that's why it should look at the supply...  But 
the node doesn't know about the supply.  To look at the supply 
changes the matrix stamp, essentially turning it into a KCL 
problem, with a big efficiency hit.


Going back ... if you look at some other standards, for example 
IBIS, they explicitly state voltages and waveforms.  So, there 
is a tradition that it a pure digital simulation the voltages 
are lost.


> The same thing I believe would be usefull for tanh function.
> Let me explain: I use a VCVS for modeling a opamp. for
> example: E1 3 0 1 2 tanh gain=10MEG limit=12. This line
> simulates a opamp (very simple) with an open gain of 10e6 and
> fed by +12V and -12V. (I thoght about other possible opamps,
> but it seems to be the most light, unless you know a better
> one.) The inverted input is note 2, non-inv. is node 1,
> output at node 3 and gnd at 0, of course. If it would be
> possible to write: E1 3 0 1 2 tanh gain=10MEG
> upperlimit=V(VCC) lowerlimit=V(VEE) it would be great! It
> would be possible to make a subcircuit for an opamp very
> simple, and, I belive, very light is terms of data
> processing:
>
> .subckt opamp OUT GND VCC VEE NINV INV
> E1 OUT GND GAIN=10MEG upperlimit=V(VCC) lowerlimit=V(VEE)
> .ends

That is much harder to do with this syntax than it looks.  There 
is a simple hack that would sort of work, but with poor 
convergence characteristics.  You might not notice.  When I put 
in the expression evaluator, this might actually work.

The problem with convergence is tracking all of the partial 
derivatives.  Some simulators just don't track them.  Sometimes 
it works, sometimes it doesn't.  When people do things that are 
weird they expect problems, so it gets by.

With Verilog-A, you can define modules that will have behavior 
like this.  That's why it is so important.


For now, if you can cope with something lower level, you can do 
this with the existing model compiler.  It is not well 
documented, because I want to replace it with one that takes a 
standard language (Verilog-AMS), and I don't want to delay it.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]