Making FPGAs work for embedded developers: Part 1 -

Making FPGAs work for embedded developers: Part 1


FPGA technology has been available since the mid 1980s. In embeddedsystems development, FPGAs have a long history of use as a containerfor the plethora of glue logic surrounding microprocessor applications.

In more recent years, FPGAs have been applied to fastsignal processing as an alternative to general purpose DSP chips. Currently there is alot of hype surrounding FPGAs as an embedded platform, with softprocessors providing the basis for FPGA-based system-on-chip (SoC)designs for applications that don't justify the cost of ASICdevelopment.

There's no doubt that increasing capabilities and sizes combinedwith shrinking price tags is changing the value equation when it comesto using these versatile programmable devices in productionapplications.

But so far the action has all been targeted at the hardwaredevelopment end of the design process. FPGA design flows haveessentially borrowed from chip design methodologies and tend to requirespecialist Register Transfer Language (RTL)design expertise and more than a passing conversancy with hardwaredescription languages such as VHSIC Hardware Description Language (VHDL)and Verilog. These are skills thatare not typical of your average embedded designer.

While FPGA technology has the potential to speed embeddeddevelopment and allow new approaches to be taken to design in general,most embedded software developers still tend to work just as before –selecting a discrete hardware processor at the beginning of the designcycle, creating the physical platform then writing the software to makeuse of this platform.

This lack of exploitation of 'soft' hardware in embedded systemsdevelopment can largely be attributed to the lack of tools to allow Cprogrammers to use their skills at the programmable hardware level. Thedesign of programmable devices must be better integrated with currentembedded design flows and made accessible to the mainstream of embeddedengineers and software developers in order for the full potential ofFPGAs to be realized in the embedded world.

It's all in the description
From the outside you'd be forgiven for thinking that FPGA design shouldbe a comfortable learning experience for embedded developers.Traditional design flows for FPGAs tend to center around hardwaredescription languages like VHDL or Verilog. While the outcome of HDLsis hardware, the methodology is software – the very realm in whichembedded developers thrive.

Of course the reality is very different. While HDLs are programminglanguages and the mechanics and syntax will generally be easy for anycompetent programmer to pick up given time, the object of HDLs is verydifferent from that of traditional software. HDLs, by their nature,define hardware. As such they are inherently designed to cope withparallelism and asynchronicity. Traditional embedded software on theother hand is destined to be reduced to a set of instructions that willultimately be sequentially and synchronously executed on amicroprocessor.

So traditional FPGA design flows are not attractive to embeddeddevelopers because, even though they are software based, they stillrely on the designer understanding and being willing to design at thehardware level. What embedded developers want is to be able to do isremain at the algorithm level.

Converting software to hardware
Some attempts have been made to make hardware description more friendlyto embedded developers. C-based languages such as SystemC have been developed thatdraw on the syntax and basic structure of C. While this can make theinitial going a little easier, these languages are basically anotherform of HDL, and therefore require embedded developers to think at thehardware level, just as traditional HDLs do.

A more promising approach is based on taking standard ANSI C code and passing itthrough a compiler that converts it not into object code, but into aRTL hardware description that can be synthesized and used to program anFPGA. Numerous companies, and indeed the FPGA vendors themselves, haverecently come out with such systems.

UsingC-to-RTL conversionembedded developers can write an algorithm in C and then createhardware to execute that algorithm directly. This is step in the rightdirection, but integrating the generated hardware into the rest of thesystem and writing the necessary code to allow the processor to makeuse of the generated hardware can often slow down the overalldevelopment process, rather than accelerate it.

Converting C to RTL is only the beginning. Making this processaccessible to embedded developers requires design toolsthat bridge thegap between the hardware and software sides of the design process.

More than just glue logic
It is clear that what is needed from a tool perspective to harness thefull opportunities offered by programmable devices such as FPGAs is asystem which raises the abstraction level of the development process toa point where core elements of the design – both hardware and software- can be easily changed using familiar design techniques and processes.

Such a system must unify the entire electronic product developmentprocess by bringing together hardware, software and programmablehardware development within a single coherent design environment.

To see how this would benefit embedded design we need to movebeyond what is essentially the glue logic application for FPGAs thatmost developers have today. A broader view involves harnessing the fulladvantages of programmable devices by bringing as much hardware aspossible into the soft realm.

This can include the processor functionality itself, and today softprocessors hosted in FPGAs are becoming more common as embeddedplatforms. At the fundamental level, moving to FPGA-hosted softprocessors will deliver advantages in terms of architecture flexibilityplus smaller, simpler boards. But there is a deep level of utilizationthat offers even more compelling benefits.

Abstracting the processor system
Intriguing possibilities open up for embedded developers when theprogrammability of FPGAs is harnessed to provide what is essentially anabstraction layer on top of the processor – an abstraction layerimplemented not only in software, but in hardware as well.

Consider a system where the processor is connected to its memory andperipherals through a piece of configurable hardware – essentially ahardware wrapper – that abstracts the processor interface (See Figure 1, below ). By simplyreprogramming the FPGA to change the hardware wrapper, the systemdesigner could change one processor for another and even move betweenhard or soft processors without having to modify the rest of the systemhardware.

From a system perspective all processors would look the same,simplifying the hardware design process. Of course, extending this tothe application software would also require compilers that providedC-level compatibility between the processors.

Figure1: Large scale FPGAs provide a versatile reconfigurable hardwareplatform for embedded systems design that can provide generic interfaceto both soft and discrete system devices and allow easy interchange ofprocessors and peripherals.

The advantage of such a system is that the processor choice wouldnot need to be made 'up front'. The system could be developed using oneprocessor, but moved to a faster device if, during development, it wasfound that more performance was needed.

Thanks to the wrapper layer, that processor could be soft, hard oreven a hard processor core within an FPGA without impact to thesurrounding hardware, since the translation layer simply creates astandard interface to the connected peripherals. Indeed the connectionof the peripheral devices themselves can be abstracted in the same way.

With this scheme the FPGA effectively becomes the systeminterconnection structure by providing a universal connectivity for allparts of the embedded system. In other words, it effectively becomes astandard interface 'backbone' that allows both hardware and software totalk to processors and peripherals with universal ease.

Hard or soft? – It's your choice
Abstracting the system hardware within an FPGA and unifying thedevelopment of the system hardware and software could potentially makedirect conversion of C code into hardware both seamless, easy andextremely useful for embedded developers. With design tool support,such a system could allow embedded developers to influence underlyingsystem hardware without the need to specifically work at the hardwaredesign level.

Because a unified design environment would have access to allhardware connected to the processor via the FPGA, soft peripheralscould be added automatically by the system to perform specificfunctions.

Any C functions or algorithms the developer wanted converted tohardware could be automatically converted from C and added as aperipheral device to the standardized processor bus. The design systemwould handle the hardware generation and even adding the code necessaryto allow the processor to utilize the hardware.

In a real sense, the programmer would gain the ability toautomatically generate an application-specific hardware coprocessor andadd it to the system without ever having to directly edit any hardware.The programmer could remain in the algorithm domain and simply choosewhether a particular algorithm should be executed in hardware orsoftware ” the system would do the rest!

Next, in Part 2: The basic building blocks in an integratedFPGA/embedded system development environment.

Rob Irwin is Product Manager, responsible for the Altium Designertools at Altium Limited. He has a Bachelor of Engineering (Electrical)from the University of Sydney, Australia, and over 20 years experiencein the electronic design industry.

Leave a Reply

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