principle of functional verification 读书笔记

 

Definitions

types of model

抽象级

1. behavior model

   不需要时序信息，不需要错误或异常处理能力，目标很明确：检查设计的基本功能，在系统中和其他设备的交互行为，多为算法。而算法可由现成的

 

软件提供，或者其他语言实现。当需要提供cycle-level的时序信息时，可小心的加入和implementation一致的delay cycle。

 

2. RTL model

 

3. Gate level model

 

可见性

1. Black box model

   验证的是设计的意图，而不是实现的方式。各个level都能复用。将设计和验证分开. 

 

2. White box model

 

3. grey box  model 

   通常大部分用black box model，而对一些Design的关键点也会用white box 方式去check

 

Methods for Determining the Validity of model

stimulus generation method

      1. vector generation

       在clock的边沿给各个input直接赋值，并捕获output和result文件比较。有波形工具可以根据波形生成激励。

 

      2. Stimulus capture

       类似于ATPC，同时抽取已有golden design的input output，分别作为激励和result。

 

      3. Transactions

 

      4. Assertions

         dynamic assertions: need dynamic simulation and relies on stimulus to be generated

         static assertions: formal tools, use mathematical model of the design to find is there any possible

         scenarios to violate the assertion. 适用于block level，无法用于多个block构成的系统。

 

result Analysis Method

      1. Eyeballing

      初次仿真，以及debug

 

      2. Golden files

      如何产生golden files： previous simulation， beforehand; 适用于有refernece model的情况

 

      3. Assertions（automated result Analysis）

 

      self checking assertions， 适用于小block，但对于复杂的设备或设备来讲（exception，interrupt，error，queueing）

      仅仅靠assertion显得有些力不从,复杂的sequence很难定义出一个完备的相应的assertion集。心，assertion的结构以及层次

      也愈发重要

 

      4. protocol Monitors

      report protocol violation; collect statistics(operation, error, timeout 频率以及条件） on particular bus to do

      performace analysis

 

      5. Predictors： 解决assertion能力的问题

          1)cycle-accurate reference model：建立这种model会费时费力

          2)behavior（architectural）reference model : 仅仅给出output，但不给出出现时间和operation的顺序。

             cache 以及 queue都会导致 behavior model 和 design的operation order不同。所以比较结果时要充分考虑这些情况

 

     6. self-checking Tests

        在testcase中设计好self-checking方法    

 

 

Structure and Reuse Functional Verification

Transactor Structure

  Transactor interface

      standard protocol interface (with DUT)

      test API(with tests)

 

   Parallelism of tests

          1) Combination of Tests Mimics Actual traffic : multistream, 模仿操作系统中multi-processes的概念， tests do not

               share resources

 

 

 

          2) Simplify Test writing : write a test for each individual sequence and mix those tests together by interleaving

              or arbitration algorithm

 

          3) multiple transactors

 

          4) highly parallel environment

 

database of transaction

        将transaction的信息存到某个地方待过后进行分析这个过程叫做scoreboarding. database中应该包含transaction的时间，数据，response，response的来源，status 以及error conditions。

        database of transaction有利于debug，有利于性能分析。性能分析一般有以下几个方面：

            1） throughput   每秒执行几个transaction

            2） 总线使用效率即占有率

            3） 仲裁的公平性

            4） 各种latency，如CPU到memory的lantency

 

structure in data streams

 

 

$Random Test

 

 

 

$Co-simulation

 

 

 

$Measuring Verification Quality

 

 

 

 

$Verification Plan

 

 

 

 

$Applying Functional Verification