XPERTS CORNER
UART Interrupt
TTC Interrupt
PS - Cortex-A9
PL - MicroBlaze Wait for char
Wait for tic
Increment the tic counter Set the BRAM offset and address
Increment the occurrence counter
BRAM
Get the occurence counter from BRAM
UART Interrupt
LEDs
Set the LEDs
Decrement the LED
Convert to hex ACSII
Occurrence = limit? DDR Memory (data space) Send msg via serial port
Validate DDR memory
Send char pair via UART
Build a buffer with checksum and write to DDR
Figure 6 – Flow diagram for both the Cortex-A9 application and the MicroBlaze application
these signals, but it can’t influence or alter them. Both the PS and the PL share the PS’ IOP block, the DDR memory and controller, and the common dual-port BRAM. From an address map standpoint, the IOP addresses are fixed in hardware and cannot be modified. Both the MicroBlaze and the Cortex-A9 must use the same addresses for any of these peripherals. The Technical Reference Manual is especially helpful in this regard. There are two portions of the TRM that are useful for dealing with peripherals in this design: the sections on the specific peripheral (such as Section 8 – Timers and Section 19 – UART Controller), and Appendix “B,” which lists all of the registers for each of the peripherals. Each register in this section is listed by its address along with a brief description. It is left as an exercise to the user to manage the resources between the two processors to avoid data collisions, starvation and so on. Use of the DDR memory and its controller is a bit easier, since the DDR memory controller is capable of managing collisions and has appropriate heuristics to avoid data starvation for any of the requestors. Since this is First Quarter 2013
not under user control, the latency may become a bit unpredictable. The common BRAM will have identical lower address bits; however, the location in each processor’s memory space for this block is selectable using the address tab in Xilinx Platform Studio. As before, data collisions, synchronization and memory allocation are left as an exercise to the reader. Our example software design is more about demonstrating the process of connecting a Cortex-A9 with a MicroBlaze than doing anything practical. A couple of techniques will illustrate some of the possibilities in this regard. The Zynq-7000 application shown in the left side of Figure 6 is a simple design that uses the Xilinx Standalone board support package. It runs a program that, for the most part, keeps the processor idling and periodically issues a “T” character (for “tic”) via the serial port to indicate that it is still alive. Additionally, it counts the number of elapsed tics and places this count in the Block RAM that is shared with the MicroBlaze. The MicroBlaze application also runs a Standalone board support package. This approach supports interrupts,
and each time a character appears on the serial port the MicroBlaze buffers that character and echoes its Hex-ASCII equivalent back to the serial port in the PS’ IOP block. Additionally, it builds a string of received characters and places it in the DDR memory for each character received. When a carriage return is received, a checksum is computed and added to the DDR memory immediately following the string. A flag is set in a predetermined location in BRAM and when the Cortex code “sees” this flag, it reads the string from the DDR memory and verifies the checksum. If the checksum is correct, the MicroBlaze emits a “+.” Otherwise, it transmits an “X.” In short, our example design proves that the MicroBlaze and Zynq7000 PS can coexist peacefully. The copious number of AXI connection points provide the MicroBlaze (or anything in the PL) easy access to the peripherals in the IOP block, the OCM and the DDR. The programmable logic can easily access interrupts from the IOP block, just as a number of interrupts can be generated in the PL and supplied to the PS. Software coordination and well-defined behavior are key to avoiding race conditions and addressing conflicts. Xcell Journal
35