[libre-riscv-dev] IEEE754 FPU

[Aleksandar Kostovic]

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

Looking at it now and literaly dont know. I will give it some thought and
try to spot a problem.

On Sun, Feb 24, 2019 at 1:01 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> 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.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>