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