[libre-riscv-dev] daily kan-ban update 06may2020

[Luke Kenneth Casson Leighton]

On Wed, May 6, 2020 at 3:00 PM Yehowshua <yimmanuel3 at gatech.edu> wrote:
>
> Still doing the legal work..

great.

> Made an attempt to explain how PowerOP combined with Enum works…
>
> https://libre-soc.org/Documentation/SOC/index/ <https://libre-soc.org/Documentation/SOC/index/>

PowerOp....
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/power_decoder.py;h=6094da1b4c84cbe1e1342cda62733bd3e1db6774;hb=HEAD#l106

ah that one mirrors what's in the CSV files, basically (where in
microwatt it was all hard-coded into the VHDL files).

it's directly equivalent to decode_rom_t type in microwatt:
https://github.com/antonblanchard/microwatt/blob/master/decode1.vhdl#L33

which you can then see in decode_types:
https://github.com/antonblanchard/microwatt/blob/master/decode_types.vhdl#L50

note that PowerOp is an *internal* type.  you would never actually use
or interface directily with PowerOp.  the "end-user" would use
PowerDecode2.
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/power_decoder2.py;h=4a3785efaba9c03d76a0159f19e4cab0219d0b7d;hb=HEAD#l329

as that contains *all* decoded fields (merged globally into the one
data structure regardless of whether they are needed), this is quite
annoying, so there are two *SUBSET* classes that "pinch" only the
fields that are needed (and there will be more of those).

ComputationUnit's Decode subset, ComALUOpSubset:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/alu_hier.py;h=0021c0793c6cf874060148ff83c0cee6720b6f8d;hb=HEAD#l23

and the LDSTCompUnit's Decode subset, CompLDSTOpSubset:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/compldst_multi.py;h=d1be1355ecce4f8e1b503c0b950a46ad306ae1f4;hb=HEAD#l66

note how CompLDSTOpSubset, CompALUOpSubset and Decode2Execute1Type all
derive from nmigen Record.  this provides "fields" (which comes from
the layout) which in turn allows us to walk through the Record and
grab only the subset of fields that we actually want to copy.

the "normal" Record.eq would unfortunately treat the *BITS* of each
derived Record as "a fixed sequential linear block of bits to copy"
(treating the two exactly like memcpy).

can i leave it with you to update the source code docstrings with
notes from the above?  if not, let me know and i'll do it.

l.