Re: [Gems-users] some queries about MOSI_SMP_bcast

[Nauman Rafique <nrafique@xxxxxxxxxx>]

I guess you answered your question yourself. Tester does not need simics
framework. And it is designed to hit corner cases. Details on using the tester
are in gems documention webpage.
Thanks. 
-- 
Nauman
Purdue University


Quoting Brinda Ganesh <brinda_ganesh@xxxxxxxxx>:

> 
> Is there anyway to test the coherence framework for
> its corner cases using either the tester exec
> framework or otherwise - without using the entire
> simics framework?
> 
> Thanks for all the help
> Brinda
> 
> --- Mike Marty <mikem@xxxxxxxxxxx> wrote:
> 
> > Ok, I understand.  For writebacks, the cache
> > controller in
> > MOESI_SMP_directory will issue a PUT control message
> > to the
> > directory/memory controller.  The directory
> > controller will ack this PUT
> > message and then the cache controller will send the
> > data and deallocate
> > the TBE.  You are correct in that the writeback ack
> > is tied to the
> > directory state in that it will only nack the
> > writeback if the directory
> > is forwarding a request to the cache.
> > 
> > You are asking if you can keep the TBE allocated to
> > possibly nack the
> > actual writeback data.  In general, you can keep
> > TBEs allocated as long as
> > you want.  As an example, MOESI_CMP_token implements
> > a non-speculative
> > delay (MM_W and M_W) and keeps the TBE allocated
> > longer than necessary.
> > 
> > It may be possibly to nack the writeback data rather
> > than the initial
> > writeback control message (PUT).  However I will
> > warn you that there are
> > deadlock issues when dealing with writebacks.  Many
> > systems and protocols
> > assume, when reasoning about virtual networks, that
> > the writeback data
> > message can always be sunk.
> > 
> > --Mike
> > 
> > 
> > > Im assuming that the action l_writeDataToMemory is
> > the
> > > actual action which initiates a write to dram.
> > This
> > > action is initiated when a message appears on the
> > > unblock queue. The cache controller places a
> > message
> > > on the queue (qq_sendTBEtoMemory) and then
> > deallocates
> > > the TBE.
> > >
> > > The writeback acks from the directory controller
> > do
> > > not seem to be tied with the memory controller
> > > behavior but rather with the directory state.
> > >
> > > Thanks
> > > Brinda
> > >
> > > --- Mike Marty <mikem@xxxxxxxxxxx> wrote:
> > >
> > > > I'm confused.  The protocol should only
> > deallocate
> > > > the TBE (MSHR) when it
> > > > receives data and does the callback to the
> > > > processor.  Where do you see it
> > > > deallocating as soon as the write is issued to
> > > > memory?
> > > >
> > > > --Mike
> > > >
> > > >
> > > > > Hi
> > > > >
> > > > > I have been playing around with the
> > > > > MOESI_SMP_directory protocol and adding the
> > > > NACK/Retry
> > > > > concept in.
> > > > >
> > > > > I noticed that the protocol deallocates the
> > TBE as
> > > > > soon as a write is issued to memory. I was
> > > > wondering
> > > > > if postponing this deallocation to after it
> > goes
> > > > > through the memory system , and adding the
> > concept
> > > > of
> > > > > dram nacks for the write request would create
> > some
> > > > > sort of incorrect state.
> > > > >
> > > > > Thanks
> > > > > Brinda
> > > > >
> > > > > --- Mike Marty <mikem@xxxxxxxxxxx> wrote:
> > > > >
> > > > > > Brinda,
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > >
> > > > > > MOESI_SMP_token might work with no
> > > > modifications.
> > > > > > The Memory controller
> > > > > > can simply ignore a request and the token
> > > > coherence
> > > > > > protocol would just
> > > > > > time-out and try again.  However if you do
> > use
> > > > this
> > > > > > protocol, set the
> > > > > > g_RETRY_THRESHOLD to something higher than 1
> > > > (like
> > > > > > maybe 10).  After some
> > > > > > number of retries specified by this
> > parameter,
> > > > the
> > > > > > token coherence
> > > > > > protocol will revert to a heavy-weight
> > request
> > > > > > guaranteed to succeed...I
> > > > > > suppose this heavy-weight request might not
> > work
> > > > in
> > > > > > your DRAM scheme as
> > > > > > your DRAM controller would have to respond
> > to
> > > > this
> > > > > > invoked requeset when
> > > > > > it is able to (but doesn't have to right
> > away).
> > > > > >
> > > > > > Otherwise without thinking about this much,
> > I
> > > > would
> > > > > > think that a
> > > > > > directory-based protocol might be more
> > > > > > straightforward to implement a
> > > > > > nack/retry.
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > >
> > > > > > With have dozens of old protocols in our
> > > > "attic".
> > > > > > The problem is that the
> > > > > > Ruby interfaces have changed requiring each
> > > > protocol
> > > > > > be modified to work
> > > > > > with the latest release of GEMS.  For
> > example we
> > > > > > have a protocol based on
> > > > > > the SGI Origin MESI protocol which does
> > > > > > Nacks/Retries.  If you wanted, I
> > > > > > could probably send this to you but it would
> > > > _not_
> > > > > > work.
> > > > > >
> > > > > > It would probably just be easiest to take
> > > > > > MOESI_SMP_directory, add a NACK
> > > > > > response instead of the normal DATA
> > response.
> > > > Then
> > > > > > in the cache
> > > > > > controller upon receiving the NACK, either
> > issue
> > > > the
> > > > > > retry right away or
> > > > > > schedule a timeout to wake up some X cycles
> > > > later to
> > > > > > issue the retry.  If
> > > > > > you want some more pointers on doing this,
> > let
> > 
> === message truncated ===
> 
> 
> 
> 		
> ___________________________________________________________ 
> How much free photo storage do you get? Store your holiday 
> snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>