[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 #99 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
ok that's done.  i was able to keep the documentation / glossary
because it was prior to the conversion to a class.

now.

i finally understood that you've been specifying part_count as
the number of bytes.

this will restrict the layout and create too many partition points
(14 rather than 5 in the case of the 5-5-6-6 example).

i've *partly* fixed that with a 1-line commit:

commit 6a50b2d1649fbf1f22be783eaa5ebbb9cdf72f64 (HEAD -> master)
Author: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
Date:   Wed Oct 13 12:51:09 2021 +0100

    redefine part_counts to be "number of vector elements in a partition"
    fixes the bug

it removes the divide operation:

-    cpart_wid = [-lane_shapes[i] // c for i, c in part_counts.items()]
+    cpart_wid = [-lane_shapes[i] for i, c in part_counts.items()]

therefore, actually, cpart_wid probably becomes just max(lane_shapes.values())

-    cpart_wid = [-lane_shapes[i] for i, c in part_counts.items()]
-    print("cpart_wid", cpart_wid, "part_counts", part_counts)
-    cpart_wid = -min(cpart_wid)
+    print("lane_shapes", lane_shapes, "part_counts", part_counts)
+    cpart_wid = max(lane_shapes.values())

yep, that works.

now, next thing: fix the documentation as well as rename part_counts to...
to... vec_el_counts so as to avoid this confusion.

vec_el_counts is "the number of vector elements required at each elwidth"

... done

commit 74ec642c0f4eb67a80b785a191ae11875416300a (HEAD -> master, origin/master)
Author: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
Date:   Wed Oct 13 13:06:25 2021 +0100

    rename part_counts to vec_el_counts
    to indicate that it is intended to be the count of the number of vector
    elements within a partition

so now there is just one bug remaining:

5,6,6,6 elements {0: 5, 1: 6, 2: 6, 3: 6}
lane_shapes {0: 5, 1: 6, 2: 6, 3: 6} vec_el_counts {0: 1, 1: 1, 2: 2, 3: 4}
width 24 6 4
dpoints
{5: [0],
 6: [0, 1, 1, 2, 3],
 11: [0],
 12: [0, 1, 1, 2],
 17: [0],
 18: [0, 1, 1, 2],
 23: [0]}

the bug is: 11, 17 and 23 should *not* have partition points.  there
should only be one element added at elwidth==0, but instead *FOUR*
are being added.

* when elwdith=0 the vec_el_count is 1 so one is being added from 0-5
* but there is also one being added from 6-11
* and another from 12-17
* and another from 18-23

also, i see only one when elwidth==3.

so it is inverted.  i will see if i can fix that.

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