Re: [Iverilog-devel] Potential rework of nets/wires support in VVP

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
> 
>> Add to that switch level modeling such as tranif* and rtran*. These
>> are odd devices in that they are bidirectional. The resistive
>> devices in particular escape me. (I was kinda holding off on resistive
>> transistors to see if the problem goes away when AMS support gets
>> figured out.)
> 
> Once we have multi output gates, or maybe that should be multi inout
> gates, implementing these should not be too hard to code. If you were to
> do multi output gates I would think implementing a multi output buffer and
> one of the rtran gates would be enough to allow someone else to build the
> rest. Is it the need or the implementation that is escaping you?

It is the implementation that is escaping me. I'm not even clear
how a rtran resolves its inputs and generates it outputs.

> Unless you are hoping that a future version of Verilog-D removes these
> gates we still have missing functionality. 

We have missing functionality. Even if Verilog-D does drop them,
I have delusions of Verilog-AMS in the future and I suspect similar
problems will turn up there.

>> I think that net delays can be understood in term of vvp_net nodes.
>> In particular, one can find ways to attach delays between drivers
>> of nets and the nets themselves. It may be possible to handle this
>> in the elaborator by propagating the net delays to the delays of
>> all the driving expressions, but putting a .delay node in place
>> is probably the best way of handling it. Specify delays for module
>> ports are handled this way.
> 
> Basic net delays may be that simple, but the ones from a SDF file are
> certainly not. As I remember it, net delays can be unique from any driver
> to any receiver, so they cannot be implemented by just inserting simple
> delays at the driver and/or receiver. So there are two net delay concepts,
> one which is a single constant value specified in the language and the
> other is provided in the SDF file which is likely not matched to a net
> that was defined to have a net delay in the source Verilog file. To me
> this implies that net delays need to be fundamental to the net handling
> code.

That kind of complexity is already handled by the existing delay
objects. Multiple specify path objects feed into a given delay
node, and they are in turn used to calculate the given delay for
logic that flows through the delay.

>> Actually, the vvp_net infrastructure inside vvp is probably the
>> cleanest and easiest to understand aspect of the vvp runtime:-)
> 
> I guess that shows how little I have looked at it.



- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH3TeErPt1Sc2b3ikRArguAJ9vnOmYita4kMzttH6h7PQcy9Pz7gCcDpKH
Yy36Nlf/3k2+fGDAkf3xCDI=
=eU5k
-----END PGP SIGNATURE-----