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. _______________________________________________ Help-gnucap mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnucap
