Fork join_none abruptly terminates

SystemVerilog
, ,
1

I have a function as below in a child class

function void func_a();
    sample_dut_signal(0);
endfunction

function void func_b();
    sample_dut_signal(1);
endfunction

function void sample_dut_signal(bit sel);
  fork
   begin
    if(sel)
     parent.sample_signal_aa();
    else
     parent.sample_signal_bb();
   end
  join_none
endfunction

Parent class is as follows:

task sample_signal_aa();
  #(5000ns);
  $display("Done with wait");
  //....code to sample
endtask

The issue is that most of the times the code works but certain times I will never see the display and tells me that the thread spawned off by the child has abruptly ended. I am not sure what is exactly going on. Can someone throw some light?

2

Not really enough code shown. Did you put a display before the #(delay)?
Are you using disable fork anywhere?

3

There is no disable fork anywhere in the child or parent.
The functions ‘func_a’ and ‘func b’ in the child class are called by events in the class. the events are well separated in time so there seems to be no contention. I did add a print before the $display and it prints as expected but dont see the print after the delay.

Funny thing is for events that happen after this failure of the fork, it again seems to work fine.

4

The disable fork doesn’t have to be in the class, just in the process that calls these functions. Without seeing any code, I’m just taking guesses.

5

So to give you a gist since the code base is pretty big.

There is a trigger function that is wrapped in a fork join_none . Lets call this function ABC.

ABC->DEF ->XYZ-> func_a and func_b (called in a sequential steps) → then the task ‘sample_signal_aa’ is called.

The original fork join_none also does not have a disable fork statement.

6

Not enough code shown to help. Learn to use your tools interactive debugger to step through the code.

7

No problem. I found the issue. it was a ‘disable fork’ like you said that caused it. funny thing is that this disable-fork was in a monitor component that was sending a transaction to one of my uvm_components that was spawning the above thread.