Re: [Iverilog-devel] Path delays simple, conditional and ifnone.

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

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

Cary R. wrote:
| --- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote:
|
|> | (in => out) = 1.5;
|> | if (cond) (in => out) = 1.8;
|> |
|> | will make the delay from in to out 1.8 when the condition
|> is true. If
|> you swap the order of the statements the delay is always
|> 1.5!
|
|> Actually, I think your example is perfectly legal and
|> useful.
|> It is possible to have multiple path delays for a given
|> output,
|> and in that case, assuming they are all activated at once,
|> the
|> output delay in use is taken to be the shortest--in this
|> case,
|> 1.5. In fact, in your specific case, it will as you say
|> always
|> be 1.5 unless SDF annotation changes the simple path delay,
|> which
|> is a possibility. So although on the surface it seems like
|> a
|> waste, back annotation can turn it into something
|> important.
|
| You misunderstood what I wrote! With the order shown the delay is 1.8
if you swap the order of the two statements you get 1.5 and why would
the smaller delay be correct? Depending on the situation the longer
delay could be the worst case. The reason this is happening is that when
the code is looking for a delay it uses the first it find which is
dependent on the order it is placed in the list. To me having this order
dependent is just plain wrong! I believe the conditional delays should
take precedence since they are more specific.

No, order should not be important, and it should collect all
the delay paths. At run time, when the "in" value changes,
all the possible paths are activated. If "cond" is true, then
both in your example are activated. Then the runtime will
choose the delay that is smallest. In your example, with the
paths not yet annotated, that is clearly 1.5. But if by annotation
the conditional path is given a delay of 1.1, then it will
be chosen instead.

If Icarus Verilog does anything other, then it is a bug.
But I think it gets this right.

|> (Remember, since all the numbers specified delays can be
|> replaced
|> by annotation, you can't use the numbers in the Verilog
|> source
|> to determine the validity of anything.)
|
| If you are not using annotation you can! Yes I understand back
annotation; remember I was one of the people pushing for it.


Well, yeah, but the compiler doesn't know that. Only the run-time
knows.

|> If the unconditional path were slower (i.e. 1.9) it would
|> be more
|> obvious that the conditional path is useful. Then you get
|> the
|> effect of the simple path acting like an ifnone path. But
|> then
|> again, if back annotation changes the time to be small, you
|> are back where you are now.
|
| Again I don't buy this. Why should the magnitude of the delay have
anything to do with which path to select? Annotation has nothing to do
with this problem.

Because "14.3.3 Delay Selection" in the -2005 LRM says so.

"The simulator shall [select a specify path to use] by first
determining which specify paths to the output are active. Active
specify paths are those whose input has transitioned most recently
in time, and either they have no condition or their conditions
are true. In the presence of simultaneous input transitions, it
is possible for many specify paths to an output to be simultaneously
active."

~  (In your example, both paths have the input "in" so if the
~  "cond" is true when "in" changes, both paths will become active.)

"Once the active specify paths are identified, a delay must be
selected from among them. This is done by comparing the the correct
delay for the specific transition being scheduled from each [active]
specify path and choosing the smallest."

~  (In your example, since both paths are active, at transition time
~  for "out" it will choose the smaller, "1.5", unless SDF has changed
~  the delays for the paths.)

|> So I see no problem here. There is a delay selection
|> algorithm
|> to handle the case of multiple active paths to an output at
|> a
|> given time.
|>
|> The ifnone syntax doesn't not allow for there also to
|> be an
|> identical unconditional path mostly as a matter of syntax.
|> Ifnone paths are allowed to be without a matching
|> conditional
|> path, in which case they are treated as an unconditional
|> paths
|> and will be visible to the SDF annotator as such.
|>
|> If there are multiple paths that are indistinguishable to
|> the
|> SDF annotator, then *that* is a problem and the symantics
|> *do*
|> disallow that. That is the rule to live by.
|
| I guess I need to look at the delay selection algorithm a little
closer, but I still assert that something is incorrect here. The
annotator multiple paths is the strongest argument for why you can't
have both a simple and a ifnone path delay (they look the same). Is it
safe to assume the annotator creates new modpaths if on does not already
exist?

Icarus Verilog elaboration will create a modpath for both the
paths in your example. The vvp will have a .modpath for both
the paths in your example and the "out" signal will scan them
both when it is time to transition in order to figure out what
delay to use for the transition.

The $sdf_annotate system task, or any other VPI for that matter,
can find those paths by matching the endpoints and conditions,
and can assign different delays to each modpath.

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

iD8DBQFIEMQcrPt1Sc2b3ikRAt3NAJ4wHSWY7BfEUlpnEyBOxA4UihrQrQCfWVhH
tdAhaMx/MC9wMB9pEY4MgcQ=
=tl8Z
-----END PGP SIGNATURE-----