[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
Tue Oct 12 13:26:12 BST 2021


--- Comment #73 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
i think we're slowly getting to the bottom of where the assumptions
are that caused you to believe that it is impossible to use nmigen
with such tiny modifications (and to believe that it is undesirable
to do so).

it revolves around elwidths and the definition of Shape.width.

the past 18 months work have been fundamentally based on the assumption
that it is, by design, possible to fit.  much of that time was spent
verifying that that was possible.

the assumption / definition and all code is based on:

Shape.width == SimdShape.width == len(SimdSignal._its_internalsignal)

we need - and other users will expect - that Casting will "just work".
SimdSignal should be castable to Signal and all bits *directly*
copied (including unused padding partitions) seamlessly at the bitlevel.

likewise Record, and other nmigen constructs (sigh yes we need to do
a SimdRecord at some point. not a priority]

this *is* how nmigen works.  all Value-derivatives *are* copyable
from one to the other by making the fundamental assumption that
when converted to bitlevel they are all effectively "the same".


this is Signal.like():

1066         kw = dict(shape=Value.cast(other).shape(), name=new_name)
1067         if isinstance(other, Signal):
1068             kw.update(reset=other.reset, reset_less=other.reset_less,
1069                       attrs=other.attrs, decoder=other.decoder)
1070         kw.update(kwargs)
1071         return Signal(**kw, src_loc_at=1 + src_loc_at)

fundamentally for that to work it is *required* that SimdSignal
have a shape() function that returns a Shape() or Shape-derivative.

the *entirety* of PartitionedSignal (now SimdSignal) is *fundamentally*
designed on this principle.

the element widths are an addition that is *our* problem to conceptualise
and deal with, and as they are our problem they need to take second
priority when fitting onto nmigen base-level pre-existing concepts.

this is standard textbook OO design, and with nmigen being so well
designed it's remarkable and fortunate that this is even possible.

if however we choose to define the *element* width as the priority
then we are in deep s*** basically because it would require a catastrophic
cascade of modifications to nmigen *and* abandonment of 18 months of

i am extremely good at identifying these kinds of "minimum retrofit"
opportunities, i have been doing it for 20 years, and it would be foolish
not to exploit them (even if the lead developer does not wish us to, and
reneged on an agreement to consider so)

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

More information about the libre-soc-bugs mailing list