[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

whitequark at whitequark.org changed:

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

--- Comment #1 from whitequark at whitequark.org ---
(The following comment is copied from the email I sent earlier, so that it is
accessible publicly.)

Of the things you mentioned, this includes only the SR latch issue.

This issue is unfortunately quite involved. (n)Migen is designed to
connect large islands of purely synchronous logic with a few async
bridges. It does not, very deliberately, directly support arbitrary
asynchronous primitives like the SR latch. So you can't just drop one
into your design and have it work the same way normal logic works.
However, you're in luck because better support for asynchronous
signals was something I took into account when designing nMigen and
both of the new simulators, pysim and cxxsim.

To solve this issue, we'll need to work together to determine your
specific use case. Do you want to use the exact same netlist for
nMigen simulation and synthesis? If not, it means you can model
whatever it is that contains the SR latches (I'm not sure what
matrices you're referring to, here) using synchronous code, and
replace them with true SR latches for synthesis. Of course, you will
need to convince yourself these two designs are equivalent.

If you *do* want to use the exact same netlist, there are a few
options. Both the new nMigen simulator and cxxrtl use an architecture
that, in principle, supports logic feedback loops. So you can model
the SR latch using two ordinary NAND gates. If you have an instance
of a SRNAND cell, you can provide a simulation model for this instance
that uses two NAND gates, and it'll work. However, I must warn you
that both for nMigen pysim and cxxrtl, this will come with a severe
performance penalty of at least ~10x, possibly worse depending on your
exact design. If you are planning to use fine SRNAND cells (one per
bit rather than one per word), expect a further slowdown of the word
size factor. Another issue is that neither pysim nor cxxsim provide
any way to control the possible race conditions. That is, the SRNAND
latch that is simulated in pysim or cxxsim will initialize to
an indeterminate value, and chaining them together will lead to
unpredictable results.

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