Menu
▾
▴
iverilog-devel
|
From: Cary R. <cy...@ya...> - 2008-04-18 20:57:24
|
I have been thinking about this for a while and here is what I have come up with so far. We need to add a new attribute to the P* objects 'has_delay' that the always command can use to print a warning if the block appears to not have some kind of delay.
The default object type will be no delay. Delay, non-blocking assignment and wait statements will return true. An if or switch statement will only return true if there is a delay in all paths. We don't know the logic so this is the safest choice. Except for a repeat with a constant positive value, loops always return false for the same reason (they may not run). The repeat mentioned above will only return true if it contains a statement that has a delay. Task calls (tasks) and blocks return true if one of their items returns has a delay.
It could be argued that a forever or a while with a constant true value should also return true, but using them inside an always seems dubious at best.
For the delay elements we should probably check that the delay is not zero. This should be easy for a constant value. For variable delays I think we just have to trust that the user is doing the right thing and assume the delay is greater than zero.
Does this make sense? Am I missing anything. The message will be a warning that the always block could create an infinite loop.
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-18 21:20:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This sounds intriguing. I think this attribute would better be attached to the NetProc base class because a thorough check for the warning will get better information from elaborated results. For example, elaboration of a process will include precomputing constant expressions and that may allow catching infinite for- and while-loops. Also, task definitions will be available as elaborated NetProc objects. I would sat that non-blocking assignments have zero delay, by the way, because they do not block execution. I think you mean that blocking assignments with internal delays should return has_delay of true, because they do have delay, and they pause the thread. By the way, this handling can also be used to detect the erroneous case of a user defined function that *has* a delay. This is illegal but currently it is not detected and reported. Cary R. wrote: | I have been thinking about this for a while and here is what I have come up with so far. We need to add a new attribute to the P* objects 'has_delay' that the always command can use to print a warning if the block appears to not have some kind of delay. | | The default object type will be no delay. Delay, non-blocking assignment and wait statements will return true. An if or switch statement will only return true if there is a delay in all paths. We don't know the logic so this is the safest choice. Except for a repeat with a constant positive value, loops always return false for the same reason (they may not run). The repeat mentioned above will only return true if it contains a statement that has a delay. Task calls (tasks) and blocks return true if one of their items returns has a delay. | | It could be argued that a forever or a while with a constant true value should also return true, but using them inside an always seems dubious at best. | | For the delay elements we should probably check that the delay is not zero. This should be easy for a constant value. For variable delays I think we just have to trust that the user is doing the right thing and assume the delay is greater than zero. | | Does this make sense? Am I missing anything. The message will be a warning that the always block could create an infinite loop. - -- 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 iD8DBQFICRCbrPt1Sc2b3ikRAkE9AKDUjoUtzFxECDy7QozGJ6O+RUBCigCgkJl9 cNpL10Hn7Z4QmHIvDQ8vz4Y= =8fAa -----END PGP SIGNATURE----- |
|
From: Cary R. <cy...@ya...> - 2008-04-18 21:30:09
|
--- On Fri, 4/18/08, Stephen Williams <st...@ic...> wrote:
> I would sat that non-blocking assignments have zero delay,
> by
> the way, because they do not block execution. I think you
> mean
> that blocking assignments with internal delays should
> return
> has_delay of true, because they do have delay, and they
> pause
> the thread.
Yes that is correct!
> By the way, this handling can also be used to detect the
> erroneous case of a user defined function that *has* a
> delay.
> This is illegal but currently it is not detected and
> reported.
If we give has_delay a pessimism flag this could work. An always wants to be conservative (always has a delay). While the function definition wants to be pessimistic (find any delay).
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-19 00:55:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cary R. wrote: | | | --- On Fri, 4/18/08, Stephen Williams <st...@ic...> wrote: | | |> I would sat that non-blocking assignments have zero delay, |> by |> the way, because they do not block execution. I think you |> mean |> that blocking assignments with internal delays should |> return |> has_delay of true, because they do have delay, and they |> pause |> the thread. | | Yes that is correct! | |> By the way, this handling can also be used to detect the |> erroneous case of a user defined function that *has* a |> delay. |> This is illegal but currently it is not detected and |> reported. | | If we give has_delay a pessimism flag this could work. An always wants to be conservative (always has a delay). While the function definition wants to be pessimistic (find any delay). Or have it return an enum with a range: ~ NO_DELAYS = 0 ~ NO_KNOWN_DELAYS = 1 ~ KNOWN_DELAYS = 3 - -- 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 iD8DBQFICUMFrPt1Sc2b3ikRAsSxAJ9kypou/yKyE3CjECLWOvEyHmcbywCgiRak rtGGjvlqR4a1fZOSnbsIgAo= =NWsW -----END PGP SIGNATURE----- |
|
From: Cary R. <cy...@ya...> - 2008-04-19 01:35:27
|
--- On Fri, 4/18/08, Stephen Williams <st...@ic...> wrote:
> Or have it return an enum with a range:
>
> ~ NO_DELAYS = 0
> ~ NO_KNOWN_DELAYS = 1
> ~ KNOWN_DELAYS = 3
If this is the route I go I think it should be NO_DELAY, POSSIBLE_DELAY and DEFINITE_DELAY. I think the code will be cleaner if we pass a control flag vs checking both possibilities and combining them correctly. Can you think of a case where we would need to know the three different states?
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-19 17:14:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cary R. wrote: | --- On Fri, 4/18/08, Stephen Williams <st...@ic...> wrote: | |> Or have it return an enum with a range: |> |> ~ NO_DELAYS = 0 |> ~ NO_KNOWN_DELAYS = 1 |> ~ KNOWN_DELAYS = 3 | | If this is the route I go I think it should be NO_DELAY, POSSIBLE_DELAY and DEFINITE_DELAY. I think the code will be cleaner if we pass a control flag vs checking both possibilities and combining them correctly. Can you think of a case where we would need to know the three different states? Your names are much better, yes. Well, if you pass a control flag to the calculation of this state, then you are implying that it is calculated on demand, possibly multiple times (and possibly no times) whereas if you just calculate the more expressive value, then you can reuse the value for different needs. (Again, perhaps you need it zero times.) My sense is that if every always statement is going to need this value, then it is going to be needed almost always, and might as well be calculated during elaboration. It strikes me that it will be very easy to calculate during elaboration, skipping the need for a post-process recursive test later when the data is needed. It can be that the expressive enum value be hidden behind a pair of boolean methods that the clients use, so this method if calculating the expressive value can have any reasonable interface. Hmm, I'm thinking about where this information may be used, and I'm starting to realize that only NO_DELAY is useful. If you have an always statement, you want to generate a warning if it IS NO_DELAY, and if the NetProc is a function definition you want to generate an error if it is NOT NO_DELAY. - -- 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 iD8DBQFICih4rPt1Sc2b3ikRAiyIAKDkfent8Ca/HJPFQ1x0Ao+KNH955gCfUZU7 UUMXHy+nzO2GU0L/GQi60lI= =7uuP -----END PGP SIGNATURE----- |
|
From: Cary R. <cy...@ya...> - 2008-04-19 22:23:14
|
--- On Sat, 4/19/08, Stephen Williams <st...@ic...> wrote:
> Well, if you pass a control flag to the calculation of this
> state,
> then you are implying that it is calculated on demand,
> possibly
> multiple times (and possibly no times) whereas if you just
> calculate
> the more expressive value, then you can reuse the value for
> different
> needs. (Again, perhaps you need it zero times.)
For the always I think it should be calculated each time since the delay could change for each instantiation of the module.
> My sense is that if every always statement is going to need
> this
> value, then it is going to be needed almost always, and
> might as
> well be calculated during elaboration. It strikes me that
> it will
> be very easy to calculate during elaboration, skipping the
> need
> for a post-process recursive test later when the data is
> needed.
If we make this part of the general elaboration then initial blocks will also do the calculations and my feeling is that there are far fewer always block. I would also guess that always blocks are in general simpler.
> It can be that the expressive enum value be hidden behind a
> pair
> of boolean methods that the clients use, so this method if
> calculating
> the expressive value can have any reasonable interface.
>
> Hmm, I'm thinking about where this information may be
> used, and
> I'm starting to realize that only NO_DELAY is useful.
> If you have
> an always statement, you want to generate a warning if it
> IS
> NO_DELAY, and if the NetProc is a function definition you
> want
> to generate an error if it is NOT NO_DELAY.
This isn't quit correct. NO_DELAY is correct for a function, but you want to print a warning for an always that has either no delay or may possible have delay. I was reflecting earlier and this probably would need to be a four state value. No delay, zero delay, possible delay and definite delay. A function definition can only have no delay and an always will not complain only when you definitely have delay. No and zero delay are definite infinite loops and possible delay may be an infinite loop.
I have build some basic infrastructure using NetProc and friends. I'm thinking that the four state method is the correct way to go so we can reuse the basic code for both the always and function checks. I think the function definition checks can cache their check state, but I think the always blocks need to be checked each time. Think about the following:
#<param_value>
This could be different for each module instantiation and when zero we would have a looping problem. Not matter what the value this is illegal in a function definition.
Cary
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
|
|
From: Cary R. <cy...@ya...> - 2008-04-21 17:32:55
|
A quick update on this.
I have the basics working. I am assuming a forever and while with a constant true expression should also check for infinite loops. I still need to add function and task call statements and the switch statement which is just an extended conditional still need to be coded. I also have a couple questions about how the indeterminate messages should be displayed.
Should we make the indeterminate case, may be an infinite loop, only display a message when the appropriate -W (inf_loop) flag is given? Do we want this included in the -Wall case? My guess is that we probably do not since this is a possible warning not a true problem that should be fixed. It's the limitations of the checks that is preventing us from making a true determination of the state. I do not believe we should try to truly determine this either. There is way too many things that would need to be looked at and evaluated for a minimal return.
Once this is completed we will need to have an explanation on the wiki that covers how to interpret what a possible infinite loop means. It may also be nice to have a small section in the manual that gives the basics.
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-21 17:39:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cary R. wrote: | A quick update on this. | | I have the basics working. I am assuming a forever and while with a constant true expression should also check for infinite loops. I still need to add function and task call statements and the switch statement which is just an extended conditional still need to be coded. I also have a couple questions about how the indeterminate messages should be displayed. | | Should we make the indeterminate case, may be an infinite loop, only display a message when the appropriate -W (inf_loop) flag is given? Do we want this included in the -Wall case? My guess is that we probably do not since this is a possible warning not a true problem that should be fixed. It's the limitations of the checks that is preventing us from making a true determination of the state. I do not believe we should try to truly determine this either. There is way too many things that would need to be looked at and evaluated for a minimal return. | | Once this is completed we will need to have an explanation on the wiki that covers how to interpret what a possible infinite loop means. It may also be nice to have a small section in the manual that gives the basics. We should warn too little, and not too much, I think. We've all gotten tired of vendor tools printing warning/info files that are bigger then the source being compiled, so let's not go there;-P And yes, while loops with constant true expressions are exactly the same as always statements as a whole, so have the potential to make just as much of a mess. - -- 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 iD8DBQFIDNFcrPt1Sc2b3ikRAi3xAJ9slh8zcKhTeVNT4E1zK4vHQkSG2wCg50nV ecGRL1C9kzcHCR1SIyuGtLs= =eEJv -----END PGP SIGNATURE----- |
|
From: Cary R. <cy...@ya...> - 2008-04-21 17:50:49
|
> We should warn too little, and not too much, I think.
> We've all
> gotten tired of vendor tools printing warning/info files
> that are
> bigger then the source being compiled, so let's not go
> there;-P
OK I will add a -Winf_loop flag that will not be part of the basic -Wall. The code will fail to evaluate if it can definitely determine that an infinite loop will occur. You can use -Winf_loop to look for possible infinite loops if you encounter one in the runtime and need help in tracking the problem down.
Cary
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X