In today’s complex SOC designs, most companies use third-party processor IP, such as the ARM A53 core, leaving SoC designers to verify the processor subsystem they want to implement. Here's how you should write the test code with coverage and functional perspectives.
When designing complex SOCs, most companies deal with third-party processor IP processor. Yet, the processor subsystem verification plays an important role in achieving design goals. The key lies in understanding the effects of instruction execution by the processor (writing the test code with coverage perspective and functional perspective). Let's take a look at the widely used ARM A53 taken as reference for explaining the processor subsystem.
The figure gives an overview and components associated with our reference processor subsystem. The components shown are generic; you may have additional more AXI interfaces.
*__Figure 1:__ Processor subsystem and System on Chip is differentiated by different boundary colours (blue denotes the processor subsystem, while pink represents the SoC).*
Here's simple test bench diagram that shows the interface between test bench and the DUT. The test bench performs the functionality of I2C slave, SPI master and Interrupt inputs to interrupt block of DUT. The dotted line C test code to TB memory is about the handshake mechanism that can be achieved.
*__Figure 2:__ A simple test bench diagram that shows the interface between test bench and the DUT.*