在我們之前的博客中，我們提到驗證NoC系統(tǒng)遠(yuǎn)遠(yuǎn)超出了事務(wù)路由檢查。我們能夠在SoC級別的復(fù)雜互連驗證期間捕獲各種問題，其中NoC具有20多個總線主控器，80多個總線從器件，以及具有不同總線協(xié)議的多個局間總線代理（如OCP 2.2，AXI 3.0，APB 3.0）。在這里，我們通過使用前兩篇文章中提到的一致方法描述了我們在SoC驗證早期階段捕獲的一些主要問題。

從站突發(fā)長度寬度參數(shù)配置錯誤

在我們的NoC設(shè)計中，訪問其中一個從站是通過來自不同子互連的交換間代理，如圖所示圖1。交換機間支持的最大事務(wù)大小是從站的最大事務(wù)大小的一半。因此，通過交換間代理將針對從站的最大分組大小的單個請求分成兩個不同的事務(wù)。因此，從屬突發(fā)長度參數(shù)被不必要地過度配置?；ミB記分板報告了此問題。

圖1突發(fā)長度問題

DMA引擎的無與倫比的帶寬要求

在性能驗證期間，性能監(jiān)視器組件報告了DMA讀寫通道的不匹配帶寬錯誤。由于從請求到請求和響應(yīng)響應(yīng)的互連路由延遲，DMA引擎無法限制未完成的事務(wù)。發(fā)現(xiàn)DMA引擎FIFO深度不足以滿足所需的SoC帶寬。

互連中安全相關(guān)寄存器的無效訪問

根據(jù)我們的互連規(guī)范，只允許控制處理器訪問互連安全相關(guān)的寄存器。但是互連設(shè)計允許從其他總線主控器（如PCIe）訪問這些寄存器。在連接檢查期間捕獲到此問題，并且互連記分板報告了錯誤。

兩個從站不支持指令獲取保護(hù)

根據(jù)我們的互連規(guī)范，所有包含防火墻保護(hù)的從站必須具有指令獲取保護(hù)過濾器。但是該設(shè)計不支持對指令獲取和非指令獲取事務(wù)的這種過濾。因此，即使請求被阻止，互連也允許所有請求通過?；ミB的安全管理驗證和互連記分板報告此問題。

互連中的默認(rèn)配置錯誤轉(zhuǎn)發(fā)問題

如圖2所示，互連有3個子交換間代理。在每個IA/TA套接字上報告的錯誤在子交換間代理處傳播和收集。來自交換機2和3的這些錯誤被傳播并轉(zhuǎn)發(fā)到交換間代理1.每個代理中的錯誤轉(zhuǎn)發(fā)可通過來自控制處理器的寄存器配置來編程。但是，默認(rèn)情況下禁用從互連3轉(zhuǎn)發(fā)的錯誤。因此，具有默認(rèn)配置的系統(tǒng)未檢測到互連3處發(fā)生的任何錯誤，并且系統(tǒng)處于死鎖狀態(tài)。我們在使用錯誤情況進(jìn)行SoC驗證時遇到了這個問題。

圖2錯誤轉(zhuǎn)發(fā)問題

特殊轉(zhuǎn)角情況下互連的限制（例如，鎖定傳輸，4K邊界重疊，具有突發(fā)傳輸?shù)紸PB目標(biāo)的字節(jié)啟用映射等）在開發(fā)軟件實施的編程指南時需要考慮。

摘要

在本文中，我們通過開發(fā)可重用的驗證環(huán)境和要驗證的功能，展示了互連設(shè)計的驗證方法。我們已經(jīng)描述了驗證期間捕獲的主要互連問題。通過采用上述方法，我們可以在設(shè)計驗證階段早期識別IP集成和互操作性相關(guān)問題。模擬和驗證了許多系統(tǒng)級方案，這有助于獲得對NoC設(shè)計的信心。與錯誤和安全管理相關(guān)的驗證也幫助我們開發(fā)了特定SoC的用戶編程指南。