You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Of course python's binary representation is a bit misleading here. -0b11 should actually be 0b111...1101 in two's complement.
So actually -0b11111101 would be 0b1111...1100000011 IIRC, which is 3 except not sign-extended.
So it appears that when you put a signed number in a Cat and convert that to signed, the result is not sign-extended correctly.
The text was updated successfully, but these errors were encountered:
I thought about it a bit more, and actually the result is obviously sign-extended, but I believe the issues is related to the width of the result. The result of negating an 8-bit number is a 9-bit number, and the result we get from the cat case only has 8 correct bits. Maybe there is some code that understandably but incorrectly assumes the result of a negation does not increase the width. (recall that the range of a signed number is -2^n to 2^n-1, so negating 10000000 would overflow and produce 10000000)
Is there an easy way to confirm this bug is specific to pysim? I see there are many backends, but not sure how easy it is to simulate their output from within Python, or you'd have to write say a whole Verilog testbench and run it in verilator.
What effect is .as_signed() expected to have on the Python side?
None; exactly as the comment says. Treating the bits as signed or unsigned doesn't change the bits, it changes how the bits are treated by arithmetic operations that follow.
I don't think the masking is fine.
The masking code performed by Cat is fine because Cat doesn't care about bitness at all, neither for its inputs (which it does not extend and does not perform arithmetics on) nor for its output (which is treated as unsigned). There's of course still a bug somewhere else.