現在業界的許多解決方案都包含多個處理器，或者是硬核處理器，如Arm A9、A53或R5，軟核如MicroBlaze、Arm Cortex-M1/M3，或者是兩者的組合。

Arm Cortex-M1被稱為軟核處理器，這主要是因為它在設計和應用上具有更大的靈活性。首先，軟核處理器是可以根據需要進行定制的。在設計上，Arm Cortex-M1可以根據特定應用的需求進行定制。例如，在硬件資源有限的情況下，如FPGA設備，Cortex-M1能通過優化設計來滿足面積預算要求。它采用了三階段32位RISC處理器架構，并且使用了高效的指令集，例如Thumb-2指令集，這樣就可以在有限的硬件資源下實現更高的性能。其次，軟核處理器在應用上也更加靈活。它們可以集成到各種不同的硬件平臺中，比如FPGA、ASIC等。同時，軟核處理器可以使用不同的編程語言進行編程和控制，這樣就可以適應更多的應用場景和需求。由于其靈活性和適應性，軟核處理器在各種應用領域中更加受歡迎。

當我們實施多處理器解決方案時，通常我們會在可用的內核之間劃分任務，利用每個內核來最大限度地提高其性能屬性。例如，在PL中使用MicroBlaze或Cortex內核來執行專用的實時卸載任務，同時使用硬核應用程序處理器來執行更高級別的功能。

如果你做過復雜Soc相關的項目，應該對于這個肯定有所了解，用一個客制化的小核去協助主處理器做很多的事情，或者是多核SMP架構中，都會常看到這種核間通信的機制。

當然，要正確實施多處理器解決方案應用程序，解決方案中的所有處理器都需要能夠安全可靠地通信和共享可用的系統資源。

這就是處理器間通信（IPC）的作用所在；如果正確實施，它可以實現處理器之間的安全可靠通信，同時也允許多個處理器共享公共資源，例如UART，而不會導致損壞的沖突。

mailbox和MUTEX在我們的IPC解決方案中扮演不同的角色：

這個字母一大寫一小寫突然看的我好難受但是又不想改哈哈哈

mailbox-允許使用基于FIFO的消息傳遞方法在多個處理器之間進行雙向通信。

MUTEX-實現互斥鎖，這允許處理器鎖定共享資源，防止同時進行多次訪問。

無論我們使用異構SoC還是FPGA，mailbox和MUTEX都在可編程邏輯（PL）中實現。

異構SoC（System on Chip）處理器是一種集成多個不同架構處理單元核心的SoC處理器。例如，TI的OMAP-L138（DSP C674x + ARM9）和AM5708（DSP C66x + ARM Cortex-A15）SoC處理器，以及Xilinx的ZYNQ（ARM Cortex-A9 + Artix-7/Kintex-7可編程邏輯架構）SoC處理器等。異構多核SoC處理器結合了不同類型處理器的優點。例如，ARM處理器廉價且耗能低，擅長進行控制操作和多媒體顯示；DSP天生為數字信號處理而生，擅長進行專用算法運算；FPGA則擅長高速、多通道數據采集和信號傳輸。同時，核間通過各種通信方式，快速進行數據的傳輸和共享，使得異構多核SoC處理器能實現1+1>2的效果。

我們可以直接從Xilinx IP庫在設計中實現mailbox和MUTEX。由于兩者都用于兩個處理器之間的通信，因此它們有兩個從AXI輸入。

使用mailbox或MUTEX，為每個處理器提供一個從AXI接口。

在本示例中，我們將使用Zynq與PL中的MicroBlaze通信和共享資源。

MicroBlaze將連接到驅動LED的GPIO。

要創建框圖，我們首先需要添加Zynq處理系統IP，并運行塊自動化以配置選定主板的Zynq。

這是添加的一個處理系統。對于第二個，使用IP目錄添加MicroBlaze。一旦MicroBlaze IP出現在框圖中，雙擊重新自定義IP，選擇微控制器預設，保持所有其他選項不變。

配置MicroBlaze IP后，下一步是運行其塊自動化以創建MicroBlaze解決方案。這將添加到塊RAM中，MicroBlaze將從中運行和調試設施。

現在有了我們的兩個處理系統解決方案，我們已經準備好添加到mailbox和MUTEX中-這兩個解決方案都可以從Xilinx IP目錄中添加。

完成后，我們可以使用連接自動化向導將它們連接到兩個處理器系統AXI連接。

mailbox使用FIFO傳輸消息，其深度可以通過重復使用mailbox IP來配置。為確保在接收處理器上有效處理消息，mailbox能夠在消息排隊時向相關處理器生成中斷。

與mailbox一樣，MUTEX非常相似，只是它不使用FIFO，而是為每個MUTEX使用寄存器來指示鎖定狀態。我們可以在多達8個處理器之間共享多達32個MUTEX。

為了防止處理器無意中或惡意地解鎖互斥體，使用CPU ID。

完成的框圖應與下面的框圖相似。

我們現在可以構建硬件并將設計導出到SDK，準備編寫軟件應用程序。

MailBox

我們檢查了Vivado中實現處理器間通信（IPC）郵箱和互斥體所需的硬件構建。

現在，我們將研究如何使用mailbox將數據從一個處理器傳輸到另一個處理器。

請記住，在這個系統中，我們使用的是Zynq處理系統(PS) A9內核之一和可編程邏輯（PL）中的MicroBlaze。

兩個處理器都使用AXI連接到mailbox，因此我們可以使用主板支持包（BSP）中提供的API很容易就實現了發送和接收消息。

將設計從Vivado導出到Xilinx SDK將將中的硬件規范導入到SDK。在硬件項目中檢查HDF文件將顯示MicroBlaze和Cortex-A9內存映射。

導入硬件定義后，下一步是創建兩個應用程序-一個用于Arm Cortex-A9，另一個用于MicroBlaze。當我們創建這些應用程序時，請確保選擇適當的處理器，并啟用應用程序也創建BSP。

完成此操作后，我們應在SDK項目資源管理器中包含以下內容：

描述Vivado設計的硬件平臺-這應用作所有應用程序和BSP的參考硬件平臺。

兩個主板支持包-PS Arm A9和MicroBlaze應用程序各一個。

兩個應用程序-PS Arm A9和MicroBlaze各一個。

在此應用程序中，MicroBlaze將報告何時啟動并運行，以及LED的打開或關閉狀態。

為此，我們將使用BSP提供的mailbox API，兩者都提供相同的API供使用。

這些文件包含在xmbox.h文件中，使我們能夠初始化和配置mailbox 以使用。

要從mailbox 讀取和寫入，有幾個功能：

XMbox_Read ( XMbox * InstancePtr, u32 * BufferPtr, u32 RequestedBytes, u32 * BytesRecvdPtr)
XMbox_ReadBlocking ( XMbox * InstancePtr, u32 * BufferPtr, u32 RequestedBytes )
XMbox_Write(XMbox* InstancePtr,u32 * BufferPtr,u32 RequestedBytes, u32 * BytesSentPtr )
XMbox_WriteBlocking ( XMbox * InstancePtr, u32 * BufferPtr, u32 RequestedBytes )

在上述函數中，實例指針引用mailbox 聲明，緩沖區指針指向我們存儲TX或RX數據的位置。雖然請求的字節是傳輸的大小，但讀和寫函數也報告實際發送或接收的字節數，因為這可能與請求的字節數不同。

這里特別指出，對于所有函數，發送或接收的字節數應該是4的倍數；如果不是，則需要一些填充。如果沒有請求4字節的倍數，將生成斷言。

當然，阻塞讀寫不會報告實際發送或接收的字節數，因為函數實際上會阻塞，直到發送或接收請求的字節數。

除了發送和接收功能，還有許多內部管理功能：

中斷使能、狀態和禁用

發送和接收中斷FIFO閾值定義

FFIO管理和控制，包括檢查空和滿、刷新和復位 通過使用這些功能，我們能夠為Arm A9內核和MicroBlaze創建簡單的應用程序。

A9程序很簡單。一旦mailbox 初始化，它就會永遠循環等待來自MicroBlaze的消息，然后再通過終端打印出來。

MicroBlaze應用程序要復雜一些。它在啟動時向A9內核發送消息，然后每次切換LED時，它還發送有關LED狀態的消息。

要在Zynq上運行此操作，我們需要創建一個新的調試配置，該配置下載兩個處理器。為了確保在多處理器環境中取得成功，我們需要考慮兩個處理器的啟動。在此調試配置中，選擇：

調試配置運行時，將配置設備，并下載兩個處理器的應用程序。然后，兩個處理器將在main()的入口點暫停。

對于此示例應用程序，請首先啟動A9處理器，然后啟動MicroBlaze處理器。

當使用上面的示例代碼執行此操作時，就可以在終端窗口中看到了以下內容：

兩個處理器都在通信!

接下來，我們關注點放到互斥體。

MUTEX

當我們的設備中有多個處理器時，多個處理器可能希望同時共享公共資源（例如內存或UART）。如果對這些資源的訪問不受控制，它可能會迅速而容易地導致腐敗。比如說串口打印，混淆在一起。

互斥似乎是最簡單的問題之一，當然可以使用一個標志，雙方都可以測試，如果是自由設置，則聲稱對資源的訪問。

然而，出現了一個問題，即在一個處理器測試和設置標志之間的時間內，對方處理器也可以將標志視為空閑，并開始其鎖定過程。

這通常被稱為競爭條件，圍繞相互排斥的其他潛在陷阱包括僵局和饑餓。處理器無法訪問資源（饑餓）或系統鎖定，因為每個處理器都在等待不同的鎖定進程進行（死鎖）。

一般提到互斥，就會涉及到死鎖問題。

有許多解決方案可以解決這些問題，包括使用多個標志。雖然，當考慮到除了最簡單的情況之外的任何事情時，它們開始變得非常復雜，簡言之，它們并不容易擴展。

解決競爭條件的方法是確保測試和設置操作合并到一個操作中，也就是說，如果我們測試互斥標記，并且它是自由的，那么它就會被設置。

這正是Xilinx互斥體的工作方式，當我們寫入互斥體時，如果它是空閑的，處理器將被分配資源。

在我們的硬件設計中設計互斥體非常簡單，每個處理器都有自己的AXI接口。由于互斥體能夠支持1到8個處理器，因此在使用操作系統和在同一處理器上運行的任務之間共享資源時，我們可以只使用一個接口。

在一個互斥體實例化中，我們最多能夠實現32個互斥體。不過，對于這個例子，我們只有一個。當我們實施互斥體時，如果我們愿意，我們還可以在AXI級別啟用硬件保護。

如果我們選擇啟用此功能，則可選AXI HWID字段用于鎖定和解鎖互斥體，防止CPU偽造CPU ID并錯誤地解鎖。

每個互斥體還有一個可選的32位寄存器，如有必要，可用于在處理器之間共享配置數據。

當談到在我們的軟件中使用互斥體時，我們可以使用主板支持包（BSP）為兩個處理器提供的Xmutex API (xmutex.h)。在此API中，我們將找到函數類：

生命周期管理-初始化和狀態報告

用戶寄存器-設置和取消設置用戶寄存器

互斥鎖操作-鎖定和解鎖互斥鎖的功能

與我們上面看到的mailbox示例類似，互斥操作提供阻止和非阻止調用。阻塞調用由函數XMutex_Lock()提供，而無阻塞函數調用是XMutex_Trylock()。

為了演示互斥體的應用，我們將更新我們的SW應用程序，以便MircoBlaze應用程序在設置LED時鎖定互斥體，并在清除LED時解鎖互斥體。

然后，Zynq應用程序將測試互斥體，并報告它是否與LED狀態一起設置。一個簡單但有效的示例，說明互斥函數是如何工作的。

兩個處理器的代碼如下。

當使用上面的代碼運行應用程序時，在終端窗口中觀察到以下情況。這表示在訪問LED資源時，MicroBlaze正在按預期鎖定和解鎖互斥體。