Verification requirements

Functional verification is a process of ensuring the fitness of DUT for its purpose.

It involves checking the compliance of the DUT to requirements. This is achieved by first translating the requirements specifications to verification plan.

Is the requirement specification used for designing DUT, the only source of requirements for verification?

Although the requirements specifications used for design are primary requirements for verification but there are additional secondary requirements to be taken into consideration. These secondary requirements stem from the effects of the process of transformations requirements into RTL design used for verification.

RTL design is transformation of requirements specification made up of

• Functional requirements
• Power target requirements
• Performance target requirements
• Security requirements

The RTL design used for functional verification has been built by doing two major transformations of requirement specifications. It’s shown in the figure below.

First transformation is mapping of the requirement specifications to micro-architecture specifications. This involves dividing the functional requirements into various blocks meeting the constraints of power, performance and security.

Second transformation is mapping the micro-architecture to implementation. Implementation is realizing data path, control path, low power related logic, clocks and resets related logic using various standard and custom logic.

Now coming back to verification requirements, verification has to not only account the design requirement specifications but also the effects of transformations. Both the steps of transformation bring in their own set of additional verification requirements beyond functional verification.

What are some of the additional verification requirements due to effects of transformations?

First transformation of requirements specifications to micro-architecture mapping can be based on certain assumptions. In serial communication design certain framing violations will never occur or certain level of FIFO depth is sufficient for crossing between two asynchronous clocking interfaces etc. Any micro-architecture assumptions must be asserted. Some special tests might have to be devised to saturate certain internal interfaces or to create scenarios for exercise all states of some internal FSMs etc.

Second transformation of mapping blocks to implementations can give rise to scenarios and checks for the structure itself used. For example a register structure looking like memory is used for mapping the control and status implementation of designs.

This register structure has two types of verification requirements. First design independent structural verification and second is design dependent functionality verification.

Design functionality independent verification requirements are accessibility of all the registers, correctness of read/write only type of attributes of each register bit etc.

Design functionality dependent verification is whether effect of the control register programmed is taking place correctly or on certain error injection scenarios are status registers getting updated correctly etc.

Low power structural elements verification for their intent of achieving low power intent and ensuring no side effects on the primary functionality has to be verified.

Side effects of HDL used for implementation have to be accounted in to the coding practices. These side effects can be in the form races, mismatches between simulation and synthesis, signaling modeling etc.

Verification requirements for verification plans has to take into consideration the requirements specification used for the design, micro-architecture specifications, implementation logic structures and side effects of the language.