We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 

MicroZed Chronicles: Inter Processor Communication (Part 1)

Xilinx Employee
Xilinx Employee
0 0 871

This content is republished from the MicroZed Chronicles, with permission from the author and Hackster.io.

Many of our solutions contain multiple processors, either hardcore processors like the Arm A9, A53 or R5, Softcores e.g. MicroBlaze, Arm Cortex M1/Cortex M3 or a combination of the two. 298_Fig1.pngWhen we implement a multiprocessor solution, typically we split the tasking between the available cores. Exploiting each core to maximise its performance attributes. For example using MicroBlaze or Cortex cores in the PL for dedicated real-time offloaded tasks while using hardcore application processors for higher level functions.

Of course, to correctly implement a multi-processor solution application, all the processors in the solution need to be able to communicate and share the available system resources safely and reliably. 

This is where inter processor communication (IPC) comes in, correctly implemented it enables safe and reliable communication between processors, while also allowing multiple processors to share common resources e.g. UARTs without conflict causing corruption.

In previous chronicles we have explored both the OpenAMP framework and Zynq MPSoC Inter Processor Interrupts. However, we have never examined IPC solutions implemented using Mailboxes and MUTEXs. 

Both Mailboxes and MUTEX play differing roles in our IPC solution

  • Mailbox — Allows bi-directional communication between multiple processors using a FIFO based approach to messaging.  
  • MUTEX — Implement mutual exclusion locks, this allows processors to lock shared resources preventing multiple accesses at the same time.

Regardless of if we use a heterogeneous SoC or FPGA both Mailboxes and MUTEX’s are implemented within the programmable logic (PL). 

We can implement both Mailboxes and MUTEXs in our design directly from the Xilinx IP library. As both MUTEX and Mailbox are intended for communication between two processors, both have two slave AXI inputs.

One slave AXI interface for each processor, using the mailbox or MUTEX. 

In this example we going to use a Zynq communicating and sharing resources with a MicroBlaze in the PL. 

The MicroBlaze will be connected to the GPIO which drives LEDs. My plan for the software application in the next blog is to show how we can send messages from the A9 to the MicroBlaze to turn on and off LEDs. A simple but effective demonstration, however first we need to complete the hardware design. 

To create the block diagram, we first need to add in a Zynq processing system IP and run the block automation to configure the Zynq for the selected board. 


That is one processing system added, to add in the second add a MicroBlaze, using the IP catalog. Once the MicroBlaze IP is in the block diagram, double click to re-customize the IP, select the micro-controller preset, leaving all other options unchanged. 


Once the MicroBlaze IP is configured the next step is to run its block automation to create the MicroBlaze solution. This will add in the block RAM from which the MicroBlaze will run and debug facilities. 


Now we have our two processing system solution we are ready to add in the Mailbox and MUTEX, both can be added from Xilinx IP Catalog.

Once these are added we can use the connection automation wizard to connect them into the two processor systems AXI connections. 

298_Fig5.pngConnection automation settings for the Zynq PS connection 

298_Fig6.pngConnection automation settings for the MicroBlaze

The Mailbox transfers messages uses a FIFO, the depth of this can be configured by re using the Mailbox IP. To ensure efficient processing of messages at the receiving processor, the mailbox is capable of generating interrupts to the relevant processor when messages are queued. 

Like the Mailbox, the MUTEX is very similar, except it does not use a FIFO instead registers are used for each MUTEX to indicate the locked status or not. We can have up to 32 MUTEX shared between up to eight processors. 

We will examine it more in the SW implementation blog next week but to prevent processors unlocking MUTEXs inadvertantly or maliciously, CPU IDs are used. 


The completed block diagram should look similar to the one below. 


We can now build the hardware and export the design to SDK, ready to write the SW application next week. 

Until then! 


See My FPGA / SoC Projects: Adam Taylor on Hackster.io

Get the Code: ATaylorCEngFIET (Adam Taylor)

Access the MicroZed Chronicles Archives with over 280 articles on the Zynq / Zynq MpSoC updated weekly at MicroZed Chronicles.