A note on processes and fine grain control

In system verilog fork join block blocks the execution of the parent class until all the process in the fork join are completed. System verilog provides two more keywods join_any and join_none are provided which can be used when we wish to continue with the parent process execution eventhough the currently spawned threads are not completed. join_any waits until any one of the spawned processes to complete where as join_none wait for nothing.

A return statement within the context of a fork...join statement is illegal and results in a compilation error.

SV also provides key words wait fork and disable fork keywords to wait for all the processes are completed for the executing the code after the wait fork. disable fork is to disable all the processes that are active and also the decendents of the processes.

One more advantage of SV is we can do Fine-grain process control i.e.,we can wait,kill,suspend,resume and know the state of a perticular process for individual processes.

LRM states:

A process is a built-in class that allows one process to access and control another process once it has started.

class process;
enum state { FINISHED, RUNNING, WAITING, SUSPENDED, KILLED };
static function process self();
function state status();
task kill();
task await();
task suspend();
task resume();
endclass

Objects of type process are created internally when processes are spawned. Users cannot create objects of type
process; attempts to call new shall not create a new process, and instead result in an error.

Call the 'self()' method of process class in the thread to be monitored and
then assign it to the process class object.

.status gives the status of the process.
= process::self()is like newing the object.
.kill will kill the process
.await will wait until that process is completed.


References:
SV LRM

following solvenet articles
https://solvnet.synopsys.com/retrieve/025657.html
https://solvnet.synopsys.com/retrieve/025656.html?otSearchResultSrc=advSearch&otSearchResultNumber=2&otPageNum=1

I got an interesting paper on different regions of a simulation time in SV.
They explained about every detail of all the different regions.
The system verilog is devided into 17 regions 8 of them are for execution of PLI code and rest are executing system verilog statements.
The nine regions are divided into 5 event region sets Preponed event region, Active event region, Observed, Reactive region set, Postponed event region.
Preponed event region: preponed region is executed once in a time slot and it will sample the values to be used in assertions. This region is read only and no assignments are done. the actual assignment can be in the postponed region of the previous time slot or the preponed region of current timeslot.
Active region: This region is to evaluate the blocking,non-blocking assignments in the module. This is having three sub regions in it. Active,Inactive, NBA. The active sub-region is for evaluating the RHS of non-blocking assihnments,executing all $finish,$display function and execution of blocking statements. Inactive region is for #0 delay statement scheduling. NBA sub region is for eveluating the non-blocking statements in the module.
Observed region: This region is for evaluating the concurrent assertions with the values sampled in preponed region.
Inactive region:This is similar to Active resion the only difference being in this region we will evaluate program block assignments.
Postponed event region: functionality of this region is for executing $strobe and $monitor regions and to collect functional coverage values of signals which are sampled using $strobe.

For further reading one can refer the following pdf:

http://www.sunburst-design.com/papers/CummingsSNUG2006Boston_SystemVerilog_Events.pdf

well well its working
we had all functions(copy,psdisplay....) of VMM_DATA in all our vmm_data extension classes instead now we are using vmm macros (`vmm_data_member_scalar(variable,DO_ALL).....)and our TB is reduced to half its original size.
One can refer VMM standard library user guide version1.12 page A-148.
but i am not sure if i do it for classes using `vmm_data_member_handle(handleof a class,DO_ALL) do the handle i use should always be of a class which is derived from VMM_DATA?I have given a handle of a class which i defined which is not extension of VMM_DATA its giving null object access . Need to check on this.