![]() |
![]() |
|
The Freedom CPU ArchitectureAndrew D. Balsa w/ many contributions from Rafael Reilova and Richard Gooch.5 August 1998A GNU/GPL'ed high-performance 64-bit microprocessor developed in an open, Web-wide collaborative environment. 1. History
The idea of a GNU/GPl'ed CPU design sprang in the middle of some email exchanges between three long-time GNU/Linux users (also Linux kernel developers in their spare time) with diverse backgrounds*. We were questioning monopolies and how the dominance of an operating system (including the kernel, the Graphical User Interface and the availability of "killer-applications" as well as documentation) was intimately related to the world-wide dominance of a specific, outdated, awkward and inefficient CPU architecture. I guess we all know what I am referring to. We also expressed our faith that GNU/Linux is well on its way to provide the basic foundation for a totally Free software environment (in the GNU/GPL sense; please get a copy of the GNU GPL license if you are reading this, or check www.gnu.org). However, this Freedom is limited or rather bound by the proprietary hardware on which it feels most at home to run: the traditional x86-based PC. Finally, we were worried that Intel's attitude of not releasing advance information to the Free Software community about its forthcoming Merced architecture would delay the development of a compatible gcc compiler, of a custom version of the Linux kernel, and finally of the vast universe of Free Software tools. It is vaguely rumoured that Linus Torvalds may have received advance information on Merced by signing an Intel NDA, but this would be an individual exception and wouldn't really fit with the spirit of Free Software. On hthe whole, even though Merced will certainly be more modern that the x86 architecture, it will be a step backwards in terms of Freedom, since unlike for the x86, there will most likely never be a Merced clone chip. In the previous days, we had been discussing the various models for Free Software development, their advantages and disadvantages. Putting these two discussions together, I quickly drafted an idea and posted it to Rafael and Richard, warning them that this would be good reading while they were compiling XFree86 or a similarly large package... and then they liked it! Here is this crazy, utopic idea, merged with comments, criticism and further ideas from Rafael and Richard:
2. The Freedom GNU/GPL'ed architecture
We started with some questions:
There are really two distinct incredible challenges here: a) the performance and feasability of the resulting architecture, and b) the open development process under a GNU/GPL license and the intellectual property rights questions raised by this process. Tackling a) first (performance and feasability), we think the Freedom architecture could be more efficient under GNU/Linux compared to other architectures by making it: 1) More compatible with the gcc compiler. We have the source code to gcc, but most importantly, we have the gcc developers available to help us figure out what features they would like to see in a CPU architecture. Why gcc? Because it is the cornerstone of the entire body of Free Software. Basically, an efficient architecture for gcc will see an increase in efficiency across-the-board on *all* Free Software programs. 2) Faster in the Linux kernel. Right now, if we take for example the PC architecture, we notice that the Linux kernel has to "work around" (and some would say "work against") various idiosyncrasies of the x86/PC specifications and hardware. We also have to maintain compatibility with outdated x86 chips. And obviously, there is no possibility of implementing some of the often used Linux kernel functions in silicon. A new design, custom fitted to the Linux kernel code, would vastly improve the performance of any kernel-bound applications. Further ideas for a possible architecture and implementation can be found in the appendices (as well as the "economics" of the project). Note that we are calling the architecture "Freedom" (for obvious reasons), and its first implementation "F1". Projected end-user cost of an F1 CPU is around $100. Everything is very utopic, we know. :-) However, it also seems to us that at this stage, the real challenges for our project are entirely within b): the development process and the intellectual property issues.
3. Developing the Freedom architecture: issues and challenges
The Dilbert cartoon says it all, in fact: our project *is* a whole new paradigm! What we are basically proposing is to bring together the competences and creative powers of thousands of individuals over the Web into the design process of an advanced, Free, GNU/GPL'ed 64-bit CPU architecture. And we don't even know if it's possible! We know two things for sure:
There are some questions raised as a consequence of the possible succes of the Freedom implementation:
4. Tools
We all know the saying: "If the only tool one has is a hammer...". We'll need "groupware" tools for the Freedom project, but the word "groupware" has a bad reputation nowadays. We prefer to use "collaborative work tools". Some of them have only come into existence and widespread use in the last decade; I am obviously talking about the Web itself, and its assortment of communication technologies: email, newsgroups, mailing lists, Web sites, SGML/PDF/HTML documentation and editing/translation software. Much of this infrastructure is/has been used to develop GNU/Linux, and is nowadays based on GNU/Linux, BTW. But we'll also need new tools, that perhaps don't even exist yet. I think it's worth mentionning that perhaps one the greatest steps in this direction is the WELD project, developped at Berkeley. It could well become the cornerstone of the Freedom project, or conversely, the Freedom project can perhaps be thought of as _the_ ideal, perfect test case for the WELD project.
5. Conclusion
The conclusion is simple and obvious:
Please join and help us turn this idea into a reality! -- *: Richard is an Australian astrophysicist preparing his Ph.D. on astronomic visualization; Rafael is a researcher on EDA tools at the University of Cincinatti. I am an ex-Ph.D. student in Management and an ex-firmware engineer, with a special interest in Ethical problems in multi-cultural environments (I was born in Brazil and am presently living in France). None of us has any formal education in CPU architecture. Rafael comes closest, since he is in VLSI design and EDA tools development, and also developed some new code for CPU recognition in the Linux kernel. Richard developed the Pentium Pro MTRR support in the Linux 2.1.x kernels (as well as other novel kernel routines), and is also a hardware developer. I have the honour of having diagnosed the Cyrix 6x86 "Coma" bug and proposed a workaround for it under GNU/Linux (both were at first rejected by Cyrix Corp.). I am also a long time hardware and firmware developer, and have contributed in various ways to GNU/Linux development (e.g. the Linux Benchmarking HOWTO). Richard E. Gooch <Richard.Gooch@atnf.csiro.au> Rafael R. Reilova <rreilova@ececs.uc.edu> Andrew D. Balsa <andrebalsa@altern.org>
6. Appendix A
Ideas for a GPL'ed 64-bit high performance processor design 24 July 1998 This is just a dream, a utopic idea of a free processor design. It's also a list of things I would like to see in a future processor.
I guess the challenge here is to determine whether a GPL'ed CPU design is feasible. Is open, collaborative development possible WRT CPU design? How does one get the funding to actually put the design on silicon, once it is ready? How can revisions be handled? Are there patents that would inherently block such a development process? The idea also is to use gcc as the ideal development compiler for this CPU (unlike Merced). And to be able to port the Linux kernel with a minimal effort on this new processor.
7. Appendix B
Freedom-F1 die area / cost / packaging physical characteristics / external bus August 5, 1998 Just as a reminder, the F1 CPU does _not_ include an FPU or 3DNow! unit (but SIMD integer instructions will be included). Recommended maximum size: 122 mm2. This gives us 200 dies/8-inch wafer (see an example of such a wafer on Hennessy and Patterson, page 11). Roughly, die yield = 0.5 for our 122 mm2 5-layer 0.25 micron CPU (H&P, page 13, updated to reflect better fabs). This allows more or less 10-11 million transistors, divided as follows: 6-7 million for the caches, 4-5 million for the rest. Assume wafer yield = 95%, final test yield = 95%. Testing costs of $500/hour, 20 seconds/CPU. Packaging costs = $25-50 (see below) Roughly, following H&P, this gives us a unit cost of $75-100/good CPU, tested, boxed in anti-static packaging and shipped to the US, if the Taiwan foundries can keep the wafer processing cost around $3.500. Packaging: I am going to propose something surprising, but I think we should use the same packaging as the Celeron CPU, in terms of physical dimensions and CPU placement. Like that we can also use the Celeron heatsink/fans already in the market, and the Celeron mounting hardware. PCI set: again I am going to propose a heresy, but I think we could use 100MHz Slot 1 motherboards. First, Intel is not alone anymore manufacturing Slot 1 chipsets: VIA has just released a Slot 1 chipset with excellent performance and the latest goodies in terms of technology (we can get timing info from the VIA chipset datasheets). Second, we don't have to worry about the motherboard/PCI set issue anymore. Third, it's almost impossible to go beyond 100MHz on a standard motherboard, because of RFI issues; so basically 100-112MHz is as good as it gets. Fourth, there will be many people out there with Slot 1 motherboards, willing to upgrade their PII/Celeron CPUs (specially the Celeron). Fifth, these motherboards are nowadays quite cheap, and we get all the benefits of high-volume production. Sixth, this allows easy upgrades of the Freedom CPU to higher speed grades, larger cache versions, FPU-with versions, etc... Now, if we accept the above, we have to put on the Celeron-style Freedom printed circuit a small EEProm that will contain the Freedom BIOS, the L2 cache and a socket for the FPU. This increases the cost of the CPU, but decreases overall costs, so I still think it's a good move. Please check a photograph of the Celeron and tell me if I am just dreaming.
8. Appendix C
Legal issues / financial issues August 5, 1998 We would like to have support from the Free Software Foundation for the Freedom project. We are _not_ proposing that the Free Software Foundation build a fab. What we are saying is: If we go to a foundry in the US or Taiwan, give them a mask, and ask them to run a batch of 0.25 micron, 5 layer 8-inch wafers for us, they'll quote approx. $3K-5K or less even, per wafer, as their price (our cost) for our batch (in the year 2000). An approximate cost for a batch of F1 CPUs would theoretically be somewhere between $ 500k and $ 1000K, for 5000-10000 good CPUs. Not exactly pocket money, but we could sell those CPUs on a subscription basis. Like this: people who would subscribe would get the Merced-killer for around $100 (compare that to the projected cost of $ 5000/unit for the Merced), on a first-come/first served basis, and any left-over CPUs after the cost of the batch would be covered, could be sold for a slightly higher price to pay for the next batch and further mask development. We suggest putting some quotas in the system. Demand is likely to be higher than supply. ;-) The Free Software Foundation could coordinate all the legal/financial/logistic aspects of the project (and would be adequately compensated for this work). This, of course, would depend on getting support from Mr. Stallman for this initiative.
temporary webmaster Last modified: Sun Mar 14 02:08:34 CET 1999 |