search

chipsalliance / rocket-chip

Rocket Chip Generator
Other
3.27k stars 1.13k forks source link

DCache ProbeAckData (Exclusive Caching?) #2119

Open seldridge opened 5 years ago

seldridge commented 5 years ago

Type of issue: feature request

Impact: API addition (no impact on existing code)

Development Phase: request

What is the current behavior?

Rocket's DCache is configured such that on a Probe the choice of response being ProbeAck or ProbeAckData is a function of the data being dirty or not. (Technically, this is hardcoded into how any ClientMetadata responds to probes.)

This works fine for inclusive caching, but an exclusive cache where the L2 does not include a copy of the data would result in additional memory accesses. E.g., a clean downgrade from Trunk to None where ownership is transferring from one core's data cache to another core's data cache would (I think) require the L2 to fetch a new copy of the data from memory.

Alternatively, I'm missing something here or there's some clever approach to handle this with the L2.

What is the expected behavior?

It seems like the choice of how the DCache responds (either returning data with ProbeAckData or not returning data with ProbeAck) should be easily configurable. However, there's no option for this due to assumptions in ClientMetadata.

A top level DCache parameter seems initially attractive. However, this is likely better handled through diplomacy to make DCache behavior a function of the memory system it's connected to.

What is the use case for changing the behavior?

Better support for alternative memory hierarchies.

ShuyunJia commented 5 years ago

Maybe it is better to re-define the ProbeBlock message for such exclusive downgrade situation.

I think it is ok in functionality if each ProbeAck carries data information for both dirty and clean cacheline. However, many modern SoCs use tend towards inclusive or tend towards exclusive policies rather than strict exclusive. For such memory hierarchies, letting each ProbeAck message carries data information would lead to a dramatic increase in dynamic power assumption.

In tilelink spec v1.8, I see the Probe message is refined to ProbeBlock and ProbePerm. For now, I don't see any implementation distinguishes these two messages in rocket-chip(correct me if i'm wrong). We could use ProbeBlock message when the local cache is exclusive thus a ProbeAckData is mandatory. In situation when local cache is inclusive, a traditional Probe message could be used.