Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

New era in embedded designs dawns

Posted: 16 Dec 2008 ?? ?Print Version ?Bookmark and Share

Keywords:embedded design? FPGA? open source model? microprocessor?

FPGA designers are embedding soft microprocessors in an increasing number of designs. As a result, FPGA vendors and third-party IP vendors have developed a number of soft microprocessors that are licensed in a variety of ways including the most recent model, open source.

Because designers typically will invest significant time in the development of software code for their soft microprocessors, it is important that they understand the implications of the associated licensing models.

Difficult decisions
Once the decision to implement a soft microprocessor is made, designers must determine which licensing model best meets their needs. There are four principle licensing models used by FPGA vendors for soft microprocessors and MCUs.

Third-party IP vendors most typically use the paid IP model. Although the approaches taken by the third-party vendors are not discussed in this article, most of them are similar to those of the FPGA vendors.

Model 1: Paid IPThe traditional model for supplying soft microprocessors for FPGAs is paid IP. This delivery model presents four challenges:

??A fee must be paid for the right to use the microprocessor development tools and the HDL code that is produced. To continue to use the tools, say for software maintenance, this fee often recurs annually.
??The HDL description of the microprocessor typically is encrypted, limiting the designer's ability to optimize the implementation and leaving the designer dependent on the FPGA vendor for bug fixes.
??Development resources to support the microprocessor are limited to those the FPGA vendor chooses. The vendor, not the designer, defines resource priorities.
??Paid IP licensing terms typically limit implementations to the vendor's FPGA devices. As designers amass code developed for the microprocessor it becomes increasingly difficult to move to another FPGA vendor, a fact known all too well by the vendors.
??The designer's virtual inability to switch vendors eliminates competitive pressure on the vendor, which can lead to less customer attention and limited future price concessions.

Model 2: Free reference designsThe free reference design approach removes two of the challenges associated with the paid IP model. The lack of an upfront fee is certainly attractive, and the fact that these designs are invariably provided in source code format allows for access to the design's structure.

However, ownership of the design by the FPGA vendor eliminates any incentive to develop additional code for the design. Finally, as with paid IP, implementation of the reference design is limited to the vendor's device architecture.

The LatticeMico32 IP core consumes minimal device resources, while maintaining performance required for a broad application set.

Model 3: Encrypted IPThis is a novel attempt to address some of the challenges of the paid IP approach. In this model, IP is incorporated within a design using the FPGA design tools and the encrypted bitstream that is generated.

To use this bitstream, special FPGAs that have been pre-programmed with the decryption key must be purchased at a price higher than that of standard FPGAs. This approach eliminates the upfront fee and allows standard microprocessor architectures to be used within FPGAs.

This use of a standard architecture allows the code to be implemented in other non-FPGA solutions such as standalone chips and ASICs. However, designers again find themselves locked into a single vendor's devices. The lack of code visibility and vendor-driven development priorities are not solved with this approach.

Model 4: Open sourceAn open source approach promises to resolve the thorny issues associated with other licensing models. It provides visibility into the code, allowing designers to understand the design's functionality and better optimize their use of it.

It provides designers with the flexibility to implement code fixes and the IP rights to encourage users to make their enhancements available to the wider development community.

Open source is free and perhaps most importantly, it provides portability that allows implementation in any FPGA architecture or a non-FPGA implementation such as an ASIC.

GPL for open source software
The open source movement started in the software arena, where many open source licensing approaches have been taken. One that has become popular is the GNU General Public License (GPL). The license grants users several important rights in return for their acceptance of the following responsibilities:

??The right to use and modify the software;
??The right to redistribute the software and derivative works;
??The requirement to make any distributions under the GPL license and to provide the license to those receiving the distribution;
??The requirement to apply the GPL license to works that are based on material received under the GPL license;
??The requirement to make source code available for works based on material received under the GPL license;
??A limitation in liability;
??The requirement to keep original copyright notices and to clearly mark modifications.

The balance the GPL strikes between protecting the contributors' right to be recognized for their work and to have the work remain in the public domain, and the requirements for future users, is clearly one of the factors responsible for GPL's popularity in the software development community. However, GPL is an imperfect license for IP that ultimately will be implemented in hardware.

Hardware distribution
The first challenge associated with using the GPL to license IP targeted to hardware is the requirement to provide a copy of the license and make the source code available.

Clearly this is reasonable and important when distributions are made in soft form, for example when posting modified code to a website, or providing it to a customer. However, when the design is implemented physically, for example within an FPGA, this is more problematic. Imagine shipping a copy of the GPL with each version of the system.

The second challenge is the requirement to license an entire derivative work that includes GPL-based code under GPL. Often designers want to use GPL along with proprietary material.

For software, it is normally not too difficult to separate GPL-based code and proprietary code as two separately compiled and documented programs. For hardware, where a single place and route yields a single design, this is not feasible.

In order to offer an open source licensing model optimized for hardware implementations such as its LatticeMico32 embedded microprocessor, Lattice developed an Open IP Core License agreement that explicitly addresses the limitations of the GPL. To resolve the GPL requirement to ship a copy of the license, the Lattice agreement stipulates that

"The provider grants to you a personal, non-exclusive right to use object code created from the software or a derivative work to physically implement the design in devices such as a programmable logic devices or application specific integrated circuits. You may distribute these devices without accompanying them with a copy of this license or source code."

The GPL requirement to separate GPL-based code and proprietary code is resolved as well:

"The provider grants to you a personal, non-exclusive right to modify the source code of the software and incorporate it with other source code to create a derivative work. At your discretion you may distribute this derivative work in a form and under terms of your choosing provided you arrange your design such that the derivative work is an identifiable module within your overall design, and you distribute the source code associated with the modules containing the derivative work in a customarily accepted machine-readable format, free of charge under these license terms."

Now, you may already have a headache from reading that thicket of legalese, but you will develop a much more severe headache if you do not appreciate the benefits as well as the limitations of licensing models.

Buyer beware
As soft microprocessors embedded within FPGAs become more prevalent, designers will need to pay attention to licensing terms. This article has examined four licensing approaches, with all but the Open Source approach limiting designers' future choice of FPGA devices. Some of these approaches also limit designers' ability to access the underlying code, hampering understanding and leaving them at the mercy of the IP providers for bug fixes.

Open source licensing of soft microprocessors provides designers the flexibility to change FPGA architectures and the visibility into the processor architecture that they need.

However, even with open source it is necessary to pay attention to the licensing details, as many open source licenses that are popular in the software arena pose significant challenges when applied to IP that is targeted to hardware, including the need to distribute hardware without a license, and the need to mix open and proprietary code in a single hardware implementation.

- Gordon Hands
Director of Strategic Marketing
Lattice Semiconductor Corp.

Article Comments - New era in embedded designs dawns
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top