RE: [fpu] FPU operations

["Rudolf Usselmann" <russelmann@hotmail.com>]

>From: owner-fpu@opencores.org [mailto:owner-fpu@opencores.org]On Behalf
>Of Jamil Khatib
>
...
>
>Sorry but still I can not get teh advantage of
>calculating teh result signals every clock.
>May be we can driver the result comparison in the
>result and the compiler has to define the states

The advantage lies in the simplicity. Lets say the FPU
pipeline is N cycles deep. That means the FPU can accept
each clock cycle an operation, and provide a result
(including compare/status/exception flags) N cycles
later. It's very simple, don't try to over-architect it.

The internal statemashine in the CPU (OR1K), knows how long
it takes for the result to come out, and will latch the
compare/status/exception flags in it's internal registers.
The CPU most likely has to do that for each operation, as
it has to track the *complete* results until the internal
write back phase is completed (see a good book on RISC
architectures).

The tracking of results will become even more complex if
some instructions have late completion times (e.g. more
than N cycles).

>Regards
>Jamil Khatib

Take a look at the PDF file I posted a while back. Perhaps
it will help to understand the flow. Think of each FPU block
(adder, subtractor etc.) as a single flow-thru block (OK,
we know in reality it has a pipeline). But if you look at it
as a flow-thru (e.g. combinatorial block), it is obvious how
the results are always generated. The 'operation' input to
the FPU, controls a mux that chooses the appropriate result.
The outputs from the comparator, are always present. The CPU
chooses to look at them or not.

rudi


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com