[libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

On Monday, June 15, 2020, Yehowshua <yimmanuel3 at gatech.edu> wrote:

> I was running through the nMIgen Minerva Cache
> codebase and would like to point out that it only
> has support for two sets.


yes.  this was noted and discussed a couple of months ago.

 It can have an arbitrary
> amount of tags, but is fixed at two sets which is
> probably notably too low performance for what
> we want.
>
> I’m currently working on writing a Minerva like nMigen
> cache that supports as many sets as desired - hopefully
> we can use that.


that would be great, if we were only doing a high performance general
purpose vector engine, because general purpose compute workloads have
unpredictable data characteristics for which multiple sets would be an
ideal solution.

for GPU workloads it is important to appreciate that to be useful.and
useable, there is more involved than just designing a set upgrade, which
needs to be discussed and understood before spending time doing work.

no disrespect intended: do you not feel that it would have been better to
ask that, particularly on a complex project that has had over 2 years
architectural design work done on it, and on which you have not had time to
get up to speed?

there is no problem highlighting a potential performance flaw however going
direct from that to an announcement to start work, without consultation or
evaluation, is... puzzling.

to explain (summarising detailed and indepth discussions that have taken
place over the past year and a half, learning from many different people):

because we are splitting into twin L1 caches, and because GPU parallel
non-overlapping workloads (particularly texture data) make ineffective use
of L1 caches, expanding the tag size may not be of as much value as might
otherwise be expected.

it would be much more useful to add "cache line pinning" such that a GPU
workload only uses a fractional percentage of the cache.

this would stop a massively parallel non-overlapping workload from flooding
the L1 Cache with data that is neverrrr going to be referred to agai.

i discussed this only 2 days ago.

in earlier discussions before that, which you have also not seen, i
suggested simply modifying the minerva one (keeping the formal correctness
proof functional is a critical part of the project, and they are very hard
to write).

we need arbitrary bitwidth as well.  128 bit minimum and the option of 256
bit for later.

also it is imperative to have the L1 cache support individual byte-enable
lines *not* a single overwrite/update line.

this because the byte enable lines are a critical part of the L0CacheBuffer
merge strategy for Vector workloads.

if you check the L0/L1 Cache diagram i drew out, the plan is to connect a
*pair* of 64 bit wishbone interfaces to the L1 cache (ignoring that there
are two L1 D Caches for now)

each pair is individually activated based on whether any of the 8
byte-enable lines are activated.

thus if there is a cache flush and only the top 64 bits have changed only
one 64 bit wishbone write is required.

these byte-enable (wen) lines directly correspond with wishbone byteselect
lines.

bottom line, feel free to spend the time doing that work if you so choose
however i have to advise you in advance that it is unlikely to be useful
and consequently the chances of receiving NLNet donations for completing it
are slim.

it *might* be useful for the ICache however this again will need evaluation
and discussion under a bugreport i.e. following software engineering
practices rather than arbitrarily going ahead without consultation.  once
consensus is reached as to the potential usefulness, then a budget could be
allocated.

i am raising an eyebrow here at this puzzling action however do not wish to
discourage you, merely steer and redirect your energies and initiative to
somewhere productive that will help us achieve our goal on this complex
project.

if you have any questions about the architecture which took 2 years to plan
and design please do ask them.  also if you would like to ask what would be
useful to work on, that is within your skillset, that you would enjoy,
please also do so without hesitation.

sorry to have to point all of these things out.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68