[lowrisc-dev] Tag system implementation questions
asb at asbradbury.org
Wed Dec 17 20:46:49 GMT 2014
On 17 December 2014 at 19:38, <hga at ancell-ent.com> wrote:
> Note that I am a ... dilettante in this area. I've never worked at this
> level, but got very interested in tagged architectures from exposure in
> the very early '80s to Lisp Machines, which used 8 bit tags for things
> like dynamic typing.
Hi Harold, thanks for the questions. I hope the answers inline below
help, do feel free to respond again if you still have queries.
> That said, in trying to figure out how the lowRISC tagging system per
> memo 2014-01 might work and perform, I wonder:
> Where will the backing store of the tag cache come from?
> If not from stealing bits from 72 bit wide ECC DIMMs (which I don't
> get the impression is the plan, although I wonder if ECC/parity will
> be supported), how will dirty tags be written if tag cache lines
> aren't 64 bits?
The tag cache is drawn in the memo between the memory controller and
L2 cache because it is logically interposed between the two. It
logically extends the word size from 64-bit to 66-bit. Supposing tags
are enabled at boot time, a portion of the physical memory of the
system is dedicated to holding the tags (2/64 ~3% of RAM). When there
is an L2 miss, the data for the cache line is loaded from RAM and the
tags associated with that line are checked for in the tag cache. If
there is a tag cache miss, another request to memory must be made. For
this reason you really want a very high hit rate in the tag cache, or
else reading a cache line is going to result in two requests to
memory. Fortunately, due to the small size of tags the reach of even a
small cache is very high.
The L1 and L2 caches are modified so the cache lines include space for
the tag bits (and this is part of the overhead of the scheme). Tags
are just copied along with the data. Rocket does implement ECC for the
caches. ECC support for the external RAM is dependent on the memory
controller, and would be below the level of the tag cache.
> Related, what sort of tag cache organizations are you looking at? E.g.
> how can the mooted "can be small" 8KiB tag cache most take advantage of
> its 32KiB possible entries?
Exact details on the organisation of the tag cache are TODO. Wei Song
who recently joined the project full-time is currently prototyping
support for tagged memory and the tag cache on top of Berkeley's
Rocket RISC-V core generator <https://github.com/ucb-bar/rocket>. But
of course to properly evaluate different choices we'll need realistic
memory traces to consider.
More information about the lowrisc-dev