Microblaze Blueshell Tile

Owned by Ian Gray
Last updated: 23 Jan, 2017

This page describes the Blueshell version of Microblaze, which has connections for both Bluetree (memory) and Bluetiles (I/O and CPU-CPU communications).

The tile contains:

  • Xilinx Microblaze CPU, version 8.40.d, with divider, barrel shift and multiplier. (ML605/VC707 version includes FPU and BTC.)
  • Direct mapped L1 instruction/data caches of configurable size (default 8k each with 16 byte cache lines)
    • Bluetree interface from cache to memory
    • Write through, no write allocate
  • Scratchpad memory of configurable size (default 8k) shared between instruction and data
  • Two FSL connections:
    • FSL0: direct access to Bluetiles
    • FSL1: debugging and cache control

The initial program executed by Microblaze is usually the boot ROM.

Diagram

Here is the diagram that Jack drew on Gary's whiteboard:
24012013435.jpg

The top level is found in Microblaze.bsv. You can use the mkMicroblaze module (default configuration) or mkConfigurableMicroblaze for your own configuration.

The top level has three important interfaces:

  • client: This is the connection for memory accesses via Bluetree.
  • bluetile: This is connected directly to FSL0.
  • start(): This method must be called to start the Microblaze CPU's operation.
  • bluetile_debug: This is connected to FSL1 as explained below. This port can be left unconnected.


There are a number of other ports for tracing. These may be left unconnected.

On Atlys boards the Microblaze CPU may run at 100MHz but timing is tight, and this seems to require a sparse design. 75MHz is much more likely to place and route. On ML605 boards, 100MHz is fine. On VC707 we are not yet sure of the best frequency. The critical path runs through the cache. It is possible that cache improvements will increase the maximum frequency.

Start Method


The Microblaze CPU tile interface includes a method named start(). This method must be called to start the Microblaze CPU, as it is held in the reset state until start() is called. start() is normally called once the boot ROM component has completed its task, i.e.:

rule boot if (booter0.is_ready());
cpu1.start();
endrule

Note that this feature was introduced by SVN revision 915. Earlier versions of the Microblaze tile started immediately. The change was introduced to allow more flexibility for Bluetree.

Sending/receiving data via the Bluetiles interface (FSL0)


Data written to this FSL interface is sent to the Bluetiles network interface verbatim.

There is C source code which implements communication via Bluetiles. You should use this if possible. You can find it in https://svn.cs.york.ac.uk/svn/rtslab/blueshell/bt/ as bt_interface.c and bt_interface.h. Bluetiles headers are described using C structures; there are functions to send and receive headers, and send and receive payload words. There are various "print" functions (for debugging). Examples of the use of bt_interface.c can be found in many of the test programs including testprog and memtest. Note that it is important to call "bt_init()" before using the other functions.

bt_interface.c was written when the header fields were rearranged to accommodate priorities. It's a good idea to keep the header definition in one place so that all programs can be updated easily.

There is also a higher-level Bluetiles "operating system" called Bluetiles Reactor which is an event-driven communications stack. It's used by the boot ROM. It includes an Ethernet MAC driver for axi_ethernetlite which could be replaced by drivers for other MACs if required. Bluetiles Reactor allows you to write functions to implement Bluetiles services that listen on specific ports and serve incoming messages appropriately.

The FSL1 interface


FSL1 is used for debugging and cache control. It is connected to the mkCacheControl module. The protocol used via FSL1 is extensible, but the basic configuration is as follows:

For every word sent, the three least significant bits have a special meaning and the four most significant bits also have a special meaning. Call the low bits cmd[2:0] and the high bits cmd[31:28]. When you put a word to FSL1, you cause a state change, which depends on cmd[2:0] and may be one of the following:

  • cmd[2:0] == 0. Reads from FSL1 will access registers that are part of the data cache controller. The register number will be cmd[31:28].
  • cmd[2:0] == 1. Reads from FSL1 will access registers that are part of the instruction cache controller. The register number will be cmd[31:28].
  • cmd[2:0] == 2. Reads from FSL1 will access the following registers that are part of mkCacheControl
    • cmd[31:28] == 0. A 32-bit clock cycle up counter.
    • cmd[31:28] == 1. A version register reporting the VERSION value defined in Microblaze.bsv.
    • cmd[31:28] == 2. Read the interrupt enable register. Bit 8 is output_ready, bit 9 is input_waiting (see below).
  • cmd[2:0] == 3. Update the interrupt enable register. Bit 8 sets output_ready, bit 9 is input_waiting. If output_ready is set, then interrupts are triggered whenever the FSL0 output FIFO is empty and ready for put. If input_waiting is set, then interrupts are triggered whenever the FSL0 input FIFO contains data and is ready for get. Interrupts also have to be enabled in the CPU's MSR.
  • cmd[2:0] == 4. The word written to FSL1 is forwarded to the data cache controller. The effect depends on the setting of cmd[31:28]:
    • cmd[31:28] == 0. cmd is interpreted as an address and the cache line for that address is invalidated.
  • cmd[2:0] == 5.The word written to FSL1 is forwarded to the instruction cache controller. The effect is as for the data cache controller.
  • cmd[2:0] == 6. A register named poke_high is loaded with the value of cmd[23:8].
  • cmd[2:0] == 7. A word composed of poke_high and cmd[23:8] is sent to the bluetiles_debug interface. This feature gives a second way to send packets over Bluetiles and can be used for debugging network interface code, e.g. printing debugging information.


Accesses to FSL1 never block. The value read from FSL1 depends on the last command as described above, so the usual paradigm for reading FSL1 is to send a command and then read back the result within the next instruction. This put/get pair is a critical section.