Module Level Verification of Subsystem

While doing System Level Verification we need to make sure that every part of system as well as Integration between the peripheral and processor should be verified properly. In order to verify that subsystem (ARM/DSP) and their integration we try to cover almost all the possible test scenarios using Verification Plan but still some part of System remain unverified & That will be resolved by using Module Level Verification of Processor Subsystem.

Let me First talk about System Level Verification Environment,

SOC (system on chip) functionality is controlled by subsystem (DSP, ARM etc).Some Complex SOC has more then one subsystem inside the chip & different IP (peripherals) which executes functionality(Serial port, Audio video coded, Camera Etc) . These subsystems control peripherals inside the chip & execute functionality of peripherals. So, here we need to verify every IP (peripherals) individually and their integration with subsystems and other peripherals.

There are two type of verification we are using to verify entire SOC (System of chip).

(A) Module Level verification

This Type of Verification used to verify module or IP individually.

IPs (peripherals) mostly controlled through input pins. We provide set of input and checking the functionality & expect desired results on output pins according to IPs specifications. In this process we are checking DUT (Design under test) behaviour by providing different type of Test scenarios using Constraint - Randomization and make sure that Module or IP is fully verified by checking Coverage (Functional & Code) Coverage.

We mostly use System Verilog, e, OVA, and VHDL/verilog languages for this type of verification.

(B) System (Chip) Level verification

This type of verification helps us to verify SOC integration between different peripherals, between two subsystems, between subsystem and peripherals & functionality of entire SOC.

Functionality of SOC is controlled by Processor subsystems (DSP, ARM etc) not by inputs only. These subsystems read instruction from the program memory and executes. All peripherals are connected with subsystems and controlled though System Bus or Bridge. Now we load set of instructions (to be executed for specific functionality) inside program memory of subsystems & it executes these set of instruction & SOC function accordingly.

We mostly use C, Assembly language for this type of verification.

we write Test case in C language to execute various functionality from Processor and assembler converts C language into Assembly language. So, The Assembler reads functions & macros from C Test case and selects set of Assembly instructions and prepare entire test case in Assembly instructions. Now these instructions get converted into binary language because we can load these binary data into program memory.

Once we load data into program memory we run entire design & this verification also has a test bench which has BFM (Bus function module), Loop back & other complimentary logic through which we validate this design by checking test case pass or failed.

Above is normal verification methodology which we are using to verify system on chip. This covers all the functionality of design.

So, why we need Standalone module level verification for Processor Subsystem?

Processors has own set of instructions & how to make sure all instruction get executed in System Level Verification?

In System level verification environment we are using Assembler which converts C Program into Assembly. So, we highly rely on assembler which has hard coded set of instructions for any functions. It uses Limited instructions or Set of instructions.

Assemblers designed only once by vendor and normally it has same set of instructions for C functions & macros.

There are other instructions also though which we can check functionality. Those instructions are not used by assembler. That way we can verify all the functionality of the design but still not verified all the instructions of Processor.

To test every instruction we have to modify the Assembler which is time consuming & also it’s difficult because by modifying it still we cant be sure of using all the instructions in assembler and again not much relevant to system level verification.

We provide Clock & Reset from Test bench and once Processor come out from Reset it start executing functionality according to given instructions & write test case in Assembly language by using all different kind of instructions & check All functionality again. So, here we don’t require assembler and we make sure that 100% coverage achieved by processor.

To execute any functionality through this module level environment, take less time & resource compare to system level.

Above mentioned figure shows the environment of Processors module Level verification. We write test case in Assembly language using all possible functionality related instructions & Assembly language is getting converted into binary format.

Now all instructions get into binary format which is now ready to load into program memory by using preloading option into test bench.

This verification environment does have its own linker file, test macros & Test bench.

Linker file which specifies the program memory location where Processor read instruction & execute also take care of jump kind of instruction where user want their program should execute from different memory locations.

Test bench at top-level which has memory pre-loading, BFM & loop back kind of functionality to verify Processors.

Conclusion:

During SOC Verification we target 100% code coverage & functionality coverage by using Module level & system level verification.

We always close our verification process once we verify all functionality but still in System like DSP/ARM remain unverified as we haven’t tested all instructions yet

Instructions are very crucial for any Processor & it’s like blood in a vein. We can’t afford to ignore it in any SOC Projects as Verification Engineer.