Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC

[Yann Guidon <whygee@f-cpu.org>]

hi,

Michael Riepe wrote:
> 
> On Tue, Sep 11, 2001 at 02:44:45PM +0200, Juergen Goeritz wrote:
> [...]
> > How about thinking of IPs as programs? When I run a program
> > on an OS, the GPL license does not affect other programs that
> > run on the same OS. When one runs the F-CPU IP on a chip how
> > can it then affect the other IPs on the chip? Just imagine some
> > kind of a loadable cpu core if you think this is to far ahead.
> > If you now think of the other IPs being the 'operating system'
> > to run the F-CPU IP you are on my view.
> [...]
> 
> If you provide ways to install, remove, modify and replace any "program"
> independently without destroying the rest, I might agree with you,
> with one exception: all IPs should be considered "programs".
> 
> I don't like this approach much, but I guess it's reasonable to allow
> this kind of "use", as long as users have the option to take advantage
> of all the rights they've been granted by the F-CPU license, without
> any restrictions.
> 

There is still the problem of the 'interface' from my POV.

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 !

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

Integrate a raster-scan controller and a video codec and you have
a free graphic chipset :-) (just for the fun).

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
>  "All I wanna do is have a little fun before I die"
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/