[Libre-soc-bugs] [Bug 422] Migrate away from nmigen Record

[bugzilla-daemon at libre-soc.org]

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

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |whitequark at whitequark.org

--- Comment #1 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
whitequark: i'm adding you as a cc on this bugreport.  awygle's comment
here that Record.connect is "not used" is incorrect:
https://github.com/nmigen/nmigen/pull/368

in the 75,000 lines of code in libre-soc, we make substantial use of
Record (the entire codebase relies on it), and also use Record.connect
in a number of places.

here is a count just the count of the number of base classes
(excluding inherited classes) and locations where Record is used:

soc$ find . -name "*.py" | xargs grep 'Record' | wc
    140     694   10827

we cannot make a similar cursory count for the IEEE754 FPU because the
OO inheritance and sub-object tree is 2 to 4 levels deep in places.

it would be *significantly* disruptive to the project to be forced to
modify and review 75,000 lines of code in order to remove Record, and
it would be seriously problematic if Record.connect disappeared.

also it would be disruptive to Minerva, where Record.connect is utilised
for all wishbone bus communications (and we are using that code)

(microwatt's wishbone implementation has to split incoming from outgoing
signals into separate structs and it becomes incredibly confusing:
it appears that a module using two such separate structs then has two
connections: one to a wishbone master and one to a wishbone slave,
whereas in fact it's just a single wishbone slave connection.  this
kind of confusion took over 15 minutes of detailed reading of the code
to identify).

any modifications to the IEEE754 FP library (45,000 lines of code)-
which critically depends on Record existing - come with a penalty of
requiring a *week* of 100% CPU on high-performance machines to run
several hundreds of thousands of unit tests and regression tests.

the bottom line is that it would be substantially detrimental to the
entire project in time and resources to deal with this, particularly
right when we have an upcoming tape-out deadline in October 2020.

i also feel compelled to point out that it is of some significant
concern to hear of major design decisions to remove critical functionality
for the first time via 3rd hand notifications where none of our team have
been involved or consulted as to the implications, and, on inspection
of the conversation logs to find that the people making the analysis and
major influential input (awygle) have clearly never looked at any of
the 75,000 lines of code that has been developed under NLNet's funding remit.

this is not a small project with a small impact.  Hugh, the former
Director of the OpenPOWER Foundation, informs me that it will be the
world's first new independent POWER9 design to go into silicon in
*ten years*.

i would welcome your input as to how we can move forward here in an
inclusive way.

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