Re: [Gems-users] some queries about MOSI_SMP_bcast


Date: Thu, 23 Jun 2005 19:24:03 +0100 (BST)
From: Brinda Ganesh <brinda_ganesh@xxxxxxxxx>
Subject: Re: [Gems-users] some queries about MOSI_SMP_bcast
Hi Mike

I'm basically integrating our dram simulator framework
into gems. I integrated our simulator into the
MOSI_SMP_bcast cache coherence protocol. It all works
except when the dram system cannot handle a request
and asks the cache hierarchy to retry it later. I
currently have a bad hack to handle this but was
looking to see if any of the SMP protocols handle
retrys.

You had mentioned in your email that you had built SMP
protocols in the past which handled acks etc. Would it
be possible for you to send me a version of these
protocols? It would definitely help me in my
integration process. 

Thanks 
Brinda

--- Mike Marty <mikem@xxxxxxxxxxx> wrote:

> > 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.
> 
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
>
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> 



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
[← Prev in Thread] Current Thread [Next in Thread→]