关于SoC Interconnect的验证方法

典型的SoC系统如下图所示，有数量众多的IP，如Processor、DMA、Memory，UART、GPIO等，它们之间需要通过interconnect进行数据交换，以实现特定的系统功能。

一般而言，Interconnect验证面临的挑战包括：

1. 如何验证通路routing的正确性？
2. 如何验证总线performance（延时与带宽）是否满足系统要求？
3. 如何验证security相关特性？
4. 如何验证power-management相关特性？
5. 如何验证多种不同协议转换的正确性，如AHB2APB、AXI2APB等？

目前大多数SoC中的Interconnect多是使用商用IP，在代码质量上相对有保证，但存在如下风险：

1. Interconnect IP是高度可配置化，需要验证设计的配置是否正确，例如port支持的transaction类型，路由表项，性能相关参数等
2. SoC系统中往往是多个Interconnect级连的架构，需要验证级连后端到端的路由、性能是否符合预期，是否存在死锁等

具体而言，实际项目中Interconnect验证需要考虑如下几方面：

1. Functional correctness：验证环境需要支持master发送spec中要求的全部trans type（如不同AXI的Axburst、Axsize等），需要支持读写response的检查（例如读数据、状态等），需要支持协议检查（protocol check，例如AXI 4K边界，AW与W channel数据长度要match等），还需要支持function coverage的收集，以度量关心的case被覆盖到；
2. Verification completeness：可以理解为验证要端到端覆盖Interconnect架构中的通路，特别是前面提到的多层总线结构，要覆盖多个Interconnect之间的交换；
3. Protocol conversion：覆盖不同总线协议转换，特别的关注error response的传递；
4. Stress verification：压力测试，模拟实际系统使用时多通路并发场景，检查潜在的性能影响，以及反压功能等；
5. Security related：支持安全特性（如ARM TrustZone）的系统，其Interconnect可能需要具备安全地址保护功能，如非安全访问（AxProt指示为non-secure）访问安全地址空间需要返回error response；
6. Interconnect Latencies：以DMA为例，DMA需要从Interconnect读取源数据，存入内部FIFO缓存，然后缓存数据通过Interconnect写出数据到目的slave，该模型中读写通道通过FIFO缓存耦合到一起。整体DMA搬数性能受到读写通道延迟，FIFO缓存大小，DMA OST能力的影响。甚至在特殊情况下，会导致总线挂死（待进一步说明）；

暂时写到这里，每天继续。。。