ASIC Verification: Planning for Verification

Friday, May 16, 2008

Planning for Verification


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.


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.


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.


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

An example of Firmware code

If (HWCFG == “010”) then
MEM(status) = software_boot;


else if (HWCFG == “011”) then

MEM(status) = ext_boot;


MEM(status) = int_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.


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.


Anonymous said...

Hey There. I found your blog using msn. This
is a very well written article. I'll make sure to bookmark it and come back to read more of your useful info. Thanks for the post. I'll definitely return.
Here is my weblog - risks of hcg diet for men

Anonymous said...

Greate article. Keep writing such kind of information on your site.
Im really impressed by your blog.
Hello there, You've done a fantastic job. I'll certainly digg it and personally suggest to
my friends. I'm sure they'll be benefited from this website.
my website - grow 3 inches

Anonymous said...

Fantastic post but I was wondering if you could write a litte
more on this topic? I'd be very grateful if you could elaborate a little bit further. Bless you!
My blog ; DSL Anbieter

Anonymous said...

I couldn't refrain from commenting. Perfectly written!

Take a look at my page - jobs in uk

Anonymous said...

I needed to thank you for this fantastic read!

! I absolutely enjoyed every bit of it. I have got you bookmarked to look at new stuff you post…

Feel free to surf to my homepage - company profile
my web page - jasa pembuatan website