Jump to content

Using sc_event_or_list to set static sensitivity of spawned processes


karthickg

Recommended Posts

Hello,

 

To allow setting static sensitivity of dynamically spawned processes to an or'd list of sc_events, I expected to see a method like:

void sc_spawn_options::set_sensitivity(const sc_event_or_list *);

but do not see any such. next_trigger and wait however, do accept a reference to sc_event_or_list, so it appears to be inconsistent? For, dynamic sensitivity can use sc_event_or_list, but not static sensitivity..

 

I suppose we can't use sc_event_or_list to set the static sensitivity of statically spawned threads either (created using SC_THREAD/SC_METHOD) - but that is not my need.

 

Further, there doesn't seem to be any way to retrieve the list of sc_event from an sc_event_or_list (as, say, std::vector<sc_event *>). If that was possible, then I could have called the set_sensitivity(const sc_event *) method repeatedly, for all events in the or'd list.

 

Any help appreciated, thanks.

Link to comment
Share on other sites

Hello,

 

To allow setting static sensitivity of dynamically spawned processes to an or'd list of sc_events, I expected to see a method like:

void sc_spawn_options::set_sensitivity(const sc_event_or_list *);

but do not see any such. next_trigger and wait however, do accept a reference to sc_event_or_list, so it appears to be inconsistent? For, dynamic sensitivity can use sc_event_or_list, but not static sensitivity..

 

I suppose we can't use sc_event_or_list to set the static sensitivity of statically spawned threads either (created using SC_THREAD/SC_METHOD) - but that is not my need.

 

Further, there doesn't seem to be any way to retrieve the list of sc_event from an sc_event_or_list (as, say, std::vector<sc_event *>). If that was possible, then I could have called the set_sensitivity(const sc_event *) method repeatedly, for all events in the or'd list.

 

Any help appreciated, thanks.

Hello Sir,

Please note that for all static processes the data elements/structures and associated

kernel operations are determined at the time of elaboration, before simulation. On the

other hand, everything related to dynamic processes is determined at runtime. So how

would the simulation kernel create a sensitivity list for something that does not exist at

the time of elaboration ?  There appears to be some confusion here.

Link to comment
Share on other sites

Hello Sir,

Please note that for all static processes the data elements/structures and associated

kernel operations are determined at the time of elaboration, before simulation. On the

other hand, everything related to dynamic processes is determined at runtime. So how

would the simulation kernel create a sensitivity list for something that does not exist at

the time of elaboration ?  There appears to be some confusion here.

Hello,

 

Thanks for your reply - after seeing which, I had to go back to the standard to check to ascertain what is allowed and what is not.. My understanding is as below..

 

Quoting from the specification:

 

 

5.2.14 sensitive

sc_sensitive sensitive;
This subclause describes the static sensitivity of an unspawned process. Static sensitivity for a spawned
process is created using member function set_sensitivity of class sc_spawn_options (see 5.5).
...
Static sensitivity shall only be created in the body of the constructor, in the before_end_of_elaboration or
end_of_elaboration callbacks of a module, or in a member function called from the constructor or callback,
and only after having created an unspawned process instance within that same constructor or callback. 

 

So - what you have written certainly applies to unspawned processes.

 

For spawned processes,

 

void set_sensitivity( const sc_event* );

void set_sensitivity( sc_port_base* );
void set_sensitivity( sc_export_base* );
void set_sensitivity( sc_interface* );
void set_sensitivity( sc_event_finder* );
Member function set_sensitivity shall set a property of the spawn options to add the object passed
as an argument to set_sensitivity to the static sensitivity of the spawned process, as described for
operator<< in 5.4.4, or if the argument is the address of an export, the process is made sensitive to
the channel instance to which that export is bound. If the argument is the address of a multiport, the
process shall be made sensitive to the events returned by calling member function default_event for
each and every channel instance to which the multiport is bound. By default, the static sensitivity is
empty. Calls to set_sensitivity are cumulative: each call to set_sensitivity extends the static
sensitivity as set in the spawn options. Calls to the four different overloaded member functions can
be mixed.

 

The only question that remains is, can set_sensitivity be called on processes spawned after start of simulation? I'm not able to find an explicit yes or no in the specification, however there is an example (page 66) that shows that set_sensitivity can be called after start of simulation.

Link to comment
Share on other sites

Sure, set_sensitivity can be called after the start of the simulation.

 

And yes, there are no overloads to use sc_event_and/or_lists for static sensitivity, mostly for historical reasons (and limitations in some implementations).

 

But why not simply use them with dynamic sensitivity?  Simply store (a copy of) the event list in your module and use wait( event_list ) instead of a plain wait() inside your spawned process.

 

hth,
  Philipp

Link to comment
Share on other sites

Sure, set_sensitivity can be called after the start of the simulation.

 

And yes, there are no overloads to use sc_event_and/or_lists for static sensitivity, mostly for historical reasons (and limitations in some implementations).

 

But why not simply use them with dynamic sensitivity?  Simply store (a copy of) the event list in your module and use wait( event_list ) instead of a plain wait() inside your spawned process.

 

hth,

  Philipp

Hi Philipp,

 

Thanks, I was curious to know why the standard doesn't implement set_sensitive for spawned processes, and your response clarifies that.

 

The issue is not so much about having to use "wait(event_list)" instead of just "wait()" - that is not a disadvantage at all (for me). The main problem is different..

 

My design requires a spawned method to set a boolean flag (say, m_flag) whenever a certain event (say, m_event) fires. This can be easily done:

// Where the method gets spawned

sc_spawn_options opt;
opt.set_sensitive(m_event);
opt.dont_initialize(); // Note!
opt.spawn_method();

sc_spawn(sc_bind(&my_module::flag_event, this, some_var), NULL, &opt);

// ....

// Method body:
void my_module::flag_event(int some_var)
{
   m_flag = true;
   next_trigger();
}

However, if the method has to wait for sc_event_or_list, then set_sensitive can't be used, and so dont_initialize can't be used. The flag_event has to now distinguish between the invocation at start of simulation, and the subsequent invocations when an event in the or'd list fires:

sc_spawn_options opt;
opt.spawn_method();
m_did_initialize = false; // Note!
sc_spawn(sc_bind(&my_module::flag_event, this, some_var), NULL, &opt);

// ....

// Method body:
void my_module::flag_event(int some_var)
{
   if(m_did_initialize) {
      m_flag = true;
      next_trigger(m_event_or_list);
   } else {
      m_did_initialize = true;
      next_trigger(m_event_or_list);
   }
}

This is just plain clumsy to read, and needs an extra if-check every time the method gets invoked. I can think of a way to eliminate the if-check at simulation time: by having one more spawned method, but that is even more clumsy code; not worth the run-time cost (in my case).

 

So I guess I do not have any alternative here. Thanks for your inputs anyway.

Link to comment
Share on other sites

I think it would be fairly straight-forward to add an sc_event_or_list overload to set_sensitivity, as it would just be expanded and appended to the set of events the process is statically sensitive to.  For symmetry reasons, users would certainly want to have an sc_event_and_list overload as well, but this "mixed expression" sensitivity is currently not easy to add (e.g. to the proof-of-concept implementation) and nobody cared enough to propose an implementation.

 

I agree that in your case there is some additional burden to work around this limitation.

 

/Philipp

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...