Multiple instantiations of vPlans > Forums

Unanswered

Active Topics

Forums

Forums > Functional Verification > Verification Planning

Subject: Multiple instantiations of vPlans

Posting to forums is available to community members only.
Login or Register

Rate this topic:

Author

Messages

stelix
Moderator
Posts: 14
Online: User is Offline

3/19/2006 2:47 AM
Hi there planners, 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 . 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. 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? Cheers, -Stylianos.

Stylianos Diamantidis Verification Zone Moderator CDNusers.org

andy
Posts: 0
Online: User is Offline

3/27/2006 9:43 AM
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

stelix
Moderator
Posts: 14
Online: User is Offline

4/08/2006 7:57 AM
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?

Stylianos Diamantidis Verification Zone Moderator CDNusers.org

Posting to forums is available to community members only.
Login or Register

Forums > Functional Verification > Verification Planning > Multiple instantiations of vPlans

ActiveForums 3.6