Let’s look at a typical AMBA based subsystem in the SOCs that we find today:
From this picture, what is clear to me is a preponderance of multiple AMBA components of different flavors (AXI3/4, ACE, AHB, APB). So, even if we have all of the different VIPs to represent these .different flavors, it is not a slam dunk as far as completing the verification of the full subsystem. Stitching all these components together and bringing up such a verification environment itself is a big challenge. To deal with market pressures of shipping out new devices every 4-6 months, SoC companies are adding new design blocks incrementally to existing platforms. Given these time constraints, new verification environments cannot be developed again from scratch. If we dig deeper, we see the types of verification needed to bring in changes to the SoC:
Ensuring Data Integrity: Maintaining the integrity of data flow across different blocks of the system environment is important. This is because each block or sub-system has its own transaction types with which it communicates within the sub-system For instance, AXI coherent transactions should get translated to AHB transactions when multiple AXI-ACE masters are talking to multiple AHB Slave memories through the interconnect fabric.
Transaction routing: One important objective of a system level verification environment is to ensure that different transactions that are routed across various components are as per the specified memory map.
Synchronization: There needs to be adequate synchronization between multiple AMBA components. This is important for meaningful stimulus generation.
Connectivity: In a system environment with multiple instances of AMBA components, there is a need to ensure that they have been hooked as per the specification. This calls for correct connectivity of various AMBA bus functional models in the testbench.
System Level Checks, Performance Analysis: Although checks at the individual blocks are important, as we graduate towards the system level, the verification environment needs to be capable of performing all system-level checks across all the AHB, APB & AXI ports within the system. It also needs to cover the transaction flow across protocols while analyzing the performance of the bust matrix with respect to throughput, latency etc.
Also, of the above requirements need to be addressed in multiple variants of the original system level infrastructure. This calls for quite a lot to be done by the verification team, right?
This got me thinking: There is no magic switch to have all these challenges addressed. So how can we support an SOC verification team in their endeavors? What would definitely be useful to have is a reusable verification environment which can be tweaked minimally so that it can be reused for the new system. In my next blog, let me put down my thoughts as to what such an environment ought to encapsulate, and how it might address some of the system level verification challenges.
Authored by Satyapriya Acharya
Here’s where you can find more information on Verification IP for AMBA 4 AXI.