Re: [Iverilog-devel] The tranif1 test is not right?

[Evan L. <sa2...@cy...>]

Stephen Williams wrote:

> Every argument claiming that the tranif1.v test is "correct" has
> so far relied on some hysteresis or capacitance or memory in the
> switch for it to work.

Mine doesn't. "tranif.v" is correct because it models a real 
transmission gate, and the simulator is responsible for applying any 
appropriate bodge to make this so. The LRM doesn't, I think, say how 
this bodge works, but Steven Sharp *does* say in the post I quoted (see 
below). There's a good chance that XL and NC both do what Steve S says.

First off, the bodge is nothing to do with drivers and driver 
resolution. You can't model a transmission gate using drivers, because 
there's *no* driver in a transmission gate; it's just a 
voltage-controlled resistive element.

Martin quotes 11.6.5:

> "Switch processing shall consider all the devices in a bidirectional 
> switch-connected net before it can determine the appropriate value for any 
> node on the net because the inputs and outputs interact."

But this is just a get-out; it says nothing about *how* the inputs and 
outputs interact, or how any combination of drivers could model a 
resistive element without interfering with each other or locking up. I 
don't buy it as an explanation of how tranif works.

Back to Steve W:

> But how can that memory be justified, or
> modeled.

The memory is justified because tranif is described as a "bidirectional 
pass switch", and the simulator needs to make that happen.
Steve S gives a more complex model in the post I quoted. Ben Cohen also 
gives VHDL models for a resistor and a switch in his FAQs book (pages 
160 and 178), which are conceptually similar to Steve S's; Ben puts in 
break-before-make switches at each end of the resistor. This is what 
Steve S says in:

http://groups.google.co.uk/group/comp.lang.verilog/browse_frm/thread/282f1cb11335752d/fe2d15e1bfb5f697?hl=en&q=tranif1+sharp+group:comp.lang.verilog#fe2d15e1bfb5f697

> You have described a fundamental problem in implementing transmission gates.
> A simulator can do this for a tran gate by splitting the connected nets into
> separate parts.  The tran gate passes through the value of the net before
> the contribution from the tran gate.  All other readers of the net get the
> value of the net after the contribution of the tran gate.  You can't do this
> yourself, because you have no way to split the net without having to use
> two explicit nets.  The closest you can get to a behavioral version of
> 
>         tranif1 (A, B, control);
> 
> would be
> 
>         module my_tran(A_in, A_out, B_in, B_out, control);
>           input A_in, B_in, control;
>           output A_out, B_out;
> 
>           assign A_out = A_in;
>           assign A_out = control ? B_in : 1'bz;
> 
>           assign B_out = B_in;
>           assign B_out = control ? A_in : 1'bz;
> 
>         endmodule
> 
> and connect other outputs on A to A_in and other inputs on A to A_out.
> If you have any other inouts on A or B, you need an even more complex
> splitting of the nets.  You just never realized how much work you were
> making the simulator do for you when you used a tran. 

Note that 'control' is a reader of the net, and it gets "the value of 
the net after the contribution of the tran gate". Consider what happens 
when A_in and control are both 1, and A_in is then driven with Z:

1 - the first driver on A_out drives Z

2 - the value of control used in the second A_out driver is the *old* 
value of A_out (1), since A_out hasn't been resolved yet; the second 
driver therefore contributes B_in, or 1

3 - A_out resolves to 1, so control remains at 1

Basically, you just do whatever's necessary to get a transmission gate. 
I think this is pretty much what Steve W said here:

> You see, the test is relying on a delta delay between an assignment
> of Z to the pin and the tranif enable gates responding. 

So Icarus presumably worked before the recent tranif changes because the 
delta delay did the same job.

-Evan