[Libre-soc-dev] my current plan regarding simdsignal

[lkcl]

(ok, replied privately to jacob, addressing how he is clearly upset) it shows in some of the language you use, jacob. hope it helps provide some context and clears things up.

technical issues:

globals are always problematic.  they have specific uses (mutex/semaphores, singletons, class factories for dynamic allocation and adaptation), beyond that they are a "red flag" especially in python.

in this case, the use of a default (non-provided, null) parameter to "pick up" a global is particularly problematic.

imagine a scenario where a newcomer creates code with 400 uses of SimdSignal, only 399 of which explicitly give a SimdScope and, buried in that, 1 that does not.

it could be days before they find the error.

i literally just used the technique of not setting a default very deliberately, to find a bug i was not expecting, when adding the lhs mode function, only 2 days ago.


additionally, globals stop you from doing 2 or more things simultaneously.  we may wish to set up 2 HDL pipelines and run them through the test API side by side: a global prevents and prohibits that unnecessarily.

pain in the neck or not, i would rather we moved forward quickly and adapt if it emerges that change is needed, so that we can get off of critical path.


regarding scalar emulation: i had a think about it, it has an actual use: testing.  can you please move the code *out* of SimdScope to a "util" function rather than delete it entirely.

the test case is: to compare scalar with scalar-emulation.  this will produce simpler HDL which can be inspected with yosys "show", at the same time checking against scalar unit tests.

but no way it should go "live" (silicon) and not replace scalar-nmigen.  as i said in the bugreport: two unknowns are at work here: 1) SimdSignal 2) minor alterations to pipeline ALUs *to* allow SimdSignal to be deployed. scalar-nmigen parameter allows (2) to be tested *without* critically also relying on unknown (1)

l.