All I really need to know about designing embedded systems on FPGAs I learned in kindergarten. Well, maybe not exactly kindergarten, but close. It was in 1983 in the undergraduate EE lab at the University of Texas. I had a Motorola 6809 development board (complete with hex keypad and LED display), my prototyping board (a mass of mostly SSI components wire-wrapped), a logic analyzer, and a scope. I was partitioning my application into hardware and software components, developing firmware, testing hardware/software interfaces, and debugging my system piece by piece. It worked.

About fifteen years later, I heard that FPGA vendors were planning to put processor cores on FPGAs. The speculation started almost immediately: “This means that FPGA designers will now have to adopt the design approach of SOC ASIC! They’ll need to do system-level partitioning, hardware-software co-design and co-verification, and sophisticated HDL design with multi-language IP re-use. Then, they’ll have to find some magic way to boost designer IQ by twenty points or so…” In corporate strategy rooms, visions of multitudes of FPGA designers standing in line to buy tools with six-digit price-tags painted broad, hopeful smiles on the faces of EDA executives.

Back in my college lab, however, I didn’t feel particularly sophisticated. I didn’t have a multi-disciplinary design team or hundreds of thousands of dollars worth of state-of-the-art virtual prototyping tools. I didn’t even have a college degree, yet I built a working system with all of the elements of today’s typical field programmable system-on-chip design.

Where is the disconnect between these two worlds? ASIC SOC design teams must conceive, develop, debug, and test incredibly sophisticated systems of hardware and software without ever building one. This is why they are forced into the Rube Goldberg world of virtual silicon prototyping. In college if I had been required to design my whole system on paper, (hardware, software, and all), then have someone else build it for me, and stake my entire grade on whether it worked the first time, it would be close to the situation faced by ASIC designers. It is no wonder that design teams will go to great lengths to avoid the catastrophe of repeated iterations through the ASIC loop when the cost for each attempt is weeks of schedule slip and hundreds of thousands of dollars.

In the kinder, gentler world of FPGA, however, we have it much easier. We can try out our systems in as many intermediate stages as we like, in whole or in part, using actual target hardware running at-speed on the board. We can debug using a variety of tools including virtual instrumentation, on-chip signal probing and bus monitoring modules, JTAG-based connections to the outside world, and versatile prototyping boards with a plethora of peripherals. FPGA system-on-chip design is, in fact, much closer to system-on-board design than to its cell-based silicon-sister.

This is probably bad news for the EDA folks who are waiting patiently by the phones for all of us FPGA designers to call and place our orders. In an attempt to rationalize the silence, they may speculate that FPGA-based embedded systems just aren’t catching on yet. Nothing could be farther from the truth. Altera alone claims to have taken over 12,000 (paying, not free) orders to date for its spectacularly popular Nios development kit. Early results from our FPGA project survey data bears this out as well – over 16% of programmable logic designs projects reported to us in Q3 2003 included some embedded processor, and Altera’s Nios led the pack with over 50% of those slots. Although Nios rules the roost at the moment, it is by no means the only game in town. The Xilinx MicroBlaze core followed closely behind with an almost 40% share of our processor-using responses. These vendors’ success is a strong indicator that embedded system design in FPGA has taken off about as fast as reality-based TV.

Even though we don’t necessarily require an ASIC-like virtual silicon prototyping environment, there is a very strong market demand for high-performance, high-productivity tools for the rapid development of field-programmable system-on-chip (FPSOC).

Before the advent of FPSOC, the FPGA design process was simple and straightforward. First, you developed some RTL code. Next you simulated it until it seemed to work, then you synthesized it into a workable implementation. If all looked good at that point, you ran your design through place-and-route, and, (assuming you met timing) you were done. Drop a processor in the mix, though, and you give rise to evil beasts such as busses, memory, peripherals, RTOS, middle-ware, and software. Unless you are truly the renaissance designer and plan to re-invent everything from scratch, you’ll also be re-using some IP blocks from previous designs or from third-party vendors. None of this is well-supported by the FPGA design methodologies of the past, and FPGA and EDA vendors alike have gone scrambling for new solutions.

Enabling much of this board-like FPSOC design revolution is key technology like that supplied by First Silicon Solutions (FS2) of Portland, Oregon. Like ASIC, FPGA suffers from limited visibility through the window of available pins into internal signals. Valuable I/O space is used to bring out signals that really do need to connect to the outside world, leaving internal signals and busses unavailable for our debugging scrutiny. FS2’s technology, dubbed “On-Chip Instrumentation” or “OCI” replaces the logic analyzer in the FPSOC to board-based system metaphor. FS2 solutions are behind the scenes in many vendors’ solutions, and are available stand-alone as well.

The grandfather of FPSOC design solutions is probably Altera’s SOPC Builder (formerly known as System Builder). Altera took essentially the same approach one would take in assembling a board-based design kit. They wanted a useful catalog of building blocks and peripherals in the form of IP, a set of tools for assembling those blocks into systems, and a framework for debugging and verifying the resulting system with its associated software components.

With SOPC Builder, Altera provides a platform for assembling bus-based systems out of common components. Their library includes elements ranging from simple blocks of fixed logic to complex, parameterized, and dynamically generated subsystems. Launched from within Altera’s Quartus II environment, SOPC Builder provides a wizard-based interface for assembling IP components to construct a system, much in the same fashion you would in creating a board-based system from discrete devices.

One of the obvious strengths of third-party design solutions is vendor-independence. If you’re comfortable tying your design irrevocably to a particular vendor or even a particular part (which many teams are), you may be perfectly well-served with vendor-supplied solutions. If, however, you think you might want to take advantage of the flexibility to try out your design on various technologies, or have the option to switch to a faster, better, or more affordable solution in the future, you might want to consider designing with some vendor- and technology-independence in mind.

Altium, an Australian company with a long history in PC-based board design tools under the Protel name, has just announced its “Nexar” system aimed precisely at the vendor-independent FPSOC design problem. Nexar is a complete solution for creating FPSOC designs based on Altium’s own vendor-independent IP. Nexar includes a suite of design tools bundled with a prototyping and development board. For more information on Nexar, read this week’s contributed article by Rob Irwin of Altium.

Not all systems are developed from the ground up. Many, if not most, in fact, are legacy designs being upgraded, updated and overhauled using modern components. One thing systems designers are most reluctant to change or re-build is working, proven software. For this reason, a number of vendors are being very successful with embedded cores based on popular older processors such as the venerable 8051. Actel recently joined this camp with their newly announced 8051-core and Platform8051, which includes a compatible set of peripheral cores such as Ethernet and serial interfaces, along with an 8051 processor. Actel’s 8051-based FPSOC solution is particularly attractive for mil/aero designers preserving legacy applications while targeting upgraded designs to Actel’s high-reliability antifuse- and flash-based devices.

This explosion in the number of applications using embedded-processor design has created an increase in demand for the tools and components required by embedded software developers. Accelerated Technology, Mentor Graphics’ embedded software division, has seen a surge in interest in embedded software tools for FPSOC design. “A few years ago, when Altera and Xilinx first started working on their hard core ARM- and PowerPC-based devices, embedded software suddenly became a concern,” says Robert Day of Accelerated Technology. “Later, when the Nios and Microblaze soft-core processors were introduced, people started dropping multiple processors onto a single FPGA to up their performance.” According to Day, multiple processors create difficulties in software/hardware debug because of communication and synchronization issues between processors. Accelerated Technology has worked on this problem to deploy solutions that help analyze and de-bug multi-processor issues.

Accelerated Technology also offers a line of “middle-ware” software components that drive components such as 802.11b, USB, TCP-IP, and graphics. These components provide an off-the-shelf solution for embedded software developers stitching together FPSOC-based applications. Leveraging embedded development IP such as these middle-ware stacks, design teams can make even shorter work of development projects and further capitalize on the time-to-market leverage gained by an FPGA implementation.

The recent introduction of super-low-cost logic families such as Spartan from Xilinx and Cyclone from Altera makes the SOPC option even more attractive, and opens it to a much wider audience of applications. Given the cost/performance ratios of these devices, we should expect that SOPC design might become a way of life for the majority of systems design teams. Judging from the teams we spoke to for this article, next year should be an exciting year in the FPSOC arena, so stay tuned.

Kevin Morris, FPGA and Programmable Logic Journal

November 25, 2003

Comments on this article? Send them to comments@fpgajournal.com