In this series:
- The soft processor in the Perseus reference designs – Part 1: Benefits
- 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
In my previous blog posts, I highlighted the advantages of using a soft core processor in an FPGA reference design for performing core and device initializations as well as control and monitoring tasks. But what if the extra resource usage is not worth all the benefits? What if freeing up the required FPGA logic allocated to the soft-core subsystem would allow you to reduce the overall design logic to a point where you can downgrade the FPGA selection for your next product?
In this blog post, I present different possible solutions and observations that need to be taken into account when thinking about completely removing the soft processor from the Perseus reference design.
Tasks handled by the MicroBlaze soft processor
First, let’s summarize what the MicroBlaze does. The MicroBlaze can run a custom client application built using Nutaq’s libraries or run the Nutaq application provided with the Board Support Development Kit (BSDK), namely the Central Command Engine (CCE). The CCE runs on embedded Linux and provides remote access through Ethernet or PCIe to initialize, monitor, and control the FPGA logic and surrounding devices. But, regardless of the origin of the initialization procedures, the MicroBlaze performs the actual initialization of the external devices and the FPGA logic cores:
- Initialization of external devices – Requires a sequence of SPI and I2C commands. Some external signals are usually also necessary and connected to some FPGA GPIO pins mapped to specific addresses. External device resets, for example, are often controlled this way.
- Initialization of FPGA logic cores – Involves a sequence of read and write accesses at specific addresses.
The control and monitoring functions are at a low level, similar to the initialization functions, and can be reduced to Serial Peripheral Interface (SPI), I2C, and read/write accesses. In fact, SPI and I2C commands are themselves reduced to read/write accesses by the MicroBlaze. We can state then that all the MicroBlaze functions are eventually reduced to a sequence of read and write accesses at specific addresses, in a specific order, and sometimes with a specific timing.
Initialization and control performed by dedicated logic
A designer may want to replace all the initialization, control, and monitoring tasks performed by the soft core processor using light-weight dedicated logic. Depending on the complexity of these tasks, various solutions are achievable:
- For a simple initialization process, a Finite State Machine (FSM) is a good candidate. The required logic can be kept quite low. Unfortunately, it can quickly become arduous with an FSM to code an initialization process with many nested switch cases.
- For an initialization of low to medium complexity, a soft processor smaller than the MicroBlaze can be a good idea. Xilinx offers an 8-bit controller, the PicoBlaze, for example.
- For designs with relatively complex initialization and control, or to keep the flexibility of a PC-like environment, remote control can be used. In this case, the FPGA logic has to provide a way to perform the read and write accesses remotely.
Remote initialization and control
This section presents three possible solutions for remote initialization and control: Ethernet, serial port, and PCIe. Figure 1 shows the Perseus BSDK MicroBlaze sub-system presented in the second blog post. The main idea behind the remote control is to replace the MicroBlaze (and all unnecessary peripherals) with dedicated logic that converts read/write commands received from a remote PC to local AXI read/write accesses.
In all cases, C functions that were originally developed for the MicroBlaze need to be modified to execute on a remote PC. Moreover, all read/write accesses to specific MicroBlaze memory map addresses now need to be redirected through the desired link (Ethernet, serial port, or PCIe).
Figure 1: MicroBlaze system for the Perseus BSDK reference design
- Initialization and control through Ethernet – As illustrated in Figure 2, the main FPGA development would be to build a core interfacing a MAC core, decode the received Ethernet packets, and perform AXI read/write accesses as required. The grey boxes are peripherals that can probably be removed in addition to the MicroBlaze and the Ethernet DMA. Control-through-Ethernet has not been explicitly done for the Perseus board but Nutaq has already validated the idea by performing it on another board using raw Ethernet packets.
Figure 2: Initialization and control through Ethernet
- Initialization and control through serial port – This solution is quite similar to the Ethernet one, except that instead of interfacing and decoding Ethernet packets, the commands originate from a serial port. Figure 3 illustrates the solution. The Ethernet MAC can be removed if no RTDEx-over-Ethernet is used.
Figure 3: Initialization and control through serial port
- Initialization and control through PCIe – Unlike the other two solutions, only slight FPGA modifications would be necessary to support remote initialization and control over PCIe. This is because the Xilinx PCIe bridge interface already has an AXI interface. The design modifications would basically consist of disconnecting and removing the MicroBlaze and its unused peripherals and then linking the MicroBlaze AXI bus to the PCIe bridge. Memory map adjustments may be required to extend the addresses of the MicroBlaze peripherals through PCIe.
While soft processors bring a lot of flexibility and can save you considerable development time and pain, their required logic might not be desirable. For those cases, many different solutions exist, from embedded lightweight logic to performing the sequential tasks remotely.