Ultra Low Cost Open Chip Development
Open Design Circuits are the chip design counterparts of Open Source Software, with designs (sources) openly shared among developers and users. The open-design circuit approach outlined here captures the true advantages of open-source software, and applies them to hardware. It avoids the large initial investments usually needed for hardware development, and it allows for the rapid design sharing, testing, and user feedback which are key to open-source software success.
Open-design circuits (ODC) offer an approach that differs quite a bit from other open-design hardware initiatives: The Open Hardware Certification Program, The Open Hardware Specification, Open Souce Hardware Page (sic). Open Design Circuits more closely resemble Open Source Software, the workings of which are most clearly described in The Cathedral and the Bazaar. The most obvious open-source success so far is Linux.
Open-design circuits are very close to reality, even though no development community exists for them at the time of this writing.
The first part of this document, which describes the ideas for ODC development, is written with generally computer-literate readers in mind. Later on, starting with the technical issues section, some knowledge of hardware and circuit design will help. These more in-depth topics are of interest mostly to people who wish to contribute to the project.
Tune in to the open-design circuits mailing list for general discussion on the topic.
Mail circuits@circu.its.tudelft.nl
to contact us directly.
Mail webmaster@circu.its.tudelft.nl
for comments on the web site.
Mail Reinoud Lamberts to
contact the author.
The primary problem for open hardware development is the cost associated with manufacturing a design. Manufacturing cannot be used to share and test a design in a way similar to open-source software releases. (Actually, you may need serious financial backing to get a design manufactured even once.)
When considering chips, the fabrication costs are particularly high for the relatively small quantities needed for development versions. Also problematic are the long fabrication delays, and the effort required to get test boards working on many sites. And, last but not least, manufacturers (foundries) are very secretive about their fabrication processes and cell libraries, while documentation is necessary to create open-source design tools.
We can safely conclude that it is best to avoid manufacturing. So how are we going to do hardware development, then?
When trying to avoid above problems, there are two fairly obvious alternatives to manufacturing:
Using FPGAs, it is possible to share and test designs just like software, yet actually achieve hardware performance. This is possible with affordable standard chips and boards, so there is no large investment required to manufacture new hardware.
The problem with FPGAs is that, compared to custom chips, their price is relatively high, while their performance is often relatively low. For users or people who want to tinker with designs occasionally, there is little incentive to obtain FPGA hardware unless there are several interesting uses for it, allowing re-use of the relatively expensive hardware (like we do with microprocessors). For designers there is little incentive to design for a target technology that does not provide for adequate price/performance when used for a single design, unless enough users have it installed already. So without a compelling reason to move in that direction, such FPGA-based development won't take off.
A desire for low cost, open chip development by the net community may be just the motivation that is needed to get FPGA-based development off the ground. Once there, it would provide for economical hardware for users and very low cost development for designers.
In short, to bootstrap open chip development we need at least one of the following:
I expect that all three of the above will be achieved, once the open-design circuit development process (see below) is started by a small number of motivated people on the net.
Phase one. A small group of people (on the net):
- sets goals for open design tools, data formats and hardware,
- selects, improves, and integrates existing open tools (see comp.lsi.cad FAQ and Lola),
- starts development of new tools (and maybe OS support for the new hardware) if necessary,
- selects FPGA devices and boards for initial development (look here for starters),
- spreads the word of their activities.
Phase two. With high quality open design tools becoming available, more people are joining the initiative, and work is started on comprehensive design libraries and large designs. All this is relatively easy to do on FPGA hardware.
Phase three. With attractive designs becoming available, users and occasionally interested people start buying FPGA boards and start downloading, using, testing and sometimes improving the designs. The number of (potential) designers is increasing, and the advantages of open development are full at work.
Phase four. Universties and small companies are noticing the powerful tools and high quality designs that are openly available, and start using them for courses, in-house applications and product development. A significant opportunity for open-design circuit consultants emerges. FPGA manufacturers start to address the wishes of the open-design community, acknowledging the huge market potential.
Phase five. Tools, design libraries and large designs reach maturity and compare favorably with commercial offerings on technical merit (they always compared favorably on price). The open design community is an established movement now with a large number of designers (home-based, in universities and industry), and becomes a major source for quality designs and new developments. Larger companies take notice and start to use the available open technology for their own tools and designs.
Phase six. World domination :-). Open-design circuits are used routinely as the basis of full-custom chips (thereby achieving top performance for open-design circuits). Open-design tools are used routinely for large commercial design projects, simply because they have become so much better than closed, commercial design software. Open-design compatible high-performance FPGA hardware has become a commodity and is used on a large scale, comparable to microprocessors.
The above may remain wishful thinking - or will it become a self-fulfilling prophecy? Phase six may indeed be taking things a bit far, but we will see. You are all invited to join the discussion and help make it happen.
People may wonder if 'Open Design Circuits' is really the right phrase. Why not 'Open Design Hardware'? Because that is too general: the ODC approach specifically applies to designing digital circuits for chips, not to e.g. writing device drivers for existing hardware, or to motherboard design. Well then, why not use 'Open Source Circuits', and ride on the wave of publicity around 'Open Source Software'? For one, because that phrase already has a totally unrelated meaning in the context of chip design (it describes circuits with a floating MOS transistor source terminal). Also, unlike software, chip designs are certainly not always represented by sources!
From here on, the discussion will be fairly technical and address details of circuit and system design.
FPGA architecture and devices. Of course we want a powerful and low-cost FPGA architecture that suits many types of design, with very high gate counts, high speed, support for fast and dense arithmetic functions, fast on-chip RAM, fast reconfigurability and lots of I/O. However, there may be even more important properties than those obvious ones. Consider:
Board features and standards. Of course we want a cheap development board with a PCI bus-master interface, the FPGA device of our choice, a load of fast RAM, programmable clocks and expansion sockets and connectors. However, we should also consider openness (documentation), and that we may be setting standards for expansion connectors (expect designs for add-on hardware to pop into existence).
Design verification, testing, and reliability. Even if we restrict ourselves to a 'safe' design style (e.g. single-phase synchronous), if a design runs on your FPGA at a certain clock speed, how do you know how fast it will run on someone else's? Are we going to distribute test and characterization routines with every design, or will there be standard device characterization support in tools, or will we distribute device description files and use conservative designs? How can we reliably port designs to new devices? This choice can be quite important for open-design circuits. Not setting standards here will probably invite chaos. How about power dissipation at high clocks on different devices?
Device and design description formats, portability and scalability. To what extent do we want (tool and OS support for) portability across devices? What FPGA and board-level features can we fit in a standard target description for the tools? We could distribute designs in source form (HDLs, schematics), in a retargettable intermediate format, or as 'binaries' (configuration files) tuned for specific devices. Mixed-format design descriptions can be very convenient too (HDL description with some hard macros for critical pieces of logic). Maybe it is not so hard to extract any tuned device-specific design and retarget it automatically to any device with at least the capacity of the original one (possibly with some constraints on design style).
Going further, to achieve maximum device-independence, we may want to be able to run designs that exceed the logic capacity of the device at hand. This may be possible by swapping parts of a design in and out of the device, transferring state as necessary.
As you may have noticed, these are just some random thoughts on the issue. However, I think it is very important to consider these issues beforehand, when setting up tooling for open-design circuits. A bad choice now may result in massive loss of effort later on.
Integration in OS and software. The issues are similar to those of the item above. However, support for (transparent) hardware-acceleration of software may introduce additional constrains and requirements on the design software. Something to keep in mind when making choices.
Patents. There are too many potential issues to list here, and I don't have the answers. Anyone?
Licensing. Same as above. Could the existing open software licenses be applied to open-design circuits?
Written by Reinoud Lamberts. The web site is courteously hosted by the Computer Architecture Lab/MOVE group at Delft University of Technology. Special thanks go to Marnix Arnold, Bert Meijs and Edwin Hakkennes!
Of course, this site runs Linux.
Copyright © 1998 Reinoud Lamberts, all rights reserved.