Forked process behaves differently with/without delay in the process. Without delay simulation is halting otherwise it is smooth (Checker vs Monitor Queue)

SystemVerilog
, , ,
1

Please help me understand the following behaviour related to fork-join_any.

In my environment I have a fork-join_any for the processes:

fork
generator.main();
driver.main();
input_mon.main();
output_mon.main();
checker.main();
join_any

There are two implementation for checker.main(). Both the version only differ from the presence of #10 delay statement within the forever. Following is the code:

task main();
    transaction mon1_trans; 
    transaction mon2_trans; // output monitor
    forever
      begin
        #10; //I inserted a delay here for every iteration. In my another version of this code : this delay is removed.
        $display ("the number of generated and monitored transactions are %dand%d ", mon2check.size(), driv2check.size() );
        wait(mon2check.size() > 0);  //This mon2check is a queue which is filled by the output monitor.
        if(mon2check.size() > 0)
          begin
            if(driv2check.size() > 0)
              begin
                $display ("WE have both the monitors filled up to hve atleast one element");
                mon2check.pop(mon2_trans);
                driv2check.pop(mon1_trans);
                ...
                ...
               end
            else
              begin
                $display("The input monitor is empty");
              end
          end
      end
endtask

So I am facing an issue here - when I don’t add the delay (#10) above in the code - Ideally this task waits for the mon2check size to be greater than 0. This queue gets updated parallelly in the output_mon.main() task (forked with the checker.main()). But though the queue shows that the data is getting filled up , here it just keeps on waiting and the simulation stalls here.

But When I add this delay of #10 - it works perfectly. ****

**What could be the mistake I am doing … Can someone help me to understand if I am missing something.
**

2

In reply to kb646bits:

Your problem may be when mon2check.size is >0, but drive2check.size is not >0, you get into a zero delay loop and there is no opportunity for any other processs to add to the drive2check queue. You need to wait(both to be >0).

3

In reply to dave_59:

Thanks Dave,

I added the wait condition for both of them - but now it just unblocks once , but after that it stalls on the second wait call even though the queues are filling up in the monitor classes. Somehow the mon2check value is not being updated in the checker class.

But when again I give a delay between each iteration of the forever block say #10 - It works.

4

In reply to kb646bits:

You are not showing enough code that would help solve your problem. You need to make sure the forever loop does not execute in a zero delay loop. When that happens, no other code has an opportunity to execute.