典型的SoC系统如下图所示,有数量众多的IP,如Processor、DMA、Memory,UART、GPIO等,它们之间需要通过interconnect进行数据交换,以实现特定的系统功能。
一般而言,Interconnect验证面临的挑战包括:
- 如何验证通路routing的正确性?
- 如何验证总线performance(延时与带宽)是否满足系统要求?
- 如何验证security相关特性?
- 如何验证power-management相关特性?
- 如何验证多种不同协议转换的正确性,如AHB2APB、AXI2APB等?
目前大多数SoC中的Interconnect多是使用商用IP,在代码质量上相对有保证,但存在如下风险:
- Interconnect IP是高度可配置化,需要验证设计的配置是否正确,例如port支持的transaction类型,路由表项,性能相关参数等
- SoC系统中往往是多个Interconnect级连的架构,需要验证级连后端到端的路由、性能是否符合预期,是否存在死锁等
具体而言,实际项目中Interconnect验证需要考虑如下几方面:
- Functional correctness:验证环境需要支持master发送spec中要求的全部trans type(如不同AXI的Axburst、Axsize等),需要支持读写response的检查(例如读数据、状态等),需要支持协议检查(protocol check,例如AXI 4K边界,AW与W channel数据长度要match等),还需要支持function coverage的收集,以度量关心的case被覆盖到;
- Verification completeness:可以理解为验证要端到端覆盖Interconnect架构中的通路,特别是前面提到的多层总线结构,要覆盖多个Interconnect之间的交换;
- Protocol conversion:覆盖不同总线协议转换,特别的关注error response的传递;
- Stress verification:压力测试,模拟实际系统使用时多通路并发场景,检查潜在的性能影响,以及反压功能等;
- Security related:支持安全特性(如ARM TrustZone)的系统,其Interconnect可能需要具备安全地址保护功能,如非安全访问(AxProt指示为non-secure)访问安全地址空间需要返回error response;
- Interconnect Latencies:以DMA为例,DMA需要从Interconnect读取源数据,存入内部FIFO缓存,然后缓存数据通过Interconnect写出数据到目的slave,该模型中读写通道通过FIFO缓存耦合到一起。整体DMA搬数性能受到读写通道延迟,FIFO缓存大小,DMA OST能力的影响。甚至在特殊情况下,会导致总线挂死(待进一步说明);
暂时写到这里,每天继续。。。