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

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