[libre-riscv-dev] Possible nMigen Milestone?
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon Jan 6 20:47:09 GMT 2020
On 1/6/20, Immanuel, Yehowshua U <yimmanuel3 at gatech.edu> wrote:
> I found some of the NlNet milestones here and realized a number of them are
> related to nMigen features.
> Since I have plenty experience in nMigen, I’ll start working on those next
> This got me thinking - I’ve been working on the verilator backend for nMigen
> - could this be a possible milestone?
*some* nmigen modifications were part of the proposal, these were
primarily for staf verhaegen, for example the fact that nmigen does
not and will not - ever - support ASICs (no "X" in signals), until the
point where someone *actually* tries to *do* an ASIC.
below sounds to me like it is its own project, in its own right, and
there's clear benefit to it. staf even contacted me yesterday just as
you were mentioning the verilator work, "i'd really like to see nmigen
with better verilator support".
now, we have two possible approaches:
1) squeeze this in to an existing project. we can potentially get
away with this if the (remaining) work needed is small and *clearly*
fits *directly* into it.
2) put in a new funding application.
either way we will need to talk to Michiel from NLNet.
> The way the verilator backend works is:
> 1. it first has nMigen emit verilog
> 2. it then collects all the port signals from the hdl.generate.verilog
> 3. it generates verilog dpi read/write functions for all these signal
> 4. it generates corresponding C DPI access functions
> 5. all this is built into a shared object with verilator and imported with
> python Ctypes(all the wire/signal sizes are analyzed to make sure that
> python passes arrays of correct length for longer signals etc.)
> 6. All the Tick(), Setlle(), Delay() etc. commands are re-implemented
> according to whitequark's original PySim spec.
what's been done, what's left, and how long will it take to completion
for stable production use?
More information about the libre-riscv-dev