In this series:
- The soft processor in the Perseus reference designs – Part 2: Resource usage
- The soft processor in the Perseus reference designs – Part 3: First level optimizations
- The soft processor in the Perseus reference designs – Part 4: No MicroBlaze at all
CPU usage in FPGA designs
Field-programmable gate arrays (FPGAs) are widely used in today's embedded systems, mainly because of their performance (a wide parallel processing architecture) and their flexibility (development tools and their ability to be re-configured). These benefits provide FPGAs with many inherent advantages over application-specific integrated circuit (ASIC) solutions. Not only do they enable a faster prototyping process (thus enabling designers to reduce their time to market) but they also simplify maintenance and product upgrades.
While the parallel processing benefits of FPGAs are obvious when compared to a conventional CPU-oriented approach, it is not so clear when dealing with sequential tasks. Usually, finite state machines (FSMs) are used for such jobs. For example, an FPGA might substantially help in a design that requires demanding or time-critical analog-to-digital conversion (ADC) output filtering. The finite impulse response (FIR) filter implementation might be sequential or fully parallel, making a trade-off between performance and cost in terms of FPGA resources. In this design, the ADC acquisition clock might be driven by a phase lock loop (PLL). The sequential tasks to program such device might then look like:
1. Receive the desired ADC frequency from the user.
2. Compute different PLL parameters like the multiplication and divider coefficients, the loop filter, etc.
3. Program the PLL through a serial peripheral interface (SPI). This might requires tens of SPI accesses.
4. Wait for the PLL lock status.
5. Reset the FPGA logic (FIR filter) using this clock.
It appears significantly easier to program these sequential tasks in C rather than in hardware description languages (HDL). So, the final design might be a hybrid solution composed of a microprocessor and an FPGA, both doing their respective tasks.
The FPGA industry, however, has produced an interesting solution in the last decade: the soft processor. A soft processor is a microprocessor implemented entirely in the general-purpose memory and logic fabric of an FPGA. It usually comes with a complete software development environment (editor, C compiler, debugger, etc) and can perfectly coexist with the remaining FPGA logic. Some examples are the Xilinx MicroBlaze and the Altera NIOS cores. In our previous example, the final design might fit on a single FPGA. Part of the logic would perform the parallel filtering while the other part would implement a soft processor that runs a program to configure the PLL.
The soft processor in the Perseus BSP reference design
Nutaq's Perseus reference design is no exception to this trend. In addition to the logic interfacing the peripherals, it includes the Xilinx MicroBlaze soft processor to perform all the initializations and to control the FPGA mezzanine card (FMC) hardware and FPGA cores.
In the Board Support Package (BSP) reference design shown in Figure 1, a standalone C application is built using Nutaq's libraries in the Xilinx SDK environment. The BSP provides libraries for the supported FMCs as well as for general utility functions. The BSP supplies the minimal design necessary to configure and operate the FMC hardware in a standalone configuration (i.e. no interaction with a remote PC). The remaining FPGA logic ("User logic") is left to the user to implement his or her parallel processing application.
Figure 1: MicroBlaze soft processor in the BSP reference design
MicroBlaze can do even more
The main objectives of the Nutaq reference designs and tools are to simplify and fasten the development process. In the Board Support Development Kit (BSDK) reference design shown in Figure 2, a lot of functionalities are added to the MicroBlaze soft processor (when compared to its standalone version). Helped by the extra FPGA logic, the user logic now has access to remote PC communication and data recording and streaming. MicroBlaze runs an embedded Linux distribution that includes a TCP/IP stack. More information can be found here.
Figure 2: MicroBlaze in the BSDK reference design
Is the MicroBlaze always desired?
As previously explained, the MicroBlaze soft processor used in the Perseus reference designs performs a lot a processing that would be hard to implement in HDL, including a TCP/IP stack and routines to configure and control different on-board chips. Nevertheless, even if a soft processor has a lot of benefits, it comes with some disadvantages. The most obvious one is that it consumes logic resources. For standalone applications, removing the MicroBlaze would necessitate the translation of C code to HDL. This would be tedious work and is probably not desired. But when a remote PC is added to the loop, the MicroBlaze disadvantages might start to over-take the benefits. This will be discussed in my next blog posts, along with some ideas and solutions.