[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 #75 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
arrgh, ok now i understand what's going on, it's possible to identify
that this is fundamentally broken:

    # compute a set of partition widths
    cpart_wid = [-lane_shapes[i] // c for i, c in part_counts.items()]
    print ("cpart_wid", cpart_wid, "part_counts", part_counts)
    cpart_wid = -min(cpart_wid)

for the example given 

    part_counts {0: 1, 1: 1, 2: 2, 3: 4}
    widths_at_elwidth = { 0: 5, 1: 6, 2: 12, 3: 24}

it creates:

    cpart_wid [-5, -6, -6, -6] 

and produces a minimum of 5 for cpart_wid.

whereas what is required is:

    part_counts {0: 1, 1: 1, 2: 2, 3: 4}
    widths_at_elwidth = { 0: 5, 1: 6, 2: 6, 3: 6} # NO part_count mul-factor

and then for the results to be:

    # elwidth=0b00 1x 5-bit     |    unused                   ....5 |
    # elwidth=0b01 1x 6-bit     |      unused                .....6 |
    # elwidth=0b10 2x 12-bit    |  unused           .....6 | .....6 |
    # elwidth=0b11 3x 24-bit    | .....6 | .....6 | .....6 | .....6 |

and therefore there to be ***FOUR*** partition points ***NOT***
14 as is currently the case by defining the base width to be 5

                                v        v        v        vv       v
    # elwidth=0b00 1x 5-bit     |        |        |        || ....5 |
    # elwidth=0b01 1x 6-bit     |        |        |        | .....6 |
    # elwidth=0b10 2x 12-bit    |        |        | .....6 | .....6 |
    # elwidth=0b11 3x 24-bit    | .....6 | .....6 | .....6 | .....6 |

the partition points created should therefore be at:

* 0 (which gets deleted, later)
* 5 (to fit the single 5-bit value when elwidth=0b00)
* 6 (to fit the single 5-bit value when elwidth=0b01 and all other
  1st elements
* 12 and 18 (to fit the other 2 elwidths 0b10 and 0b11
* 24 (which gets deleted, later)

layout as designed creates something absolutely mad, something
in excess of 14 partition points!

test elwidth=0
(0,
 ([1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0],
  64,
  {0: 5, 1: 6, 2: 12, 3: 24},
  16,
  4))

creating that compact set is a lot more involved than simply selecting
the minimum width and dictating that all partitions shall fit onto
an aligned boundary that must always begin at a multiple of that
minimum width.

intuition tells me it should probably be the other way round: start
at the maximum element width and subdivide all others to fit into
that.  round up all element widths within an elwidth to that max
value.  assume all partition counts are power-of-two, and i think
this is the basis of an algorithm that would slot everything onto
suitable "shared" boundaries.

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