static and dynamic sensitivity

[amitk3553]

Hello all,

 

Could somebody explain the difference between dynamic and static sensitivities of processes in SystemC with some example.

 

 

 

Thanks Regards

Amit Kumar

[David Long]

Hi Amit,

 

A process has static sensitivity if it contains one or more calls to wait(). The sensitivity is set before the simulation starts running, usually be using "sensitive" in its parent module's constructor.

 

Dynamic sensitivity is where a process contains one or more calls to wait(a_time_value) or wait(a_named_event). It is dynamic because the conditions that cause a thread process to wake up change as each wait statement is executed when the simulation runs.

 

Here is a very brief example (not tested):

 

SC_MODULE(mod) {
  sc_in<bool> clk;
  sc_event e;
  void proc1() {
     wait();  //static sensitivity
     e.notify();
  }
void proc2() {
  while(1) {
    wait(e);  //wait for event (dynamic)
    //do something
    wait(1,SC_NS);  //wait for time (dynamic)
    //do something
  }
  SC_CTOR(mod) {
     SC_METHOD(proc1);
     sensitive << clk.pos();   //static sensitivity
     SC_THREAD(proc2);     //no static sensitivity, runs during initialization until 1st wait reached
 }
};

 

You can find further details in section 4.2 of the SystemC LRM (1066.2011).

 

Regards,

Dave

[amitk3553]

Then whats about wait() and next_trigger()?

 

Using wait() for static and dynamic both and next_trigger() for dynamic sensitivity??

[David Long]

wait() with no arguments is only used for static sensitivity

 

next_trigger() has similiar functionality to wait() but is only used within sc_method processes, while wait() is only used within sc_thread processes. The main difference is that sc_methods cannot consume time (wait is illegal) so next_trigger (with an argument) overrides any static sensitivity to control when the sc_method will next be called (after it has completed). There might be multiple calls to next_trigger in the same sc_method - the last one to be executed before the function returns is the one that sets the sensitivity for the next call.

 

Regards,

Dave

[amitk3553]

wait() with no arguments is only used for static sensitivity

 

next_trigger() has similiar functionality to wait() but is only used within sc_method processes, while wait() is only used within sc_thread processes. The main difference is that sc_methods cannot consume time (wait is illegal) so next_trigger (with an argument) overrides any static sensitivity to control when the sc_method will next be called (after it has completed). There might be multiple calls to next_trigger in the same sc_method - the last one to be executed before the function returns is the one that sets the sensitivity for the next call.

 

Regards,

Dave

 

wait() with no arguments is only used for static sensitivity

 

next_trigger() has similiar functionality to wait() but is only used within sc_method processes, while wait() is only used within sc_thread processes. The main difference is that sc_methods cannot consume time (wait is illegal) so next_trigger (with an argument) overrides any static sensitivity to control when the sc_method will next be called (after it has completed). There might be multiple calls to next_trigger in the same sc_method - the last one to be executed before the function returns is the one that sets the sensitivity for the next call.

 

Regards,

Dave

Thanks Dave

 

next_trigger is also appearing like delay element??

Please more elaborate the operation of next_trigger() with some example..

 

 

 

Regards

Amit

[David Long]

Hi Amit,

 

I would not say that next_trigger is "like a delay element" since it does not hold up execution of an SC_METHOD (which would be illegal). It overrides the static sensititivity of an SC_METHOD and so changes the conditions which next cause the method to execute. There is an example on page 51 of the LRM.

 

Regards,

Dave

[karandeep963]

Hi Amit,

 

I would not say that next_trigger is "like a delay element" since it does not hold up execution of an SC_METHOD (which would be illegal). It overrides the static sensititivity of an SC_METHOD and so changes the conditions which next cause the method to execute. There is an example on page 51 of the LRM.

 

Regards,

Dave

Hello Dave,

 

Please elaborate:

 

void proc1() // SC_METHOD process

{

---------------

--------------

-------------

next_trigger(x);

}

 

void proc2() // SC_THREAD process

{

while(true){

-------------

wait();

-------------

event.notify (x);

   }

}

 

 

Consider the case that proc2 executes before proc1.

 

proc1 & proc2 has static sensitivity @ pos.clk.

 

So if considering section 5.2.10 of IEEE Std 1666-2011 LRM which states "A method process instance may have static sensitivity. A method process, and only a method process, may

call the function next_trigger to create dynamic sensitivity". 

 

Now the question is does the proc1 after the 1st execution cycle , be sensitive to event x not to clk for rest of the time?????

 

or does it triggers for the same clk twice ???

 

 

Regards, 

KS

[David Long]

Hi KS,

 

By default, proc1 runs once during the initialization phase (unless dont_initialize() is called immediately after SC_METHOD(proc1) in the module constructor).

Once proc1 has executed, the next_trigger statement changes its sensitivity so that from then on it will be called whenever event x is notified, not when clk has an event.

 

Regards,

Dave

[jenjel]

Hi everybody, 

 

i'm using a sc_method which i want to be triggered once one of the input ports value changes. With a static sensitivity list, the result is that is triggered 2 times in the same moment because 2 of the input ports values have changed. i tried with a dynamic sensitivity list using the next_trigger method with as arguments a combination with "|" between input_ports.value_changed_event() but it returns the same thing. Someone can suggest me a solution to do that plz ? 

 

Regards, 

Seif

[dakupoto]

Hello,

Please note that all thread control/manipulation depends on

the thread scheduler of the underlying OS. Also, note that the

use of 'wait - notify' pairs is good mostly for simple cases. In

a reactive system with lots of events, each triggering a different

action, using 'wait - notify' pairs would lead to much misery,

as the programmer has to correctly track through the code,

which 'wait' corresponds to which 'notify'. In such cases, 

using static sensitivity is much more reliable, because at

the core, which thread is going to get activated at a given

time, depends totally on the thread scheduler. Also, to best

get a grip on how these things work, it is best to create a

few test examples, compiling and running them, and then

carefully analysing the results. Often times it will be seen

that the generated results are somewhat contrary to what

was anticipated. Hope that helps.

 

[dakupoto]

Hi everybody, 

 

i'm using a sc_method which i want to be triggered once one of the input ports value changes. With a static sensitivity list, the result is that is triggered 2 times in the same moment because 2 of the input ports values have changed. i tried with a dynamic sensitivity list using the next_trigger method with as arguments a combination with "|" between input_ports.value_changed_event() but it returns the same thing. Someone can suggest me a solution to do that plz ? 

 

Regards, 

Seif

 

Hello,

When you say "2 of the input ports values have changed" it appears your are

using a sensitivity list like: sensitive << x << y; /* x, y -- trigger ports */

Instead, have you tried something like : sensitive << x ; 

that is sensitize it to just one port ? Or is it the case that because of constraints

of the problem, you have to sensitize the same thread to both the ports at the

same time ?

Also as a "|" is an OR operation, and since you say 

"because 2 of the input ports values have changed" using dynamic sensitivity

is not going to be of much help. Rather, why not break your thread into two,

and then trigger one of the two on the first port, and other on the second port.

Now, if both both port values change at the same time, both threads will

react, if not one of the two will. But then you have complete control over

your model as each thread reacts to one port change only.