I've something similar to following pseudo code:
for (lets say 10 iterations)
begin
// Do some configuration changes
fork
begin
///apply input to design
end
begin
while (1)
/// at particular point update expected status / values
end
begin
while (1)
/// read status and verify with expected values
end
join_any
end
From code: only application of input can break fork, since other 2 threads are working under while (1) I want to disable all threads between each iteration of for i.e. once stream of input is applied -- disable all spawned threads until next iteration starts (with new configuration)
so I modified above code to
....
join_any
disable_fork
end
However this seems to disable for loop as well / or something similar which I don't understand but effect is test is hung up. Can someone explain me the reason and solution?
"disable fork" kills not only the processes launched by your fork...join_any, but also any other processes that are descendants of the same process that executes the disable-fork. If you have launched any other processes (using, for example, fork...join_none) earlier in the life of this process, then those other processes will be killed too.
You can rather easily protect against this by causing your fork...join_any, and its later disable-fork, to run in a new child process of its own. This limits the effect of your disable-fork so that it can affect only the newly launched processes that you care about, and is guaranteed to have no other unwanted effects.
Do this by enclosing the whole mess in "fork begin...end join" like this:
fork begin // isolate the following code as a single child process
fork // launch the processes you wish to manage
apply_input();
update_status();
verify_status();
join_any // kill off the *_status threads when apply_input terminates
disable fork;
end join // end of child process isolation
This is a well-known issue with fork...join_any and fork...join_none. It's been discussed recently on Verification Guild forum, and is described in sections #79 and #80 of the Sutherland and Mills book "Verilog and SystemVerilog Gotchas".
Putting "fork begin" and "end join" on single lines is unusual, but I like it as a way to make it very obvious that I'm synchronously forking exactly one child process. Normally that would be a useless thing to do, but in this situation it's essential.
This idiom is so common, and so easy to get wrong, that you may prefer to encapsulate it in a pair of macros (I don't like this, but...):
`define BEGIN_FIRST_OF fork begin fork
`define END_FIRST_OF join_any disable fork; end join
Now you can write...
`BEGIN_FIRST_OF
apply_input();
update_status();
verify_status();
`END_FIRST_OF
where the names "...FIRST_OF" are intended to reflect the similarity to the Specman (e) language construct that does the same thing.