Stats

  • Locked Locked
  • Replies 8
  • Subscribers 64
  • Views 15865
  • 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

In what aspects is verification different from design?

archive

Hi,
            I will be co-moderating this board together with Stylianos, a formal introduction will come sometime later.
 
            It appears to me that recently there has been a significant interest in designing new methods for verification planning. Classic methods of planning have been known to result in late releases (in some projects multiple months late) and unpredictable quality.
 
            I believe this forum could become a catalyst to understanding the underlying problem we are trying to solve, and to both discuss and shape the solutions that are taking form.
 
            To trigger some discussion, I want to pose a simple question: In what ways is Verification different from Design? (ways which might affect planning)
 
            I believe if we clarify this question, we can better understand why some of the classic methods fail with verification.
 
            Looking forward to your responses,
 
                                                            Akiva


Originally posted in cdnusers.org by Akiva
Parents

  • Verification requires engineers to worry about two big areas:
    1) Verify implementation meets specification - usually normal mode behavior is specified - This task is complex given engineers take a fairly narrow sample of the design space to verify what they perceive are representative scenarios that encompass the entire design space.
    2) Everything that falls out of what is specified, error scenarios and their temporal aspects, are handled in a graceful way without bringing down the system - This can be an order of magnitude more complex task as the permutations become infinite.
    While designers are wrestling with meeting timing budgets, reducing power and area to push integration limits, verifyers are dealing with modeling the world around the design to verify it as thoroughly as possible, often with same or fewer human resources. This leaves verifyers no choice but to innovate and automate or risk product quality.

    A key factor at play is reuse. Maturing IP reuse cultures are making the verifyers job appear more time consuming as a percentage of total "design time". This usually means more pressure on the verification team to get the job done faster. Sophisticated verification teams are addressing this by investing in reusable Verification IP and verification plan reuse to keep pace with front-end design. This allows them to devote as much time to defining key scenarios/interactions and refining the verification plan vs. spending months of time developing verification IP for a project.



    Originally posted in cdnusers.org by umer
Reply

  • Verification requires engineers to worry about two big areas:
    1) Verify implementation meets specification - usually normal mode behavior is specified - This task is complex given engineers take a fairly narrow sample of the design space to verify what they perceive are representative scenarios that encompass the entire design space.
    2) Everything that falls out of what is specified, error scenarios and their temporal aspects, are handled in a graceful way without bringing down the system - This can be an order of magnitude more complex task as the permutations become infinite.
    While designers are wrestling with meeting timing budgets, reducing power and area to push integration limits, verifyers are dealing with modeling the world around the design to verify it as thoroughly as possible, often with same or fewer human resources. This leaves verifyers no choice but to innovate and automate or risk product quality.

    A key factor at play is reuse. Maturing IP reuse cultures are making the verifyers job appear more time consuming as a percentage of total "design time". This usually means more pressure on the verification team to get the job done faster. Sophisticated verification teams are addressing this by investing in reusable Verification IP and verification plan reuse to keep pace with front-end design. This allows them to devote as much time to defining key scenarios/interactions and refining the verification plan vs. spending months of time developing verification IP for a project.



    Originally posted in cdnusers.org by umer
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.