[Libre-soc-dev] SimdSignal scalar/vector switching and SimdShape.width

[lkcl]

On October 29, 2021 2:43:51 AM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:

>An additional benefit of routing the full-simd-width access logic
>through
>either introspecting the underlying signal or through
>SimdScope.full_width
>-- and also having SimdShape.width be the element widths is that it
>makes
>it nearly trivial to make a 32-bit or a 128-bit, also scalar or vector
>ALU
>merely by changing SimdScope's settings, all of our ALU code won't need
>to
>change one bit.

look again more closely at the constructor and in SimdSignal.  i will update it with a comment.

what you expect, this is already handled.

i repeat: i have already handled this.

i repeat: the code as written has the behaviour that you expect

(remember: 18 months planning to design something that is, exactly as you expect, not going to need massive ALU changes, you would think i would come up with something, in that time, that doesn't need massive ALU changes! :) )

it works by putting fixed_width into the layout() function and the width parameter into the vec_el_counts parameter.

because the width parameter, when it is an integer, gets expanded to a dict {0b00: wid 0b01: wid ...} this gives the exact expected behaviour you describe above where scalar ALU code does not need modifying (elwidth priority)

layout *outputs* a fixed_width (not to be confused with the *input* parameter of the same name, which is then stored in the Shape.width in order to meet downcasting requirements)

therefore, exactly as you say and expect, the requirements are met.

it is just met in a different way from what you may have envisaged.

now, what is "odd" is that the parameters get swapped about.  the fixed width and elwidths are "decoupled" in effect from the resultant (computed) widths.

this is down to meeting other requirements (downcasting) and that "disconnect" is precisely why the 2-bit mode flag is needed.

you cannot determine just by looking at the *computed* fixed with or elwidths whether the input parameters were fixed or elwidth priority, hence the need for the flag.

l.