iverilog-devel

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

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 

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

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

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.

Actually, the vvp_net infrastructure inside vvp is probably the
cleanest and easiest to understand aspect of the vvp runtime:-)
- --
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

iD8DBQFH2/QLrPt1Sc2b3ikRAjCTAJ0V64KzvJ/ogtxUINznj5zv4ren1QCgymms
lUU5OlZ+fWOriiSsc/QIWuw=
=Pddy
-----END PGP SIGNATURE-----

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

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

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

Unless you are hoping that a future version of Verilog-D removes these
gates we still have missing functionality. 
 
> 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.

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

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

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

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

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

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

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

I'm not sure if this is feasible or not, but would tagging the propagating
signal with the source help (a pointer to the driver object)? Only the
tran/rtran gates would retag a signal and would only propagate signals
they did not send. There is still the possibility of multiple gates
creating a loop, but that problem already exists. As a bonus, having a
usable tag would also allow us to print error messages that could point to
the driver when something goes wrong.

So something like this: the tran receives a signal on inout1 it retags the
signal making it the driver and sends the modified signal to the net
connected to inout2. It will receive a signal back on inout2, but since it
is the driver of this signal it will be ignored.
 
> > 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.

Yes, at the digital-analog interface you could have the same problem. 
 
> 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.

I didn't realize the existing delay objects were that powerful.

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs