| dbo:abstract
|
- In electronic design automation, functional verification is the task of verifying that the logic design conforms to specification. Functional verification attempts to answer the question "Does this proposed design do what is intended?" This is a complex task, and takes the majority of time and effort 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. 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:
* Logic simulation simulates the logic before it is built.
* Simulation acceleration applies special purpose hardware to the logic simulation problem.
* Emulation builds a version of system using programmable logic. This is expensive, and still much slower than the real hardware, but orders of magnitude faster than simulation. It can be used, for example, to boot the operating system on a processor.
* Formal verification attempts to prove mathematically that certain requirements (also expressed formally) are met, or that certain undesired behaviors (such as deadlock) cannot occur.
* Intelligent verification uses automation to adapt the testbench to changes in the register transfer level code.
* HDL-specific versions of lint, and other heuristics, are used to find common problems. 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:
* The generator generates input vectors that are used to search for anomalies that exist between the intent (specifications) and the implementation (HDL Code). This type of generator utilizes an NP-complete type of SAT Solver that can be computationally expensive. Other types of generators include manually created vectors, Graph-Based generators (GBMs) proprietary generators. Modern generators create directed-random and random stimuli that are statistically driven to verify random parts of the design. The randomness is important to achieve a high distribution over the huge space of the available input stimuli. To this end, users of these generators intentionally under-specify the requirements for the generated tests. It is the role of the generator to randomly fill this gap. This mechanism allows the generator to create inputs that reveal bugs not being searched for directly by the user. Generators also bias the stimuli toward design corner cases to further stress the logic. Biasing and randomness serve different goals and there are tradeoffs between them, hence different generators have a different mix of these characteristics. Since the input for the design must be valid (legal) and many targets (such as biasing) should be maintained, many generators use the constraint satisfaction problem (CSP) technique to solve the complex testing requirements. The legality of the design inputs and the biasing arsenal are modeled. The model-based generators use this model to produce the correct stimuli for the target design.
* The drivers translate the stimuli produced by the generator into the actual inputs for the design under verification. Generators create inputs at a high level of abstraction, namely, as transactions or assembly language. The drivers convert this input into actual design inputs as defined in the specification of the design's interface.
* The simulator produces the outputs of the design, based on the design's current state (the state of the flip-flops) and the injected inputs. The simulator has a description of the design net-list. This description is created by synthesizing the HDL to a low gate level net-list.
* The monitor converts the state of the design and its outputs to a transaction abstraction level so it can be stored in a 'score-boards' database to be checked later on.
* The checker validates that the contents of the 'score-boards' are legal. There are cases where the generator creates expected results, in addition to the inputs. In these cases, the checker must validate that the actual results match the expected ones.
* The arbitration manager manages all the above components together. 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?). (en)
- 功能验证（英語：functional verification），是电子设计自动化中验证数字电路是否与预定规范功能相符的一个验证过程，通常所说的功能验证、功能仿真是指不考虑实际器件的延迟时间，只考虑逻辑功能的一个流程。功能验证的目标是达到尽可能高的测试覆盖率，被测试的内容要尽可能覆盖所有的语句、逻辑分支、条件、路径、触发、状态机的状态等，同时在某些阶段还必须包括对时序的检查。在较小型的电路设计中，设计人员可以利用硬件描述语言来建立测试平台（通常这是一个顶级模块），通过指定测试向量来检验被测模块在各种输入情况下，检验对应的输出是符合要求。但是，在更大型集成电路设计项目中，该过程会耗费设计人员较大的时间和精力。许多项目都采用计算机辅助工程工具来协助验证人员创建随机测试激励向量。其中，硬件验证语言在建立随机测试和功能覆盖方面具有显著的优势，它们通常提供了专门用来进行功能覆盖和产生可约束随机测试激励向量的数据结构。除了上面讲述的这种通过输入测试向量的方式，功能验证还可以通过形式等效性检查（形式验证）、断言等方式来进行，达到更高的功能覆盖率。 (zh)
|
| rdfs:comment
|
- 功能验证（英語：functional verification），是电子设计自动化中验证数字电路是否与预定规范功能相符的一个验证过程，通常所说的功能验证、功能仿真是指不考虑实际器件的延迟时间，只考虑逻辑功能的一个流程。功能验证的目标是达到尽可能高的测试覆盖率，被测试的内容要尽可能覆盖所有的语句、逻辑分支、条件、路径、触发、状态机的状态等，同时在某些阶段还必须包括对时序的检查。在较小型的电路设计中，设计人员可以利用硬件描述语言来建立测试平台（通常这是一个顶级模块），通过指定测试向量来检验被测模块在各种输入情况下，检验对应的输出是符合要求。但是，在更大型集成电路设计项目中，该过程会耗费设计人员较大的时间和精力。许多项目都采用计算机辅助工程工具来协助验证人员创建随机测试激励向量。其中，硬件验证语言在建立随机测试和功能覆盖方面具有显著的优势，它们通常提供了专门用来进行功能覆盖和产生可约束随机测试激励向量的数据结构。除了上面讲述的这种通过输入测试向量的方式，功能验证还可以通过形式等效性检查（形式验证）、断言等方式来进行，达到更高的功能覆盖率。 (zh)
- In electronic design automation, functional verification is the task of verifying that the logic design conforms to specification. Functional verification attempts to answer the question "Does this proposed design do what is intended?" This is a complex task, and takes the majority of time and effort 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. (en)
|
