notify() or notify(SC_ZERO_TIME)

[rahuljn]

Hi Expers

When I should use notify() and when notify(SC_ZERO_TIME)

Should I always use notify(SC_ZERO_TIME) to overcome threads indeterministics order ?

Is there some scenarion when I should strictly us notify() ?

Is there some scenarion when I should strictly us notify(SC_ZERO_TIME) ?

 

Thanks

RahulJn

[dakupoto]

Hi Expers

When I should use notify() and when notify(SC_ZERO_TIME)

Should I always use notify(SC_ZERO_TIME) to overcome threads indeterministics order ?

Is there some scenarion when I should strictly us notify() ?

Is there some scenarion when I should strictly us notify(SC_ZERO_TIME) ?

 

Thanks

RahulJn

Hello Sir,

Your questions are very broad. Please look up a good reference on SystemC

first for the detailed information.

[apfitch]

notify() makes a process runnable within the evaluation phase. So it can cause non-deterministic process execution.

You might use notify() when modelling something like multi-threaded software, because software does not have delta cycles.

 

notify(SC_ZERO_TIME) triggers on the next delta, which avoids some non-deterministic behaviour, and is closer to how languages like VHDL and Verilog work. Note that all runnable processes are still picked in an unknown order when choosing which process to run next in the evaluation phase.

 

regards

Alan

[c4brian]

Alan,

 

So you recommend using wait(SC_ZERO_TIME) in general, for most situations?

 

Let me ask you a question about the "runnable set".  If the wordage of any of the following is off, please let me know.

"The primary effect is that a process waiting for zero-time will resume after all runnable processes have yielded" _{p75 SystemC: From the Ground up}

Can the runnable set grow?

 

For example, lets say a blocking transport call performs

event.notify();

wait(SC_ZERO_TIME);

 

This places another process into the "runnable set".

Can this process also perform event notifications to continuously feed the "runnable set"?

[David Black]

Careful... if you always wait(SC_ZERO_TIME), then your simulation will not be able to progress time. If your simulation has no need of time, then this is fine. Usually I find that waiting for events or non-zero time serves best. wait(SC_ZERO_TIME) is for special situations when you know the information needed is in the current time, but be careful you don't lock out other processes that may need time to progress. One or two is fine, but if that is all you have then there are problems...

[apfitch]

Hi C4brian,

  no I don't recommend always using wait(SC_ZERO_TIME). I recommend understanding how the scheduler works, which I guess is what your aim is too!

 

The scheduler is well described in the LRM. A shortened description (ignoring lots of details) is

 

1. if there are runnable processes, execute them. ( a process that calls immediate notify here can make another process runnable at this point)

        repeat 1 until no more runnable processes

2. advance to evaluation phase

       update all primitive channels and events. A call to notify(SC_ZERO_TIME) here will cause you to go back to step 1 (execute another delta)

 

keep going round until there's nothing to do.

 

3. Advance time to the earliest future event

   go back to step 1

 

If there are no future events, end simulation.

 

So the answer to your last question is yes, calling notify() with no arguments during step 1, the evaluation phase, causes any process that was waiting for that event to become immediately runnable.

 

But as I said, the LRM is your friend,

 

regards

Alan

[c4brian]

Careful... if you always wait(SC_ZERO_TIME), then your simulation will not be able to progress time. If your simulation has no need of time, then this is fine. Usually I find that waiting for events or non-zero time serves best. wait(SC_ZERO_TIME) is for special situations when you know the information needed is in the current time, but be careful you don't lock out other processes that may need time to progress. One or two is fine, but if that is all you have then there are problems...

Hi David,

The model is untimed; the simulation time is never advanced.  I was started on SystemC a year and a half ago modelling this way, and it is all I know.  At the same time, I think it does make for a confusing mess if one doesn't understand the scheduler (I do now).  The models are primarily for a software team to bang their software against, however they are also used in a UVM environment with a DUT.  This complicates things further in regard to "time".  Our approach has been to use an untimed, functional SC model that is synchronized via the hardware by passing various synchronization transactions.

 

 

Hi C4brian,

  no I don't recommend always using wait(SC_ZERO_TIME). I recommend understanding how the scheduler works, which I guess is what your aim is too!

 

The scheduler is well described in the LRM. A shortened description (ignoring lots of details) is

 

1. if there are runnable processes, execute them. ( a process that calls immediate notify here can make another process runnable at this point)

        repeat 1 until no more runnable processes

2. advance to evaluation phase

       update all primitive channels and events. A call to notify(SC_ZERO_TIME) here will cause you to go back to step 1 (execute another delta)

 

keep going round until there's nothing to do.

 

3. Advance time to the earliest future event

   go back to step 1

 

If there are no future events, end simulation.

 

So the answer to your last question is yes, calling notify() with no arguments during step 1, the evaluation phase, causes any process that was waiting for that event to become immediately runnable.

 

But as I said, the LRM is your friend,

 

regards

Alan

 

Hi Alan,

 

I read the scheduler section of the LRM; you are right, this made everything much clearer.  I was relying on the kernel description in a single book, but it was not as comprehensive. 

My model is untimed, so the scheduler will spend its life hopping between the evaluation phase and the delta notification phase.  I think I will walk back through my design, as an example, and try to jot down the runnable set, etc, to fully understand what is happening with my newfound information.  Great suggestion btw.

 

Brian

[dakupoto]

Careful... if you always wait(SC_ZERO_TIME), then your simulation will not be able to progress time. If your simulation has no need of time, then this is fine. Usually I find that waiting for events or non-zero time serves best. wait(SC_ZERO_TIME) is for special situations when you know the information needed is in the current time, but be careful you don't lock out other processes that may need time to progress. One or two is fine, but if that is all you have then there are problems...

 

Absolutely true. In fact, using the wait- notify pair is tricky, because

one has to very carefully and manually track events. Also, if there 

are to many events waiting on events, funy things might happen

if some event is lost (e.g., event queue is full etc.,)

[FreeSourceC.com]

On 7/7/2014 at 4:24 PM, rahuljn said:

Hi Expers

When I should use notify() and when notify(SC_ZERO_TIME)

Should I always use notify(SC_ZERO_TIME) to overcome threads indeterministics order ?

Is there some scenarion when I should strictly us notify() ?

Is there some scenarion when I should strictly us notify(SC_ZERO_TIME) ?

 

Thanks

RahulJn

hope this information is useful to you

http://freesourcec.com/whats-the-diffrence-between-notify-and-notifysc_zero_time/