Re: [Gems-users] changing cache latency

["Mike Marty" <mikem@xxxxxxxxxxx>]

> These are not intended to model the network latency -- that was my
> point.  The network latency is modeled by links and switches between the
> core and the remote L2 module.
>

Right, they are intended to model the tag and access latency.

 
> The L2 hit latency will depend on the protocol.  You have to look at
> what transitions (and actions) occur on an L1 miss that hits in the L2,
> and see what latencies are inserted for each action.
> 

And the structure completely depends on whether you are using a SMP or CMP
protocol.  

> For example, consider the MOSI_SMP_bcast-cache.sm file.  Here's what I
> think happens:
> 
> (1) CacheRequest message reaches the head of the mandatory queue.
> (2) Controller determines that it's a load, and that the line is present
> in the L2 (but not in the L1D).  Therefore, it "triggers" an L2_to_L1D
> event (on the same cycle).
> (3) Let's suppose that the line is in state S in the L2.  The L2_to_L1D
> event causes a transition to the same state (S), but the side effect is
> to copy the block from L2 to L1D.
> (4) On the next cycle, the controller wakes up again, because there's
> still a message in the mandatory queue (since we didn't yet remove it).
> (5) This time, the controller sees that the line is in L1D in the right
> state, so it triggers a Load event.  This causes a transition to occur
> that handles a cache hit (i.e., calls the Sequencer.readCallback method,
> etc.) and pops the mandatory queue.
>

This is right, except for step (4), I think it will wakeup in the same cycle
because the wakeup() is a while loop until everything for that cycle is
processed.  

> Therefore, I believe (but am not absolutely sure) that the minimum L2
> hit latency would be 2 cycles -- one to transfer the data to L1, and one
> to handle the "hit" in L1.  (Could be more if there was a queueing delay
> in the mandatory queue...)  I hope the GEMS developers will correct any
> mistakes in my interpretation of the code.
> 
> The L2_*_LATENCY parameters don't come into play -- they are not used in
> any of the actions that handle this memory transaction.
>

Yes.  The L2_*_LATENCY parameters are used in the CMP protocols.  

To control the latency of a L2 hit in the SMP protocols, you need to set the
SEQUENCER_TO_CONTROLLER latency so that the step (1) latency above is what
you want the L2 hits to be.  Then L1 hits are handled by the "fast paths" in
the Ruby Sequencer.

But for the CMP protocols, the L1 and L2 controllers are separate, so the
SEQUENCER_TO_CONTROLLER latency should be lower.  

--Mike