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

Re: [f-cpu] F-CPU vs ALPHA and licence



hello,

nicO wrote:
> Yann Guidon a écrit :
> > > In all case, you have one memory access + 1 or more port to the outside.
> > maybe not. I am thinking about a separate and dedicated port in the chip,
> > that will communicate to a central FPGA or ASIC that will perform the
> > arbitration. a dozen of signal pins do the trick.
> >
> 
> Yep, it's 12 pins more for a very short use. We add the chipset inside
> the fcpu to avoid an other chip and you want to introduice another chip
> ! This chip to be fast will need as many port as cpu. In all case, this
> component must be design. In actual chip design, we don't make
> difference with system boad and the cpu chip. So if we could put this
> componant inside the fcpu we will gain a lot of money ! Soc
> (system-on-chip) are not just fashon. It's how todays chip are made.
> Nowdays, you would never see an ARM in a chip alone, NEVER. StrongARM
> are _the_ only exception.
> 
> Before, you will choose between chips to make your system. Nowdays, if
> you want to make more than 100 000 pieces you will choose the good IP
> and then make your system. Most of it on the same die for cost and power
> saving problem (less pin, so less power transistor, ...).

let's sum it up : you don't want extra pins and i don't want to go through
memory. We can still try to "multiplex" the semaphores on the front side bus.
Note that in a mutli-CPU system with tens or hundreds of chips, because
you have to go through the "normal" path, the latency of the semaphores
will be this of the memory.
Now imagine we had around ten or twelve pins anyway. A "cheap" FPGA can have
around 160 user pins, so we can connect more than ten CPU DIRECTLY to each
others. With a good PCB layout, a good topology, some VHDL and a few more
pins per CPU, we can increase the "cut" of the system and drastically reduce
the semaphore latency.
There's no secret to performance : you get what you buy. And as you know,
the F-CPU is open-sourced so if you don't like it and if you target
single-CPU systems, you can simply remove the "feature" before funding
your batch.


Concerning SoCs : would you call the P4, the G4, the US3, the R18K... SoC ?
maybe, maybe not. i stick to the definitions that were defined before i came.
i recently browsed the net and found that on f-cpu.tux.org :

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Freedom CPU ISA and Register Organization
Andrew D. Balsa (maintainer/coordinator)
Rev. 0.0.2, 24 September 1998 
<>
3. Mission statement

The mission of the Freedom Project is to develop a new high-performance
64-bit CPU architecture, suitable for Personal Workstation use, and to
implement this architecture in the available process technology. 
<>
It is perhaps useful to mention development issues that are not part of
the Freedom Project, e.g.:
*   Develop a new microcontroller-type 8, 12, 14 or 16-bit microprocessor
    (e.g. PIC devices). Reason: outside the scope of the project. 
*   Develop yet another 32-bit RISC processor for low-power/low cost
    embedded applications (e.g. ARM). Reason: there is an infinite
    variety of such processors on the market now, with excellent characteristics. 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"SoC trend" or not, the goal was not to make a "microcontroller" (old
denomination) or an "integrated controller", but a CPU (Central Processing
Unit) for PC/Workstation.


> So my problem concern our licence, the GPL. We say it's ok ! Because we
> couldn't mix GPL code and private code, but we could mix after at the
> layout level. The problem is that isn't very usefull for a compagny to
> do it at this level. LEON was written in LGPL to be used with the meiko
> floating point unit, very easly.

Our goal is not to make a Nth Sparc clone or a LEON.
it is not either our goal to use Meiko's FPU.
Btw, have a look at Opencores.org : they have already a FPU
for add/mul.

> In your case, to make a Chip (or a SOC, it the same !), all vhdl code
> must be in GPL. All the code ! Which compagny would make a fcpu if it
> couldn't add something to create more value than the other ?

Our goal is not to let "companies" make money "for free" with our work.
If they want to play the faire game, they use the GPL. If they want to
make more value than others, they still have to respect the GPL.
My understanding of what the LGPL would do is : companies will not
respect the architecture and add non-standard extensions. It may be
"worth" for an individual company but it's not a benefit for everybody.

> That said
> that we will never use all proprietary interface (IEEE1394, ethernet,
> USB, PCI, hyperband,...) so nobody could be connected to a fcpu at low
> cost. Never forget that board=chip, todays.

again : look at opencores : they have an increasing number of free cores.

> If the code stay in GPL, it will be very difficult for compagny not to
> release all it's code in GPL. I personnaly think it's too much to ask.
Our goal is not to be "kind" with companies, to the point that they
will benefit from our work for nothing. Others would call this a
"fucked up business plan". Once they will fabricate the chips, what
will they do then ? I do not ask for money, i simply ask for the respect
of my work and of my copyright. I do not want to promote captive
and proprietary work. Otherwise i would work for Sun/Intel/IBM
and drop F-CPU.

> We made a cpu not systems. A computer could be used in very different
> way what is in common with a numerical camera, an hard disk controleur,
> or a PDA. In each of this system, you could use a fcpu BUT, peripherals
> and interface could be very different (no need of LCD display port for
> the hard disk controleur).

IMHO, a F-CPU would consume too much power and silicon for a digital camera ;-)
(in today's standards).

> In SW, Linux and some software are in GPL but could be used with
> proprietary program.
and vice versa : Emacs runs under Windows, for example.
But concerning our case : it is simply a matter of tools.
i don't want to change my mind simply because others don't do their
work at making their product work.

> Lot of compagny want to sell solution with linux
> for embedded market, for example. This system work well, no code stolen,
> but you could sell something, so made a wide spread of the GPL code (Red
> hat, Mandrake are responsible to make linux so well known, never forget
> that !).

What RedHat and Mandrake do (apart from playing with stocks) is service
around, not on, what they distribute. They distribute, customize,


>  In the case of the fcpu, where a compagny could make money ? By selling
> exactly the same chip than the other ? But no system is built like that,
> any more (no use in SoC)! So forget the use of the fcpu in wide spread use.

please tell me : why are compnies still making 74xxx devices ?
look at catalogs ! (ie Radiospares/Arrow/Radioshacks...)
Why do companies produce the "same" part numbers ???
one will emphasize on the package (SOP, DIL, ...), the other
will provide more diversity, another will reduce the power consumption,
another will increase the speed, another has more marketing
and better fundries... and you know what ? even though they produce
"the same thing" these companies are still in business ;-P

Even with a single source code, you can make a large number of
variations. the resulting F-CPU can be customized without even
having to redistribute the source files, simply because
f-cpu_config.vhdl will have a few changed lines. Use a different
compiler/synthesis tool, go to another fundry, hire more or less
people and the product will be more or less expensive with more
or less performance.

> It's still possible to change our licence because few people write
> code(whygee and Michael, that's all i think). I think that LGPL are more
> appropriate.

i am against, you are not. I will follow Michael Riepe's choice.
What does he vote for ? i do not want to spoil the situation
between you and me so i prefer to listen to others's choices.
As you know, i am not the reincarnation of the project.

> > > Today's µp implement semaphore with atomic read_modify_write
> > > instructions.
> > so what ?
> So you don't need special port !
And what is your answer to the performance loss ?
do you have anything smarter ?

> > > > So i could say : Alpha is dead as much as F-CPU is alive.
> > > > it's time to learn alpha's lessons, i think.
> > > the problem is the tone not the content.
> > what would you write instead ?
> Avoid bads word.
i can change the first sentences if you want but i don't know
what i could write instead.

@+ !

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