[Libre-soc-bugs] [Bug 713] PartitionedSignal enhancement to add partition-context-aware lengths

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sun Oct 10 11:51:40 BST 2021


--- Comment #60 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #58)
> (In reply to Luke Kenneth Casson Leighton from comment #56)
> > i am still mulling over how and whether Par...^W SimdSignal
> > can be adapted to support elwidths but also as a default
> > option create full power-2 partitions and cover all
> > permutations currently covered by PartitionedSignal.
> oh, well all permutations currently covered by PartitionedSignal (at least
> add/sub/logic-ops) are waay more than just the aligned, power-of-2 lanes.

yes, i know.  that's covered in

and it is covered by the enhancements to the layout() adapter function
i describe in comment #53.

the example in the (new) wiki page is a cleanup of the example in comment #2

there are actually NINE (nine!) underlying partition points created by
that innocuous-looking example.

so it looks like we need a completely insane 2^9 (512) permutations, right?


there are only three in that example.

* elwidth=32
* elwidth=16
* elwidth=8

and that's where the adapter comes into play.  it defines what the switch
is, it defines the cases.

you DO NOT need a switch taking a 9-bit input

you DO NOT need a massive batch of 512 case statements

i wrote an adapter which covers the existing PartitionedSignal behaviour:
please take a look at the patches 
from comment #56 to understand it.

the "Elwdith" adapter is conceptually finished as well, based on the
code in comment #53.

> This may take a little more work to decode, and be more wires for
> part_starts, but it covers everything that both the simd_signal code I wrote
> and the layout() in comment #20 can do. it covers everything PartitionPoints
> can do, too,

jacooob: we're *not* throwing away code, we're *adapting* and slowly morphing
*existing* code, one incremental step at a time.

this is the project's base-line operating protocol

this means that we go from one known-tested to another known-tested
without scaring ourselves by taking on too much.

it does mean however that you need to have a full working knowledge of
the *existing* design.

> though we'll probably still want to restrict lanes to be
> aligned,

the Elwidth adapter from comment #53 is predicated on the fundamental
assumption that all elements start on power-two boundaries, yes.

> simd_signal.SimdPartMode.is_valid can be adapted to create a circuit used to
> feed into an Assume to get only valid part_starts combinations (checks that
> lanes are sized correctly, and are aligned correctly).

you're confusing me with a new design when my entire mindset is focussed
on the existing design.

if you describe things to me in terms of how the EXISTING design is
code-morphed *INTO* the proposed new design - not replaced by - CHANGED INTO -
i will be able to understand.

feet on the ground, jacob.

rename is done, btw.

commit df93b8f37bea53917d67e87ce2190981bc2ef667 (HEAD -> master, origin/master)
Author: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
Date:   Sun Oct 10 11:35:20 2021 +0100

    big rename PartitionedSignal to SimdSignal (shorter)

You are receiving this mail because:
You are on the CC list for the bug.

More information about the libre-soc-bugs mailing list