SoC设计中的互连验证中遇到的问题

在我们之前的博客中，我们提到验证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）访问这些寄存器。在连接检查期间捕获到此问题，并且互连记分板报告了错误。

两个从站不支持指令获取保护

根据我们的互连规范，所有包含防火墙保护的从站必须具有指令获取保护过滤器。但是该设计不支持对指令获取和非指令获取事务的这种过滤。因此，即使请求被阻止，互连也允许所有请求通过。互连的安全管理验证和互连记分板报告此问题。

互连中的默认配置错误转发问题

如图2所示，互连有3个子交换间代理。在每个IA/TA套接字上报告的错误在子交换间代理处传播和收集。来自交换机2和3的这些错误被传播并转发到交换间代理1.每个代理中的错误转发可通过来自控制处理器的寄存器配置来编程。但是，默认情况下禁用从互连3转发的错误。因此，具有默认配置的系统未检测到互连3处发生的任何错误，并且系统处于死锁状态。我们在使用错误情况进行SoC验证时遇到了这个问题。

图2错误转发问题

特殊转角情况下互连的限制（例如，锁定传输，4K边界重叠，具有突发传输到APB目标的字节启用映射等）在开发软件实施的编程指南时需要考虑。

摘要

在本文中，我们通过开发可重用的验证环境和要验证的功能，展示了互连设计的验证方法。我们已经描述了验证期间捕获的主要互连问题。通过采用上述方法，我们可以在设计验证阶段早期识别IP集成和互操作性相关问题。模拟和验证了许多系统级方案，这有助于获得对NoC设计的信心。与错误和安全管理相关的验证也帮助我们开发了特定SoC的用户编程指南。