[libre-riscv-dev] daily kan-ban update 23may2020
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Sat May 23 16:15:02 BST 2020
On Sat, May 23, 2020 at 3:56 PM Tobias Platen
<libre-soc at 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.
More information about the libre-riscv-dev
mailing list