[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC
On Thu, Sep 13, 2001 at 03:18:25AM +0200, Yann Guidon wrote:
[...]
> Programs have interfaces : you can write a proprietary SW
> on Linux, but even though you have the source of the libraries,
> you can't change them at will (even under GPL) because
> other programs wouldn't work, or not work as well as with
> the proprietary thing. The summit is reached with the new
> "desktop managers" (KDE, GNOME etc) which are extremely complex,
> and can't cooperate EVEN THOUGH THEY ARE FREE !
I love standards -- there are so many of them to choose from ;(
I'm afraid that we may get an `interface explosion' when users start to
populate the area around the F-CPU core with their own stuff. In order
to prevent that, we should provide a fixed, well-documented `general
interface' and encourage people to connect to it instead of patching
the core.
> There is a small danger with the wishbone stuff. It is public domain,
> not an IEEE or ANSI standard (AFAIK). I don't believe that the
> performance is extraordinary. It's ok if you want to communicate
> with mid-speed I/O or do some IC2IC intercom, but F-CPU needs
> some strong doses of EPO+amphetamines, if you see what i mean.
Just because something is PD (or GPLed), it doesn't have to perform
badly ;)
> Otherwise, stick with LEON : having a lot of CPU power is not
> interesting if you're 'memory-bound' whatever you do. Cache miss
> rates and refill speed kills all CPU. So at least with LEON you
> are not too much memory bound.
>
> My current view for a "decent" F-CPU chip is :
> - SDRAM (DDR/whatever) direct interface with the core
> - onchip L1 cache (low latency)
> - onchip L2 with very wide words, such as suggested by nicO, ie with DRAM,
> so we can do very wide SIMD computations
Only useful if we can bypass the L1 cache. Otherwise, we'll get lots
of misses there. What about a bigger L1 cache instead? HP did that in
the PA-8500.
> - some kind of relatively fast interface to the outside, possibly
> with rather wide words (64-bit or 128-bit at a time) if it is on-chip.
I like the FSB of the MP-Athlon... it's a fast point-to-point link
(200/266 MHz, using DDR), 64-bit wide with separate, unidirectional
control buses. It somehow reminds me of the F-BUS ;)
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/