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

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=713

--- Comment #80 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #78)
> (In reply to Luke Kenneth Casson Leighton from comment #74)
> > the problem is that you've defined lane_shapes to *be* the
> > sum total of the element width *times* the part_count.
> 
> no, i didn't. a lane (minus padding) *is always* a single element.

ok whew, that's what i'd expect.

>  a lane
> for one elwid (including padding) is split into multiple smaller lanes for a
> *different* elwid.
> > 
> > * for an element width of e.g. 16
> > * and for a part_count[2] == 2
> > * you require lane_shapes[2] to be **32** not 16
> 
> lane_shapes[2] = unsigned(16) for an element shape of unsigned(16).

just 16.  not unsigned(16).

> 
> lane_shapes *never* includes padding.

yes agreed.  this makes sense.

> > 
> > this makes no sense, and is completely counterintuitive.
> > 
> > part_count defines the number of partitions in each elwidth
> > 
> > lane_shapes naturally should define the *individual element*
> > width *not* the element width times the number of partitions.
> 
> yup!
> 
> > otherwise that information bleeds back into the actual usage
> > and it becomes impossible to define a transparent API that
> > allows dynamic SIMD or Scalar compile-time switching
> 
> Yup!

nggggh so why does the example i added where lane_shapes=None
calculates this based on same part_count and fixed_width=32:

0: 32
1: 32
2: 16
3: 8

but then the partition cpart_wid gets computed as completely
wrong, like 32 32 8 2 or something.

can you take a look?

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