.

MicroBlaze

Overview

MicroBlazeTM is a 32-bit soft microprocessor IP core from Xilinx Inc. The processor was first introduced in 2001 and has since then evolved from a very basic RISC processor to quite an advanced one. The processor has however maintained binary backward compatibility of the instruction set architecture (ISA). The current (June 2006) version of the processor is v4.00a. This version supports all Virtex-based FPGA architectures (i.e. Spartan2 and Virtex families or later). The MicroBlaze processor has been developed with a strong emphasis on user-controlled configurability. The goal is to deliver a single IP core that permits the user to make detailed trade-offs between cost and performance for their specific target application. This is different from Altera's approach with Nios II, where the user must pick one out of three different versions ( economy, standard or fast) when starting the design, and then do a more limited configuration of this selected version.

Architecture

MicroBlaze is a 32-bit RISC processor with a Harvard memory-architecture. The baseline functionality of the processor is a 3-stage pipeline with an ALU, a 3-level interrupt input, and a bus interface (IBM Coreconnect standard OPB). This baseline version can be configured to add additional functionality like; a barrel-shifter, a multiplier, an integer divider, a single-precision FPU, instruction and data caches, local memory interfaces, hardware acceleration interfaces, exception handling, debug logic etc.

Development Tools and Operating Systems

The MicroBlaze IP core is licensed as part of the Xilinx Embedded Development Kit (EDK). EDK includes embedded design tools and IP cores necessary to build complete embedded systems in an FPGA. The configurability of the MicroBlaze core is automatically handled by the design tools, e.g. the compiler will use floating point instructions only if the MicroBlaze is configured with an FPU, and use floating-point libraries otherwise. The current version of MicroBlaze does not implement any memory management unit (MMU). This limits the selection of real-time operating systems available, however uClinux, Nucleus and a few others do support the processor in their non-MMU implementations.

MicroBlaze Design Tips

The powerful MicroBlaze configurability gives freedom under responsibility. It is important to understand the system effects caused by configuration choices. In the subsequent sections we want to give you some general tips to help you get the most of your MicroBlaze design.

Processor Interfaces

MicroBlaze comes with three bus interfaces: OPB, LMB and XCL. Each interface is subdivided into a data and an instruction side (Harvard architecture). The only requirement for a functional MicroBlaze design is that one instruction memory interface is connected to a memory controller. Everything else is optional. Here is a guideline for which interface to use for your system: The OPB (On-chip Peripheral Bus) is the general I/O interface for MicroBlaze. The data side of the OPB interface should be used to connect peripheral cores like; GPIO, uart, ethernet, external memory controllers etc. The instruction side of the OPB interface should only be used if you need to execute from multiple different memories, or if you execute from an external memory without MicroBlaze caches turned on. The LMB (Local Memory Bus) is used with RAM blocks inside the FPGA (i.e. RAMB). This guarantees low latency access, but limits memory size. This interface is ideal if your SW application is small (fits in the limited on-chip RAM), or for sections of your SW application where low latency is of high importance (e.g. boot code, interrupt and exception handlers). You should avoid placing custom IP cores on this interface since thet will very quickly impact the maximum frequency of the processor. The XCL (Xilinx CacheLink) interface should be used for external memory controller whenever you configure MicroBlaze with caches. There are legacy caches over OPB but these are much lower performance than the XCL caches. If your SW application enables and disables caches dynamically you must remember to connect the OPB interface to the external memory controller as well, since OPB will be used for memory accesses while the caches are disabled.

OPB Master Arbitration

If you connect both data and instruction side of OPB you should make sure that the data side master has higher priority in the bus arbiter than the instruction side master. If you have multiple MicroBlaze processors in a single FPGA it is normally better to let each processor have a private OPB bus and then add bridges to a shared bus, than to hook all processors on the same OPB bus. If you do connect multiple MicroBlaze processors directly to a shared OPB bus, you must make sure that the bus arbiter is configured to use round-robin arbitration, otherwise the highest priority processor will starve the others.

Performance

The following list is a rule-of-thumb for which optional MicroBlaze features will improve your application performance the most:

  • Add XCL instruction cache (if your application execute from external memory)
  • Add XCL data caches (if your application accesses external memory)
  • Add barrel shifter
  • Add multiplier
  • Add integer divider
  • Add pattern compare instructions

Instruction caches are normally more important than data caches even if they are small. Note that small data caches can have worse performance than no data cache at all (due to thrashing and cache-line fetching). If MicroBlaze isn't meeting your frequency target you can try the following:

  • Remove all configured watchpoints
  • Optimize your design with the Xilinx XPLORER implementation script
  • Try to eliminate the OPB instruction side connection
  • Remove the debug logic
  • Remove performance enhancing options from the earlier list starting from the back

Hardware Acceleration

One of the most powerful techniques available with MicroBlaze is the ability to connect powerful custom hardware accelerator functions and call these from the software. MicroBlaze use a very simple FIFO based communication protocol over its accelerator interface, called Fast Simplex Link (FSL). The EDK development tools include a peripheral creation wizard that helps the user to quickly create a stub FSL-accelerator including macros for calling it from the application software.