Re: [Gems-users] Do you have the plan to support the Dragonprotocol inGEMS?

["Mike Marty" <mikem@xxxxxxxxxxx>]

Agreed, but Write-through L1->L2 are pretty common in real systems (IBM 
Power4/5, Sun Niagara, Xbox360, etc) and you need a coherence protocol even 
in a shared-L2 system.
One big advantage with write-through L1s is that ECC at the L2 is easier to 
implement than ECC at the L1s.  Plus doing ECC at the L1s would probably 
impact this critical latency.
--Mike


----- Original Message ----- 
From: "Milo Martin" <milom@xxxxxxxxxxxxx>
To: "Gems Users" <gems-users@xxxxxxxxxxx>
Sent: Monday, June 18, 2007 1:17 AM
Subject: Re: [Gems-users] Do you have the plan to support the Dragonprotocol 
inGEMS?

> I agree with Mike's assessment that update protocols are
> challenging.  However, I would strengthen his comment to say that
> update protocols aren't just challenging in GEMS, they are
> challenging to implement in *real* systems as well.  The memory
> consistency model issues become really complicated really quickly.  I
> think this is one of the main reasons that most real systems today
> use invalidation-based cache coherence protocols.  Sure, there are
> some issues with write-through L1s to a shared L2 used in systems
> such as IBM's  Power4, but that isn't as bad as a full update
> protocol.  I just can't think of a example of a high-performance
> multiprocessor with an update protocol built in the last decade (or
> longer).
>
> For this reason, the Ruby/SLICC part of GEMS explicitly focuses only
> on block-level coherence (which usually implies invalidation-based
> cache coherence).  Modifying GEMS to support update-based coherence
> could be done, but most of SLICC would need to be removed (or heavily
> modified) to do so.
>
> - Milo
>
> On Jun 17, 2007, at 7:57 AM, Mike Marty wrote:
>
> > I think implementing any update protocol is a challenge in GEMS
> > because of
> > memory consistency issues.  The Simics functional simulation
> > implements
> > sequential consistency, and this might be hard with an update protocol
> > (especially without an atomic bus)
> >
> > --Mike
> >
> >
> > ----- Original Message -----
> > From: "??" <timmyguo@xxxxxxxxxxxxxxxx>
> > To: <gems-users@xxxxxxxxxxx>
> > Sent: Sunday, June 17, 2007 4:38 AM
> > Subject: [Gems-users] Do you have the plan to support the Dragon
> > protocol
> > inGEMS?
> >
> >
> > > Dear GEMS TEAM,
> > > I recently find that a dragon protocol simulation would be
> > > beneficial to
> > > my
> > > research. And GEMS doesn't implement this. Do you have a plan on
> > > this?
> > >
> > > As far as I know, the SLICC language & compiler handles memory
> > > transaction
> > > in per-line basis. I think it's crucial for an updating protocol
> > > to handle
> > > transaction in per-word basis, which not only eliminates false
> > > sharing but
> > > also reduces bandwidth consumption. Do you have a plan to
> > > implement this?
> > >
> > > G.R.
> > >
> > > _______________________________________________
> > > Gems-users mailing list
> > > Gems-users@xxxxxxxxxxx
> > > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > > Use Google to search the GEMS Users mailing list by adding
> > > "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding
> > "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> --
> Milo M. K. Martin (milom@xxxxxxxxxxxxx)
> http://www.cis.upenn.edu/~milom/
> Assistant Professor
> Computer and Information Sciences Department
> University of Pennsylvania
>
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding 
> "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.