Functional verification is the task of verifying that the logic design conforms to specification.[1] Functional verification attempts to answer the question "Does this proposed design do what is intended?"[2] This is complex and takes the majority of time and effort (up to 70% of design and development time)[1] in most large electronic system design projects. Functional verification is a part of more encompassing design verification, which, besides functional verification, considers non-functional aspects like timing, layout and power.[3]


Although the number of transistors increased exponentially according to Moore's law, increasing the number of engineers and time taken to produce the designs only increase linearly. As the transistors' complexity increases, the number of coding errors also increases. Most of the errors in logic coding come from careless coding (12.7%), miscommunication (11.4%), and microarchitecture challenges (9.3%).[1] Thus, electronic design automation (EDA) tools are produced to catch up with the complexity of transistors design. Languages such as Verilog and VHDL are introduced together with the EDA tools.[1]

Functional verification is very difficult because of the sheer volume of possible test-cases that exist in even a simple design. Frequently there are more than 10^80 possible tests to comprehensively verify a design – a number that is impossible to achieve in a lifetime. This effort is equivalent to program verification, and is NP-hard or even worse – and no solution has been found that works well in all cases. However, it can be attacked by many methods. None of them are perfect, but each can be helpful in certain circumstances:


There are three types of functional verification, namely: dynamic functional, hybrid dynamic functional/static, and static verification.[1]

Simulation based verification (also called 'dynamic verification') is widely used to "simulate" the design, since this method scales up very easily. Stimulus is provided to exercise each line in the HDL code. A test-bench is built to functionally verify the design by providing meaningful scenarios to check that given certain input, the design performs to specification.

A simulation environment is typically composed of several types of components:

Different coverage metrics are defined to assess that the design has been adequately exercised. These include functional coverage (has every functionality of the design been exercised?), statement coverage (has each line of HDL been exercised?), and branch coverage (has each direction of every branch been exercised?).


See also


  1. ^ a b c d e Molina, A; Cadenas, O (8 September 2006). "Functional verification: approaches and challenges". Latin American Applied Research. 37. ISSN 0327-0793. Archived from the original on 16 October 2022. Retrieved 12 October 2022.
  2. ^ Rezaeian, Banafsheh. "Simulation and Verification Methodology of Mixed Signal Automotive ICs". CiteSeerX
  3. ^ Stroud, Charles E; Change, Yao-Chang (2009). "CHAPTER 1 – Introduction". Design Verification. pp. 1–38. doi:10.1016/B978-0-12-374364-0.50008-4. ISBN 978-0-12-374364-0. Archived from the original on 12 October 2022. Retrieved 11 October 2022. ((cite book)): |journal= ignored (help)