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

[lkcl]

On October 29, 2021 10:46:42 AM UTC, lkcl <luke.leighton at gmail.com> wrote:

>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)

so to support both fixed and elwidth priority, and because the width argument to SimdScope.Signal() has to, indeed, exactly as you expect (and i designed / expected 18 months ago) be the elwidth argument in order to preserve Scalar ALU context behaviour, fixed width can *not* be added to SimdScope.Signal()

why?

because fixed width is not part of nmigen.ast.Signal

which is why these commits occurred, added it then removed it

https://git.libre-soc.org/?p=ieee754fpu.git;a=commitdiff;h=fff6d9ab2de5700103e0f9c1bb9fab64233f1783

https://git.libre-soc.org/?p=ieee754fpu.git;a=commitdiff;h=87025f55f7d25f576aaead40c78b6c4e0f714666

where the one in between (creating an explicit SimdShape which *does* take a fixed_width parameter, bypassing the SimdScope.Shape context-aware API) needs some explaining.

  33         with SimdScope(self.m, elwid, vec_el_counts) as s:
  34             shape = SimdShape(s, fixed_width=width)
  37             self.a = s.Signal(shape)

note how that is NOT:

    self.a = s.Signal(fixed_width=width)

and also not:

  34             shape = s.Shape(fixed_width=width)

because, as explained above, fixed_width is not a nmigen scalar concept.

follow the chain...

1) the Pipeline APIs are established waay back, using a MixIn class that was designed 2 years ago for this kind of OO purpose i am about to describe

2) SIMD ALU inputs and outputs need to be allocated automatically, through the regspec API (depending on runtime/compiletime switch of course)

3) this point is WAY too early to create modules (every SimdSignal needs to have a module parameter) and even if you did it would be a nightmare to create a bunch of dsl.Module instances.

4) yet, the regspec API still needs to be passed the elwid parameter and thus needs a SimdScope of some kind

5) further, at the regspec point any SimdShapes() need to be established with FIXED width parameters

6) therefore, some delayed setup and decoupled initialisation is needed.

7) the context (ctx) that is part of the Pipeline API can have an extra variable added to it, or, as part of the Mixin class, a scope and other parameters (XLEN most likely being one of them, see how this gets rid of the need for globals?)

it's quite a long chain, but it means that some SimdShape()s get created *before all parameters are known*.

which means some tweaking is needed of how to bring all that together.

l.