Many of today’s SoCs are built around multi-layered, sophisticated interconnect IP components that link together multiple processor cores, caches, memories, and dozens of other IP blocks. These interconnects are enabling new generations of data servers and high-performance mobile devices. Being at the heart of SoCs, they introduce significant challenges to verification engineers both from functional verification and performance validation points of view. A bug in the interconnect IP’s functionality may affect operation of the entire SoC. A seemingly small variation in configuration of the interconnect IP may introduce unintended bottlenecks that degrade SoC performance. To properly tackle these challenges, a comprehensive verification approach is required.
Let’s start with functional verification aspects. Since interconnect IPs connect multiple IP blocks and subsystems within an SoC, thorough verification of each IP block is expected. Normally this is done in dedicated block level verification environments where each subsystem is verified and stressed out to a high degree. Even though they are tested at the block level, once the IP blocks are integrated into SoC and connected to the central interconnect IP, they require close monitoring. This task is accomplished by passive interface VIP agents which reside at each individual interface and monitor traffic at the interface. While interface VIP monitors can flag out protocol violations at the monitored interface, they suffer from an inherent limitation – their verification capabilities are limited to a single interface only, i.e. they are lacking the system view.
The missing piece of the puzzle is a system level scoreboard which, by connecting to interface VIPs, can track traffic as it traverses SoC via the interconnect IP. Since the system level scoreboard connects to interface VIPs, it gains the system view. It knows where a certain transaction originated, how and where it was routed, which device received it, how it responded to and how the response was routed back to the originating device. If you consider multiple participating devices (e.g. CPU clusters, GPUs, DDR sub-systems) as well as various communication protocols and transformations, such as up-sizing, downsizing, and splitting, the verification becomes quite complex even in non-coherent systems. Once coherency is added to SoC architecture, it takes verification challenges to a whole new level because in coherent SoCs, interconnect IPs play a role of the coherent manager. In those applications, interconnect IPs are tasked with maintaining the overall hardware coherency in the system. They decide which L2 caches must be snooped, how partial responses from various sources get assembled into a full cache line, which cache lines are stored in the internal System Level Cache, etc. It means that the system level scoreboard used for verification of modern SoCs must be able to address all these challenges.
So far, we mentioned functional verification challenges only. Even if SoC functions properly, it may not be able to meet the required performance budget, especially under challenging operating conditions. To avoid nasty surprises down the road, performance validation should start from the beginning of the verification effort and progress hand-in-hand with functional verification. It should address all target use cases and rely on realistic steady-state and peak traffic profiles, considering scenarios when a common resource (e.g. DDR sub-system) may simultaneously get accessed by multiple demanding resources such as CPUs, DSPs, and more.
We going to discuss these and other verification aspects at a greater level of details in the upcoming issues of the blog. Check back soon for more interesting discussions and insights!