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

[Milo Martin <milom@xxxxxxxxxxxxx>]

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