Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

FPGA designers are embedding soft microprocessors in an increasing number of designs. As a result, FPGA vendors and third-party Intellectual Property (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 microcontrollers.

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 IP
The 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. This limits the designer's ability to optimize the implementation, and leaves 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 Designs
The 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.

Model #3 - Encrypted IP
Encrypted IP 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 stand-alone 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 Source
An Open Source approach promises to resolve the thorny issues associated with other licensing models. Open Source 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 intellectual property 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: Great for open source software...But Not Hardware
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 responsibilities or requirements that are summarized below (visit www.gnu.org for the precise wording of the license).

* 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 intellectual property that ultimately will be implemented in hardware.

Two Challenges When Using GPL For Hardware Distribution
The first challenge associated with using the GPL to license intellectual property 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.

Summary: Buyer Beware
As soft microprocessors embedded within FPGAs become more prevalent, designers will need to pay careful 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 close attention to the licensing details, as many Open Source licenses that are popular in the software arena pose significant challenges when applied to intellectual property 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 is Director of Strategic Marketing for Lattice Semiconductor/ Silicon Valley, participating in the definition of Lattice's next-generation programmable device technologies and associated intellectual property (IP) cores. Most recently, Hands has been involved in the definition and launch of the low-cost LatticeECP2M FPGAs and the LatticeMico32 embedded microprocessor, which is licensed under a unique, no cost Open Source license.

RELATED ARTICLES Code Signing in Adobe AIR Dr. Dobb's Agile Newsletter 08/08 CUDA 2.0 Released Coverity Intros Software Readiness Manager for Java New Data Center Architecture Proposed		TOP 5 ARTICLES No Top Articles.