Re: [Iverilog-devel] Questions about modpath::recv_vec4()

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

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

Cary R. wrote:
| I am working on the final integration of ifnone and have a few
questions concerning vvp_fun_modpath::recv_vec4().
|
| If the current modpath wake time is less than now why is it being
processed? I believe it should have already been scheduled. Ignoring
this in the first for loop means the candidate list only has active
candidates and simplifies the code greatly.

The wake_time_ is the simulator time when the modpath received its
input, so is by definition before (or exactly at) "now". The "for"
loop that scans through the 12 delays is calculating the specified
output time based on the wake_time_ (the input time) and the 12 delays.
Some delay times may be before now, and some may be after now.

The early "for" loop (the one that is building the candidate_list)
is using the wake_time_ for the path to figure out if it is a
candidate delay *path*. It is not yet looking at actual delays. Only
the latest *enabled* modpath is used to make up the specified delays
for this output, so this loop is scanning all the specified paths
looking for the active one[s]. There may be multiple paths with the
exact same wake_time_, so there may be multiple active paths, but
we don't know which paths are active until we look at the wake_time_
for all of them.

Once the paths are selected, we are no longer interested in the
activation time (the wake_time_) but the output time. Calculate that
from the wake_time_ plus the delays. This gives us the output time,
which may be after now (the most common case) or before now if there
were distributed delays between the input and this output. If there
are multiple active paths (by definition with the same wake_time_)
they are all combined by selecting only the smallest delay (for each
of the 12 edges) from the selected candidate paths.

After all that, we have the output time (not the delay) and that is
what the scheduler wants to know.


| Why is the code redefining the candidate list when it finds an object
with a future wake time? Is this some kind of rudimentary pulse control?
This redefinition seems to be counter to the use minimum delays edict
"Delay selection".

In that first "for" loop it is looking for the path that was activated
the latest. Note that the wake times are *before* now. This loop is not
calculating the delays, it is selecting the activated *paths*. The
delays are calculated in the later loops. The minimum delays edict only
comes into play if there are multiple candidate specify paths, and that
can only happen if multiple modpath objects have the same wake_time_.

| Some of the set_delays() routines in netlist.cc seems to be different
than table 39 (1364-2001 page 103) and table 48 (1364-2001 page 225).
Did the 2005 standard change the rules on these? These table also appear
to have some inconsistencies.

I don't think there were any rule changes.

- --
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 v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIFmh+rPt1Sc2b3ikRAhJvAKC6avN2tArHVd0lS8EVsJoNeN9m7wCgo2TD
5qDPJJZEiEZKlwnWzL3/kHA=
=uc1r
-----END PGP SIGNATURE-----