Support disabling blocks containing forks #6514
Conversation
The disables in that are all to exit the loop, they should be becoming JumpGo's and shouldn't ever get std::process added. Maybe you are adding std::process too soon? Likewise the altera READER. |
|
This happened when I merged handling of two cases into one: 029bf3e, which was required to make the test antmicro@80ba0e3 pass. |
7a61f8a to
e7a8c05
Compare
|
I implemented the solution I proposed. |
| if (!v3Global.hasForks()) { | ||
| // No forks in the user code, so can be handled in simple way | ||
| // by jumping to the end of the named block | ||
| AstJumpBlock* const blockp = getJumpBlock(beginp, false); | ||
| nodep->addNextHere(new AstJumpGo{nodep->fileline(), blockp}); |
There was a problem hiding this comment.
This will break if there's a fork far removed in the sources from the jump/disable. We still want jump/disable to work as previously in small modules.
I think the rule should be record the block name when we see it and set a flag. Clear the flag if we see a fork. If we get here and see same block name, and no fork, then error. Else fine to just jump.
There was a problem hiding this comment.
I think that if we have at least one fork in the source code inside a function and at least one function call inside our block then it is hard at this stage to know if some fork is spawned in our block, because functions aren't linked yet.
There was a problem hiding this comment.
I don't understand. The disables I'm talking about are how "break" statements had to be coded before Verilog had "break". If the user had used "break" instead then this code would have worked, correct? So how does not converting such a disable to Jump make a difference? I suspect you will say the difference is if such a loop calls a task, that disable needs to disable a fork that was spawned inside a function in such a loop. I think that's true, but I think the loop itself can become still a "JumpGo", with the disable becoming a "disable all but my own loop". Then if there are no forks that becomes a nop. The important thing is we don't want common disables in loops that are just "breaks" to become non-loops, this will be very performance harmful.
There was a problem hiding this comment.
I suspect you will say the difference is if such a loop calls a task, that disable needs to disable a fork that was spawned inside a function in such a loop. I think that's true, but I think the loop itself can become still a "JumpGo", with the disable becoming a "disable all but my own loop".
It is true and it works that way after my changes. The jump is inserted in handleDisable function: https://github.com/antmicro/verilator/blob/e7a8c054930fe819a4e5fde94688dead900a9ded/src/V3LinkJump.cpp#L222-L224.
There was a problem hiding this comment.
I think we still have the case where previously a task had a block and disable (which worked previously), and a completely separate fork without disable (which worked previously), and now this will break. I suspect this is is reasonably likely on any 1995 code. Maybe we need the analysis of which functions could be called from a fork? Other ideas?
There was a problem hiding this comment.
I thought about it. The problem is that our handling is in V3LinkJump and at that stage functions aren't linked yet, so we can't check which function calls which.
There was a problem hiding this comment.
Add a new node node in V3LinkJump, then later when know the whole picture can either delete it and will act like previously, or flag the error.
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
Signed-off-by: Ryszard Rozak <[email protected]>
e7a8c05 to
c8cb4a6
Compare
|
If you think this is ready please merge in master, fix conflicts, and let me know and will give it another review pass, thanks. |
|
What is left to do is what you proposed in the comment. I stopped working on this PR, because I need to focus on other things. I will come back to it later. |
It adds support for disabling blocks that contain forks, but aren't inside forks themselves.
The handling is similar to the ones of previous cases. For each
disablestatement a queue ofstd::processis created which contains processes that entered into the block to which thedisablestatement points to. Thedisablestatement is replaced with the call ofdisableForkon each element of the queue and a jump to the end of the block.Currently, the test I temporarily committed gives wrong results: antmicro@80ba0e3. It is because it enters into this case: https://github.com/antmicro/verilator/blob/7a61f8a55fb5d429273a8119f498512c1acd1fa7/src/V3LinkJump.cpp#L426-L430 (even on master). I wanted to merge this case with the case above (which I added in this PR), but it broke a few tests. Some of them started requiring the
--timingflag and at least one failed because the usage ofstd::processwas added to the function that is used on the RHS of the parameter assignment and as a result, that function stopped being constant. This test is https://github.com/verilator/verilator/blob/7d4e5595d06fe971449eb17faeef4f8628549fe1/test_regress/t/t_unroll_nested_param.v.Another thing that I committed and reverted is throwing
UNSUPPORTEDwarning ondisablestatement pointing to a block that is inside a function. In such a case we can't detect if that function is called inside a fork and if it is, it will be handled wrong. It broke existing tests, such ast_altera_lpm_ram_dp, because its code containsdisablepointing to a block that is inside a task:verilator/test_regress/t/t_altera_lpm.v
Line 280 in 7d4e559
These two problems exist currently on master, I just found them during the work on this PR. Do you have any idea what to do with them? The best thing that comes to my mind is to restore my reverted commits, but use the old handling in case when no forks are present in the user code.