[Libre-soc-dev] my current plan regarding simdsignal

Jacob Lifshay programmerjake at gmail.com
Fri Oct 22 01:00:48 BST 2021

I'm planning on implementing Slice next, but, a prerequisite to that is
improving the PartType and layout APIs to get them into a shape where I can
use them effectively.

Slice's result requires layouts with padding: a[3:5] mean all elements in
the result must have shape unsigned(2), which the PartitionPoints without
padding can't represent.

Because we are leaving layouts with padding for things more complex than
just plain elwid for SimdSignal 2.0, I will be implementing Slice just for
the elwid-based PartType, and not for the PartitionPoints-based PartType.

Planned incremental PartType improvements:
move elwid/mask to separate class (called SimdMode) (one instance is shared
among all SimdSignals in an ALU), separated from an individual SimdSignal's
layout. Add member for vec_el_counts.

(optional, maybe leave for later): Replace uses of SwizzleKey with
SimdMode. Delete SwizzleKey.

Change ElwidPartType into holding layout description, at least lane_shapes
and fixed_width and a reference to the ALU's single SimdMode instance.
Remove psig member.

Change SimdSignal to hold reference to ElwidPartType as the source of truth
for all elwid/mask and layout information, partpoints transforms into a
property returning ElwidPartType.ppoints.

Rename ElwidPartType to SimdLayout.

Inline layout() into SimdLayout's constructor, changing its results into
member variables.


More information about the Libre-soc-dev mailing list