Menu
▾
▴
iverilog-devel
|
From: Cary R. <cy...@ya...> - 2008-04-24 01:58:52
|
I have started looking at implementing ifnone and in the process I'm looking at the various delay constructs to see exactly how they work. In doing this I ran into something that seems very strange. If you have both a simple path delay and a state dependent path delay. Depending on the order they appear in the specify block the state dependent delay can be missed. For example:
(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!
I have not found anything in the spec. that talks about how this should be resolved. I would expect the simple path delay to act like ifnone and only fill in cases that are not explicitly covered with a more specific conditional or it should be flagged as an error since you are double specifying some of the cases. The only clue implying that this may be legal is that in the ifnone description it mentions that it is illegal to specify both an ifnone and a simply (unconditional) module path. This would imply that ifnone and a simple path delay are identical in functionality and that we need to make the simple path delay or ifnone be a default that is used only if you cannot find an active path in the normal list.
Does the 2005 standard say anything more about this? Thoughts?
Cary
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
|
|
From: Stephen W. <st...@ic...> - 2008-04-24 15:20:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cary R. wrote: | I have started looking at implementing ifnone and in the process I'm looking at the various delay constructs to see exactly how they work. In doing this I ran into something that seems very strange. If you have both a simple path delay and a state dependent path delay. Depending on the order they appear in the specify block the state dependent delay can be missed. For example: | | (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! | | I have not found anything in the spec. that talks about how this should be resolved. I would expect the simple path delay to act like ifnone and only fill in cases that are not explicitly covered with a more specific conditional or it should be flagged as an error since you are double specifying some of the cases. The only clue implying that this may be legal is that in the ifnone description it mentions that it is illegal to specify both an ifnone and a simply (unconditional) module path. This would imply that ifnone and a simple path delay are identical in functionality and that we need to make the simple path delay or ifnone be a default that is used only if you cannot find an active path in the normal list. | | Does the 2005 standard say anything more about this? Thoughts? 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. (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 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. 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. - -- 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 iD8DBQFIEKUtrPt1Sc2b3ikRAmhhAJ998l89g7LTY0XHXhfUxuhNlMa4RACfaCn9 7ugs8Gx8aQ7TfW+4CIMZVXE= =Qfp6 -----END PGP SIGNATURE----- |
|
From: Cary R. <cy...@ya...> - 2008-04-24 16:18:26
|
--- 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.
> (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.
> 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.
> 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?
Cary
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
|
|
From: Stephen W. <st...@ic...> - 2008-04-24 17:32:15
|
-----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----- |
|
From: Cary R. <cy...@ya...> - 2008-04-24 17:56:35
Attachments:
ifnone.v
|
--- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote:
> 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.
OK we have a bug because it is giving different results depending on order!
The attached program gives different delay values depending on the order of the statements as shown the conditional paths are active. If the simple path delay is moved after the conditionals it overrides the value used no matter what.
Cary
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
|
From: Stephen W. <st...@ic...> - 2008-04-24 18:15:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cary R. wrote: | --- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote: | |> 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. | | OK we have a bug because it is giving different results depending on order! | | The attached program gives different delay values depending on the order of the statements as shown the conditional paths are active. If the simple path delay is moved after the conditionals it overrides the value used no matter what. Looks like the bug is in the selection process in vvp, in the vvp_fun_modpath::recv_vec4 method. It is selecting only 1 path and using that for delays. That is obviously wrong:-( Looks like something I should deal with. - -- 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 iD8DBQFIEM44rPt1Sc2b3ikRAnW6AJ942agw+qvQxsHHPGiRRt0gPYCRxACfRZZX oWiN+PSGAGw3NoijffIze3Y= =csA3 -----END PGP SIGNATURE----- |
|
From: Cary R. <cy...@ya...> - 2008-04-24 18:36:40
|
--- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote:
> Looks like the bug is in the selection process in vvp, in
> the
> vvp_fun_modpath::recv_vec4 method. It is selecting only 1
> path
> and using that for delays. That is obviously wrong:-( Looks
> like
> something I should deal with.
Sounds fine. If you are going to do this will you think about how you would like ifnone to fit into the mix. That will somewhat determine how I implement this in the compiler.
Cary
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
|
|
From: Stephen W. <st...@ic...> - 2008-04-24 19:14:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cary R. wrote: | --- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote: | |> Looks like the bug is in the selection process in vvp, in |> the |> vvp_fun_modpath::recv_vec4 method. It is selecting only 1 |> path |> and using that for delays. That is obviously wrong:-( Looks |> like |> something I should deal with. | | Sounds fine. If you are going to do this will you think about how you would like ifnone to fit into the mix. That will somewhat determine how I implement this in the compiler. All I will do is collect all the paths that have the same wake_time_. Currently, it is only saving 1 with the maximum wake_time_, so I'll have to find a way to list the matches instead of saving a single pointer. The condition is handled by the paths themselves managing the condition_flag_ member of the vvp_fun_modpath object. The actual delay then can quickly reject paths that are disabled by conditions. It would be nice if you can get the ifnone condition to manage that member as well. - -- 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 iD8DBQFIENwWrPt1Sc2b3ikRAsLFAJ9gEM+F3KiM9ZzYo2pus28huOqSuACgvpl8 65jMcSJBepV7bZN2GXXVrg8= =Q1Py -----END PGP SIGNATURE----- |
|
From: Cary R. <cy...@ya...> - 2008-04-24 20:48:26
|
--- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote:
> All I will do is collect all the paths that have the same
> wake_time_.
> Currently, it is only saving 1 with the maximum wake_time_,
> so I'll
> have to find a way to list the matches instead of saving a
> single
> pointer.
>
> The condition is handled by the paths themselves managing
> the
> condition_flag_ member of the vvp_fun_modpath object. The
> actual
> delay then can quickly reject paths that are disabled by
> conditions.
> It would be nice if you can get the ifnone condition to
> manage
> that member as well.
I was assuming the ifnone would fit in after the loop, so if src == 0 and you have an ifnone set src to the ifnone delay. Making ifnone handle a condition_flag_ seems overly complicated.
Cary
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
|
|
From: Stephen W. <st...@ic...> - 2008-04-26 00:20:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cary R. wrote: | --- On Thu, 4/24/08, Stephen Williams <st...@ic...> wrote: | |> No, order should not be important, and it should collect |> all |> the delay paths. |> If Icarus Verilog does anything other, then it is a bug. |> But I think it gets this right. | | OK we have a bug because it is giving different results depending on order! I've pushed a commit into git that should fix this. - -- 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 iD8DBQFIEnVNrPt1Sc2b3ikRAsYFAKCdexFvPorSMvehs12IPnX8IM0QBgCdH27C nhr+uMoPMC3MFMlh/VgJWFk= =vHHM -----END PGP SIGNATURE----- |
Thanks for helping keep SourceForge clean.
X