Planning for Verification

INTRODUCTION

Verification planning is most important part of verification, irrespective of the size of the design. Since, about 70% of the design cycle time is spent on verification, with proper verification planning some of the issues faced during the later stages of the design cycle can be easily avoided earlier. Verification planning is described as a set of goals that needs to be verified. A verification plan would consists of:

1. Functional requirements
2. Design requirements
3. Defining coverage goals and
4. Embedded firmware requirements
   

Apart from these requirements, the verification plan should also focus on reusable methodology.

SPECIFICATION

The specification is for capturing the requirements of the design. It is required to split the specification into Functional and Design requirements. Functional requirements can be defined as the behavior required by the system while the Design requirements is used to check the implementation of the function against the design specification. For verifying the design requirements, bottom-up verification approach can be adapted to reduce the effort spent on SOC level. The Design requirements need to be split into system-specific requirements and peripheral specific requirements . The peripheral-specific requirements are those which can be verified in module level. Examples of peripheral-specific requirements are

• Verifying all possible packet types for all HS/FS/LS for USB
  

• Verifying all possible baud rate for a UART
  

System specific requirements focus more on system level issues such as reset generation logic and clock generation logic can be completely verified only on system level.

Examples of system-specific requirements are

1. Verifying the system is properly reset for the different types of reset

2. Verifying the system for different types of power saving modes

3. Verifying the interconnectivity of clock

4. Verifying the connectivity to pads, interrupts, debug interfaces.

With this approach, the peripheral is verified completely in the module level. The SOC level verification could then focus more on top-level issues such as interconnectivity, interrupt system behavior (response of interrupt for that peripheral), bus interfaces, I/O interfaces. The system level verification could focus more on system level issues and speed up the overall verification process.

COVERAGE HOLES

It is good to have a complete coverage metric for all the peripherals, but this would mean additional overhead for simulators which would slow down the simulation speed drastically. There has always been a compromise for coverage against the simulation speed. Hence it becomes necessary to understand the complexity of the design before identifying the coverage points.

For SOC verification it would be good to have interconnectivity coverage, coverage for interrupts, system-specific behavior such as power saving features, recovery sequences, reset and clock (power saving features), and system buses.

EMBEDDED F/W REQUIREMENTS

An embedded firmware can be described as a piece of software embedded into the ROM/EPROM which would initialize the chip into a defined state on reset. This piece of software could contain Startup sequences, bootstrap loaders, memory test routines, tests for production etc. It can be seen that this software is very complex and the corresponding verification is a complex task. Unlike the verification of peripherals, firmware verification is restricted to SOC level which further increases the complexity of verification. So how do we ensure this piece of software works? For firmware verification, it is necessary to have a good coverage metric. During the verification planning phase, we need to identify all the coverage points with iterative process of review from the members involved in the development of concept and firmware. Normally the firmware verification plan is a list of coverage items that needs to be addressed in the process.

Figure shows the coverage points for firmware ( Thanks to http://www.us.design-reuse.com)

An example of Firmware code

If (HWCFG == “010”) then
MEM(status) = software_boot;
Software_start();
else if (HWCFG == “011”) then
MEM(status) = ext_boot;
Ext_start();
else
MEM(status) = int_boot;
Internal_boot();
end if;

The firmware code can then be translated to a flow chart which gives the verification engineer an overview of the software flow.

Conclusion

Verification plan gives an early estimate on effort, resource required, reuse percentage and coverage goals. Verification closure is an iterative process where the plan is measured against the implementation and coverage goals. Verification reuse can be achieved with proper planning, reusable verification environment and proper documentation.