[libre-riscv-dev] IEEE754 FPU

[Luke Kenneth Casson Leighton]

On Sat, Feb 23, 2019 at 1:06 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> ok!  right... i created something called dual_add.py, it seems to work
> on the first add, and not the second.  something about the signalling
> is wrong.

so it's set up so that a + b = intermediate, and c + intermediate =>
z.  signalling is set up so that a b and c are all to be read and
transferred immediately into their respective adders.

i *think* what is happening is that the output from the first adder is
*also* triggering the 2nd adder to go into computation, too early.  so
the sequence goes like this:

* 1st add, a b c set on "trigger".  intermediate (1st adder) output,
stb is DEASSERTED
* 1st adder DEASSERTs stb (to indicate ready) then ASSERTs it again
* 2nd adder has ACK and STB ASSERTed for its "b" operand open for the
brief window above, and proceeds
* 2nd adder produces (correct) result, DEASSERTs stb then ASSERTs it
again when unit test ASSERTs output ACK.

unit test then DEASSERTs a b and c STB, and moves to 2nd loop:

* 1st adder is *STILL* asserting output STB (this is i think where the
problem is)
* 1st add a b c input is provided
* 2nd adder now has *VALID* c input *AND* the *OLD* 1st adder input ASSERTed.

so of course the 2nd adder proceeds with the OLD value.

problem is, i don't know how to stop this from happening.

any idea?

l.