利用可移植性激勵為軟件驅動的驗證鋪平道路

簡介

本文引用地址：http://www.104case.com/article/202002/409646.htm

設計正變得日益復雜，越來越多的設計包含了處理器，甚至經常包含多個處理器。由于處理器是設計的不可分割的一部分，因此我們必須驗證在處理器上運行的軟件與設計的其他部分之間的交互，這一點非常重要。軟件對當今系統(tǒng)的運作至關重要，因而在實驗室中調通原型芯片之前，對硬件／軟件邊界的驗證和確認不容出現任何延遲。至少，驗證團隊必須完成這項任務，并且自行承擔風險。相信我們都聽說過一些嚴重錯誤的場景，例如，團隊在實驗室中發(fā)現，處理器的總線與設計的連接順序接反了，或者處理器在低功耗模式下再無法加電啟動。

硬件／軟件逐步細化

一個顯而易見的解決方案就是在傳統(tǒng)的驗證流程中，圍繞硬件／軟件邊界進行更多驗證。但是，我們無法直接從以硬件為中心的驗證，轉變?yōu)閲L試運行整個應用程序堆棧。嘗試運行大量的軟件而導致的復雜性及生成的大量調試日志，讓追蹤簡單錯誤也會變得非常復雜。一種高效的方法是在最簡單的驗證環(huán)境中進行所有可行的驗證，該環(huán)境讓我們能夠執(zhí)行目標功能，并且具有最高的可見性，最大程度減少與測試意圖不相關的工作。在本文中，我們將討論涉及到寄存器訪問驗證的簡單示例。驗證處理器是否能夠正確寫入和讀取 IP 寄存器，是非常關鍵的集成驗證任務。即便是簡單的 SoC，也包含數以百計的寄存器，因而創(chuàng)建測試來驗證處理器是否能夠讀取和寫入所有寄存器將會是非常耗時的工作。圖 1 顯示了一個簡單的 SoC，它搭載了閃存、DDR 存儲器、緊耦合存儲器以及  UART  和  DMA  引擎，引擎的寄存器通過低速外設總線來訪問。雖然最終目標是驗證在處理器上運行的代碼是否能夠訪問  IP  寄存器，但我們可以首先從基于  UVM  的驗證開始，更加集中驗證某一部分。在率先驗證UVM 中的存儲器子系統(tǒng)后，我們在嵌入式處理器上調通軟件時將更有信心。使用 Mentor 的 Questa inFact 可移植性激勵工具，可讓我們將同一測試意圖重定向到UVM 和嵌入式軟件環(huán)境，從而節(jié)省測試開發(fā)時間。

圖 1 - 簡單的 SoC

使用圖表描述寄存器

Questa  inFact  使用了基于圖表的聲明輸入描述，可提供約束編程的功能，增強以迭代方式指定決策的能力。在指定訪問寄存器的約束方面，以迭代方式進行決策的能力非常有幫助。

首先，我們要捕獲存儲器測試操作的核心屬性：地址、訪問大小、寫入數據、寫入掩碼。寫入掩碼指定了在進行檢查時應該讀取／寫入哪些位，而必須忽略哪些位。

Action 是指要在目標驗證環(huán)境中執(zhí)行的操作單位。在下文中，我們將了解更改  body  action  的實現如何讓我們輕松地將寄存器訪問測試意圖重定向到UVM 和嵌入式軟件環(huán)境。

圖  2  顯示的寄存器訪問描述符不包括系統(tǒng)中的任何IP 詳細信息。接下來，我們需要添加這些限制。我們的  DMA  引擎（來自  opencores.org  的  Wishbone  DMA Core）包括一系列的核心寄存器，還有一組通道描述符寄存器。使用基于圖表的描述，我們能夠以迭代方式描述寄存器地址。

圖 3 中的圖形描述顯示了選擇 DMA 寄存器地址的過程：

■ 選擇核心寄存器或通道控制寄存器陣列(dma_reg)

■ 如果選擇通道控制寄存器

——選擇哪個通道 (dma_ch)

——選擇哪個通道寄存器被作為目標(dma_ch_reg)

圖 2 - 核心寄存器訪問結構體

圖 3 - DMA 寄存器地址選擇

圖 4 - DMA 寄存器地址選擇規(guī)則

圖 4 顯示了此過程的文字描述

…未完待續(xù)…

點擊免費下載完整白皮書>>