Re: [Gnucap-devel] Problem with logic elements on transient simulation

[al davis]

On Monday 05 November 2012, Rupert Swarbrick wrote:
> I get the expected complaints about not having an analogue
> subckt model (fine), but also get two lines
> 
>   @@#
>   @@@unreachable:d_logic.cc:422:tr_accept

This is a bug.  That line should be, as it says, unreachable.

So, why is it there if it is unreachable?

Two simple answers, in general:
1. In some cases the compiler or a test tool requires it to 
avoid a warning or error message.
2. Maybe it isn't really unreachable, if there are bugs 
elsewhere in the code.  Think of it as a permanent assert that 
allows flow to continue.

In this case, both apply.

1. Good practice states that a switch must handle all 
possibilities.  If the argument is an enum, that means all 
possible values of the enum.  Then DO NOT use a default.  The 
compiler will warn if one is missing.  Similar reasoning applies 
in cases where gnucap code has an empty else.

2. In this case, that line represents a state change from a 
stable state to initial unknown, which should not happen.  If it 
does, there is something wrong somewhere else that caused it to 
happen.  That was the intent.  Looking at it today, I suspect 
that this statement I just made may be incorrect, that it IS 
possible for a real circuit to have a transition from a stable 
state to unknown.

> Hunting through the code, I think I've worked out what's
> going on. Switching on tracing (and commenting out
> bit-rotted lines so it would compile, grrr), I saw that this
> is caused when VCLK first goes high. This is attached to the
> S line of the SR latch and causes the various states to be
> recomputed. The new output of U1 becomes TRUE (this is "Q"),
> and the new output of U2 will become false. Unfortunately,
> the response U2 is computed before U1 for whatever reason.
> This would be fine, but the result is that U2 ends up with
> an indeterminate output again in d_logic.cc:tr_accept().

The logic algorithm is completely different from the analog 
algorithm.  One important difference is that changes in logic 
mode are not instantaneous.  If you change an input, it takes 
some time for that change to propagate to the output.  
Therefore, all logic evaluations are based on some previous 
time.  The delay is defined in .model xxxx logic "delay" 
parameter, which defaults to 1 ns.  This is why it appears that 
"the response U2 is computer before U1".

Also, all nodes have state "unknown" until driven to something 
else.  If you provide an analog model, whenever issues arise 
that lead to question of the digital results, gnucap will use 
the analog model to solve for the actual state.

If you look inside the subckt, you will see that node 4 never 
leaves the unknown state.  That's the bug.  The bug is that node 
"0" doesn't work in logic mode.

As a workaround, instead of tying that digital node to 0 
directly, tie it through a resistor.  Then the circuit works as 
expected.

> Questions
> =========
> 
> (1) Is this a bug? (I presume so, but thought I should
> check!)

Yes.  Any appearance of "unreachable" is a bug.  Any assertion 
failure is a bug.

> (2) Has anyone written down an explanation of how d_logic
> should work somewhere? I'd happily search for a fix, but it
> feels like I'm stumbling around in the dark a little bit.

My Ph.D. dissertation?

> (3) Is this going to be irrelevant if/when upcoming
> VHDL/Verilog work gets merged?

Somewhat.  This code needs to be reworked, but the basic design 
remains the same.  What will change is that some of the code 
will move to plugins.  In particular, the details of the 
conversion will be in a plugin.  Verilog calls this a 
"connectmodule".

In this code, gnucap is the first simulator to properly 
implement the semantics of a connectmodule, with automatic 
insertion, long before it became part of the Verilog-AMS 
standard.

What will change is just that this becomes a plugin, making it 
user definable.  As it stands there is only one connectmodule.

> Not quite on the same topic:
> 
> (4) Is there an "official" development repository? I am using
>     git://github.com/savvy2020/gnucap.git, but this is just
> imports of various snapshots. And the most recent
> non-git-related change is from 2009(!)

I still use RCS.  There has not been a gathering of changes 
since 2009.  The plan was (and still is) to convert to GIT after 
a refactoring of the code.  This almost happened early 2010, but 
then some other matters made it so I couldn't finish it or get 
much of anything done for a couple of years.





> 
> 
> Many thanks for any help,
> 
> Rupert