Search code examples
system-verilogverificationuvm

Explain verification of a DUT in interview

I am attending an interview tomorrow and I have been asked this question in almost every interview I have attended.

Given a DUT + specification, how do you verify?

Could someone briefly explain me how I should start answering this question? What all should I consider (Testplan first with priorities, Testbench environment, coverage etc) ?

NOTE: Answer doesn't have to be specific to this DUT. I want overall picture of how to explain this.

Thanks in advance

Solution

  • Obviously there are many ways (and many views) on How to go about verifying a DUT .

    This is just one the many views. Even though there is an order some of the steps can change or they can even be merged or even skipped based on the design specific requirements.

    1. Study Specification ( obviously )
    2. Gather testing requirements. a. High-level - Block Size, possible users of the TB , outputs needed , types of input to the TB
      b. Low-level/Details - specific debuging requirements,
    3. Develop Top-Level TB architecture document.
    4. Develop top-level test plan.
    5. Top-level test plan can be converted into or a detailed test plan can be developed.
    6. Develop or derive a functional coverage excel sheet. [ most simulators will support tracking such a sheet]
    7. Derive a random control variable list and range/constraint for the variables. [ optional ]
    8. Low-level TB document - describes specify drivers, agents, interfaces.
    9. Develop a schedule based on the above inputs - complexity of design and tb. [ this step itself can happen in parts]
    10. Start script development - for run and regression etc. .
    11. Develop and deploy test cases as per the test plan.
    12. Report/file bugs - monitor bug rate.
    13. Monitor and measure coverage - code and functional.
    14. Reach 100% coverage (ideally), but realistically some agreed upon target and 0 bug count (pipe dream)
    15. End Verification and Declare success

    Things to consider on the way

    1) 1) Is this a System-level, Full Chip, Block level verification environment or Is this an ASIC or an FPGA

    2) Based on the complexity how many levels of TB are required.

    e.g. many Block level -> few sub-system->single full-chip environment…

    3) Based on project duration and time to closure – do you need to support FPGA and /or emulation.

    4) Formal Verification – which blocks.

    5) Is there a requirement for co-simulation – from the software team. Do you need to use API from the software/architecture team?

    6) Is there requirement to generate vectors – tester vectors , bring up vectors .

    7) How do you want to check the test pass criteria?

    a. Model/scoreboards –

    i. Architecture Models

    ii. Transaction level Models ( more detailed from above )

    iii. Cycle accurate Models. (e.g. arbiters )

    b. Assertions – run time + formal

    8) Re-use consideration

    a. Sequences

    i. Init

    ii. Data/control

    b. Scoreboard

    c. Agents

    9) Debug Requirements

    a. Output formatting.

    b. Tools to monitor and extract information.

    10) Which Language, Simulator and tools best fit the requirements?