Re: [libre-riscv-dev] daily kan-ban update 23may2020

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Sat, May 23, 2020 at 3:56 PM Tobias Platen
<libre-soc@platen-software.de> wrote:
>
> If no one else is working on the LDST unit I will start working there.

good.  please however listen, pay attention, keep in constant
communication (do not wait until the end of the day if you are stuck,
like yesterday).

> First I'll copy the skeleton files from another function unit,

that will not be necessary: LDST is special-cased.  LDST is not
pipelined (they are FSMs), so virtually none of the infrastructure
there in soc.fu/* applies to it.

the reason why i created soc.fu.ldst.ldst_input_record is to make it
"consistent" when it comes to wiring up the Computation Units, which
will be dropped into soc/fu/{somefile.py} later.

> then I'll
> try to implement the things described in the video L0 cache/buffer walkthrough [1].

there are several pieces to this.  i need you to focus on them one at
a time, as this is particularly tricky.

first, a new class in soc/experiment/l0_cache.py is needed which
implements that core algorithm: the one that uses a PriorityPicker to
select one of the "active" LD/STs, then use that to OR-select an
output.

please assume the following inputs:

* an array of 8 Signals of length 8 bits which tell you which
addresses have matched against which other addresses.
  ( we call this the "address-match" array)
* an array of 8 Records containing {16 bytes data, 16 "enable" lines}

and the following output:

* a Record containing {16 bytes data, 16 "enable" lines}

in the address-match array, you want to find the first non-zero line.
once you have that index, use it to OR the 16 bytes and 16 "enables"
from the 8 records, into the output.

that's it.  it's quite simple, and is a crucial piece that we need.

i will cut/paste this into the appropriate bugreport (once i have found it).

please do *NOT* modify, replace or remove the existing L0CacheBuffer.
we need it, because it is currently in use.  it is not
high-performance, however it "works", and the rest of the code relies
on it.

l.

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