[libre-riscv-dev] Possible nMigen Milestone?

[Luke Kenneth Casson Leighton]

(still going into spam btw, i suspect there's something weird about
the combination of gatech.edu email going through libre-riscv.org
mailman)

On 1/6/20, Immanuel, Yehowshua U <yimmanuel3 at gatech.edu> wrote:
>> what's been done, what's left, and how long will it take to completion
>> for stable production use?
>
> Steps one through 5 work. Tick() and Settle() in 6 work.
>
> **Remaining Tasks:**
>
> 7. Support for multiple synchronous domains in waveform generation
> 8. Timekeeping for writing waveforms
> 9. Plugging Pysim into verilator backend for to evaluate expressions inside
> yield - fairly low priority

ok.  well let's keep an eye on things because if those don't require
say... 2-3 months to complete, and we really need them, i'm sure they
could be added under a pre-existing project.

> I’ve been communicating with Whitequark and I think Verilator backend would
> be upstream and production ready by the beginning of March if not earlier.

that's absolutely fantastic news.

> I should also add that whitequark is adding a C++ yoys(CXXSim) based backend
> that has been shown to be reasonably fast in its own right.

ah goood.

> I thought the verilator backend might solve the problem with needing to
> convert verilog to nMigen -

we don't *have* to - ok, that's not quite true: we picked ariane
source code to use / convert because it's so well-written and has
L1/L2 cache etc. infrastructure that we could really do with not
having to rewrite.

however it's using proprietary Mentor Graphics modifications to SV
that standard IEEE authorised SV simply does not support.

> but I now know that is not the case.
>
> So the only advantage I see the verilator backend bringing to the table is
> its multithreaded capabilities which might come in handy with later
> arithmetic intense simulations.

ohhhh yes.

the cycle time on e.g. FPDIV is around 2 sim clocks per second, and
the partitioned INT multiplier is around the same.

that's *without* the partitioning, and without even linking any of
this together into an actual processor.

*combine* the partitioned INT mul code into say FPMUL or FPMAC and we
could well be looking at seconds to tens of seconds per sim-clock
tick.

the simulation times, without some kind of drastic performance
increase, are going to be awful :)  so i am veeery glaad you and
whitequark have been working on this.  it'll just be around the right
time, too.


l.