Hi, this is best described on a forum rather than IRC.
We are developing a pipelined IEEE754 FPU which handles not just FP16, FP32, FP64, it also handles integer computations and also predicated SIMD operations of all types of operations and bit widths.
What we are not going to do is lay down multiple separate pipelines for each bitwidth: instead we have designed a partitionable adder and a partitionable wallace multiplier because doing so saves a huge gate count percentage.
By "partitioning" we mean dynamic partitioning, so that a runtime bitmask is passed in to say "hey in this cycle the ADD is going to be one big 64 bit ADD" then in the very next cycle it will be told to do 8x 8bit adds.
The thing is: the pipeline code for the non SIMD ALUs is complex enough as it is. The absolute last thing we want is to duplicate that code and have multiple code paths for each operation, each and every line of code being replaced laboriously with a partitioning decision tree.
The solution that we came up with is to create a NEW Signal type - derived from Signal - called PartitionableSignal. It will have parameters which point to another signal (a bit mask) that will dynamically do the partitioning.
We will need operators for everything listed in Value. xor, eq, ge, lt, shift, add - everything.
My first thoughts are that each function add etc would return something a little more complex than just Operator("+", .....) instead it would call a function that returned something which checked the current partition bitmask etc. you get the general idea.
Once we have a PartitionableSignal class, it really should just be a matter of replacing all arithmetic occurrences where Signal is currently used, and the existing ALU pipelines should happily spew out runtime partitionable SIMD capable code.
No we cannot use Arrays because Arrays are not dynamically reconfigureable.
We could try this from "outside" of nmigen (no new type, not derived from Value). This might work.
What I am hoping is that it will not be massively invasive.
One problem that I foresee is that if we derive from Signal, the use of type() will prevent and prohibit the derivation from Signal from operating correctly.
However adding new types to nmigen is not something that the code is designed to cope with (no modular plugin system).