[libre-riscv-dev] [Bug 154] Cell for Dependency Matrices is needed

[bugzilla-daemon at libre-riscv.org]

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

--- Comment #9 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Staf Verhaegen from comment #4)
> Some of my comments:
> - A SR latch could be easily added to the standard cell library and I will
> do that. I'm not sure though current nmigen + yosys will actually infer SR
> latches.

yosys is supposed to.  very quick search

https://www.reddit.com/r/yosys/comments/8014ji/sr_latches_flipflops/?utm_source=amp&utm_medium=&utm_content=post_num_comments

yosys has $sr and others.  (that author was not able to get advice on how to
use them, i will find others)

we can ask whitequark to add support for them or even add them ourselves 

> - If one wants to use SR latches nmigen is not the right language. nmigen is
> based on normal latches with just a reset signal which is only an init
> value. I do think it is better to rephrase the code as logic with one sync
> statement of one wants to keep on using nmigen for the scoreboards.

there are design reasons why the twin output (combination of the sync and comb)
are needed.

if the code is turned into sync only, it will require a near total redesign of
the Dependency Matrix logic, which took several months of 100% focus to
understand and implement, with almost daily help and input from Mitch Alsup.

also it will adversely affect the performance, introducing unnecessary gate
delays.  these additional syncs would cause pipelined data and control to lose
sync, hence the implications of a near-total redesign.

even if done, this will, i believe, result in a DFF which will be 10 gates
instead of 2, and the 128 x 128 Register Dependency Matrix will have an
additional 200,000 gates added.

clearly this is something we would like to avoid :)

however if impractical, we accept it.

> Certainly on nmigen level one should not try to take into account the
> undefined behaviour of a latch when both inputs are 1 or 0. That should be
> taken care of behind the scene by nmigen and yosys.

the analysis i did after finding that initial "state" diagram online shows thar
the "UNSTABLE" assessment is wrong (more accurately: a huge misleading
simplification).

both SRNOR *and* SRNAND are entirely stable: they both however if you try to
transition simultaneously from 1s to 0s on the inputs (or 0s to 1s for NAND)
*then* the output is "indeterminate".

in simulations, a simple "exception" or even setting the output to verilog "X"
to represent "uninitialised" would seem the logical thing to do here.

and we know that the 6600 avoided this situation with some extremely good
design.


> - Efficiency of simulation should not be the guidance on how to implement
> things. 

good advice.

> Better to switch to cocotb + verilator or other solution for
> simulation then.

i needed to get up and running in a fast iterative loop.  i like cocotb. 
immanuel is working on nmigen verilator integration.  we have options coming
up.

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