[libre-riscv-dev] [Bug 333] investigate why CR pipeline code took 100% CPU and locked up generating ILANG

[bugzilla-daemon@libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=333

--- Comment #12 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #11)
> Luke, there's not a way to do something like a C union in nmigen is there?

no, you just push bits around.  it's up to the recipient to have the required
state to correctly interpret them.


> I'm thinking for the CR pipeline to have it put one or two of the crs in the
> 32 bit cr input for the cases where it doesn't need the full cr as input.

mmmm that again involves "lane crossing MUXes" at the operand buses.  it is
slightly better in that it is not crossing a regfile but it is still
nontrivial.

however the (planned) cyclic buffers now become even more complex, because each
register could contain two values not one.

oh, i saw the CSV changes, adding the extra field.  i was going to suggest
simply using src1 src2 src3, by adding "CR" type to the Reg Enum :)

(sorry for not mentioning that sooner...)

then if src1 is CR and op is.. whatever, then DecodeA drops the BFA field
(whatever) into... mmm... rega.cr_out

etc.

the CRin field just added could be part-used for that purpose.  it contains in
effect the same information, without needing the OP_CRXXX test at DecodeA/B/C/O

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