Test Bench:

• generating the inputs, driving those inputs to the design and checking the expected values with actual values.

when we will conclude our verification was done?

• whenever we got 100% coverage and 100% assertion based verification, we will conclude that our verification was done.

Coverage

• it tells about that all the possibilities will be covered or not

• coverage can be classified into two types

  1. Functional coverage

  2. code coverage

Functional coverage:

• • functional coverage will deals with the test bench

    * functional coverage will provide the coverage for test bench input signals.

    * functional coverage will provide the coverage for transaction class signals.

code coverage:

• • code coverage will deals with design

    * code coverage will provide each every part of the design will be covered or not.

    * code coverage will provide the coverage for FCBEST

    1. F means FSM coverage

    2. C means CONDITIONAL coverage

    3. B means BRANCH coverage

    4. E means EXPRESSION coverage

    5. S means STATMENT coverage

    6. T means TOGGLE coverage

• How to get the transactions into coverage

  • monitor will collect the signals from the interface, it will make those signals into transactions, it will send those transactions to the coverage through mailbox.

  • coverage will get data from the mailbox and it will check all the possibilities will be happened or not

Steps to do code coverage

Here some things we have to do:

• generating coverage report for each test case

  Tools→coverage report→HTML→click on the check box(source code,all coverage)

• ucdb files gets creat for each test case merge that all ucdb files:

  vcover merge -out merged.ucdb file1.ucdb file2.ucdb file3.ucdb

• do exclusions:

  files→open.ucdb extension->select the ucdb file→open analysis tab→right click on signal we need to do exclusive the selection.

functional coverage Hierarchy?

• 1. cover group

     • it is a group of features.

       syntax:

       covergroup <covergroup_name>;

       // feature1;

       // feature2;

       ………..

       endgroup

     2. cover point

        • it is a group of possibilities to the particular feature

          syntax:

          cover point <coverpoint_name>;

          // possibility1;

          // possibility2;

          ………..

          endgroup

     3. bins

        • it is also known possibility of the feature.

          syntax:

          bins <bin_name>={value or range};

• complete functional coverage Hierarchy?

  covergroup covergroup_name;

  coverpoint <coverpoint_name1>{

  bins <bin_name1> = {value or range};

  bins <bin_name2> = {value or range};

  bins <bin_name3> = {value or range};

  }

  coverpoint <coverpoint_name2>{

  bins <bin_name1> = {value or range};

  bins <bin_name2> = {value or range};

  bins <bin_name3> = {value or range};

  }

  coverpoint <coverpoint_name1>{

  bins <bin_name1> = {value or range};

  bins <bin_name2> = {value or range};

  bins <bin_name3> = {value or range};

  }

  endgroup

functional coverage filter:

let us consider we are devloping one complex project, that complex project will be devloped by using some sub blocks, if i develop a covergroup for that complex project it will provide the coverage for all the blocks, so if i want to taget sub blocks means we need to consider functional coverage filter called “iff”

syntax:

• covergroup covergroup_name;

  coverpoint1 iff(condition1){

  bins <bin_name1> = {value or range};

  bins <bin_name2> = {value or range};

  bins <bin_name3> = {value or range};

  }

  coverpoint2 iff(condition2){

  bins <bin_name1> = {value or range};

  bins <bin_name2> = {value or range};

  bins <bin_name3> = {value or range};

  }

  coverpoint3 iff(condition1){

  bins <bin_name1> = {value or range};

  bins <bin_name2> = {value or range};

  bins <bin_name3> = {value or range};

  }

  endgroup

Example coverage for iff filter

you should know these topics related to coverage

• types of bins

  bin: the actual possibilities of the feature. The bins are involved in the percentage calculation.

  we have 3 types of of bins

  1. normal bins

  2. ignore bins: there is a chance of the possibilities happening, but we ignore those possibilities.

     syntax: ignore_bins <bin_name> = <value or range>;

  3. illegal bins: these are the illegal possibilities of the feature, and they are not involved in the percentage calculations.

     syntax: illegal_bins <bin_name>=<value or range>;

• types of bins creations

  we have 3 types of bins creation

  1. implicit bins creation: In implicit bin creation, we do not need to create the bins explicitly. Based on the size of the signal, it will create the bins automatically.

     • it will create maximum of 64 bins.

     • If the signal has more than 64 possibilities, it will arrange all the possibilities into those 64 bins.

       [note: for my understanding i am writing this,there are 3 ways we can give tx to the cov

       1. randomizing the tx inside the cov class

       2. randomizing data in module or other class(gen) and accessing through mailbox (which i was preferred)

       3. randomizing the data in module tb or other class(gen) and shallow copy from tx to cov object ,passing argument tx in new function in cov class.]

  2. explicit bins creation: in explicit bins creation we need to create the bins explicitly.

     • for creating the explicit, we need to consider the bins names as:

       1. singular variable

       2. static array

          • for creating the bins we can consider as static array

            syntax: bins bin_name [<size>] = {value or range};

            ex: bins arr_s = {[0:255]};

       3. dynamic array

          • for creating the bins we can consider dynamic array

            syntax: bins bin_name [] = {[0:255]};

            note: we can create n no.of bins based on our size.

       4. array with condition

          • for creating the bins we can consider dynamic array

          • we need to consider “with“ clause.

            syntax: bins <bin_name> [] = {value or range} with (condition);

  3. by using option

     • in coverage we have some options, so for creating the bins we have the option will be.

       syntax: option.auto_bin_max = <value>;

     • Based on that value, it creates that many bins. If the bit size is more, the remaining possibilities are adjusted into those number of bins.

• instance coverage

  its just a instance of cover group

• where in real projects, do we use instance coverage?

  • Design with multiple interface of same protocol type.

    • Ex: Design having 3 APB interfaces

  • To implement same cover group for all 3 interfaces, use instance coverage.

  • Guidelines to follow while implementing instance coverage

    • Covergroup definition should be in global scope, not in the class

  • Task run should be implemented such that, user decides which covergroup to sample.

  • what are the advantages of instance coverage

    • User don’t have to duplicate covergroup coding

    • Number of lines is reduced.

• Transition coverage

  • it is used to tell the state transitions are happened or not.

  • we will mostly used this transition coverage in FSM.

  • in transition coverage state transitions can be represented as “\=>”

• Cross coverage

  • it will perform the cross product of two coverpoints.

  • for perform the cross coverage we need to consider a keyword called “cross”

    

  • in cross coverage we have 2 filters

    • binsof

      it will filter the bins basing on the bin name.

      syntax: bins <bin_name> = binsof (<name>)

      

    • binsof intersect

      it will filter the bins basing on the bin values.

      syntax: bins <bin_name> = binsof (<coverpoint_name>) intersect {<range>};

Options in Coverage

1. weight : it will provide the weightage to the coverpoints. basing on the weightage it will caluclate coverage percentage

   total coverage %= (%cp1*w1)+(%cp2*w2)+……/w1+w2+…..

   syntax : option.weight= <value>;

2. name : this option is used to provide the name to covergroup

   syntax : option.name = <name>;

3. comment : this option is used to pass any comments regarding the coverpoints

   syntax: option.comment = “comments“;

4. goal : it is used to represent the colour coding

   RED- 0 to 50, Yellow- 51 to 90, Green- 90

   for modifying the colour coding we need to consider this goal option

   syntax : option.goal=<value>;

5. per_instance : this option is used to create the instance for the covergroup.

   syntax : option.per_instance = <0 or 1>;

6. atleast : this option will tells about how many times the bin need to be hit

   syntax : option.at_least=<value>

7. detect_overlap : if any overlapping will be happened b/w the bins this option will detect that overlapping

   syntax : option.detect_overlap = 1;

8. auto_bin_max :

   • In SystemVerilog covergroups, when you define a coverpoint with a range of values, the simulator automatically creates bins to track coverage.
     Sometimes the range is large, and creating a bin for every possible value would be inefficient.

   • auto_bin_max:
     It is a covergroup option that specifies the maximum number of automatically created bins for a coverpoint

     syntax : option.auto_bin_max = <value>