利用可移植性激勵為軟件驅(qū)動的驗證鋪平道路
簡介
本文引用地址:http://cafeforensic.com/article/202002/409646.htm
設(shè)計正變得日益復(fù)雜,越來越多的設(shè)計包含了處理器,甚至經(jīng)常包含多個處理器。由于處理器是設(shè)計的不可分割的一部分,因此我們必須驗證在處理器上運行的軟件與設(shè)計的其他部分之間的交互,這一點非常重要。軟件對當(dāng)今系統(tǒng)的運作至關(guān)重要,因而在實驗室中調(diào)通原型芯片之前,對硬件/軟件邊界的驗證和確認(rèn)不容出現(xiàn)任何延遲。至少,驗證團(tuán)隊必須完成這項任務(wù),并且自行承擔(dān)風(fēng)險。相信我們都聽說過一些嚴(yán)重錯誤的場景,例如,團(tuán)隊在實驗室中發(fā)現(xiàn),處理器的總線與設(shè)計的連接順序接反了,或者處理器在低功耗模式下再無法加電啟動。
硬件/軟件逐步細(xì)化
一個顯而易見的解決方案就是在傳統(tǒng)的驗證流程中,圍繞硬件/軟件邊界進(jìn)行更多驗證。但是,我們無法直接從以硬件為中心的驗證,轉(zhuǎn)變?yōu)閲L試運行整個應(yīng)用程序堆棧。嘗試運行大量的軟件而導(dǎo)致的復(fù)雜性及生成的大量調(diào)試日志,讓追蹤簡單錯誤也會變得非常復(fù)雜。一種高效的方法是在最簡單的驗證環(huán)境中進(jìn)行所有可行的驗證,該環(huán)境讓我們能夠執(zhí)行目標(biāo)功能,并且具有最高的可見性,最大程度減少與測試意圖不相關(guān)的工作。在本文中,我們將討論涉及到寄存器訪問驗證的簡單示例。驗證處理器是否能夠正確寫入和讀取 IP 寄存器,是非常關(guān)鍵的集成驗證任務(wù)。即便是簡單的 SoC,也包含數(shù)以百計的寄存器,因而創(chuàng)建測試來驗證處理器是否能夠讀取和寫入所有寄存器將會是非常耗時的工作。圖 1 顯示了一個簡單的 SoC,它搭載了閃存、DDR 存儲器、緊耦合存儲器以及 UART 和 DMA 引擎,引擎的寄存器通過低速外設(shè)總線來訪問。雖然最終目標(biāo)是驗證在處理器上運行的代碼是否能夠訪問 IP 寄存器,但我們可以首先從基于 UVM 的驗證開始,更加集中驗證某一部分。在率先驗證UVM 中的存儲器子系統(tǒng)后,我們在嵌入式處理器上調(diào)通軟件時將更有信心。使用 Mentor 的 Questa inFact 可移植性激勵工具,可讓我們將同一測試意圖重定向到UVM 和嵌入式軟件環(huán)境,從而節(jié)省測試開發(fā)時間。
圖 1 - 簡單的 SoC
使用圖表描述寄存器
Questa inFact 使用了基于圖表的聲明輸入描述,可提供約束編程的功能,增強(qiáng)以迭代方式指定決策的能力。在指定訪問寄存器的約束方面,以迭代方式進(jìn)行決策的能力非常有幫助。
首先,我們要捕獲存儲器測試操作的核心屬性:地址、訪問大小、寫入數(shù)據(jù)、寫入掩碼。寫入掩碼指定了在進(jìn)行檢查時應(yīng)該讀?。瘜懭肽男┪唬仨毢雎阅男┪?。
Action 是指要在目標(biāo)驗證環(huán)境中執(zhí)行的操作單位。在下文中,我們將了解更改 body action 的實現(xiàn)如何讓我們輕松地將寄存器訪問測試意圖重定向到UVM 和嵌入式軟件環(huán)境。
圖 2 顯示的寄存器訪問描述符不包括系統(tǒng)中的任何IP 詳細(xì)信息。接下來,我們需要添加這些限制。我們的 DMA 引擎(來自 opencores.org 的 Wishbone DMA Core)包括一系列的核心寄存器,還有一組通道描述符寄存器。使用基于圖表的描述,我們能夠以迭代方式描述寄存器地址。
圖 3 中的圖形描述顯示了選擇 DMA 寄存器地址的過程:
■ 選擇核心寄存器或通道控制寄存器陣列(dma_reg)
■ 如果選擇通道控制寄存器
——選擇哪個通道 (dma_ch)
——選擇哪個通道寄存器被作為目標(biāo)(dma_ch_reg)
圖 2 - 核心寄存器訪問結(jié)構(gòu)體
圖 3 - DMA 寄存器地址選擇
圖 4 - DMA 寄存器地址選擇規(guī)則
圖 4 顯示了此過程的文字描述
…未完待續(xù)…
評論