SV Part-9 Test-Bench Architecture

Functional Verification:

what is functional verification :

• process of validating the design functionality (RTL code) against design specification.

Functional verification engineer:

• Catching Functional issues(design issues)

• 2 inputs :

  • Design specification(spec we called)

  • RTL Code

    • Developed by Design engineer, Integration engineer

  • Verification engineer develops Test bench to make the functional verification more process oriented.

Types of functional issues

• Bugs due to wrong understanding of the design specification.

• Bugs due to wrong coding(coding mistakes)

why Simulators are required:

• As per of verification, verification engineer develops and simulates the testcases. For this we require simulator.

Functional verification-driving factors

Catch all the bugs in RTL Code

• Less time in setting up Test bench

• More time in developing test cases and debugging those testcases

  • Verilog → SV → UVM

DUT-Ethernet MAC

• Verilog for verification - 6months

• SV for verification - 4.5 months

• UVM for verification - 3.5 to 4 months

For simple designs like memory, Asynchronous FIFO

• Verilog based verification will get over quickly. We will not see real benefit of SV.

• Complex design verification is where we can see benefit of using SV.

Why don’t we develop entire TB in a single class or single file?

• Test bench is developed for modularity and reusability.

Modularity:

• Concept of dividing Test bench into various sub components based on functions they are supposed to do.

• Ex: Scenario generation (generating tx)is done using generator,

• Scenario driving is done using BFM (Bus Functional Model).

• monitoring is done by monitor.

Dividing Test bench functionality in to different components ensures reusability of these components across different Test benches, like objects we are using.

So compared to Verilog it’s better for TB development :

modularity, reusability, readability, and easy to debug.

So SV has:

1. New data types

2. New Operators

3. Arrays-Dynamic, Queue, mailbox

4. Inter process syncronization constyructs

5. Object oriented programming

6. Functional and Code Coverage

7. Assertions

8. Interface, Program, Clocking blocks

9. modports

SV TB for Examples:

Note: These are not projects, they just show the SV TB development, actually.

Interface

it is a System Verilog construct, which is used to connect the class and module.

• interface is almost similar to module.

• The interface is static in nature. Like a module, if we create an instance of the interface, memory allocation will happen automatically.

interface <interface_name> (input port list name);
  //signals name
  //clocking blocks
  // assertions
endinterface

Similarities with module:

• in interface we can consider port list like module.

• In an interface, we can use initial blocks, tasks, functions, and declare ports.

Differences with module:

• we can consider only input port list in the interface

• we can pass interface as port to the other module or an argument to the task and function which is not possible with the module. like through virtual

  • Physical interface

    • interface which having the the physical appearance is known as physical interface.

    • we don’t need to allocate memory for the physical interface.

  • Virtual interface (virtual keyword)

    • interface which does not have the physical appearance is known as virtual interface.

    • we need to point or assign physical interface memory for the virtual interface memory.

    • virtual interface having the capability of accessing the physical interface memory.

// data driving from bfm to dut through interface is happend automatically, so some sampling issues will be happend while driving the data. to avoid that sampling issue we need to consider clocking blocks.

clocking blocks

• it is a system verilog construct used in interface

• clocking are used to avoid the sampling issues happend while driving the data from bfm to dut through interface.

• skew

  • skew is used to delay the data.

    1. input skew : it tells about that at what time we need to sample the data before posedge clk.

    2. output skew : it tells about that at what time we need to sample the data after posedge clk.

clocking <clocking_block_name> <clocking_event>
  default input #<delay> output #<delay>
  input signal1;
  input signal2;
  .......
  output signal1;
  output signal2;
  .......
endclocking

Mod Ports

• mod port also known as module ports

• mod ports will tell about the directions of the signals to a particular block.

• mod ports can be coded in interface.

  syntax:

  modport modport_name(

  <input> signal1,

  <input>signal2,

  <input>signal3,

  ………………….,

  <output>signal1,

  <output>signal2,

  <output>signal3,

  ……………………..,

  );

• steps i followed for during my memory project writing the modports.

  1. Interface(physical interface) is connected the design

     • writing the input and output signals in interface(sizes will taker on compiler directives).

       

     • and then writing <interface_name>.<that_design_name_mp> <instance_name> in ( ).

       

     • instantiation dut in tb or top, design_name <instance_name>(pif.<design_name_mp>)

       

  2. extra things, interface(virtual interface) will connect with the BFM & Monitor

     1. with clocking blocks i considered so no need to consider writing all the ports names insted we already declared inputs and outputs in clocking blocks so, Just write

        modport bfm_mp(

        clocking bfm_cb

        );

        

     2. same as for monitor

        modport mon_mp(

        clocking mon_cb

        );

        

Thank you,

Shaik Mahammad Hussain,

7671947173, mahammadhussainshaik54@gmail.com