[Libre-soc-bugs] [Bug 583] Implement simple VL for-loop in nMigen for TestIssuer
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Sun Feb 7 01:16:49 GMT 2021
https://bugs.libre-soc.org/show_bug.cgi?id=583
--- Comment #23 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #22)
> It works!
ha! totally awesome!
> No regressions that I could see.
>
> I had to add a register between instruction memory and decode, but I think
> it's a good thing, despite taking an extra cycle.
yeah not a problem. we're not focussing on performance at the moment.
there is a way to not need the extra cycle, you get each stage of the
FSM to place the data combinatorially, so that the "users" of that data
have it available immediately. it does however make things a bit messy.
fascinatingly, if you look at the diff, it's a very clean separation.
ok so _now_ the SVP64PowerDecoder can be added (combinatorially) in
fetch_fsm, which analyses the incoming 32-bit instruction.
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/power_decoder2.py;hb=HEAD#l1284
then if the "is_svp64_mode" is set, take a copy of svp64_rm first (in a
register), read another 32 bits, and pass in the svp64_rm into the
PowerDecoder2 (self.pdecode2).
that should still do absolutely nothing: zero impact (no regressions)
oh one minor complication: the PC must *not* advance even though reading the
next 32 bits. the PC *must* still point to the start of the 64-bit operation.
this is going to be slightly complicated... actually maybe not, because
branches and traps are not possible to SV extend.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list