目前，多媒體芯片的開發面臨著集成度高、產品上市時間緊迫、市場變化迅速等諸多挑戰。不同于傳統的ASIC，多媒體芯片通常是復雜的SoC，在芯片中除了核心的音視頻處理電路以外，一般都有MCU、DSP或CPU來協助音視頻處理電路完成系統級的控制功能，或者由DSP、CPU完成某些音視頻算法。有的多媒體芯片內部甚至集成了多個MCU、DSP或CPU內核。另外，大部分多媒體芯片都需要與外部CPU協同工作，如PC攝像頭多媒體芯片需要和PC一起工作，移動終端多媒體芯片需要和基帶處理器一起工作。

中星微電子公司致力于多媒體芯片的開發，并可提供完整的軟件和系統解決方案。根據功能的不同，軟件可分為驅動程序、固件和應用程序。對多媒體芯片進行系統級驗證要同時驗證驅動程序、固件等軟件部分。基于NC-SystemC，中星微開發出系統級的驗證平臺，該平臺用SystemC集成芯片的驅動程序和應用程序，用Perl來解析測試命令，用NC仿真器進行SystemC和Verilog的聯合仿真，較好地解決了軟硬件聯合仿真的問題，大大提高了驗證效率。但由于多媒體芯片規模比較大，依據一個系統級的仿真向量對芯片進行仿真時往往需要幾個小時，比如仿真一秒鐘的聲音需要7～10個小時，仿真一幅1.3M或3M的圖像需要1～2個小時。在驗證初期，系統的硬件和軟件都不穩定，往往需要花費大量時間來驗證一個很小的問題，這嚴重影響了芯片的開發進度。在驗證后期，迫于流片時間的壓力，又沒有時間對芯片進行充分驗證。因此，工程師迫切需要一種新的驗證方法來加快仿真速度，這就是硬件加速器。

目前，EDA市場上有許多硬件加速器的解決方案，Cadence的Palladium是基于定制CPU的解決方案，其它都是基于FPGA的。本文采用Palladium作為硬件加速解決方案。

基于ARM的STB

STB的硬件結構

基于ARM的STB（可綜合測試平臺）的硬件結構如圖1所示。

傳統的硬件加速器大多工作在ICE（電路內仿真）模式下，這種模式的測試激勵由外部硬件設備提供。但是，由于硬件加速器的工作速度有限，無法實現與外部高速設備的直接連接，因此，需要采用Cadence的速率適配器（Speedbridge）來進行速率轉換，這樣又會增加整個驗證系統的復雜程度。STB的基本思想是用可綜合的RTL來實現SoC驗證中用到的所有仿真模型。由于不同的SoC芯片對各個仿真模型的要求不完全相同，所以，仿真模型必須是可配置的。STB中利用ARM來配置各個仿真模型，并控制各個仿真模型對芯片進行操作，比如讀／寫芯片的寄存器、為芯片提供音視頻輸入數據等。同時，ARM也可以運行芯片的驅動程序和應用程序（實際上許多手機基帶處理器都是ARM內核）。STB可以對中星微的所有多媒體芯片進行系統級的軟硬件聯合驗證，能夠降低驗證環境的復雜度，實現更靈活的配置，同時不會降低性能。

STB的ARM子系統

ARM子系統包括ARM內核、多層AHB總線、連接到AHB總線上的SRAM控制器、SDRAM控制器、DMA控制器、外部異步接口CPU_BFM、AHB-APB接口電路，以及連接到APB總線上的中斷控制器、定時器等。

多層AHB總線可以連接8個AHB主設備和8個AHB從設備。不同的AHB主設備可以同時訪問不同的AHB從設備，從而提高了系統的數據吞吐能力。為了簡化設計，多層AHB總線不支持Burst、Split、Retry和Error傳輸。為了適應不同仿真模型的需求，多層AHB總線對AHB總線的傳輸類型沒有限制，支持SINGLE和所有INCR及WRAP傳輸類型。

DMA控制器協助ARM完成數據搬運工作。DMA控制器提供了4個硬件通道和4個軟件通道，每個通道可以獨立設置源地址、目的地址、傳輸長度和控制字。DMA控制器支持嵌套操作，即高優先級的數據傳輸可以暫時打斷低優先級的數據傳輸，高優先級的數據傳輸結束后再繼續進行低優先級的數據傳輸。為了提高數據傳輸的速率并盡量減少對多層AHB總線的占用，DMA控制器使用了兩個AHB主設備：一個AHB主設備負責從源地址讀取數據，然后把數據存人FIFO中；另一個AHB主設備則從FIFO中讀取數據，并寫到目的地址中。

CPU_BFM模擬了手機基帶處理器的異步接口，用來訪問其它異步接口。CPU_BFM是STB控制DUV的主要途徑，ARM通過CPU_BFM可以讀寫DUV的寄存器，DMA控制器可以通過CPU_BFM把需要解碼的音視頻數據快速寫到DUV中，或者把解碼后的數據讀入到STB中。ARM可以配置CPU_BFM的讀寫寬度，從而具有更大的靈活性。

AHB-APB接口電路提供了ARM控制大多數仿真模型的通路。ARM子系統中的中斷控制器和定時器都連接到APB總線上。

STB的其它仿真模型

除了ARM子系統外，STB還集成了其它仿真模型，如USB OTG、UTMI PHY、圖像傳感器、ADC、SCI、SPI、IIC、NOR閃存、NAND閃存、SD卡等。這些仿真模型都連接到APB總線上，ARM通過AHB-APB來配置和控制這些仿真模型。

STB的軟件架構

eCos（嵌入式可配置操作系統）是一種針對16位、32位和64位處理器的可移植嵌入式實時操作系統。eCos的源代碼是公開的，其最大的特點是模塊化，內核可配置。它的另一個優點是使用多任務搶占機制，具有最小的中斷延遲，支持嵌入式系統所需的所有同步原語，并擁有靈活的調度策略和中斷處理機制，因而具有良好的實時性。

STB的軟件基于eCos構建，如圖2所示。HAL、eCos內核、eCos內核API、硬件驅動程序構成了eCos的基本架構。DUV驅動程序可以調用STB硬件驅動程序、eCos內核API和HAL硬件抽象層。DUV應用程序調用DUV驅動程序和文件系統對DUV進行系統級驗證。如果對相對比較簡單的DUV進行驗證，可以不使用文件系統和eCos。

Palladium的使用流程

Palladium是基于定制CPU的硬件加速解決方案。和傳統的基于FPGA的硬件加速器相比，Palladium的編譯速度快、調試能力強，并支持多用戶。

Palladium支持SA（模擬加速）和ICE兩種模式，后者的運行速度更快，但要求測試平臺完全可綜合。本文選用ICE模式，其流程順序為模型替換、代碼綜合、編譯硬件、編譯軟件、運行和測試。

模型替換

由于ICE模式只能處理可綜合的RTL代碼，所以需要把測試平臺和DUV中所有不可綜合的仿真模型（如存儲器的仿真模型）都替換為可綜合的仿真模型，把所有不可綜合的語句如initial、PLI調用等放入∥synopsys translate_off／on語句塊中。Palladium可以支持Pullup和Pulldown。

代碼綜合

對驗證的測試平臺和DUV進行綜合，把RTL代碼轉化為門級網表。典型的綜合腳本如下：

綜合結束后可以檢查報告文件hdlIce.log，如果有錯誤提示，就需要修改RTL代碼并重新綜合；如果有警告提示，則需要確認是否有問題。

編譯硬件

對綜合后的門級網表進行編譯，把門級網表轉化為可以在Palladium上運行的數據庫。編譯過程分為如下步驟：輸入門級網表、設置設計、設置仿真器配置、設置時鐘、設置編譯、選項、預編譯、ICE準備、編譯。

編譯軟件

編譯STB中在ARM上運行的軟件，把編譯后的軟件代碼存為數據文件。同時準備其它的數據文件，如音視頻輸入數據等。

運行

在Palladium上運行編譯好的數據庫，運行過程分為如下步驟：下載設計的數據庫和各個存儲器的初始化文件、設置內置邏輯分析儀的觸發條件、設置波形信息、復位芯片、運行芯片、上載存儲器內容和仿真波形。

調試

檢查上載的存儲器內容和仿真波形，如果不符合設計的要求，則查找相應原因。如果是測試平臺和DUV的錯誤，則需要修改相應的RTL代碼并重新進行綜合、編譯硬件和運行；如果是ARM軟件的錯誤，則需要修改ARM軟件、編譯軟件并運行。

Palladium的測試結果

對Palladium的使用可分為三個階段：第一階段主要測試Palladium的基本流程，重點是STB的硬件和基本軟件；第二階段用已經流片的設計進行測試，測試重點是STB的軟件和Palladium的功能、運行性能以及測試能力；第三階段用Palladium對正待開發的芯片進行驗證。

Palladium可以正確仿真數字邏輯，并且能夠處理多時鐘和異步時鐘。Palladium的運行速度大約是200 kHz～500kHz，比RTL仿真快了100倍～500倍。

使用Palladium時的限制在于，Palladium只能做數字邏輯的功能驗證，不能做模擬電路的驗證，也不能驗證建立時間和保持時間等時序問題。為了達到更好的運行性能，需要對DUV中相關的時鐘電路進行優化，所以該部分電路不能通過Palladium進行驗證。另外，由于替換了存儲器仿真模型和其它不可綜合的仿真模型，所以該部分也不能通過Palladium進行驗證。所有Palladium不能驗證的部分必須采用傳統的邏輯仿真器進行充分驗證。

可以看出，Palladium不可能取代傳統的邏輯仿真和FPGA原型驗證，Palladium只是這些驗證手段的補充。

結語

基于Cadence提供的Palladium硬件加速解決方案，本文構建了一個全新的驗證平臺。該平臺加速了多媒體的系統級驗證，使得工程師可以在流片之前對芯片進行更充分的軟硬件驗證。

責任編輯：gt