[libre-riscv-dev] Minerva L1 Cache

[libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

I was running through the nMIgen Minerva Cache
codebase and would like to point out that it only 
has support for two sets. 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.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

> I’m currently working on writing a Minerva like nMigen 
> cache that supports as many sets as desired - hopefully
> we can use that.

I need a cache with arbitrary amount of sets for my thesis
anyways so - might be useful in a LibreSOC context too.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

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

>
> > I’m currently working on writing a Minerva like nMigen
> > cache that supports as many sets as desired - hopefully
> > we can use that.
>
> I need a cache with arbitrary amount of sets for my thesis
> anyways


ah ok now this makes sense.


>  so - might be useful in a LibreSOC context too.


maybe.  we will have to evaluate it.  as i explained in the crossover
message there are other higher priority design requirements that are unique
and specially required for the design.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

> 
> maybe.  we will have to evaluate it.  as i explained in the crossover
> message there are other higher priority design requirements that are unique
> and specially required for the design.

I watched the video and read through the pages.
I understood high level what is going on - the details are 
not entirely clear to me at this stage.

At some point, I can imagine that you’ll want to connect
up the memory systems. How much labor do you think 
is needed for this? Assuming I’m free starting at the end of July,
It would probably take me a couple weeks to catch up to speed
on the intricacies of the scoreboard.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 5:47 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> >
> > maybe.  we will have to evaluate it.  as i explained in the crossover
> > message there are other higher priority design requirements that are unique
> > and specially required for the design.
>
> I watched the video and read through the pages.
> I understood high level what is going on - the details are
> not entirely clear to me at this stage.

this is understandable: it's literally taken me 2 years to learn.

> At some point, I can imagine that you’ll want to connect
> up the memory systems.

yes.  *right now*!

i just got LD/ST CompUnit working in test_core.py and it is relying on
a hard-link to a Test Memory limited to 64 8-byte words.

i am holding off putting in Wishbone interfaces onto the
(prototype/test) L0CacheBuffer because it is yet another layer of
complexity and it needs unit tests of a wishbone link in isolation,
first, before becoming comfortable with it.

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/l0_cache.py;h=5213ee986da7524b41ba8fb6842a15dc2c861d49;hb=HEAD#l318

that in turn requires that we have an actual SRAM *behind* that
Wishbone interface in order to be able to actually *do* those tests.
this is what i've been able to find.  harry points out that he did not
write any unit tests (yet).

https://github.com/HarryMakes/nmigen-soc/blob/wishbone_interconnect/nmigen_soc/wishbone/sram.py


at that point it is a matter of connect-connect-connect and finally we
are in a position to flip out the test infrastructure at the Wishbone
level and drop in Litex instead.

if Minerva's Load/Store interface is used / adapted then there is no
need to write-code-from-scratch, and it also means that enabling L1
caches is a brain-dead runtime configuration switch.

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/minerva/units/loadstore.py;hb=HEAD#l75

however there are *zero* unit tests for this code and so that will be
important to write.


> How much labor do you think is needed for this?

if we have the right components and the right people, probably only
about 2-3 weeks.

> Assuming I’m free starting at the end of July,
> It would probably take me a couple weeks to catch up to speed
> on the intricacies of the scoreboard.

with the current resources the scoreboard is not an immediate
incremental priority: getting a functional core that executes
instructions is a top priority... *and then* the scoreboard can be
incrementally added to it if there is time to do so.

this all changes if the people from Marketnext are good quality
engineers, who can get up to speed rapidly.  subtasks can be allocated
to them and at that point yes there will be plenty of time to do do
heavy-duty sustained focus on complex tasks.

in the meantime i know you really want to get to understand the
precise-augmented scoreboard system.  the only thing i can suggest is:
read and re-read Mitch's book chapters again and again and again, run
the unit tests again and again, go over the Tomasulo "morph" page
again and again, and look at the graphviz diagrams and match them to
Mitch's diagrams.

it littteerrallly takes mmmooonnnths of sustained dedicated focus on
this and *nothing* else, for the design to properly sink in.  remember
it took me *four* months to find a bug in the later sections of
Mitch's second book chapter, which not even he had noticed.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

> 
> with the current resources the scoreboard is not an immediate
> incremental priority: getting a functional core that executes
> instructions is a top priority... *and then* the scoreboard can be
> incrementally added to it if there is time to do so.

OK. So right now, it sounds like instructions execute in order with
scoreboard?

Are we simply stalling with instructional dependencies?
I’m assuming that right now there is no multi-issue or anything of that
nature at the moment?
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 8:54 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> >
> > with the current resources the scoreboard is not an immediate
> > incremental priority: getting a functional core that executes
> > instructions is a top priority... *and then* the scoreboard can be
> > incrementally added to it if there is time to do so.
>
> OK. So right now, it sounds like instructions execute in order with
> scoreboard?

no scoreboard at all.  no dependency checking at all.


> Are we simply stalling with instructional dependencies?

correct.  it's why it's nicknamed the brain-dead core

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple/core.py;hb=HEAD
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple/test/test_core.py;hb=HEAD

at the moment it has three major top-level components:
* Function Unit block
* Register Files
* TSTL0CacheBuffer which contains a single memory port to a single
nmigen Memory with 64 8-words.

the unit test feeds instructions directly into one (and only one) of
the pipelines, and waits for the busy flag to go LOW.

> I’m assuming that right now there is no multi-issue or anything of that
> nature at the moment?

correct.  incremental development.  each step - each new piece of
functionality - confirmed by a unit test.

* when the core's executing instructions, we can start writing more
comprehensive unit tests.
* when the scoreboard is added, we re-run those unit tests.  if they
work, chances are scoreboard is functional.
* when that's added, we add multi-issue.  exactly the same same thing
again: run the unit tests.

i am absolutely shocked to find that there is not a single other
"open" processor that takes this approach.  they all - all of them -
rely heavily on "high level" integration tests.  test suites written
by other people.  or just a series of binaries which test the *whole*
system.

one error and the only way to find it is to compile up one massive
core.  if that takes several minutes to do (minerva takes a *minute*
to compile to verilog), tough luck.

we can run the *local* unit tests for the *local* module that is
believed to be the problem and rapidly track the problem down.


btw my brother dan pointed out that this type of approach - which is
not carried out *AT ALL* by *ANY* commercial team (especially Intel
right now) let alone an "open source" one, is a critically important
"Unique Selling Point" to investors.

by having a combination of low-level unit tests (and formal
correctness proofs) that test components individually prior to use in
a higher level that then *ALSO* has a unit test, this type of approach
is *EXACTLY* the kind of thing that will give investors a high degree
of confidence that we will be a safe bet.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

> * when the core's executing instructions, we can start writing more
> comprehensive unit tests.
> * when the scoreboard is added, we re-run those unit tests.  if they
> work, chances are scoreboard is functional.
> * when that's added, we add multi-issue.  exactly the same same thing
> again: run the unit tests.

I completely support this approach.

>  if that takes several minutes to do (minerva takes a *minute*
> to compile to verilog), tough luck.

Minerva took 8 seconds to compile on my Mac…

> a higher level that then *ALSO* has a unit test, this type of approach
> is *EXACTLY* the kind of thing that will give investors a high degree
> of confidence that we will be a safe bet.

Exactly! I plan to mention this in my pitch deck.
My mentor has been helpful in getting the meat of the ideas out of my head.

Also, I’m fiddling around with the Minerva cache.
Not quite sure about a few things:

	1. Why are there s1 and s2 inputs? What does 1 vs 2 mean?
	https://github.com/lambdaconcept/minerva/blob/master/minerva/cache.py#L43 <https://github.com/lambdaconcept/minerva/blob/master/minerva/cache.py#L43>

	2. Why does s1_stall switch the memory read ports addresses from s1_addr to s2_addr?
	https://github.com/lambdaconcept/minerva/blob/master/minerva/cache.py#L141 <https://github.com/lambdaconcept/minerva/blob/master/minerva/cache.py#L141>
	
I reached out to Jean Paul from lambda concepts about this.
Once I figure out exactly how Minerva core works - I’ll write a 
tiny unit bench for it. Hopefully this would be helpful in modifying
it for our needs.


Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

> 
> Minerva core works

Meant to say Minerva cache.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

> 
> I reached out to Jean Paul from lambda concepts about this.
> Once I figure out exactly how Minerva core works - I’ll write a 
> tiny unit bench for it. Hopefully this would be helpful in modifying
> it for our needs.

Actually - I figured it out.

Stage1 and stage2.

Stage1 is address pre-fetch.
Stage 2 is actual fetch.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 9:31 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> >
> > I reached out to Jean Paul from lambda concepts about this.
> > Once I figure out exactly how Minerva core works - I’ll write a
> > tiny unit bench for it. Hopefully this would be helpful in modifying
> > it for our needs.

yes please.  please drop it into soc/src/soc/minerva/test/... ah!
excellent!  there *is* a test_cache.py already in that directory.
(i'm currently making all imports explicit)

> Actually - I figured it out.

ah excellent

> Stage1 and stage2.
>
> Stage1 is address pre-fetch.
> Stage 2 is actual fetch.

okaay.  which isn't documented.  no code-comments (at all).  sigh.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

> 
> there *is* a test_cache.py already in that directory.
> (i'm currently making all imports explicit)

Right this is the formal.

The formal doesn’t make it clear how to actually 
use the thing.

Another question: what is the interface you want to the cache?
I think you said you wanted to go with Minerva’s loadstore frontend?

Could be a bit tricky as the loadstore frontend uses stage specific
bit masks. Might be easier to morph the L1 cache to your needs directly.

From your video, it seems that there is no instruction cache vs. data cache.

Can you specify what interface you want to see from the cache’s perspective?
I suspect the only change we need to make is set s1_stall to Const(0), and disable 
s2_addr in Minerva’s L1Cache.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 10:08 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> >
> > there *is* a test_cache.py already in that directory.
> > (i'm currently making all imports explicit)
>
> Right this is the formal.
>
> The formal doesn’t make it clear how to actually
> use the thing.

sigh this is what Samuel Falvo pointed out: he advocates two unit
tests.  one formal, one standard.  the formal one does code-coverage,
the standard one acts more as a "tutorial and demo".

minerva is missing that.

> Another question: what is the interface you want to the cache?
> I think you said you wanted to go with Minerva’s loadstore frontend?

yes.  basically adapt this:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/l0_cache.py;hb=HEAD

so that it instead talks this:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/minerva/units/loadstore.py;hb=HEAD#l13

right now, L0CacheBuffer is talking *directly* to the nmigen Memory
rdport / wrport:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/l0_cache.py;hb=HEAD#l400

if those direct calls are replaced with calls that are compatible with
the Minerva LoadStoreUnitInterface, adapted to 64-bit-wide, then for a
1st version approximation we're "done".

the next task on from that

>
> Could be a bit tricky as the loadstore frontend uses stage specific
> bit masks.

LoadStoreUnitInterface.x_mask? that's perfect.  it's exactly what's
needed.  those are i assume byte-level write-enable lines, exactly as
needed.  now, it's only 4 bits because the data width is only 32 bit:
those need to be expanded to 64 bit.

LDSTSplitter - when it's time to add that - *might* take care of the
128 bit cache-line requirement, however might not.  we may simply have
to internally not be compliant with Wishbone for the paths between
L0CacheBuffer and LoadStoreUnitInterface.

this would mean LSUI.x_mask being 16 bit wide, x_store_data being 128
bit, m_load_data being 128 bit.  and the L1 cache likewise widened to
128 bit, and given a 16 bit byte-enable line.

*that* - on the other side of the L1 cache - where it talks to actual
Wishbone - would be where a split to 2x 64-bit outgoing Wishbone
interfaces would be needed.


> Might be easier to morph the L1 cache to your needs directly.
>
> From your video, it seems that there is no instruction cache vs. data cache.

the video covers the data cache only.  the instruction cache is
"normal" and we should - unit tests notwithstanding - be able to just
drop minerva I-Cache (units/fetch.py, adapting PCSelector) directly
into place.

the only reason i haven't done that already is because i don't feel
comfortable doing it without the proper unit tests confirming that
they're functional.


> Can you specify what interface you want to see from the cache’s perspective?
> I suspect the only change we need to make is set s1_stall to Const(0), and disable
> s2_addr in Minerva’s L1Cache.

i honestly don't know, i haven't investigated the code closely (only
just literally got to the point where it's needed) will try to go over
it.

*thinks*.... ah.  we *do* actually have an AGEN phase, if that's what s1 is for?

at line 112 this is addr which is of type Data record which includes
an "ok" signal not just "data".
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/l0_cache.py;hb=HEAD#l112

at line 114 a response is expected to come back indicating that the
address is "ok" or that there was an error [currently this is ignored,
because there's no exception code - Cole - TRAP pipeline....]

and there *will* be a potential delay between the s1 reservation phase
and the s2 (commit) phase.  the AGEN phase should say "yes you can, if
you acknowledge it, safely proceed.   i will reserve the cache line
until you tell me go or cancel".

equally (particularly right now) the acknowledgement may actually be
combinatorial and immediate, so both these scenarios (delay, no-delay)
need to be taken into consideration, between s1 and s2.


btw, for later (when the scoreboards are added): up until that
"proceed or cancel" point, the Shadow Matrices will "hold" the actual
commit (s2 stage).  ONLY when the s1 stage has said "yes if you really
want to do this it is absolutely safe to proceed, guaranteed 100%
success", *then* the shadow is dropped and the commit to memory
allowed to proceed.

if however that error comes back at the AGEN stage (s1), then the
Shadow Matrices are told "activate go-die, please - kill *EVERYTHING*
that is downstream of this instruction, *right* now".

so, ignoring scoreboards for now: it does indeed look like the Minerva
cache - and the LoadStoreUnitInterface - is precisely and exactly what
we need.

just modified to 64 bit wide data buses, and 48 bit address buses.
actually, parameteriseable with defaults to those values would be
better.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Cole Poirier]

> On Jun 15, 2020, at 2:55 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> 
> at line 114 a response is expected to come back indicating that the
> address is "ok" or that there was an error [currently this is ignored,
> because there's no exception code - Cole - TRAP pipeline....]

Will work on this tomorrow. Just trying to get my head above water with organizing all of my new tasks and onboarding the two new members (hehe my sisters). Will spend 1/3 of my time tomorrow on *actual* work that furthers the product, spend the other two thirds helping Anais get setup and learning nmigen, and if not finishing hopefully getting half way through organizing my todos. So I can finally update my wiki page and also calm my growing sense of being overwhelmed. Order and prioritization once done will quell this.

Col 
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

On Tuesday, June 16, 2020, Cole Poirier <colepoirier@gmail.com> wrote:

> wiki page and also calm my growing sense of being overwhelmed. Order and
> prioritization once done will quell this.


use the priority field thing on the bugtracker.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Cole Poirier]

> On Jun 15, 2020, at 6:54 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> 
> On Tuesday, June 16, 2020, Cole Poirier <colepoirier@gmail.com> wrote:
> 
>> wiki page and also calm my growing sense of being overwhelmed. Order and
>> prioritization once done will quell this.
> 
> 
> use the priority field thing on the bugtracker

I need something much more substantial than that where I can get quite granular and use checklists and other tools. Will get this implemented in time on the to-be-built bugzilla front end, but until then I will be using a tool that has this functionality privately to organize my thoughts and mirroring my conclusions on the bug tracker and my wiki.

Cole
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

> 
> I reached out to Jean Paul 

Sorry, Jean Francois - not Jean Paul.
Keep mixing them up.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 11:20 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> >
> > I reached out to Jean Paul
>
> Sorry, Jean Francois - not Jean Paul.

ah good.  donations _are_ available.  last time they said, "oh we work
for a company, we couldn't possibly take _donations_"  *face-palm*...
now of course things have changed, maybe they will not turn down
money, ehn?  *sigh*.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

> maybe.  we will have to evaluate it.  as i explained in the crossover
> message there are other higher priority design requirements that are unique
> and specially required for the design.

I watched the video and read through the pages.
I understood high level what is going on - the details are 
not entirely clear to me at this stage.

At some point, I can imagine that you’ll want to connect
up the memory systems. How much labor do you think 
is needed for this? Assuming I’m free starting at the end of July,
It would probably take me a couple weeks to catch up to speed
on the intricacies of the scoreboard.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

And more generally, if I understand things correctly:
Our memory architecture is the following?

cpu -> MMU -> L1 Cache -> main memory?

Yehowshua

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

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

> And more generally, if I understand things correctly:
> Our memory architecture is the following?
>
> cpu -> MMU -> L1 Cache -> main memory?


the diagram i drew, which took several weeks to design and review on here
and comp.arch, which i have referred you to a couple of times but have
noted each time, puzzlingly, did not result in any engagement or questions,
contains the layout.

i wondered if perhaps this is because this is a high traffic list and you
have been so busy on other important things.

here is the page again:

https://libre-soc.org/3d_gpu/architecture/memory_and_cache/

there are other locations and discussions however this diagram is key.

the multiple LDST CompUnits can produce up to *SIXTEEN* 64 bit LDST
requests.

these are "funneled", grouped, and directed to *separate* odd/even L1
Caches, each being 128 bit wide.  the split decision uses bit 4 of the
address.

the TLB and MMU i have not been able to get to because there is so much
else to do, first.

without that funneling (merging) we simply could not meet a GPU workload.

All LDST operations (all 16 of them) have the potential to be merged in a
single cycle.  in reality only 8 are likely to be merged.

it is important therefore to appreciate that this architectural strategy
has been designed and evaluated over a 2 year period to give "reasonable"
64 bit scalar performance, yet 2 to 4x that performance if certain criteria
are met such as if FP32 sequential (element atrided) vector workloads are
issued.

this eliminates many of the N to N crossbars that would obliterate any
chance of us being able to claim low power consumption as well as make the
routing and layout absolute hell.

it really is a hybrid VPUGPUCPU not a "CPU pretending to be a GPU" or the
other way round.

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Yehowshua]

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

Pardon me. This should have said two ways.
Line 18 in cache.py

Yehowshua

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

On Monday, June 15, 2020, Yehowshua <yimmanuel3@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
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] L1 cache and GPU workloads

[Jacob Lifshay]

On Sun, Jun 14, 2020, 21:04 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> <snip>
> 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.
>

Do note that a lot of a GPU workload will be rewriting a memory chunk over
and over again because of triangles being drawn on top of other triangles,
as well as using several potentially-colliding memory buffers and textures,
where it's quite common to load from the same section of texture
repeatedly, since each texture sampling operation will read a potentially
large group of adjacent pixels (called a footprint) in order to interpolate
between them.

Also, we want our processor to be good at CPU tasks as well, so having a L1
cache with more than 2 sets is advantageous.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev