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

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

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


It looks like pr1652096 is going to cause me some real grief. The
root of the problem is that nets (the things that are visible to
VPI) are special functors, and in particular they are placed in the
vvp_net netlist as *receivers* of the data that flows through the
vvp_net network. Normally that is OK, but when some VPI code tries
to vpi_put_value to these vpi nets, the value goes into a spur of
the vvp_net netlist instead of into the net as a whole.

Variables work out differently because they are handled as drivers
in the vvp_net netlist, and so the netlist is built around them
appropriately. Wires cannot be handled that way because of the
tying together that is expected of a wire in a Verilog netlist.

It looks like I'm going to have to rework the handling of Verilog
wires so that they are not themselves nodes in the vvp_net netlist
but instead point to the place in an existing vvp_net. The problem
here is that force/release work on the nodes that represent wires.
This is obviously already a problem because there is a chance that
forcing a wire, like the vpi_put_value, may wind up forcing its
value into a spur of the vvp_net netlist. But if the vvp_net nodes
for wires are removed, then force/release are going to have to
work on general vvp_net nodes, and not just "wire" nodes.

Hmm...

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

iD8DBQFH2wzDrPt1Sc2b3ikRAjWNAJ41U5hJowvMHvOtXsBxehcCfmu+WACeLqCV
osLh2jQXANlZbB9R45Vjk+M=
=1R+9
-----END PGP SIGNATURE-----