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

[lkcl]

On October 28, 2021 3:26:12 AM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:

>That apparent unworkability is the result of still conflating two
>unrelated
>things that coincidentally have the same value: overall simd width, and
>the
>width of an element for elwid=64.

in order to *make* downcasting work, i have *defined* the overall width to be exactly equal to the underlying signal width, including, obviously, any padding.

it is thus defined because that is the width of the self.sig member.

thus, downcasting becomes a simple matter of returning self.sig.


when there is an elwid=0b00 which is the "request to treat the underlying sig member as a 1x 64 bit value" it is NOT necessarily the case that this is equal to len(self.sig) because there are other elwids that could be 2x36, 4x18, 8x9 etc.

however when that occurs, it is the developer's responsibility to be aware of it.  they specified the vec_el_widths that way, they take responsibility for dealing with the fact that layout() will compute a much larger len(self.sig).  max(1*64, 2*36, 4*18, 8*9) i.e. 72 not 64.

you are overthinking this and trying to "protect" developers from themselves.


> In actuality, it works just fine for
>SimdShape.width to be multi-valued,

no, it is not, unfortunately, because that bleeds down into nmigen scalar behaviour when a developer accesses width assuming (quite reasonably) that it is Shape.width, because that is what it is: an integer.

SimdShape.width === Shape.width

look at the constructor for SimdShape.

l.