[Libre-soc-bugs] [Bug 340] formal proof of POWER9 SHIFTROT pipeline needed
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Sat Sep 5 00:16:48 BST 2020
https://bugs.libre-soc.org/show_bug.cgi?id=340
--- Comment #25 from Samuel A. Falvo II <kc5tja at arrl.net> ---
I'm running into a situation where computing ((1ULL << 63) << 0) == 0 instead
of ((1ULL << 63) << 0) == (1ULL << 63).
# main assertion of arithmetic operations
with m.Switch(itype):
# left-shift: 64/32-bit
with m.Case(MicrOp.OP_SHL):
comb += Assume(ra == 0)
with m.If(rec.is_32bit):
comb += Assert(o[0:32] == (rs << b[0:6])[0:32])
comb += Assert(o[32:64] == 0)
with m.Else():
comb += DESIRED_sig.eq((rs << b[0:7])[0:64])
comb += Assert(o == DESIRED_sig) #<--- assertion fails
here.
>From what I can discover, based on GTKWave investigation, it looks like the
Rotator module is operating in mode 0, which applies both mr and ml masks to
the output. The problem is, while ml = 0xFFFFFFFFFFFFFFFF, mr is
0x0000000000000000. This means that (ml & mr) == 0, which means the actual
rotator output is also zero.
This begs the question, when invoking an OP_SHL type instruction, where
mb=me=0, should it be operating in mode 0? Should the masks be generated
differently for these types of instructions? Etc.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list