RE: [fpu] FPU operations

[Damjan Lampret <damjanlampret@yahoo.com>]

> 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).
> 

Exactly.

> 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.
> 
I have three block diagrams of FPU operations. It looks like Rudi's RTL
models them. I'll post them right now. I apologize since they are
images.


--damjan


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/