[libre-riscv-dev] [Bug 271] SigDecode in power_fields has extra spurious fields

bugzilla-daemon at libre-riscv.org bugzilla-daemon at libre-riscv.org
Mon Mar 30 16:09:21 BST 2020


--- Comment #8 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Michael Nolan from comment #7)
> Ok, I've got it sort of working in df295b5. I removed TopPowerDecoder's
> inheritance of DecodeFields and moved DecodeFields to a member. I then had
> TopPowerDecoder go through each of the "common" fields in DecodeFields and
> copy it to a signal. 


> This works, but it doesn't take care of the form
> specific fields (e.g. dec.FormXL.XO[9]), and I'm not sure what to do with
> those. I suppose I could add in submodules for each of the forms and copy
> their signals like I did with the common ones, would that work for you?

submodules is unnecessary (and a bit overkill): an object that is a dummy class
would do (similar to the use of NamedTuple)

class Form:

or, actually, just a NamedTuple again.  hmm take a look see what you

commit 5374cb82b

_should_ be accessible as

comb += something.eq(decoder.FormX.RA)

which becomes important in the autogenerator code because each instruction
is listed as having a "Form", and we can drop the decoder.Form{something}
into its context, and the pseudo-code fragment will go "oh, i recognise
these variables RA, RT etc. as being from Form{something}"

You are receiving this mail because:
You are on the CC list for the bug.

More information about the libre-riscv-dev mailing list