[libre-riscv-dev] Yehowshua Tasks

[libre-riscv-dev] Yehowshua Tasks

[Yehowshua]

Hello again Luke,

	As I wrap up my thesis, I’d like to get into the flow of things more.
	I can put I about four hours a day on LibreSOC.

	1. What are some tasks I can get started with right away?
	Mainly related to nMigen - I don’t have patience for QEMU 
	right now. Last time I did extensive QEMU work was a pretty
	painful experience about a year ago.

	2. I can go ahead and write a bench test for Minerva’s cache.

	3. Also, how can I get more familiar with the LD/ST comp unit
	including the dual cache even/odd architecture from the YouTube 
	video you linked to earlier today?
	Is it related to the memory Hierarchy section in Mitch Alsup’s 
	computer architecture chapter 10?

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] Yehowshua Tasks

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 11:47 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> Hello again Luke,
>
>         As I wrap up my thesis, I’d like to get into the flow of things more.
>         I can put I about four hours a day on LibreSOC.

fantastic.  that's a _lot_.

>         1. What are some tasks I can get started with right away?

(btw all of these, start by raising a bugreport.  i'll catch up
tomorrow and link them in to various dependent tasks).

an immediately useful task: a unit test for harry ho's sram.py (which
the comments on the pull for nmigen-soc say he didn't have time to do)
would be invaluable.  i will do a repo tomorrow for that.


some comments in soc/minerva/cache.py!  there's virtually none - at
all - in the entire codebase, and it's a serious problem.  the
comment-to-code ratio in soc is somewhere between 5% and sometimes as
high as 20%.  minerva?  0% to 1%.  cache.py is *zero* comments.

some references to *any* kind of online documentation about "what kind
of cache this is".

also, parameterising of the minerva code so that address and data
widths can be selected (128-bit, 64-bit, 32-bit)


also another useful task: LDSTSplitter needs to have the data bitwidth
multiplied by 8.   rather embarrassingly i forgot to do that, and
consequently the mask is *bit* level not *byte* level :)

this involves multiplying ashift1 and ashift2 by 8, as well as using
the same Repl trick as used in LenExpand on mask1 and mask2:
        l = []
        print ("llen", llen)
        for i in range(llen):
            l.append(Repl(mask[i], 8))
        comb += BYTEEXPANDED_mask.eq(Cat(*l))

that little trick turns a 16 *bit* mask into a 16 *byte* mask, where
each byte is either 0b00000000 or 0b11111111

the *expanded* masks can then be applied here:

            comb += ld1.ld_i.eq((self.st_data_i << ashift1) &
BYTEEXPANDED_mask1)
            comb += ld2.ld_i.eq((self.st_data_i >> ashift2) &
BYTEEXPANDED_mask2)

and at that point, LDSTSplitter is ready for use in DualPortSplitter
(or, we code-morph LDSTSplitter *into* DualPortSplitter).

this is how we will be dealing with mis-aligned requests (exactly as
in the diagram), so it's kinda strategically important.


>         Mainly related to nMigen - I don’t have patience for QEMU
>         right now. Last time I did extensive QEMU work was a pretty
>         painful experience about a year ago.

yeh we're not going to modify qemu: the level of optimisations they've
added is far beyond the understandability we need at the moment.
_using_ qemu (see soc/simulator/test_sim.py) is a different matter.

>         2. I can go ahead and write a bench test for Minerva’s cache.
>
>         3. Also, how can I get more familiar with the LD/ST comp unit
>         including the dual cache even/odd architecture from the YouTube
>         video you linked to earlier today?

run the following - and carefully examine both the ilang file using
yosys "show", and load the resultant vcd files in gtkwave.  they are
in order of simplest (lowest level leaf nodes) right the way up to
where things are at the moment.

* soc/experiment/l0_cache.py

   see TestL0Cache.  this will run a couple of LDs and STs directly.
they go straight into a TestMemory instance.


* soc/experiment/compldst_multi.py

  (which sigh after getting the next tests working, that one doesn't.
will fix it tomorrow)

  this will run some LD/STs through the Computation Unit interface.
this is pretty much exactly as described in Mitch's book... except
it's been converted to multi-signal (one REQ/GO per *register* rather
than a "global read" and "global write")

 LDSTCompUnit is a more advanced (more REQ/GO signals) version of an
ALU MultiCompUnit.  it is probably also worthwhile checking
soc/experiment/test/test_compalu_multi.py as well (which Cesar has
been working on).

 see https://bugs.libre-soc.org/show_bug.cgi?id=336 and
https://bugs.libre-soc.org/show_bug.cgi?id=312

 bear in mind that REQ/GO are basically ready/valid signalling and
follow the EXACT same protocol followed by AXI4 and Wishbone
signalling.


* soc/fu/compunit/test/test_ldst_compunit.py

  this one runs *actual LD/ST instructions*, after actually decoding
them (with PowerDecode2) and throws the input in using the REQ/GO
protocol, followed by waiting for (and confirming) the output is as
expected using (surprise) the REQ/GO protocol.  it also enumerates the
ISA Simulator memory and checks that the memory modifications are
identical


* soc/simple/test/test_core.py

 this one runs *all* available unit tests - actual instructions, again
after actually decoding them.  if you want to "only" test the LD/ST
ones, go to the bottom of the file and comment out everything but the
LDSTUnitTest.

 the difference between this and test_ldst_compunit.py is it actually
grabs the inputs needed to go to the LDSTCompUnit (and all others)
*from the register file*.  and likewise on output REQ/GO, puts the
results into the regfile.

 the REQ/GO is *DIRECTLY* synchronised with the Regfile read-enable /
write-enable for the active port.


regarding the Dual Port Splitter:  this code hasn't been written yet,
although the pieces are in place (use ctags -R and vim ":tag
{insertkeyword}" to navigate to these classes)

* DualPortSplitter
* LDSTSplitter
* LenExpand
* PortInterface
* DataMerger (this will be relevant later - not straight away)




>         Is it related to the memory Hierarchy section in Mitch Alsup’s
>         computer architecture chapter 10?

almost - not quite.  i've had to go far beyond that although the
basics are there.

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] Yehowshua Tasks

[Luke Kenneth Casson Leighton]

one fundamental aspect of what we are doing: anything that has the
slightest possibility of causing "irreversible damage" absolutely has to
have both a "hold off" and "go die" signal.

nothing and i mean nothing can be allowed to proceed unless it has a 100%
chance of success because we are *not* doing a "transaction / rollback /
history" system, we are doing a *shadow* (write-hold) system.

if there is any possibility of a memory write causing an exception, that is
the *very definition of causing damage*!

the memory write therefore must be subdivided into two phases:

1) to check if the write WOULD succeed ***IF*** permitted to proceed

2) after notification and receiving permission to proceed, ***ONLY*** then
proceeding with the actual commit to memory.

this has implications as i understand it even for the L1 Cache.

it is *not* ok to have phase 1 proceed, the notification go back, "yes
there is room in the cache for you" followed in phase 2 "actually i lied,
we need to raise an exception now".

so to make this clear:

* phase 1 is the only time that exceptions can be raised.

* phase 2 is absolutely fundamentally the part where no exceptions of any
kind can be raised.  the write MUST occur... or if it genuinely cannot we
will be required to halt the processor as it is a serious critical mistake
on our part or fundamental data corruption event, from the hardware.

this has implications that phase 1 may need to "hold" resources (reserve
cache lines, reserve TLB entries) for a short duration until it receives
either the "proceed" or "cancel" signal.

i do not know if Minerva L1 can handle that because there is zero code
comments.

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] Yehowshua Tasks

[Yehowshua]

> 
> it is *not* ok to have phase 1 proceed, the notification go back, "yes
> there is room in the cache for you" followed in phase 2 "actually i lied,
> we need to raise an exception now”.

	Right. So I read through the Minerva cache and understand about 
	98% of it. There is a cache miss signal. And also a bus error signal
	for example, if the cache tries to flush to the main memory via the 
	wishbone bus and it fails, it will raise bus_err.
	
	What is the difference between hold off and go die?
	
	I’m trying to write a simple unit bench for minerva L1Cache today.
	Is there an NLNet task covering this?

	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] Yehowshua Tasks

[Luke Kenneth Casson Leighton]

On Tue, Jun 16, 2020 at 2:50 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> >
> > it is *not* ok to have phase 1 proceed, the notification go back, "yes
> > there is room in the cache for you" followed in phase 2 "actually i lied,
> > we need to raise an exception now”.
>
>         Right. So I read through the Minerva cache and understand about
>         98% of it. There is a cache miss signal. And also a bus error signal
>         for example, if the cache tries to flush to the main memory via the
>         wishbone bus and it fails, it will raise bus_err.

ok the bus_err one would be an exception, and would fall into phase (1).

the cache miss signal: that would be an indicator to the FSM that
further work needs to be done.  this would i imagine still be part of
phase (1).

i *believe* this is taken care of by the time we get to the
LoadStoreUnitInterface.  i.e. i anticipate that CachedLoadStoreUnit
will use the cache-miss signal to determine if it should check the
address on the outgoing Wishbone Bus.

i.e., from CachedLoadStore Unit:

Phase (1) for a LOAD

- put the address into the cache.  get a "ok or cache miss" (this on same cycle)
- if "miss", put the address out onto the WB Bus (this may take
another cycle and that's ok)

we must HOLD LoadStoreUnit.m_stall indefinitely until such time as
EITHER the cache OR the WB Bus comes back with "yes this will succeed
100% if allowed to proceed".

Phase (2) for a LOAD

- ONLY after the first phase (m_valid but not m_load_error) is raised
will the external dependency tracker drop "m_stall"


it will be absolutely critical to have a unit test (and preferably a
Formal Correctness test) that confirms that at no time will
m_load_error be raised during Phase (2).


>         What is the difference between hold off and go die?

they're shadow matrix signals.  the logic is actually brain-dead
simple (only a few gates)
https://libre-soc.org/3d_gpu/shadow.jpg

* "hold off" prevents write.  it delineates phase 1 and phase 2.
that's both its definition and its job.  i believe it corresponds
directly to LoadStoreInterface.m_stall [or possibly x_stall.  there's
no documentation here, and x_ and m_ are non-standard conventions].

* "go die" will terminate all current state (full hard reset), free
all held resources, without causing any damage of any kind.  this has
to be done on the same clock cycle that the "die" is raised. (not on a
"sync" in other words).

another word for "go die" would be simply "cancel" or "reset".  i'm
not seeing any evidence of anything in Minerva loadstore.py which
suggests that such cancellation is possible.

so that would be a specific task that would need to be added.

>         I’m trying to write a simple unit bench for minerva L1Cache today.
>         Is there an NLNet task covering this?

no - feel free to make one, and refer to the archives (here).

also please do create one for investigating adding "cancel" (go_die)
to loadstore.py.  it should do a full hard-reset (withdraw all pending
states back to idle without causing any "damage")

l.

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