[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 #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
staf i apologise if this is wellkniwb to you already, i went through the two
truth tables and it seems that SRNand is just the logical inverted equivalent
of SRNor, *including* the so-called "instability".

when SRNAND S,R=0,0 i see that the output is *not* unstable, it is 1,1

however if there is a simultaneous transition to 1,1 *then* the output is
indeterminate.

this is exactly the same as for SRNor except all input and output inverted from
the above paragraphs.

so i see no reason at all why SRNAND should not be used, and the simplest and
quickest way to check that would be to flip Q and ~Q as outputs and put
inverters on SRLatch's inputs:

https://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/nmutil/latch.py;h=84235ffada66bb4b69249e585970e5097e939277;hb=a60f0c986284e28b204c1057ba9a501353683449#l33

_s and _r can be created which will be set to ~s and ~r.

oh, ah... you can probably see straight away from that code, it is *not* an
SRNOR (it should be).  it is a priority-set SR latch which you can see at line
47:

m.d.sync += q_int.eq((q_int & ~self.r) | self.s)

also... ah :)  one thing that turned out to be very important: hum.  a register
mechanism is built-in to that code.

this you can see from the fact that line 47 is a *sync* not a comb.

it turns out that these built-in registers help avoid having to sprinkle them
consistently across the entire set of DM Cells.

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