Re: [Gems-users] some queries about MOSI_SMP_bcast

[Mike Marty <mikem@xxxxxxxxxxx>]

> I was trying to better understand the workings of the
> MOSI_SMP_bcast protocol and have a couple of
> questions.
>
> What exactly happens when a request is recycled on the
> network queue i.e. action zz_recycleMandatoryQueue in
> MOSI_SMP_bcast.sm.
>

Recycling a request pops it from the head of the queue and places it at
the end of the queue, and schedules a wakeup in case the controller
doesn't wake up the next cycle anyways.  Essentially recycling a request
allows our queues to be non-FIFO and allows one request for cache line to
block while others are serviced.


> What parameter can be used to limit the number of
> outstanding cache requests?
>

The number of requests issued to the memory system can be controlled by
the g_SEQUENCER_OUTSTANDING_REQUESTS parameter.  However the L1 cache
controller itself can control how many MSHRs are available with the
NUMBER_OF_TBES parameter.


> What is the equivalent of the mshr in ruby?
>

a TBE.  Each protocol will have a TBETable in the cache controller.

> Finally unrelated to the MOSI_SMP_bcast protocol - are
> there any SMP protocols which are part of your release
> which can handle retry requests?
>

We've certainly implemented Nack/Retry directory protocols before.  But it
doesn't appear that the SMP protocols we include with the release do this.

The token coherence protocols retry requests.