"crash" branch ..... ... supplies a test case where when compiled with debugging an assert fails, but it runs when asserts are disabled.
It's a known deficiency in the algorithm. The circuit is a gate that is overclocked. The propagation model used is not valid when features of the input are faster than the delay in a gate. It is not known what a real circuit would do. The failed assert probably could be commented out. Not removed, but commented out. A commented out assert means "this really should be true, but sometimes it isn't". Since it is overclocked, there is a logic transition here from a known state to an unknown state. "set_in_transition" marks a node as being "in transition", which is somewhat ambiguous intentionally. It is in the process of making a state change, but hasn't completed yet. So here, it is already "in transition", and now you hit it again. Normal logic states .. we have the stable "logic 1" and "logic 0", and the transitional states "rising" (changing from 0 to 1) and "falling" (changing from 1 to 0). Supplying an analog model for the gate would probably result in a correct simulation. In "mixed" mode, gnucap would switch to the analog model to deal with this. In "digital" mode, or in almost any gate level logic simulator, you can't be sure what it is. Considering all that, it really does work as well as can be expected in this case. The analog voltage at 8n looks like a glitch, but when the state is "unknown", what is the correct voltage? This is a known issue. The time step control for the logic device needs work. I don't have time to do it now. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
