• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Functional Verification
  3. Multiple instantiations of vPlans

Stats

  • Locked Locked
  • Replies 2
  • Subscribers 64
  • Views 13722
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Multiple instantiations of vPlans

archive
archive over 19 years ago

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.


Originally posted in cdnusers.org by stelix
  • Cancel
Parents
  • archive
    archive over 19 years ago

    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?


    Originally posted in cdnusers.org by stelix
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • archive
    archive over 19 years ago

    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?


    Originally posted in cdnusers.org by stelix
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information