According to Gartner’s Jim Tulley, there are around 7,000 ASIC design starts a year, a number that is in slow decline. By way of contrast, there are around 100,000 FPGA design starts a year, of which 30,000 include a microprocessor of some kind. Yet for eleven years at the IP conference in Grenoble, the leading get-together for IP suppliers and users, the only mention of FPGAs has been in the context of building blocks for ASIC prototyping tools or, more recently, for testing the market before undertaking the incredibly more costly task of building an ASIC.
Obviously, this situation has to change, and it was with an eye to making a change that we helped organise a panel session at IP08. On the platform were Actel, Xilinx and Altera, as well as Synopsys, as a third party IP provider, and Alcatel-Lucent as a user. Conference organisers, Design and Reuse, also have a web site that provides a search mechanism for IP, both for ASICs and for FPGAs, and Gabriele Saucier, the CEO of Design and Reuse, was on the panel, which I tried to keep in order. The title of the session was “IP vision for FPGA: Do complex FPGA designs rely on the use of vendor-created and third-party IPs?”
The ASIC design world is made up of a lot of different companies, all supplying different parts of the solution and all trying to charge enough to stay in business and make a profit. If you are designing an ASIC, you buy tools from a range of companies and build your tool chain. You buy IP licenses from the same people and from third party companies. You integrate it with in-house IP and with new, custom, design. There is a range of foundries to build your product, but only towards the end of the design process do you begin to make your design foundry-specific. You then pay the foundry obscenely large amounts of money for the initial wafers. Once in manufacture, the IP providers will expect royalties on top of what you are paying the foundries for silicon.
With FPGAs, the situation is totally different. Actel’s Tom Moore was refreshingly frank. His company’s job is to sell silicon: to make sure you buy their silicon, Actel provides a lot more. The example he gave was that of a design using an ARM Cortex M1 core, a full 32 bit processor. The entire tool chain is available on the web, for nothing. So is the IP for the Cortex. Once these are downloaded and a design created, then a flash programmer and a development board with a sample device together cost only $350. If the device goes into production, there is no need to get an ARM licence or to pay royalties – these are all included in the price of the FPGAs that you buy from Actel.
Both Stuart Nesbit (Xilinx) and Mark Dickinson (Altera) said that they recognised the importance of IP, and that their own IP is priced so that it does not disrupt the market. Xilinx now sees the FPGA as a system level platform, and, at that level, IP provides the only route to implementation.
All three agreed that IP was essential, and that this means that third party IP was also essential. While FPGA vendors provide considerable quantities of IP, they do not have, nor could they have, knowledge of every domain, particularly in areas like communications interfaces or for very application- specific designs. For these domains they rely on third parties, and they work to encourage them. In addition to 200 people working internally on IP, Xilinx has the largest third party programme, with over 300 partners.
Altera chooses its partners carefully and then works closely with them, both to ensure that they make money and that their products help to sell silicon for Altera.
Actel has a number of programmes, and many of the 58 companies in these programmes offer IP, in addition to over 170 IP cores from Actel.
Synopsys has an active IP programme, although their FPGA products are a spin-out from their mainstream ASIC tools programme. They are primarily intended to ensure that companies using FPGAs for prototyping or market validation are using the same IP that will be used in the final ASIC, and that it will perform in the same way – over half their customers are using FPGAs in ASIC designs, and most are using IP, with about half of them including processors. A particular issue is interface IP, which needs hardware validation and conformance validation.
One advantage that the FPGA designers have over their ASIC equivalents is the increasing platformisation of IP. A designer building a device that requires USB connectivity, for example, may have to source the PHY and MAC hardware IP from different suppliers and use a third for the software. They will then have to spend time integrating and testing these parts, at the same time learning more than they want to know about USB. Those working in the FPGA arena, including the silicon vendors, have realised, for some time now, that the user doesn’t want to become an expert in the subject of the IP. They have made it is possible to get everything needed in a single bundle. And, since the FPGA IP guys will have implemented the USB on the same target silicon, they should be able to guarantee conformance to the standards.
Alcatel Lucent’s Francois Kleitz put in a user’s view, based on many hundreds of FPGA developments. With low end FPGAs, normal practice is to use in-house resources, but larger projects do use external IP. Roughly 75% is sourced from the silicon vendors and 25% from third parties. His experience is that, when compared with ASIC IP, you can normally expect FPGA IP to be of higher quality, particularly for more popular areas, since it will have been used in many designs, possibly hundreds of times. However, the big draw-back is that integration presents significant issues: compiling and simulation can take a very long time, as IP is not normally delivered as source code.
This was a general issue for users. Users want to be able to verify the IP itself and include it in any higher-level verification activity, yet suppliers, including the silicon vendors, are, naturally, reluctant to do more than provide a net list. Two years ago, Synplicity, now part of Synopsys, developed an open IP encryption environment and placed it in the public domain. The IP provider uses the standard to encrypt the source code, and the different elements in the tool chain are able to decrypt as appropriate to carry out verification, synthesis, etc. While Actel has adopted this approach, Altera and Xilinx use their own, proprietary, encryption and obfuscation technologies, adding further complications. The vendors are not committed to a particular mode of delivery of IP, and are all normally prepared to make the RTL of a core available to customers, but this would come at a significant premium.
Alcatel Lucent is also interested in simplifying the IP business model. If you are building a chip where the NRE is going to be measured in millions of dollars and manufacturing volumes are also measured in millions, then negotiating with multiple vendors of IP, each of whom has a separate licence and royalty pattern and whose contractual terms are different, while still a royal pain, is more or less acceptable. If you are looking at the shorter production runs and much lower NRE of an FPGA, this approach becomes intolerable, and Kleitz suggested that there should be work on a “Standard Contract Interface.”
There are significant advantages for designers in the Actel – ARM approach, where buying the silicon also buys the IP to the ARM core, but the FPGA vendors are not (yet?) geared to this model for much IP, let alone all of it.
Gabriele Saucier’s Design and Reuse web site was set up to match IP suppliers’ offerings with designers’ requirements. The site is seeing some growth in the use of the portal for finding FPGA IP, and she is building portals for large companies which include both third Party IP and that from FPGA vendors.
Back to the rhetorical question set to the panel: “Do complex FPGA designs rely on the use of vendor-created and third-party IPs?” The answer is, of course, yes. But while designs do rely on IP, the FPGA business model for IP suppliers has to be different to that for ASICs. The new model has to reflect the much larger numbers of designs, but smaller production runs. It has to work within the broader model already established by the FPGA vendors, where much of the tool chain and even considerable quantities of IP may be supplied free of charge. This is a difficult balancing act, and it is not clear that all, or indeed many, of the IP suppliers have yet mastered it.
