Bug 73 - all nmigen module-based classes now need to derive from Elaboratable
Summary: all nmigen module-based classes now need to derive from Elaboratable
Status: PAYMENTPENDING FIXED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks:
 
Reported: 2019-04-23 09:28 BST by Luke Kenneth Casson Leighton
Modified: 2020-12-06 14:06 GMT (History)
1 user (show)

See Also:
NLnet milestone: NLnet.2019.02
total budget (EUR) for completion of task and all subtasks: 500
budget (EUR) for this task, excluding subtasks' budget: 500
parent task for budget allocation: 191
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:
"lkcl"={amount=500, paid=2019-06-16}


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2019-04-23 09:28:38 BST
this is already going to be a *lot* of work, it would be good to
tackle this as a team (everyone pick a file, perhaps coordinate
on freenode #libreriscv)

the constructor (__init__) does not need calling, it is a metaclass,
it just needs to be added:

class RecordTest(Elaboratable):

wherever there is a def elaborate(....)
Comment 1 Luke Kenneth Casson Leighton 2019-04-25 13:28:38 BST
turns out that this has knock-on ramifications for the pipeline API.
anything that's used in the incoming or outgoing data, that happens
to be a module, *has* to be added as a submodule to its parent,
otherwise warnings are thrown.
Comment 2 Luke Kenneth Casson Leighton 2019-06-16 13:23:18 BST
split out FPNumBase into FPNumBaseRecord which is not derived
from Elaboratable, then passed that in as an argument to
FPNumBase, FPNumIn/Out and others that needed some module
work.

Overflow - just made it no longer a module.