help-gnucap
[Top][All Lists]
Advanced

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

Re: [Help-gnucap] Flip-flop RS


From: al davis
Subject: Re: [Help-gnucap] Flip-flop RS
Date: Mon, 7 Aug 2006 01:01:15 -0400
User-agent: KMail/1.9.3

The digital portion has not been well tested recently.  The 
regression suite has only very sparse coverage.  Although I 
think it worked years ago, this part has really only 
had "student PhD project" level testing.  Part of what you 
report is bugs, with an easy fix.  Part is "correct" behavior.

On Friday 04 August 2006 08:29, Jose Roberto B. de A. Monteiro 
wrote:

> The DC simulation gave the result as follows:
> #           V(V2)      V(V3)      V(U1)      V(U2)
>   0.         0.         10.        5.         0.
>   2.         2.         10.        5.         0.
>   4.         4.         10.        5.         0.
>   6.         6.         10.        5.         0.
>   8.         8.         10.        5.         0.
>   10.        10.        10.        5.         0.
>
> Now the output have a numeric answer but is not as expected.
> If it is a CMOS type logic, the expected answer for V(U1) is
> 10V, like V1. 

This part is actually working as designed.  In digital mode, the 
value at a node is a logic state, not a voltage.  If you 
probe "logic(U1)" it will tell you the logic state which is 
coded as "3." which means "stable 1".

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.

> And, if V2 is 10V in the last line, V(U1) and 
> V(U2) should be both equal to 0.

This one is a bug.  If you look at the logic value, you would 
see that it changes to state 2, which is "falling", which means 
it is currently a 1, but a change to 0 is pending.  

The bug is that the actual change never happens.  I think this 
one was introduced a long time ago as a result of some other 
rework, but I am not sure just what or why.  It might have 
happened when code was converted from C to C++.

I didn't see it, because I have been doing mostly pure analog 
since then, and when used in true mixed-mode, it is common to 
have both analog and digital models of such a device.  The 
simulator would notice the issue with the digital only side, 
and use the analog model to determine what is really correct.  
In this particular circuit, you run 5 volt logic on 10 volts, 
which alone is enough to tell the simulator to use the analog 
model if it has one.

The fix is simple.  I will post it after a little more testing.

> I tried a simple simulation for a transient analisys but I've
> got a seg fault! The script is the following (the circuit is
> the same):

This one is a bug introduced recently as part of some efficiency 
improvements.  The "subckt" attachment was changed from an 
object to a pointer.  What was an empty subckt is now a null 
pointer, which needs to be checked.  Just checking for a null, 
and skipping the action if it is null, fixes the 
problem.  "dc_begin" has the correct code.  "tr_begin" doesn't.  
I will post it after a little more testing.

You can ignore the messages:
can't find subckt: CMOSnor2
U2: no model, forcing digital

They just tell you that since there is no analog model it is 
always using the digital model.

> Someone else tried to use a TTL subcircuit for the NOR gates,
> but he got a segfault too.

If there really is a subcircuit, he should not get the segfault.  
Just changing CMOS to TTL really doesn't change anything.  
Those names are just strings to the simulator, with no special 
meaning.



The next development snapshot will have documentation updates, 
Muntzing, and minor updates called for by formal testing.  No 
feature changes.





reply via email to

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