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

從站突發長度寬度參數配置錯誤

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

圖1突發長度問題

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

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

互連中安全相關寄存器的無效訪問

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

兩個從站不支持指令獲取保護

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

互連中的默認配置錯誤轉發問題

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

圖2錯誤轉發問題

特殊轉角情況下互連的限制（例如，鎖定傳輸，4K邊界重疊，具有突發傳輸到APB目標的字節啟用映射等）在開發軟件實施的編程指南時需要考慮。

摘要

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