[Libre-soc-dev] dynamic simd wiki page: updated with alternative ideas

[lkcl]

https://libre-soc.org/3d_gpu/architecture/dynamic_simd/

in line with an RFC i've collated and analysed some of the many ideas proposed for implementing dynamic simd.  i recommend reading them.

whilst i don't wish in any way to be disparaging, it is unfortunately a risk that has to be taken when pointing out, plainly, that every single one of the alternative ideas is completely unacceptably costly or damaging (in multiple ways, in some cases) not just to Libre-SOC but to nmigen's reputation as well.

what is fascinating about the alternatives proposed is that absolutely every single one of them assumes that *active* explicit work needs to be performed in order to achieve the desired goal: duplication of dsl.Module, overrides of dsl.Module, replacement of dsl.Module, alternative high-level compilers, and so on.

absolutely not one single one of them look at nmigen's Type 2 (dsl.Module) behaviour, notice that it is 98%  implemented *in* Type 1 (ast.*) lower-level constructs, and exploit that fact by finishing off and cleaning up the last 2% abstraction, such that the Liskov Substitution Principle may be successfully deployed.

in a fascinating and productive discussion earlier today, whitequark implicitly (very indirectly) acknowledged the distinction between the Type 1 (ast.*) and Type 2 (dsl.Module) nmigen language onstructs, but chose - *chose* - to *define* (declare) nmigen as *being* of a single entity (single language type). i.e. although recognising the *existence* of the two types, seeks to declare that they are "internal implementation details" rather than something that is part of an external published API, that external published API being *only* one type of nmigen language construct: nmigen.

whilst this is perfectly reasonable it unfortunately leaves us in a position of having no other alternatives left.

my hope is that at some point, it will be safe to express the need for dynamic simd support in such a way that its critical strategic importance is recognised and accepted, and that efforts to prevent and prohibit us as well as other nmigen users from deploying similarly advanced Signal types are no longer attempted.

with all other options being absolutely catastrophic and/or costly and actively harmful to both nmigen and Libre-SOC, and with communication on this complex topic being quite challenging, we are in a weird "limbo" state at the moment where "progress without huge cost" - right at a critical path juncture - is only possible by working from a fork / development branch.

fortunately, the modifications required to nmigen to support PartitionedSignal as an external construct are ridiculously ludicrously small: currently a 413 line diff, 10% of which is comments, and 3% of which is a missing unit test detected by the changes made.

these miniscule strategic changes allow many other nmigen users to create highly advanced Signal types, extending nmigen far beyond its original intended design parameters, with almost no effort.

one discussion related a ComplexNumberSignal type, and its creator saw no need, at all, for the advanced changes needed for dynamic simd.

however what that individual missed was that if their ALU has both Real *and* Imaginary number support, then just like in the dynamic simd case, the lack of sharing of the underlying arithmetic gates means that they effectively are forced to use double the silicon area (or double the FPGA DSP resources).

what they could do is have the ComplexNumberSignal type have a runtime switch that, if fliicked, uses the internal arithmetic gates (which for multiply or shift are incredibly costly) to perform either twice or four times as many *Real* arithmetic computations, or to perform one computation at double the precision, through one and *only* one ALU.

then, the next phase would be to create an equivalent of PartitionedSignal which amalgamated all of those, and so on.  the next expectation is that it should conform to the nmigen AST operators, and very quickly the next expectation becomes, "you know... it would be *really nice* if this dynamic Real-Complex class worked with dsl.Module" as well.

such expectations however are terminated by an artificial prohibition that is extremely easy to overcome through the application of under 400 lines of code changes.

we need to move quickly now. Dimitry is progressing with the XLEN element width overrides and we will soon be in a position to add elwidth overrides to ISACaller.

therefore the dynamic partitioning needs to be done at the same time otherwise it will not be ready in time to deploy and cross-test in the ALUs.

l.