Re: [fpu] Current progress

[Usef Saiful-Ulum <usef@vlsi.itb.ac.id>]

On Wed, 12 Apr 2000, Jamil Khatib wrote:

> Do you mean that the registers are located in OR1k core?

No, but the spec of OR1K is: we have sixteen 64-bit FPRs.

> > if we want to develop a stand alone core we should avoid "bus watching"
> > mechanism (ARM style) because the coprocessor should not be attached to
> > OR1K native bus. I'm not sure what was the main advantage of having this
> > processor-independent FPU core since otherwise, in my opinion, it would
> > simplify the design of the portion of the interface and fasten the
> > coprocessor-register transfer instruction.
> >
> 
> Why do not we design two versions?

I will consider that, but which is better to design two versions of FPUs 
or cooperating in design of our common choosed version?

> Do you think about any application that may need only floating point processor?

Multimedia and game apps use FP intensely, the problem is that does those
apps have been optimized to utilize a very fast FPU?, say a 1,2 GFLOPS
K6-2 300 FPU or Katmai 500 2 GFLOPS. So in this matter we have to choose
carefully which is best suit for our target application, because we have
 trade offs such as  between get better performance and limitation of
number of gates.

> may be the stand alone FPU can be plugged to any system that needs to get some FPU
> operations only to enhance its system performance.

I prefer to focus on OR1k system and its descendants because at this
moment I'm not quite clear whether "stand-alone"-ness should be a
problem, in fact I don't mind on both approaches.

My main focus is to raise the performance using superscalar FP with
doubling its execution unit, reduce latency, etc.
 
> I think for now we have to list all possible floating point instruction "both
> software and hardware"

Yeah, I agree, you can start with publish it on the web.
 
Best regards,

Usef