[f-cpu] Re:

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

Yann Guidon a écrit :
> 
> MIME-Version: 1.0
> To: f-cpu@seul.org
> Subject: Re: [f-cpu] F-CPU vs ALPHA and licence
> References: <3B78E4A0.A27CADE@f-cpu.org> <20010814182230.63114@thrai.stud.uni-hannover.de> <3B79F022.661E7A3E@f-cpu.org> <3B7A5F1D.9F63DDD1@f-cpu.org> <3B7AA9B1.947ABE82@jetnet.ab.ca> <3B7AD505.F2417336@f-cpu.org> <3B7C1961.B7603F9B@ifrance.com> <3B7BE3E6.EE28E24C@f-cpu.org> <3B7C4BC3.F058CE06@ifrance.com> <3B7C6DFA.B1E75224@f-cpu.org> <3B7DDB4B.911EE4A1@ifrance.com> <3B7D9D6C.8EBAB6ED@f-cpu.org> <3B7E0AB7.635A4194@ifrance.com>
> Content-Type: text/plain; charset=iso-8859-1
> Sender: owner-f-cpu@seul.org
> Reply-To: f-cpu@seul.org
> X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe f-cpu
> Content-Transfer-Encoding: quoted-printable
> X-MIME-Autoconverted: from 8bit to quoted-printable by moria.mit.edu id f7I1qOb15752
> 
> hello,
> 
> nicO wrote:
> > Yann Guidon a =E9crit :
> > > hello,
> > > nicO wrote:
> > > > Yann Guidon a =E9crit :
> etc.
> 
> > > let's sum it up : you don't want extra pins and i don't want to go th=
> rough
> > > memory. We can still try to "multiplex" the semaphores on the front s=
> ide bus.
> > > Note that in a mutli-CPU system with tens or hundreds of chips, becau=
> se
> > > you have to go through the "normal" path, the latency of the semaphor=
> es
> > > will be this of the memory.
> > > Now imagine we had around ten or twelve pins anyway. A "cheap" FPGA c=
> an 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.
> >=20
> > 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).
> and that's their problem.
> note that your "always" shows that you don't know alternatives,
> there are other computers that have different architectures than
> the SMP/MPP you learn at school.
> 

When you don't criticize my school, it's my books ! You're funny (jalous
?) ! As you, i read a lot on the net about a lot of architecture, and i
please you to stop this kind of personal attack. I'm really feed up with
it ! Don't you remember when i try to explain how COMA from sun work,
and you don't understand a word ? It's just to refresh your mind a
little.

> > > 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 ar=
> e
> > 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.
> 
> i do not "fight against", i "fight for" a free, ununcumbered platform.
> i do not work as SoC expert. i'm just a wannabe-computer-architect.
>

Hum, so you never mind, if no fcpu will be made ?
 
> > 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 !
> 
> they didn't obviously found their market.
> and Next is not the only "fallen" company around.
> you should read the book i showed you :-)
>

Ooooh, you read book ? It's not only crap ? What a surprise from you !
 
> > > 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=
> )
> so either you use a slow foreign IP, or we redesign design it from scratc=
> h
> for speed, freedom and all the bells and whistles.
> 
> > > > In your case, to make a Chip (or a SOC, it the same !), all vhdl co=
> de
> > > > 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 wor=
> k.
> > > If they want to play the faire game, they use the GPL. If they want t=
> o
> > > 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 everybod=
> y.
> >=20
> > _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)
> 
> remove your pink glases. Of course, i know that the f-cpu itseld must not
> modified. But you forget one detail : as you said, "the chip is the syste=
> m"
> and what's the use of a system where the CPU is surrounded with "cores"
> that you can't access as a programmer ? LGPL does not tell anybody to
> release the API/ABI/interface of the other cores.
>

And so ? Where is the problem ? There is a lot system where there isn't
programmer at all ! (hard disk controler ?) Look around you programable
product are rare, you only think about workstation, don't be so narrow
minded. For me, it's the only market that is almost impossible to reach
(old concept, dominated by the PC (so the cost will be much lower, see
the price of the G4), market which didn't grow any more ).
 
> So imagine i am Intel or whatever "big bad company".
> i come, d/l the code, add my "proprietary" stuff to the f-cpu core,
> such as the SDRAM controller, the interrupt controller and a secret
> backdoor or two. now, who will bug me about that ???
>

Where is the problem ? They always use our compiler, simulateur and
emulateur ! Or even debugger and so one. The interrupt handler should be
done by the fcpu project that sure. But if intel want to make a fcpu
with a RDRAM controler, for me that's fine, where is the problem ? You
could always run those program with SDRAM. Intel try to keep the
compatibility with 8086 and you think that they want to brake the
compatibility with the other line of product.
 
> i try to have a long sighted vision, and i am not impressed by short-
> or middle-term issues about revenue or whatever. I have seen that the lac=
> k
> of long-term vision does to my own life and other's.
> I would like to find a good solution but IMHO it is not a good solution
> to help companies stay in their short-term revenue goals.
>

I know you're a great visonnar and you will never failed or make a
mistake.
 
> > > > That said
> > > > that we will never use all proprietary interface (IEEE1394, etherne=
> t,
> > > > USB, PCI, hyperband,...) so nobody could be connected to a fcpu at =
> low
> > > > cost. Never forget that board=3Dchip, todays.
> > > again : look at opencores : they have an increasing number of free co=
> res.
> > Yes, but what about IP right ?...What about the choice ?
> what what ?
> you want everything ready for you ?
> you have access to the source, you have direct connexion to the authors,
> so instead of paying an inhouse engineer for customizing the external
> cores, you can pay (often "less" than the inhouse engineers,
> particularly in France where the taxes for working are very expensive)
> the original developper to do its works, and that's all.
> what more do you want ???
>

But no, you speak about the fcpu, i speak about peripherals : what is in
common with fcpu and a numerical filter or specific buses ?
 
> > > 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...
> ain't it a bit optimistic ? :-P
> 
> > > > 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.
> i should add : these tools are extremely expensive and they work
> only in ideal cases ;-P=20
>

No, i speak about tools like for embedded market, where the compagny
write the code for it's own product. Or Oracle, from example, which has
no equivalent in GPL world.
 
> > > > Lot of compagny want to sell solution with linux
> > > > for embedded market, for example. This system work well, no code st=
> olen,
> > > > 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 fo=
> rget
> > > > that !).
> > >
> > > What RedHat and Mandrake do (apart from playing with stocks) is servi=
> ce
> > > around, not on, what they distribute. They distribute, customize,
> > But that the problem ! How would you customise fcpu with GPL ?
> open EMACS and a good VHDL book.
> don't forget to read the manual, btw.
>

Stop kidding. I speak from a compagny point of view. If compagny
couldn't make money with the core, it will dy because nobody will use
it.
 
> > For exemple, suse couldn't make a priorietary distribution of the fcpu.
> that is their problem.
> 
> > If a distrib could be see as a "chip".
> btw, their distribution is "proprietary" because they ADDED
> a non-gpl part at the critical place. this is what i want to prevent
> and avoid, and this is what WILL happen if LGPL is used.
> 
> now, apart from being in bad terms with Lionel, does Suse's
> strategy help anybody ???
> 
> > 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.
> 
> don't worry for that.
> Japan, India, South America and other countries are already doing their
> own projects. I have contacts with several working groups.
> i'll let you know when i have news.
> My REAL worry is to have the core ready enough before october :-(
> 
> > In SW GPl allow to run gpl program and proprietary program. How do you
> > do that in HW ?
> that is a problem that we have to solve.
> 

Oooh, you think ? That what i speak since 100 lines.

> > > >  In the case of the fcpu, where a compagny could make money ? By se=
> lling
> > > > 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 spr=
> ead 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 consumptio=
> n,
> > > 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
> >=20
> > 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 stil=
> l
> > in production, not new one. The catalog that you speak are for PME of 1=
> 0
> > people who produice very few number of pieces for a product, it's not
> > serious for "great public" for exemple. (
> 
> however, if your previous statement was true, there would be only
> one single source for the 74xxx series. well, there are FPGAs,
> GAL, PAL and even resistors, condensers, connectors....
>

Yes you could, but it's old. and i repeat myself : 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.
> >=20
> > 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.
> 
> so what ?
> do you want short-term  or long-term POV ?
> 
> > > > 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.
> >=20
> > The trend is to know how to interest chip maker in our project. That's =
> all !
> 
> i don't think that it is a real problem.
> for DATE 2002, we'll go together speak to the companies' reprensentors.
> you will be surprised. but it's not the "big thing". they are only follow=
> ers.
> 
> > > > > > Today's =B5p 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 enough=
> t.
> 
> i told you : FC0 handles memory accesses with 256-bit lines.
> if you do RMW you WASTE a lot of performance.
> but i think that you don't care.

Yep, because semaphore aren't access so much and not inside inner loop.

> 
> ok, i'll try to sleep. i hope that this licence discussion will not
> degenerate in a war, because i prefer to code : "make file, not war"
> (lame attempt at doing humor at 4am, sorry)
> 

I think you had better to wait this morning to answer...
nicO
> > 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/