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

[nicO <nicolas.boulay@ifrance.com>]

Yann Guidon a écrit :
> 
> 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.

So you add another chip it cost a lot. Why using a new port ? What does
it add ? Nothing ! Just few more problem ! Canonical CPU are always put
on one bus (or switch, it's the same).

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

We could _never_  fight against G4, US3, ... because our design flow are
semi-custom. So we lose 30% of the performance. We fight against R10000,
SH4, SH5, ARM9-10, even a kind of PPC, all this are made for SOC only.

If you want create a complete new computer never forget what happen to
Next. they were the best computer during there life, but now is dead :
too new !

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

I know it's very slow (60 Mhz compare to 450 Mhz for michael's mul unit)
 
> > 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.
>

_NO_ ! LGPL just said you could _link_ with proprietary code. If you
touch the fcpu it-self, it's like touching GPL code ! You absolutely
can't touch the code as you want ! (that's the goal of LGPL)
 
> > 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.
>

Yes, but what about IP right ?...What about the choice ?
 
> > 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).
>

fcpu will be finish in 2 years, so...
 
> > 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,
>

But that the problem ! How would you customise fcpu with GPL ? For
exemple, suse couldn't make a priorietary distribution of the fcpu. If a
distrib could be see as a "chip". That's the problem. With the current
licence system, i'm afraid that no compagny will invest an euro in the
project. But we need some compagny to produice chips, to make the fcpu
alive. 

In SW GPl allow to run gpl program and proprietary program. How do you
do that in HW ?
 
> >  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
>

Haven't you seen that that kind of chip are almost always made by the
same compagny (ST for power product,...). It's old line of product still
in production, not new one. The catalog that you speak are for PME of 10
people who produice very few number of pieces for a product, it's not
serious for "great public" for exemple. (try to buy a big fpga with
radiospare or Farnell !)
 
> 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.
> 

I don't speak about the fcpu it-self, but all peripheral put beside.
Imagine an LCD controller for example for PDA. This has nothing to do
with the fcpu project ! Or imagine a compagny which made a video card,
and put a 3D accelerator beside the fcpu.

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

The trend is to know how to interest chip maker in our project. That's
all !

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

Memory access in an atomic way like is made by other cpu. That's
enought.
 
nicO

> > > > > 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/
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/