[Libre-soc-dev] SimdSignal update

[Jacob Lifshay]

On Wed, Oct 27, 2021, 02:58 lkcl <luke.leighton at gmail.com> wrote:

> On October 27, 2021 9:32:05 AM UTC, Jacob Lifshay <
> programmerjake at gmail.com> wrote:
> >Since XLEN-based arithmetic may end up with a
> >inconsistent/garbage/non-existant value for fixed_width, I decided to
> >name
> >it SimdWHintMap.width_hint instead.
> >
> >The idea is that SimdShape will check if width_hint looks sane and, if
> >not,
> >ignore it and use the width calculated from element widths like usual.
>
> unfortunately, that won't work.  you should have raised this before
> proceeding: now it needs reversion because it is a fundamental and
> unauthorised change to the API.
>

As you noticed in the follow-up emails, what I actually committed is purely
an addition of new API, existing API is unmodified.

>
> when something is set to e.g. 64 bit fixed_width, it has to be actually
> and truly 64 bit.
>

Well, maybe you missed it, but when you have element widths set to XLEN
(the case for all ALU I/Os that are SimdSignals) you're *guaranteed* to get
a 64-bit full simd width (assuming el-counts are as expected), *even if
there's no fixed_width logic whatsoever*.

This is because it would use the minimum required width, which is 64-bits
because it includes an el-width of 64-bits for I64 or F64.

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.

So, the only function that the fixed_width/width-hint logic does that isn't
covered by element-width logic is purely optimization: reducing the amount
of muxing needed due to elements lining up better in intermediate
SimdSignals.

Since optimization is the only function it provides, a hint is sufficient.

That said, the SimdWHintMap class I just wrote needs some adjustment to get
the best value of width_hint, it currently computes the wrong value for
XLEN + 1.

Jacob

>