UVM, which produces random address for every transaction, is best suited for stress testing.
The processor can be replaced by the verification IP (VIP) and can be used to access entire address space, which helps verifying system behaviour. These include error responses, interrupts, etc.
Although the directed test case can be used for accessing system address space, UVM, which produces random address for every transaction, is best suited for stress testing. UVM is extremely useful in verifying the MMU block.
Verification of the A53 block (functional verification) involves verifying the ARM core integrated with other hardware blocks. Some of the scenarios that are tested specific to A53 are given below.
Some of the verification is done in Verilog/System Verilog, while some others are done with C/Assembly test cases and, in some cases, it can be a combination of both.
For example, if SoC integration is in progress, then there is no need to wait until it is done. You can write a code where the processor goes into WFI mode after executing boot code. The processor can be made to come out of the WFI mode by driving the IRQ pin from the test bench. When integration is completed, same can be tested by configuring one of the slave peripherals to generate an interrupt.
Static memory check (back door)
Using Perl script, we can verify the memory configuration and instances in the memory configured for L1 and L2 cache. This is to verify if cache configuration and memory instances meet specification. For example, integrating L1 and L2 cache requires the ARM guidelines to be followed depending upon memory size.
Clock and reset check has already been explained.
In a system with multiple cores, the ARM-provided test bench needs to be modified based on the signals that are brought out of processor subsystem interface. For example, some signals in ACE interface might be tied off or, if there are multiple clock inputs, then corresponding clk port pins must be added in the test bench to match the multicore ARM interface.
The same can be applied to resets. In the processor subsystem diagram, there are many IP’s coherent Interconnect, NIC, etc . Each of these can have their resets drawn from the main reset. Alternatively, there could be separate resets brought out to the top level and if they are separate then, then the test bench needs to have corresponding port pins.
Directed test cases can be used to verify the behaviour of the multicore ARM processor. A few important tests are mentioned below.
A brief note on GLS: During your gate level simulation (GLS), the probability of violations at L1 and L2 cache transactions would be high. Another area where violation can be observed would be at the DDR interface. This does not mean other interfaces might be clean, but the probability of violations at these areas is high. In case of post DFT, test pins and TDR reset have to be followed.
There may be different and better approaches than the one described. The method discussed here is one among several. When working in the multicore environment, it is important to test some of the negative scenarios.
For example, the problem that could be most observed is in generating slave error responses. This is due to the fact that some slaves do not support this response. In such cases, it can be forced from the Verilog/System Verilog file.
Therefore, before starting the verification task, some of these errors can be captured and discussed instead of starting on them in middle of the verification task.
About the author
Guruprasadh P.V. works at Ensilica in processor subsystem verification. He has 14 years of experience, which includes verification, validation and firmware drivers for ARM. He writes technical papers on processors as a hobby.