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

[bugzilla-daemon@libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=271

--- Comment #8 from Luke Kenneth Casson Leighton <lkcl@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. 

great.

> 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:
    pass

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

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.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev