Guidelines for complex SoC verification

Inevitable changes

Consider the example of a typical SoC, consisting of a processor, several IPs, Direct Memory Access for data control, a common bus matrix for data transfers and inter-block communication and a system memory for data storage.

The requirements may change many times during the execution of a project. For instance, system memory size may be changed from X to Y to meet software needs. Third party IP may need to be changed, or a new IP or feature may need to be added. So, significant SoC functional specification change happens and we have to deal with adding, changing and removing features targeted for verification, updates in register definition and the like.

With above dynamics, a verification team has to tackle the following hurdles:

• How to or what to plan in verification?
• What type of execution flow model needs to be setup?
• How to manage SoC verification on time?

Plan and manage

The real skill in planning is to adopt and to manage the verification plan which can cope with inevitable functional specification or requirement changes. There is a need to have a proper plan on automation and also to implement and manage reusable test benches.

Automation

Considering that there are significant changes in register specifications, planning to manually change the register tests will be a huge, time-consuming exercise. You need to plan for automation in which register contents are extracted from specification to your verification environment register model. You need to have an increasing amount of automation in place to cope faster with functional and requirement changes.

Below, in Figure 1, DMA_CFG register is shown as an example from the complete register set of specifications. PERL script is used to extract information from register worksheet file and convert into a register model file which is then imported imported by register model in the verification environment. Register model test library performs Read, Write and other application specific functions from the Register file set.

Click on image to enlarge.

Once the above flow is established, when there any changes in register fields or any additions/deletions of register contents, only the script has to be executed to get a completely updated register file. The same register model test library is used with updated register file to perform read, write and other application specific functions (may be minor changes) from the register file set.