利用便攜式激勵為軟件驅(qū)動的驗(yàn)證鋪平道路

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

硬件/軟件逐步細(xì)化

一個(gè)顯而易見的解決方案就是在傳統(tǒng)的驗(yàn)證流程中，圍繞硬件/軟件邊界進(jìn)行更多驗(yàn)證。但是，我們無法直接從以硬件為中心的驗(yàn)證，轉(zhuǎn)變?yōu)閲L試運(yùn)行整個(gè)應(yīng)用程序堆棧。運(yùn)行大量的軟件而存在的復(fù)雜性及生成的大量調(diào)試日志，讓追蹤簡單錯(cuò)誤也會變得非常復(fù)雜。

一種高效的方法是在最簡單的驗(yàn)證環(huán)境中進(jìn)行所有可行的驗(yàn)證，該環(huán)境讓我們能夠執(zhí)行目標(biāo)功能，并且具有最高的可見性，最大程度減少與測試意圖不相關(guān)的工作。

在本文中，我們將討論涉及到寄存器訪問驗(yàn)證的簡單示例。驗(yàn)證處理器是否能夠正確寫入和讀取 IP 寄存器，是非常關(guān)鍵的集成驗(yàn)證任務(wù)。即便是簡單的 SoC，也包含數(shù)以百計(jì)的寄存器，因而創(chuàng)建測試來驗(yàn)證處理器是否能夠讀取和寫入所有寄存器將會是非常耗時(shí)的工作。

圖 1 - 簡單的 SoC

圖 1 顯示了簡單的 SoC，它搭載了閃存、DDR 存儲器、緊耦合存儲器以及 UART 和 DMA 引擎，它們的寄存器通過低速外設(shè)總線來訪問。

雖然最終目標(biāo)是驗(yàn)證在處理器上運(yùn)行的代碼是否能夠訪問 IP 寄存器，但我們可以首先從基于 UVM 的驗(yàn)證開始，更加集中驗(yàn)證某一部分。在UVM 中率先驗(yàn)證存儲器子系統(tǒng)后，我們在嵌入式處理器上調(diào)通軟件時(shí)將更有信心。使用 Mentor 的 Questa inFact 便攜式激勵工具，可讓我們將同一測試的目標(biāo)重定向到 UVM 和嵌入式軟件環(huán)境，從而節(jié)省測試開發(fā)時(shí)間。

使用圖形描述寄存器

Questa inFact 使用了基于圖形的聲明輸入描述，可提供約束編程的功能，增強(qiáng)以迭代方式指定決策的能力。當(dāng)需要對訪問寄存器的規(guī)定約束時(shí)，以迭代方式進(jìn)行決策的能力非常有幫助。

首先，我們要捕獲存儲器測試操作的核心屬性：地址、訪問范圍大小、寫入數(shù)據(jù)、寫入掩碼。寫入掩碼指定了在進(jìn)行檢查時(shí)應(yīng)該讀取/寫入哪些位，而必須忽略哪些位。

圖 2 - 核心寄存器訪問結(jié)構(gòu)體

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

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

圖 3 - DMA 寄存器地址選擇

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

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

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

o 選擇哪個(gè)通道 (dma_ch)

o 選擇哪個(gè)通道寄存器被作為目標(biāo) (dma_ch_reg)

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

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

圖 5 - DMA 寄存器地址選擇約束

用于指定在約束中編碼的寄存器地址和寫入掩碼的更詳細(xì)約束顯示在圖 5 中。請注意，此約束標(biāo)記為“dynamic”(動態(tài))，這意味著在圖形范圍內(nèi)，它只有在激活之后才會應(yīng)用 – 在這種情況下，我們已經(jīng)決定訪問 DMA 寄存器。雖然這些約束是手動創(chuàng)建的，但它們也可從機(jī)器可讀取的寄存器描述生成，例如 IP-XACT、SystemRDL 等。

圖 6 - 簡單 SoC 寄存器訪問圖形

整合寄存器訪問圖形的 DMA、UART 和 TCM 部分之后，可獲得圖 6 中顯示的圖形。我們可以將它視為流程圖：首先，我們決定要訪問哪個(gè) IP，然后基于選定的 IP 來決定圖形分支，并且做出特定的選擇。例如，最左側(cè)的圖形分支包含 DMA 特定的決策。

定向測試

即便是小型 SoC，也有超過 250 個(gè)寄存器，而常規(guī)的 SoC 的寄存器數(shù)量甚至還會超出很多倍。我們必須確保能夠訪問所有這些寄存器，并通過某種隨機(jī)順序進(jìn)行訪問。我們還可能希望集中測試某一部分 – 例如，僅測試 UART 寄存器。

Questa inFact 允許結(jié)合使用約束和圖形覆蓋率目標(biāo)，將測試重點(diǎn)放在要實(shí)現(xiàn)的目標(biāo)上。約束指定允許生成哪些測試，而覆蓋率目標(biāo)則側(cè)重于系統(tǒng)性生成某些測試。例如，我們可以使用約束來指定 UART 當(dāng)前尚不能進(jìn)行測試。使用覆蓋率目標(biāo)可指定某個(gè)特定測試的重點(diǎn)是 DMA 引擎，但在實(shí)現(xiàn)該目標(biāo)之后，可將目標(biāo)定向到其他可用 IP。

圖 7 - 將 DMA 作為重點(diǎn)的覆蓋目標(biāo)

圖 7 中顯示的覆蓋率目標(biāo)(藍(lán)色陰影區(qū)域)將當(dāng)前測試活動的重點(diǎn)集中于 DMA 寄存器上。Questa inFact 將生成測試，按照偽隨機(jī)順序，系統(tǒng)地訪問 DMA 寄存器，然后生成對 DMA、UART、TCM 的混合訪問。

映射到 UVM 環(huán)境

截止目前，我們創(chuàng)建的寄存器訪問測試的描述都是獨(dú)立于任何驗(yàn)證環(huán)境的。我們現(xiàn)在必須提供一點(diǎn)膠接邏輯，將我們的測試圖形連接到子系統(tǒng)級驗(yàn)證環(huán)境。

圖 8 - 子系統(tǒng)級驗(yàn)證環(huán)境

在 UVM 子系統(tǒng)級環(huán)境中，我們使用總線功能模型 (BFM) 取代了處理器的 RTL 模型，以便通過互連訪問寄存器。寄存器測試圖形封裝在將通過 BFM 訪問寄存器的 UVM 虛擬序列 (virtual sequence) 中。

基本“CPU”虛擬序列提供通過類 API 對 BFM 的訪問，它支持不同大小的讀取和寫入。我們添加了特定的“memcheck”序列，它在“do_memcheck”任務(wù)內(nèi)部執(zhí)行寫入、回讀和檢查，如圖 9 所示。

圖 9 - UVM do_memcheck 任務(wù)

將寄存器測試圖形連接到虛擬序列中的 do_memcheck 任務(wù)所需的映射信息收集在一個(gè)文件中 – 在本例中該文件為 target.rseg。映射信息顯示在圖 10 中。

圖 10 - UVM 序列目標(biāo)映射

映射信息指定：

· 圖形應(yīng)該封裝在從 or1k_memcheck_vseq 擴(kuò)展的類中

· 在 UVM 環(huán)境中，應(yīng)該使用 or1k_memcheck_c 類來代表 or1k_soc_regacc 結(jié)構(gòu)體。

· 當(dāng) or1k_soc_regacc 內(nèi)部的“body”操作執(zhí)行時(shí)，應(yīng)調(diào)用 do_memcheck 任務(wù)。

只需這幾行代碼，我們就能在 UVM 環(huán)境中運(yùn)行寄存器測試圖形。這讓我們能夠使用標(biāo)準(zhǔn)的 UVM 和 SystemVerilog 調(diào)試工具，驗(yàn)證寄存器連接的基本信息，并對任何問題進(jìn)行調(diào)試。

映射到嵌入式軟件

當(dāng)然，驗(yàn)證確認(rèn) BFM 能夠訪問寄存器存儲器，并不一定確保處理器也能夠訪問。因此，在處理器上以與嵌入式軟件相同的方式，來運(yùn)行寄存器訪問測試，仍然非常重要。這種最簡單的完整 SoC 驗(yàn)證環(huán)境如圖 11 中所示。

圖 11 - 軟件驅(qū)動的驗(yàn)證環(huán)境

在本例中，我們將創(chuàng)建以 C 語言編寫的一系列測試，使用處理器寫入和回讀寄存器。我們的測試將使用 do_memcheck 函數(shù)來執(zhí)行實(shí)際的寫入、回讀和檢查。此函數(shù)如圖 12 所示。

圖 12 - 嵌入式軟件 do_memcheck 函數(shù)

與在 UVM 環(huán)境中相同，我們需要指定圖形如何映射到嵌入式軟件環(huán)境。映射信息顯示在圖 13 中。

圖 13 - 嵌入式軟件映射

映射信息指定以下內(nèi)容：

· 必須包括頭文件 or1k_memcheck.h。此文件聲明 do_memcheck 函數(shù)。

· 每次 body 操作執(zhí)行時(shí)，必須調(diào)用函數(shù) do_memcheck，傳遞 addr、size、wr_data 和 wr_mask 字段的值。

生成 C 測試

我們已經(jīng)介紹了要執(zhí)行的寄存器測試的基于圖形的模型，我們在如何生成一系列特定測試方面具有很大靈活性。圖 14 顯示了生成的測試的一個(gè)示例。在本例中，我們允許 inFact 將目標(biāo)定向到所有三個(gè) IP，但限制該測試只能通過圖形進(jìn)行五次迭代。

圖 14 - 示例寄存器測試

正如您看到的那樣，生成的測試是定向測試，在生成過程中，inFact 填充了隨機(jī)值。雖然特定測試在每次運(yùn)行時(shí)始終執(zhí)行相同的操作，但我們可以重新生成測試，每次在回歸運(yùn)行時(shí)使用不同的種子，從而在回歸運(yùn)行中實(shí)現(xiàn)更多隨機(jī)性。

為了實(shí)現(xiàn)對上文所述的寄存器訪問目標(biāo)的覆蓋率，我們需要生成更多針對性的測試。由于所有這些測試都是從單個(gè)描述模型生成的，因此我們可以簡單地更改測試生成程序的選項(xiàng)，以便在以下兩種方式之間切換：運(yùn)行很多測試，每個(gè)測試都對 do_memcheck 進(jìn)行少數(shù)幾次調(diào)用;或者運(yùn)行少數(shù)幾次測試，每次測試都對 do_memcheck 進(jìn)行很多次調(diào)用。我們還可以簡單地調(diào)節(jié)覆蓋率目標(biāo)，例如，生成一系列測試，僅將重點(diǎn)放在 DMA 寄存器測試上。

總結(jié)

采用步進(jìn)式方法來驗(yàn)證嵌入式處理器與設(shè)計(jì)其他部分的IP之間的交互，可在驗(yàn)證流程中及早發(fā)現(xiàn)錯(cuò)誤，以便最簡單地進(jìn)行調(diào)試和糾正，從而節(jié)省時(shí)間。使用便攜式激勵，可從描述的測試意圖著手，生成高質(zhì)量的測試，并將目標(biāo)重定向到多個(gè)環(huán)境。這樣可以應(yīng)對步進(jìn)式方法的主要挑戰(zhàn)，即它需要大量的重復(fù)工作，在多個(gè)位置執(zhí)行測試意圖，另外還需要使用低效率的定向測試，創(chuàng)建嵌入式軟件測試。在本文中，我們看到對 SoC 寄存器的測試意圖的單個(gè)描述如何能夠輕松將目標(biāo)定向到 UVM 和嵌入式軟件環(huán)境，作為 SoC 集成測試的一部分。我們還看到了如何使用 Mentor 的 Questa inFact 便攜式激勵工具，對此測試意圖進(jìn)行描述，并將目標(biāo)定向到特定環(huán)境。

下一次當(dāng)您開始計(jì)劃 SoC 集成測試時(shí)，應(yīng)該考慮到便攜式激勵和步進(jìn)式測試方法如何讓您的驗(yàn)證流程受益!