[Libre-soc-dev] mulhw / mulhwu in microwatt updates SO

[Luke Kenneth Casson Leighton]

On Saturday, August 29, 2020, Paul Mackerras <paulus at ozlabs.org> wrote:

> Correcting myself:
>
> On Sat, Aug 29, 2020 at 10:05:58AM +1000, Paul Mackerras wrote:
>
> > Note that the write to XERC at 3445ns is the result of the previous
> > instruction at 10358, which is "sraw.", which writes XER[CA].  The
> > mulhw. at 1035c writes back at 3495ns, and we see it writing to CR0
> > and GPR 1E (r30) but not XER.  It writes "5" i.e. binary 0101 to CR0,
>
> It writes "9", binary 1001, I mean.


just to wrap up, here: it looks like i got confused from the pipeline
latency when examining the output from core_tb.

i've re-enabled the check which stops OE from activating on OP_MUL32/H32
and can confirm that libresoc matches microwatt behaviour by ignoring OE=1
for mullw and mulhwu


all of this has me wondering if it would not be better to have an XER_in
and XER_out column in the CSV/decode1 table

for libresoc this information literally goes directly into the XER Regfile
read/write enable.

or if indeed it is more elegant (and less gates) to create a DecodeXER_In
(and out) module similar to decode_a, decode_rc etc. that uses the current
CSV/decode1 format.

in terms of "usefulness beyond libresoc" i am still mulling over which has
more value.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68