Open source soft microprocessors promise a new era in embedded design - Embedded.com

Open source soft microprocessors promise a new era in embedded design

FPGA designers are embedding soft microprocessors in an increasingnumber of designs. As a result, FPGA vendors and third-party IntellectualProperty (IP)vendorshave developed a number of soft microprocessors that are licensed in avariety of ways including the most recent model, Open Source.

Because designers typically will invest significant time in thedevelopment of software code for their soft microprocessors, it isimportant that they understand the implications of the associatedlicensing models.

Difficult Decisions
Once the decision to implement a soft microprocessor is made, designersmust determine which licensing model best meets their needs. There arefour principle licensing models used by FPGA vendors for softmicroprocessors and microcontrollers.

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

Model #1 ” PaidIP
The traditional model for supplying soft microprocessors for FPGAs ispaid IP. This delivery model presents four challenges:

* A fee must be paid for the right to use the microprocessordevelopment tools and the HDL code that is produced. To continue to usethe tools, say for software maintenance, this fee often recursannually.

* The HDL description of the microprocessor typically is encrypted.This limits the designer's ability to optimize the implementation, andleaves the designer dependent on the FPGA vendor for bug fixes.

* Development resources to support the microprocessor are limited tothose the FPGA vendor chooses. The vendor, not the designer, definesresource priorities.

* Paid IP licensing terms typically limit implementations to thevendor's FPGA devices. As designers amass code developed for themicroprocessor it becomes increasingly difficult to move to anotherFPGA vendor, a fact known all too well by the vendors.

The designer's virtual inability to switch vendors eliminatescompetitive pressure on the vendor, which can lead to less customerattention and limited future price concessions.

Model #2 – FreeReference Designs
The free reference design approach removes two of the challengesassociated with the paid IP model.

The lack of an upfront fee is certainly attractive, and the factthat these designs are invariably provided in source code format allowsfor access to the design's structure.

However, ownership of the design by the FPGA vendor eliminates anyincentive to develop additional code for the design. Finally, as withpaid IP, implementation of the reference design is limited to thevendor's device architecture.

Model #3 -Encrypted IP
Encrypted IP is a novel attempt to address some of the challenges ofthe paid IP approach. In this model, IP is incorporated within a designusing the FPGA design tools and the encrypted bitstream that isgenerated.

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

This use of a standard architecture allows the code to beimplemented in other non-FPGA solutions such as stand-alone chips andASICs. However, designers again find themselves locked into a singlevendor's devices. The lack of code visibility, and vendor drivendevelopment priorities are not solved with this approach.

Model #4 – OpenSource
An Open Source approach promises to resolve the thorny issuesassociated with other licensing models. Open Source provides visibilityinto the code, allowing designers to understand the design'sfunctionality and better optimize their use of it.

It provides designers with the flexibility to implement code fixesand the intellectual property rights to encourage users to make theirenhancements available to the wider development community.

Open Source is free and, perhaps most importantly, it providesportability that allows implementation in any FPGA architecture or anon-FPGA implementation such as an ASIC.

GPL: Great for open sourcesoftware…But Not Hardware
The Open Source movement started in the software arena, where many OpenSource licensing approaches have been taken. One that has becomepopular is the GNUGeneral Public License (GPL).

The license grants users several important rights in return fortheir acceptance of the responsibilities or requirements that aresummarized below (visit www.gnu.org for the precise wording ofthe 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 andto provide the license to those receiving the distribution.
* The requirement to apply the GPL license to works that are based onmaterial received under the GPL license.
* The requirement to make source code available for works based onmaterial received under the GPL license.
* A limitation in liability.
* The requirement to keep original copyright notices and to clearlymark modifications.

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

Two Challenges When Using GPL ForHardware Distribution
The first challenge associated with using the GPL to licenseintellectual property targeted to hardware is the requirement toprovide a copy of the license and make the source code available.

Clearly this is reasonable and important when distributions are madein soft form, for example when posting modified code to a website, orproviding it to a customer. However, when the design is implementedphysically, 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 entirederivative work that includes GPL-based code under GPL. Often designerswant to use GPL along with proprietary material.

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

In order to offer an Open Source licensing model optimized forhardware implementations such as its LatticeMico32 embeddedmicroprocessor, Lattice developed an OpenIP Core License agreement that explicitly addresses the limitationsof the GPL. To resolve the GPL requirement to ship a copy of thelicense, the Lattice agreement stipulates that

“The provider grants to you apersonal, non-exclusive right to use object code created from thesoftware or a derivative work to physically implement the design indevices such as a programmable logic devices or application specificintegrated circuits. You may distribute these devices withoutaccompanying them with a copy of this license or source code.”

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

“The provider grants to you apersonal, non-exclusive right to modify the source code of the softwareand incorporate it with other source code to create a derivative work.At your discretion you may distribute this derivative work in a formand under terms of your choosing provided you arrange your design suchthat the derivative work is an identifiable module within your overalldesign, and you distribute the source code associated with the modulescontaining the derivative work in a customarily acceptedmachine-readable format, free of charge under these license terms.”

Now, you may already have a headache from reading that thicket oflegalese, but you will develop a much more severe headache if you donot appreciate the benefits as well as the limitations of licensingmodels.

Summary: Buyer Beware
As soft microprocessors embedded within FPGAs become more prevalent,designers will need to pay careful attention to licensing terms. Thisarticle has examined four licensing approaches, with all but the OpenSource approach limiting designers' future choice of FPGA devices.

Some of these approaches also limit designers' ability to access theunderlying code, hampering understanding and leaving them at the mercyof the IP providers for bug fixes.

Open Source licensing of soft microprocessors provides designers theflexibility to change FPGA architectures and the visibility into theprocessor architecture that they need.

However, even with Open Source it is necessary to pay closeattention to the licensing details, as many Open Source licenses thatare popular in the software arena pose significant challenges whenapplied to intellectual property that is targeted to hardware,including the need to distribute hardware without a license, and theneed to mix open and proprietary code in a single hardwareimplementation.

Gordon Hands isDirector of Strategic Marketing for Lattice Semiconductor/ SiliconValley, participating in the definition of Lattice'snext-generation programmable device technologies and associatedintellectual property (IP) cores. Most recently, Hands has beeninvolved in the definition and launch of the low-cost LatticeECP2MFPGAs and the LatticeMico32 embedded microprocessor, which islicensed under a unique, no cost OpenSource license.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.