[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
Thu Oct 7 23:33:30 BST 2021


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

--- Comment #34 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #32)

> what are the implications of that being a nmigen AST
> code-fragment rather than a plain slice on a Signal...
> i'll have to think that through.

got it.

it wasn't actually whether it's a code-fragment or not at all
(which comes with inherent risks of AST Expression duplication
which yosys can *in no way* properly handle and optimise away)

it was the submodules.

example:

https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part_ass/assign.py;h=00cebc6dab33a25f93d4e790dd7883fc859bae9e;hb=HEAD#l88

that Switch, to support elwidths, would become Switch(self.elwidth)

the next problem is: how do you now reduce the number of Case() statements
needed to four, or, more to the point, on doing so which bits of data do
you copy from which partition, without the prerequisite information?

turns out that *if* you have the binary values (integer values) associated
with the respective elwidth value, that is exactly what is needed.

which is why i asked for it (as the 2nd function).

now, i believe it may be possible to adapt layout() very easily, by making
it a two-stage process.

stage 1:

add_p becomes:

    points[p] = points.get(p, []).append(i)

stage 2:

    a post-processing phase that goes through each list:
    points[p] = map(lambda i: elwidth == i, points[p])
    points[p] = reduce(points[p], operator.or_)
    (or better, use nmutil.treereduce, there)

stage 3:

   a second postprocess on a copy of points which does
   a bitwise shift-and-or
    points[p] = map(lambda i: 1<<i, points[p])
    points[p] = reduce(points[p], operator.or_)

which i *think* should create the binary values needed
which represent the settings of when elwidth==i

urrr...

maybe not.

no.  drat.  it's the order, the bit-position, depending on
the length of p.

something more like:

  plist = list(points.keys())
  for i in range(max(elwidths)):
    bitp[i] = 0
    for p, elwidths in points.values():
    if i in elwidths:
       bitpos = plist.index(p)
       bitp[i] |= 1<< bitpos

that's more like it.

that gives a binary value which should match exactly with
the PPs that light up should an elwidth be set to any of its
four values.

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


More information about the libre-soc-bugs mailing list