By Adam Taylor

Within the embedded system space, it is very common to find a FPGA at the heart of the system. This is due to the FPGA’s ability to perform several functions in parallel and its deterministic response. Many embedded systems also contain a processor to handle communication, housekeeping, scheduling, and other tasks traditionally performed in software.

The combination of FPGA and processor can add to what is often called the SWAP-C of the system. SWAP-C relates to Size, Weight, Power and Cost of the solution. Obviously, using both a processor and an FPGA increases not just the BOM cost but the non-recurring engineering costs as well. In addition, design and verification becomes more complicated. The two devices will also require more board space, which increases the solution’s size and weight. The power architecture will also be more complicated than if just one device were used, further impacting the SWAP-C.

While it is difficult to implement functions typically performed by an FPGA with a software-driven processor, a design can often benefit by implementing a processor within the FPGA.

We have several choices when it comes to implementing a processor in a Xilinx FPGA:

PicoBlaze – 8-bit, highly deterministic microcontroller (see Xcell Journal 89, “Getting the most out of your PicoBlaze Microcontroller.”)

MicroBlaze – 32-bit RISC (Reduced Instruction Set Computer) processor, customizable for numerous applications in terms of performance and area.

The Zynq UltraScale MPSoC and Zynq-7000 SoC, which combine hardened, embedded ARM processors with programmable logic on the same silicon. (See the MicroZed Chronicles for information on using the Zynq-7000 SoC.)

In this article, we’ll take a closer look at implementing a Xilinx MicroBlaze processor within our FPGA design to reduce our SWAP-C.

What is MicroBlaze

MicroBlaze is a 32-bit softcore processor. That means it is soft IP that you can customize and then synthesize, followed by place and route into the logic resources of the target FPGA. Each MicroBlaze processor instantiation is customized and can include advanced features such as FPUs (floating-point units), MMUs (memory-management units), and instruction and data caches.

You can run a number of operating systems on the MicroBlaze processor including FreeRTOS, Micrium uc/OSiii and Linux. You can also run bare-metal code. The soft nature of the instantiation ensures that we do not run into obsolescence problems. In short, the MicroBlaze processor is a very powerful tool to have in our embedded system development tool box.

Creating a MicroBlaze System

The ability to implement MicroBlaze processors within our design is a standard feature of the Xilinx Vivado HL WebPACK edition.

The first thing to do is to create a new project in Vivado and add a new block diagram. We can then add in the MicroBlaze processor core from the IP Catalog. Once we have placed the MicroBlaze processor in the block diagram, we need to customize it for the performance we require. Opening the MicroBlaze processor for customization will present the first of five processor customization pages. On the first page, we can select the desired performance for from the core as shown in Figure 1. For this example, we will develop a high-performance MicroBlaze processor.

Figure 1: Selecting the configuration of the MicroBlaze

To create the basics of our system we are going to need the following IP cores:

MIG (Memory Interface Generator) – Provides interface to DDR memory

AXI UART lite – double-click on it to set your RS232 options. The default is 9600bps, no parity, one stop bit.

AXI Timer

AXI Interrupt Controller – Requires a concatenate block to drive the interrupt from the Timer and the AXI UART lite.

AXI BRAM Controller and BRAM for the AXI Data and Instruction Cache

Clocking wizard to output a 166.667MHz clock and a 333MHz clock

MicroBlaze Debug Module

AXI Peripheral Interconnect to connect to the timer and UART

AXI Memory Interconnect to connect to the MIG (DDR) and the AXI BRAM controller

Processor Reset System for the MicroBlaze clock domain

Processor Reset System for the Memory Interface Generator Clock Domain

Our connection architecture for these blocks is shown in Figure 2 below:

Figure 2: High Level Block Diagram

We are going to use a 100MHz clock that will be the input to a Clocking Wizard, which will use an MMCM (mixed-mode clock manager) to generate clocks at 100, 166.667, and 200MHz. The MicroBlaze processor will run from the MMCM’s 100MHz output while the other clocks will be used for the Memory Interface Generator. Tables 1 and 2 below show the configuration of the AXI Interconnects:

Table 1: Peripheral AXI Interconnect, Clock and Reset Configuration

Table 2: Memory AXI Interconnect, Clock and Reset Configuration

Configuring the DDR Memory

We are developing a high-performance MicroBlaze system so we want to be able to execute our program from DDR SDRAM and also use more exotic capabilities including DMA so that the MicroBlaze processor can process captured data. DDR memory interfaces can be difficult to implement due to the complex driving requirements but the Xilinx MIG can automatically generate the DDR interface between the AXI bus and the DDR SDRAM.

The MIG is available from the IP Catalog and customizing it allows us to select the desired clock frequency, target memory device, memory options, termination schemes, and pin allocation. Figure 3 below shows the selection of the target DDR device. While it may initially look complicated, it is very easy to work with and to get up and running quickly.

Figure 3: MIG selecting target device

Once we have customized the interface as required for our application, we need to provide two clocks: a 200MHz reference clock and a 166.667MHz system clock in this example.

With all of the modules within the design customized to our needs, we can create an RTL wrapper and re-generate the outputs, allowing us to build the system and develop our first application.

Developing the Software

Once the project implementation completes and we have a bit file, we can open the implemented design and export the HDF and the bit file to SDK. Now we’re ready to create our software application.

If this is the first time you have opened SDK, you will be asked for the workspace you wish to use. The workspace is the area where your projects and associated software project files such as BSPs (Board Support Packages) and the hardware definition will be stored.

To get this up and running within SDK, we need to do the following:

Create a hardware definition project

Create a BSP for the hardware definition

Create our application

Build the application

Define the debug environment so that we can run the application on the board over the JTAG link

The first step is to import the hardware definition. To do this in Vivado, select file -> new -> other from the SDK menu. This will open a dialog box as shown in Figure 4. Select “Hardware Platform Specification” beneath the Xilinx folder.

Figure 4: Selecting the Hardware Platform Specification

Enter your project name in the next dialog box. One good practice to get into is always to call it project_HW, to label it clearly. Browse to the directory within your Vivado project that contains the HDF file. Note this is within the .sdk folder under your Vivado project.

This will create the hardware specification that will appear in the project explorer on the left side of SDK. Within this project, you should be able to open the HDF file and see the addresses of all memory-mapped peripherals.

With the hardware platform created, we are now ready to create a BSP. This will contain the drivers and API that allows us to drive and control the hardware. We can create the BSP by selecting file -> new -> board support package. This will open a dialog box and we can step through the pages.

Enter a project name. Notice how it has picked up the hardware platform we just created. For this example, we will use the standalone operating system. This will open a settings pop-up for the BSP. There are no changes we need to make here, but this is where we can add options if needed—e.g. light-weight IP stack, etc.

On the standalone page, we can also select the stdin and stdout for the compiler. Make sure this is set to AXI UART.

At this point, we can then create our application. For this example, I am going to use the simple “hello world” template. We can create the application project by selecting file -> new -> application project within SDK. This will open a dialog box where we can select the BSP we previously created as well as the hardware definition and the processor we are targeting. (In this case there is only one.)

These steps will create a simple application that outputs the character string “hello world” over the UART. Selecting “build all” will then build the BSP and the application project, producing an ELF file, which you can download and run on the hardware.

Running on the Hardware

We need to create a debug environment that will download the ELF when we click on it. To do this, right-click on your application project and select Debug As -> Debug Configurations. This will open a dialog box, as shown in Figure 5, where you can create a new debug environment. We wish to create a new GBD debug application.

Figure 5: Creating the debug configuration

Provide a name and, if not selected, select “Reset Processor” from the drop-down menu close to the bottom. We also need to click on the Debugger applications tab and uncheck the option “stop at main() when debugging.” to ensure that the application will run automatically on download. Finally then click on apply, not debug, and then close.

The first thing to do is program the FPGA. We do this under the Xilinx Tools -> Program FPGA. Once you see that the FPGA is programmed, you are now ready to download your ELF file. Click on the bug icon on the top menu and this will use the debug configuration we just created.

Once downloaded you should see the software run and the message “hello world” appear in your chosen terminal program.

Conclusion

Building your own MicroBlaze system is very simple and straightforward to implement, as is developing the software to run on it. If you are looking to reduce your system’s SWAP-C, a MicroBlaze processor can help.