Sensitivity list

[h_narasimhan]

In a SC_METHOD which is triggered by multiple signals in a sensitivity list, is it possible to find out automatically which signal among the list has asserted, i.e without polling for each signal's value ? 

[Philipp A Hartmann]

You can query the event() function of the signal, to check whether it has been triggered in the previous update phase (see IEEE 1666-2011, 6.4.9).  Of course, multiple signals might have been updated even though your process is only invoked once.

 

Greetings from Oldenburg,
  Philipp

[dakupoto]

You can query the event() function of the signal, to check whether it has been triggered in the previous update phase (see IEEE 1666-2011, 6.4.9).  Of course, multiple signals might have been updated even though your process is only invoked once.

 

Greetings from Oldenburg,

  Philipp

Very true. But as each of SC_METHOD, SC_THREAD and the older SC_CTHREAD all tied

to the underlying OS's thread scheduler, this information would be uncertain ? As you have

rightly pointed out that multiple signals might get updated on the same event, so in that case

which is the first amongst equals.

[Philipp A Hartmann]

Very true. But as each of SC_METHOD, SC_THREAD and the older SC_CTHREAD all tied

to the underlying OS's thread scheduler, this information would be uncertain?

 

 The OS scheduler has nothing to do with the SystemC process scheduler.  SystemC uses a custom, cooperative scheduler following the simulation semantics as defined in IEEE 1666-2011:  Only one SystemC process is guaranteed to run at all times.  Even if SystemC processes might be implemented as OS threads, their scheduling is enforced to follow the SystemC rules.

 

 

As you have rightly pointed out that multiple signals might get updated on the same event, so in that case which is the first amongst equals.

 

You can't tell.  All of them are "equal".  Whether or not this is sufficient for the original poster's use case depends on his/her requirements.

 

/Philipp

[dakupoto]

 

 The OS scheduler has nothing to do with the SystemC process scheduler.  SystemC uses a custom, cooperative scheduler following the simulation semantics as defined in IEEE 1666-2011:  Only one SystemC process is guaranteed to run at all times.  Even if SystemC processes might be implemented as OS threads, their scheduling is enforced to follow the SystemC rules.

 

 

 

You can't tell.  All of them are "equal".  Whether or not this is sufficient for the original poster's use case depends on his/her requirements.

 

/Philipp

Thanks for correcting my misconception.