Re: [Gems-users] Ruby-Opal interface

[Luke Yen <lyen@xxxxxxxxxxx>]

   In the context of the rubycache object the m_is_scheduled is set
whenever there are requests in the m_delayed_pool to be processed.  This
queue is inserted with requests that have not been inserted in the
m_request_pool queue, to try to simulate a full MSHR.  Note that this is
not exactly accurate because Opal does not stall the front-end on a full
m_request_pool queue.

  If the event queue is NULL, one can add a check in
simulate() in system/system.C, before or after calling advanceCycle() on
the processors, but before the advanceTime() Ruby call, like this:

     if(rubycache object's m_is_schedule == true){
        rubycache object->Wakeup()
     }

  Wakeup() is going to reset the m_is_scheduled, and might invoke
scheduleWakeup() again if there are more requests to be handled in the
m_delayed_pool.  Thus on the next iteration of the main simulation loop
the flag will be polled and might be true again.

   Luke

On Fri, 16 Sep 2005, Gilles Pokam wrote:

> Gilles Pokam wrote:
>
> >
> > Thanks for replying. Now I think I catch how it works. So, in case you
> > have a miss in Ruby, the pseq set the value of m_fetch_status to
> > PSEQ_FETCH_ICACHEMISS. Meanwhile, the request has been issued to the
> > L1 cache controller via the issueRequest function in Ruby, right ? At
> > completion, either one of write/read Callback function is invoked,
> > which in turn invokes the hitCallback and the Complete function in
> > rubycache ? This is where the wakeup function of the pseq is invoked,
> > changing the fetch status to ready, right ?
> >
> Still one more question. In rubycache.h, there is this comment stating
> that if the event queue NULL, the scheduler relies on the caller to poll
> the 'm_is_scheduled' variable to detect when 'Wakeup() should be called.
> Can you describe me an example of how I can make use of it ?
>
> Thanks.
>
> --
> Gilles
>