[Libre-soc-dev] SimdSignal update

[Jacob Lifshay]

On Thu, Oct 28, 2021, 01:46 lkcl <luke.leighton at gmail.com> wrote:

>
>
> On October 28, 2021 2:55:10 AM UTC, Jacob Lifshay <
> programmerjake at gmail.com> wrote:
>
> >If you depended on a width *hint*, XLEN would still have the hint be
> >64-bits so SimdSignals of XLEN-bits would *still* be 64-bits wide.
>
> this misses the interaction between fixed width (XLEN, 64Bit) SimdSignals
> and some temporary (intermediary) signals that will have been specified at
> elwidth priority (usually by code that is tmp = Signal(4) being converted
> to tmp = scope.Signal(4))
>

Well, those intermediate signals are defined internally to the ALU and
*aren't* part of it's external API, so, since they're always used as SIMD
signals, it doesn't matter (for correctness, not optimization) what the
underlying signals' widths are.

Since all SimdSignals in the ALU's externally-visible API are always
*exactly* `SimdSignal(XLEN, ...)` and because the shape of the underlying
signals are always completely determined *at construction time*, they will
always be exactly 64-bits (for SimdScope set as expected) because that's
what you get from XLEN with/without width_hint or fixed_width.

Therefore, fixed_width isn't necessary for correctness. A width hint is
sufficient *and preferred* over fixed_width because element widths *must
always take priority for correctness*.


Intermediate signals that need a width hint can be converted like follows:
tmp = Signal(4) becomes tmp = scope.Signal(scope.Shape(4, width_hint=64))

we can create a warning for code that uses an impossible width_hint, but
we'll need a way to disable the warning when creating SimdShapes as results
of arithmetic, i recommend a whint_warn SimdShape argument that defaults to
True.

>
> which is why a flag indicating the priority mode is needed (FIXEDWID,
> ELWID, BOTHDASHNEITHER)
>

*please* don't use the name BOTHDASHNEITHER, it's unreadable. use
BOTH_OR_NEITHER instead.

Jacob