[Libre-soc-bugs] [Bug 734] add Partitioned SimdSignal support for elwidth-based layouts (currently ElwidPartType)

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Fri Oct 22 15:28:37 BST 2021


https://bugs.libre-soc.org/show_bug.cgi?id=734

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
i put in quite a few TODO of code-comments that are missing in SimdScope

https://git.libre-soc.org/?p=ieee754fpu.git;a=commitdiff;h=a95f90848c98564d6fcb2ec48c018d2362eed2e4

one in particular stood out: it is critically important NOT to try
to treat SimdSignal as if it could potentially be a scalar.  this will
have massive detrimental implications

the idea is to completely transparently switch all code - at compile-time -
with an option to issuer_verilog.py and to test_issuer.py - between
Simd and Scalar with a single command-line option that goes directly
into SimdScope's scalar argument.

if that scalar argument is True, the ENTIRE Simd behaviour of SimdScope
must get the hell out the way, leaving the entire code base unaltered
in every way at every level, exactly as if SimdScope was never even
being used.

this allows us to test that the changes to the ALUs do in fact not
damage the code's scalar behaviour

the absolute last thing we need is to radically alter the entire
suite of ALUs, encounter a bug, and have absolutely no idea and no
way to determine if the bug was down to EITHER:

1) changes to the ALUs
2) the new SimdSignal

only by having the ability to swap SimdScope and SimdScope RIGHT
out the way do we have a means by which the distinction between
those two can be made.

that, and the amount of code created will be s*** on gate count
for scalar, punishing test_issuer in scalar mode completely
unnecessarily.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the libre-soc-bugs mailing list