[Gnucap-devel] "crash" branch

[al davis]

"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.