[libre-riscv-dev] [Bug 276] SR NAND Latch needed in nmigen

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=276

--- Comment #6 from whitequark at whitequark.org ---
> yes.  this i _believe_ is what Staf has implemented for us, in the nsxlib Cell Library: http://bugs.libre-riscv.org/show_bug.cgi?id=154#c21

If your designs are already using $sr cells then the cxxsim approach would be
ideal.

> ah then that's worthwhile investigating straight away.  are there examples anywhere?

Yes, in the pull request introducing the backend (which is not yet merged, I'm
adding some polish to it right now):
https://github.com/YosysHQ/yosys/pull/1562. The examples are a bit sparse but I
think the developers working on this project will have no issues figuring
things out (or just ask me).

The general idea behind cxxsim is to be as straightforward translation of RTLIL
to C++ as possible. Of course, RTLIL is not imperative, so some extra logic is
necessary.

This extra logic isn't something I invented myself, but rather I took the
well-known VHDL two-phase simulator that provides deterministic* results
regardless of evaluation order, even for combinatorial loops, and adapted it to
RTLIL. Some VHDL developers call it "the crown jewel of VHDL" and I concur, it
is an excellent algorithm.

* The "deterministic" in reference to this simulator means that the results are
the same regardless of the order in which the (parallel) RTLIL is translated to
(sequential) C++, taking that one step out of consideration when debugging your
code. If your design is inherently racy, you will get nondeterministic results
anyway.

> using e.g. cocotb (a python co-simulator which compiles verilog using verilator and then annotates and interacts with it from python) was on the cards.
> out of interest would that be feasible using cxxsim (either as an addition
to cocotb or as a separate project)?

So, I'm working on two different patches, which are somewhat confusingly named
"cxxrtl" and "cxxsim".

Cxxrtl is an addition to Yosys that allows it to emit C++ simulating virtually
any valid RTLIL, similar to Verilator but more flexible. (Verilator doesn't
support asynchronous logic at all, cxxrtl does, at a fairly significant
performance penalty if you have any in your design.) Cxxrtl is largely
finished; it has been used for simulating medium-sized SoCs and I expect it
would not present any issues for your codebase as long as you stick to
synchronous logic only.

Cxxsim is an addition to nMigen that would do basically the same thing as
cocotb, but present an interface identical to the existing pure-Python
simulator. Cxxsim does not yet exist. It is however fairly high on my list of
things to do.

For now I suggest that you simulate your code using a C++ testbench to see what
sort of performance you get, and running simple acceptanace tests to see if
there are any glaring issues in cxxrtl that break your design. I think there is
no point writing code to integrate cxxrtl with cocotb; cxxsim is about as much
effort, and will let you use your exiting testcases unmodified.

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