[Libre-soc-dev] [OpenPOWER-HDL-Cores] bug in libre-soc "modsd" and possibly in microwatt as well

[Benjamin Herrenschmidt]

On Tue, 2020-08-25 at 14:48 +0100, Luke Kenneth Casson Leighton wrote:
> On Sun, Aug 23, 2020 at 2:55 PM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
> 
> > which now leaves me *really* confused because in that debug int
> > regfile dump you can clearly see r0 == 0xff not 0x7fff_ffff yet the
> > answer being returned in r17 is "0x1".
> > 
> > this leads me to suspect that there's something wrong with the DMI FSM
> > i created.
> 
> found it, sigh.  the FSM that issues the DMI "GPR ADDR set" was being
> corrupted by a prior command, leaving the core_debug.vhdl address at
> its previous value, which happened to be 31 (from the end of the loop
> of getting int regs 0-31).  thus the value reported for int reg 0 was
> in fact reg 31.
> 
> sigh.
> 
> fixed it and also added a better FSM, one that now waits for "core stopping".
> 
> paul, mikey: i am however noticing that _some_ operations - div, mul,
> shift in particular - simply do not report their values correctly even
> after "stabilisation".  only after the *next* "STEP" does the regfile
> update and the correct values can be enumerated.
> 
> this is... slightly annoying because a comparative diff
> (cycle-accurate) is impossible.  can this be fixed in microwatt, such
> that any outstanding pipeline operations are not paused and are
> allowed to complete and update the regfile?

Hrm.. this could have bitrotted... normally we wait until the pending
ops is 0 in decode2, which I would assume means we have committed the
results to the reg file. Paul, are we failing to track these multi-
cycle's completion properly in ctrl ?

Cheers,
Ben.