Category: Functional Verification – Planning

About the planning phase of functional verification.

  • Planning – Tasks lists

    Tasks lists, detailed tasks lists are anchors for the development phase. A good tasks lists provides the more accurate forecasts of the development phase schedules.

    The criteria to have start listing tasks is to put in place:

    With these two documents in hand, its time to build a detailed task lists. Simple benchmark for granularity of tasks should be maximum man days. Maximum man days per task should not exceed 3 man days. Ideal granularity should be task lists of 1 man day. Create as detailed tasks lists as possible. These are as important as the verification plan and architecture. Good detailed task lists is half the job done.

    Task lists should contain:

    • Each test should be part of the task list. Each test will have to be tracked for written and compiling, all unique variants of the test passing and seeded run for the test variants passing
    • Every check coding, infrastructure needed around the check for its implementation and verifying the check working should be part of the tasks lists
    • Each functional group coding, compiling, integration and sanity check of the integration should be items in tasks lists
    • For each test bench component development or enhancement, tasks with class or algorithm details should be added
    • Tool flow, regression flows and any automation requirement tasks should be made part of the tasks lists
    • Each task should be given priority and estimated man days

    Sum total of all the man days  of all tasks would be total minimum duration required. A simple division this total man days with the number of engineers available for the implementation would provide the initial insights into the times lines by which verification project can be completed.
    (more…)

  • Verification plans – 3 Plans

    Verification plan is process of translating the verification requirement specifications into verifiable description.  A verifiable description has to be aligned to technology being used for the verification. This alignment helps improve the chances of success.

    Verification plan is one of the key deliverables of the functional verification. Starting verification without good verification plan is strict no. Test bench architecture is dependent on the verification plan. So cutting corners on creating verification plan will directly affect testbench architecture and that will impact the functional verification quality.

    One of the current popular approach to functional verificaiton is coverage driven constrained random verification. Verification plan aligned to this approach is primarily driven by three plans: Test plan, coverage plan and checks plan.

    Fundamentally functional verification is about two things. First one is stimulus generation. Second is doing the response checks. In the constrained random verification approach, there is uncertainty about stimulus generated. Hence there is third dimension of functional coverage  to confirm indeed all interesting scenarios have been generated.
    (more…)

  • Verification Planning : Anchor for execution

    “In preparing for battle, I have always found that plans are useless, but planning is indispensable.”

    –General Dwight D. Eisenhower

    A perfect planning is, planning done once and executed to completion successfully without any change. Honestly, It does not exist. We are in times, where projects are three months behind the schedule on the day one. First day of project awaits critical item requiring delivery end of the day.  That’s reality of the modern projects. End of day(EOD) and as soon as possible(ASAP) are the only schedules.

    Can we break this cycle? Yes, but (yes there is always a but for such questions) not completely. Best we can hope is to minimize EOD and ASAP scenarios. Schedule is madness. Mad schedules are fine as long as there is method to madness. Here is an attempt to put that method to this madness.

    Get clear understanding of verification requirements. Create detailed technical plans first before getting into creating schedules and doing resource requirements evaluations. Schedules and resource allocation should be based on technical plan.  Jumping in directly into it creates inaccurate forecast for both schedules and resources.

    A technical plan is two key sub-items a verification plan and test bench architecture specification.

     

    Verification planning flow
    Verification planning flow

    Read about the details of each of the steps of the planning in the links pointed below.

    Key to success, while creating the initial technical plans is to forget about the deadlines and resources. Technical plans and execution are two different activities. These should not be mixed with each other. One should follow “dream big, execute small” philosophy.

    Theoretically enumerate all the requirements assuming infinite time and resources. Execution of the same can be driven by priorities and resources later. Cutting corners in creating technical plans will keep project execution on toes all the time for very long time. Any time saved by cutting corners is not really worth it. Thinking does not really take as much time as execution takes. There is always option to prioritize items later.

    All the plans be it test plan, checks plan, coverage plan or tasks lists should be capable of adapting to dynamically changing requirements and allow the effective teamwork anchored around them.