[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] the wrong way (or not?)



hi,

Juergen Goeritz wrote:
> Hi,
> 
> my opinion is that the core parts of f-cpu should be verified.
this remembers me that i still have to design the BIST unit :-)

> The parts outside the core like memory
> controller, interrupt unit a.s.o. could be 'delayed'.
> The best way to get started is to use some FPGA to
> test the concept in hardware.
yup, but before that, we need VHDL source code :-P

> But to remind everybody of Intel x86 success. One
> part was that it came with the x87 floating coproc
> that speeded up arithmetics quite a bit. Motorola
> had no real floating point unit fitting to 68K. It
> may be a bit carried to far to claim that this was
> the only point for Intel success but it is at least
> one of them.
one "part" of the success is the lobbying they did
at the IEEE committee so the standard could adhere
to the chip.... which was under design already.

I don't think that the x86 FP is such a wonderful thing :
sure it is practical in certain circumstances but from
experience, i have never used it, though i know how
to do.

Other "keys" to the "success" of the 8088/8086 are :
 - IBM did not choose the 68000 because they wanted
   a cheaper CPU for their "IBM PC".
 - Intel was second-sourced by AMD, IIRC : less risk
   if either one goes out of business.
 - the 8080 and 8085 families were already widely used
   and had source code base. 68000 was new.

> If you don't go for floating point right from the
> start you will have targeted the f-cpu to embedded
> applications.
F-CPU is what you make with it. it is already configurable
to a certain extent, so it can be retargetted by modifying
one user-visible file.

> I don't know if that can be 'healed'
> later but it's much easier to strip a unit to make
> some shrinked version than to extend something.
how can you "strip" something that doesn't exist ?

> The direct competition right now is the LEON Sparc
> which comes with the nearly free Meiko FPU for low
> quantities (SUN SDLC license required). I don't see
> the Alpha architecture as THE direct competition at
> all - sorry WHYGEE.
I both agree and disagree. Yes, LEON will win, so
why "compete" ? F-CPU's goal is not to compete with LEON,
it would be pointless.

> LEON is only 32 bit though but a lot of software for
> it is already available as open source. And it could
> be used as a powerfull IO processor...
LEON serving as "service processor" for the F-CPU is
cool but there must be a way to handle the bandwidth and
clock speed difference : the F-CPU works with 256-bit wide
cache lines and is clocked at least 2x faster (with the
same silicon process, as a rough estimate). You'll have
to put two or four LEONs in your desktop box to make a
balanced system.

However i don't see what the LEON can do that the F-CPU
can't do. Adding a LEON or more, you will increase the
cost and complexity of the machine, making it useless.
And today, i don't see what would be the use of a Peripheral
Processing Unit.


> Why not implement f-cpu as a coprocessor into the
> LEON IO processor. With the LEON coprocessor opcodes
> it could be easy to implement a debug interface for
> f-cpu testing with download and single stepping...
F-CPU as a coprocessor INSIDE LEON ?
if you put them in the same chip, the difference
in the pipeline complexity will make the F-CPU
a ridiculous underperformer if you clock the
chip at a fixed frequency.

If you want single-stepping, a simple FPGA board
or a CELARO emulator can do the trick. I don't see why you
would need to put a SPARC next to F-CPU, a direct
interface to the host station is more useful.

> Does anybody have access to a synthesis tool for some
> prototyping? Does anybody have access to a FPGA board
> for testing?

i think that some people here have some means.
however, without complete source code, it's almost
useless :-(

> JG
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/