wait() vs wait(SC_ZERO_TIME)

[mohitnegi]

my issue is -

i am calling b_transport from my initiator which is writing a register in target model ...a process in target model is waiting for the event which is generated when that register is written  ...then there is wait(SC_ZERO_TIME) which is sync the initiator thread and target thread...

Now when i have e.notify() in register the target process is starting immediately but when i am using e.notify(SC_ZERO_TIME) [which is usually recommended ] the target process is not starting immediately but after in next evaluation phase which i check by applying two wait(SC_ZERO_TIME)  ...

 

What is the reason for such behavior ???

[David Black]

SystemC processes operate in a manner known as cooperative multi-tasking. This is common to event driven simulators such as VHDL, Verilog, SystemVerilog, SystemC, etc. It means that until a process decides to voluntarily yield, the process may execute for as long as it likes. Yielding in SystemC means calling the SystemC wait() function. So if you have some code actively executing in an SC_THREAD or SC_METHOD process, it can issue multiple event notifications and do all sorts of b_transport calls without allowing other processes to execute. Only when you call wait() will the other processes be allowed to execute. In their turn, they get the same privilege.

 

This is quite different from processes and threads in a modern OS, which operate pre-emptively. The operating system gives each process or thread a certain amount of time, and interrupts the execution of the process or thread when that time is up.

 

The reason cooperative multi-tasking was chosen for event driven simulators is to simply issues in coding. If pre-emptive scheduling were adopted, then a lot of extra work would need to be done to ensure safe communications between processes (which multi-tasking software programmers have to deal with all the time).

[mohitnegi]

SystemC processes operate in a manner known as cooperative multi-tasking. This is common to event driven simulators such as VHDL, Verilog, SystemVerilog, SystemC, etc. It means that until a process decides to voluntarily yield, the process may execute for as long as it likes. Yielding in SystemC means calling the SystemC wait() function. So if you have some code actively executing in an SC_THREAD or SC_METHOD process, it can issue multiple event notifications and do all sorts of b_transport calls without allowing other processes to execute. Only when you call wait() will the other processes be allowed to execute. In their turn, they get the same privilege.

 

This is quite different from processes and threads in a modern OS, which operate pre-emptively. The operating system gives each process or thread a certain amount of time, and interrupts the execution of the process or thread when that time is up.

 

The reason cooperative multi-tasking was chosen for event driven simulators is to simply issues in coding. If pre-emptive scheduling were adopted, then a lot of extra work would need to be done to ensure safe communications between processes (which multi-tasking software programmers have to deal with all the time).

thanks David for the detailed response ...

 

but could you give a simpler to my question as i have some difficulty in relating this answer with my question...

 

and another thing is it advisable to use e.notify(SC_ZERO_TIME) as far as possible ...

[c4brian]

Hi Mohit,

 

I'm working on understanding these topics as well currently.  I am working on something very similar to what you described. 

 

After you set the register value, issuing an e.notify() I believe is identifcal to e.notify(void) which is an "immediate notification".  This doesn't mean any threads waiting on this event start running, it just means they are placed into the "runnable set for execution" (p73 systemC: from the ground up).  Therefore whenever your b_transport releases the thread, the "target process" will start running.

 

If you do a e.notify(SC_ZERO_TIME), aka "delayed notification with a time of 0", any processes waiting on this event will only execute after all processes in the "runnable set" have been executed.  Long story short, the "target process" is not placed into the runnable set at the time of the notification.  Once your b_transport releases the thread for the first time,  i.e. wait(SC_ZERO_TIME), it completes the current runnable set, then places the "target process" into the runnable set. 

 

Now your second wait(SC_ZERO_TIME) will kick off the target process.

 

This exact topic is discussed on page 75 (notify(SC_ZERO_TIME)).  It discusses it's merits over notify(void) for a selected scenario (when a process could miss an event).

 

In your scenario I dont believe you can miss the event, so notify(void) seems more appropriate.

 

brian

[susharmas]

Hello Mohit,

 

May be below mentioned is useful for you:

 

e.notify(SC_TIME_ZERO) is called when all the runnable process is emptied. It is called delayed notification. In other words, process waiting for delayed notification are set to runnable only after all the runnable process are done.

wait(SC_TIME_ZERO): A process waiting for zero time will resume its execution after all the runnable process have yielded. Then that process will be next in queue for runnable.

notify(void): It may cause one or more process in the waiting set to be moves into the runnable set.

wait(void): This lets the thread to use the static sensitivity, and control goes to the next clock cycle.

 

Regards

Sunil Sharma