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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed May 6 15:55:16 BST 2020

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


> 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/>


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:

which you can then see in decode_types:

note that PowerOp is an *internal* type.  you would never actually use
or interface directily with PowerOp.  the "end-user" would use

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:

and the LDSTCompUnit's Decode subset, CompLDSTOpSubset:

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.


More information about the libre-riscv-dev mailing list