Multiple instantiations of vPlans

Stylianos, you wrote:

> I was wondering if you guys and gals have encountered multiple instantiations of the same vPlan as part of a larger vPlan:

>     SoC vPlan
>       |
>       | -- > Core A vPlan
>       |           |
>       |           | -- >  DDR Controller
>       |
>       | -- > Core B vPlan
>       |           |
>       .           | -- >  DDR Controller
>       .

Absolutely.  With each verification component (ex. Core A and Core B eVCs), there is an associated verification plan.

> Obviously you would like to design a vPlan for the standalone DDR controller, use it for block-level verification, and then reuse it at the system level.  Also, you would develop some VIP that would be used to verify the controller standalone, and then be reused to verify integration of the controller at the (sub)system level.

I agree.

> So how do you do this?  The DDR vPlan will be associated with coverage items of the VIP, which do not include instance info when they are created.  Any ideas?

To date, the reuse of verification plans from block to system level has been more akin to a salvage operation.  That is, elements of each of the block level plans have been physically included in the system level plan with system level goals, weights and milestones.

With the upcoming Enterprise Manager 1.4 release (end of April), we are introducing a set of reuse features in the verification plan and tool that directly facilitate block-to-system plan reuse.  These include:

  * Parameterized verification plans
  * Per-instance plan section association
  * Plan refinement via an extensions file

They are implemented using new document styles and tables bundled in the verification templates for each of the supported word processors (MS Word, FrameMaker [structured and unstructured], OpenOffice.org and native XML).  Their use is illustrated in the sample verification plan packaged with Enterprise Manager.

Coming back to you example, in order to reuse the DDR controller verification plan without modification in the core A and core B verification plans, each of the core verification plans would include this vPlanReferenceTable near the beginning of the file:

    Core A Verification Plan
    ...
    Module Name    Verification Plan
    -----------    --------------------
    DDRctlr        /.../ddr_ctlr.xml

This associates the name "DDRctrl" with the verification plan file "/.../ddr_ctrl.xml."  Then, the DDR controller verification plan is instantiated in each of the core verification plans using a vPlanInstanceTable:

    Core A Verification Plan
    ...
    1  Functional Requirements
    1.1  DDR Functional Requirements
    ...
    Name      Path                         Parameters    Instance Match
    -----     --------------------------   ----------    --------------
    DDRctlr   DDRctrl::Verification Plan


    Core B Verification Plan
    ...
    1  Functional Requirements
    1.1  DDR Functional Requirements
    ...
    Name      Path                         Parameters    Instance Match
    -----     --------------------------   ----------    --------------
    DDRctlr   DDRctrl::Verification Plan

At the system level, the core A and core B verification plans would be included in the SoC verification plan in a similar fashion:

    SoC Verification Plan
    ...
    Module Name    Verification Plan
    -----------    --------------------
    CoreA          /.../core_a.xml
    CoreB          /.../core_b.xml
    ...
    1  Functional Requirements
    1.1  Core A Functional Requirements
    ...
    Name    Path                       Parameters    Instance Match
    -----   ------------------------   ----------    --------------
    CoreA   CoreA::Verification Plan
    ...
    1.2  Core B Functional Requirements
    ...
    Name    Path                       Parameters    Instance Match
    -----   ------------------------   ----------    --------------
    CoreB   CoreB::Verification Plan

The "Parameters" and "Instance Match" columns are only used when only subsections of the referenced plan or particular instances are used.

--
        Andrew Piziali, , +1-214-455-8577
        Skype andrew_piziali

Andy, you raise a variety of interesting issues!

I will start by concentrating on one of your comments:

> To date, the reuse of verification plans from block to system level has been
> more akin to a salvage operation.  That is, elements of each of the block
> level plans have been physically included in the system level plan with
> system level goals, weights and milestones.

Indeed this is very true. Cut-n-paste is a very common reuse practice ;-)
So when I reuse my DDRctrl vPlan to, say, the CoreA level vPlan, I may, or may not be interested in running the full plan. Why is that?

Well, my goals and weights could change depending on the application I am interested in. When I first design the DDRctrl, I really need to be very exhaustive. I may need to include a variety of metrics, like code coverage or formal model coverage. Now, when I instantiate my DDRctrl block several times and integrate it into my CoreA and CoreB designs, I want to select certain aspects of the vPlan, most likely the ones that pertain to interfacing with the core logic rather than the memory. I may not want to include formal model coverage anymore, since I am not running formal at the (sub)system level. I may want to combine such coverage with, say, software coverage. And so on.

In your opinion, who should be responsible for vPlan reuse in an engineering team? What are some good practices that a verification specialist, in charge of compiling a block-level vPlan, needs to apply to ensure reuse at the (sub)system level?