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

[Cary R. <cy...@ya...>]

--- Stephen Williams <st...@ic...> wrote:

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

I must confess that this net stuff is still a bit opaque to me, so I don't
have much to add except I would ask that you look at some of the other
limitations we currently have in this area and see if they all in
aggregate suggest a solution. Off the top of my head the other limitations
I can remember are multiple output support, net delays (from SDF files),
net traversal from the PLI. I'm sure there are more, but I'll leave
finding them as an exercise for the reader.

My rational for this approach is since you are already making significant
changes to this section of code you might as well fix everything you can.
The amount of code you need to understand/relearn is about the same.
That's where I am with expressions (it all started with an implementation
for **). Months later my primarily focus is still fixing problems in the
compiler expression code.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ