Stats

  • Locked Locked
  • Replies 3
  • Subscribers 65
  • Views 14731
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Components of System verilog VE

Leo1008

 Hi,

I am new to writing verifcation environments and so wanted some briefing about the same. I have written one simple VE uptill now wherein I used as components an object, a generator, a driver, DUT, an output monitor, a scoreboard and an interface. I wrote a program block for the testbench with instances of the object, driver( which was extended from the generator), interface, monitor and the scoreboard. But I understand that the testbench should ideally include instances of only the DUT, VIP/VE and the monitor/checker.

I am not sure what the VIP/VE block should contain. Also how to pass commands to all these components from the Test? 

It would be really nice if you could provide me with a sample env for reference.

  • Hi ,

    A TB essentially consists of the following

    1.DUT instance

    2.Clock generator for the DUT using always block or forever loop statement

    3.Reset generation mechanism

    4.Local wires and reg declaration to drive clock ,reset and connect the DUT to the testbench since the testcase instantiates the TB and the medium to access the DUT is through the TB

    5.Monitors,scoreboards and Coverage modulkes can be optional yet recommended

    So fundamentally a SV testbench comprises of

    1.A class that defines the data object which can model an ethernet packet /ATM cell / processor instruction/register transaction

    2.A Generator that randomizes this data structure and sends it to the transactor which may contain functionality such as prioritizing the data as per 'some' specific field in the data

    3.Further down you have the driver which is a BFM essentially and it connects to the DUT at signal level,it translates and drives the high level data structure onto the DUT inputs,for e.g you have a high level register transaction then it must be converted to a write request ,send address and send data to the DUT .

    4.You then have a monitor that monitors the dut output signals and it is essentially forchecking protocol violations.

    5.The monitor integrates the dut output at signal level and integrates it to form a high level data object that was originally sent ,this goes toscoreboard where the input data and output data are checked.Usually monitor also implements the transfer function required for comparing the DUT output and input ,thus eliminating need of a scoreboard.

    6.Assertions are a part of monitor and are used for checking protocol violations such as read and write request should never be true simultaneously ,fifo full and empty conditions must occur atleast once to check if FIFO has been fully exercised.

    7.The DUT instance and connections to the TB module through interface.

    You may refer to www.testbench.in for more details.

     

    Regards,

    Pooja Vaishnav

  • Pooja was very thorough in his explanation of all the components. This is basically what OVM gives you is the base class library to construct all of those object AND the methodology to put them together in a way that makes it highly reusable from project to project and block to chip.

    You can find out more about OVM at http://ovmworld.org.

    Tim

  • Hey Pooja,

    Thanks a lot for the detailed explanation. 

    And the link you provided, www.testbench.in, was really helpful :)

    Insiya

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.