Processor subsystem verification: UVM

Article By : Guruprasadh P.V.

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.

A53 verification

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.
 
 

1. Warm reset/cold reset
2. WFI
3. IRQ and FIQ
4. Static memory check
5. Clock and reset check

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.

Multicore processor

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.
 
 

• All the validation tests (provided by ARM) should run in the multicore environment.
• All the cores should access all the peripherals in the processor subsystem and all the hardware blocks in the SoC (memory map test).
• Apply power on reset to all the cores at the same time; another scenario is to apply reset at different times.
• Different types of reset tests (cold reset and warm reset). From the test bench, drive CPUPORESET and CPUCORERESET to 1 0 and 0 1, respectively. Try to access the debug block within the cores from other cores using memory mapped access (applying reset to one core should not affect other cores' reset pins).
  For example, if core1 is in warm reset state, then core0 should be able to access the debug registers within core1 (read and write).
• Flush the L1 cache from each of the cores and observe if it is moving to L2 cache.
• From one of the cores, access an invalid memory location. This is to make sure that the abort initiated by the interconnect is passed to the correct core. You need to repeat this for all cores.
• Access different memory from all cores (normal, shared and device memory).
• Core sight is very important for verification. You need to enable all processor core sight block and verify if the trace is captured for all the cores in the core sight block.
• Verification of external booting for all the cores–simultaneously. This will verify the bandwidth of the interconnect.
• If Design Simulation Model (DSM) is available, then some of the tests need to be executed in this environment. Typically, ARM DSM simulation takes more time when compared to ARM RTL simulation.

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.

Conclusion

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.

« Previous: Directed Verification

Subscribe to Newsletter