[Libre-soc-bugs] [Bug 731] potential design oversight in Partitioned SimdSignal Cat/Assign/etc lhs/rhs

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Fri Oct 22 00:21:59 BST 2021


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

--- Comment #23 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #20)

> For things like Cat(a[30:50][2:10:2], b, Repl(c[23], 5)):
> SimdSignal will generate 8(!) layers of muxes (on the order of 2-4000
> gates!), whereas SwizzledSimdValue will generate only 1 layer (since that's
> what it always generates)

ok.  so - finally - it emerges what the purpose (and value) of
SwizzledSimdValue
is.

anyone else who did not also have Asperger's would say something stupid
(like they did to me, and i found it terribly discouraging), along the lines
of,
"well why the bloody hell didn't you explain this initially??"

the idea - complete idea - sort-of "emerged" in your head, fully-formed,
solving multiple problems at once, and the full list of things it solved
were so overwhelming that you *couldn't* explain them all at once, could you?

(i cannot count the number of times over the past 30 years that this happened
to me.  you are extremely lucky that i recognise it).

so.

what i learned to do was to say this:

"i have a solution, but it solves so many things that i can't explain all
of them immediately to you.  even if i write this in 4 hours flat it will
take about 2 days to 3 weeks for me to even grasp fully what *i* have solved
in a way that allows me to explain it. i need to put together a
proof-of-concept, which can be analysed retrospectively: is that ok?"

because i recognise this syndrome ("ideas emerging fully-formed") i have
no problem at all with you saying that.  [corollary: where i _do_ have a
problem is if you go ahead *without* saying that, because it severely
disrupts planning and task prioritisation].

i will put together a new bugreport, and what i will do - and i need you
to understand and accept this - is to put together a series of tasks
outlining necessary test suites and other blocking tasks that it is
*essential* that are completed first because SwizzledSimdValue is categorised
as an "optimisation" not an "essential", where the existing classes
"already do the job" and allow SimdSignal to be signed off and thus move
off of critical path.

those test suites - all of which can be added right now - do not have
to pass with version 1 code: they do have to be written though.  those
unit tests will be essential to proving that the ALU code is not going to
be disrupted by a drop-in replacement in the form of SwizzledSimdValue.

in particular, the unit tests must include the 2 different PartTypes
(one "existing" PartitionedSignal behaviour, covering all permutations,
one "elwidth" behaviour.  i expect SwizzledSimdValue to pass 100% all
unit tests with *both* PartTypes, and that means that the unit tests
need to be augmented - beforehand - to show that *existing* SimdSignal
with both types of behaviour - also work 100%.

i also have no problem at all with you putting in "this is planned to
be replaced with version 2 code, see bugreport XYZ" *as long as you
actually help do the version 1 code*.

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


More information about the libre-soc-bugs mailing list