Re: [Gems-users] about transition behaviors

[Greg Byrd <gbyrd@xxxxxxxx>]

> Yes. I haven't checked this specific call chain, but just want to 
> mention that ruby does get woken up every SIMICS_RUBY_MULTIPLIER (or 
> OPAL_RUBY_MULTIPLIER if using opal) cycles. Search for 
> "runRubyEventQueue" (for ruby+simics) and "OpalInterface::advanceTime" 
> (for opal+ruby+simics).
Ruby wakes up (i.e., checks the event queue), but that doesn't mean that 
a particular component (e.g., L2Cache) wakes up.  If there are no events 
on the Ruby event queue, the wakeup for a particular component will not 
be invoked.
You need to be careful about transitions in your class (4) -- those that 
leave the message on the incoming queue.  This does not stall anything.  
The wakeup routine asks again and again whether that port has an 
available message, and it will say yes again and again.  Eventually, the 
limit of actions allowed during a single wakeup will be reached, and the 
simulator will move on to another component.  Input ports are handled in 
the order in which they are specified in the SLICC file.  So if you do 
this in the first in_port, then the incoming response message (on 
another port) might never be seen, and you might cause a deadlock.  
That's one reason for doing a recycle with a non-zero latency, rather 
than simply leaving the message on the buffer.  (I added a "block" 
capability to the MessageBuffer for this case.  If a port is blocked, 
then isReady() returns false, and the simulator moves on to the next port.)
It's very instructive to look at the wakeup method for your component in 
ruby/generated/<protocol>/<component>_Wakeup.C.
...Greg