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

[Juergen Goeritz <goeritz@oekomm.de>]

On Tue, 28 Aug 2001, Yann Guidon wrote:
> this remembers me that i still have to design the BIST unit :-)
> yup, but before that, we need VHDL source code :-P

Yes, a lot to do still...

> > 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 ?

Yes agreed, but the name (i.e. f-cpu) will be burdened by
the first running silicon functionality. It's like a brand.

> F-CPU's goal is not to compete with LEON, it would be pointless.

I didn't mean to compete. Just wanted to say that LEON is
the first open source processor available.

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

Maybe you don't see it the same way. But my opinion is
that interrupts of different sources will give penalty
on cache hits, thus slowing down the hardware. Ideally
the main processor should concentrate on the job that
it should do - not to serve I/O devices.

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

No, you got it wrong. I mean why not use LEON as a
debug frontend tool. I didn't mean to clock it the
same frequency, nor did I mean to let the memory
interface of f-cpu go over LEON AMBA bus.

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

No, the problem is that you have to get/put the data
and verify it. If you use a prooved design for control
it gets easier. Of course you can write and run the
control software on your PC but the interface is even
worse than the coprocessor interface of LEON.

Hey, I didn't say to integrate the f-cpu into LEON,
just to use the coprocessor interface as a built-in
control functionality for debugging.

> > 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 :-(

Anybody out there? By the way, what is still missing?

JG

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