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

  • Good responses.

    I'd like to add that my fist observation is that design is "bounded" while verification is "unbounded".

    To explain: When a designer has implemented the logic defined in the specification, he is "done" designing. He can improve the code, add comments etc. But aside from bug fixes (which can be considered part of verification) his job is done.

    In verification, there are always more things which could be done.. The space in infinite and the methods are multiple so you can always do more verification.

    Have you defined all possible functional coverage? Have you added in all the assertions possible? Have you achieved all the functional coverage? Have you achieved all of the structural/code coverage? Have you written all the performance tests? Have you verified it with formal verification? Have you run it with other blocks? At the system level? on an FPGA? With the production software? With other components? Etc.

    The amazing thing is that you can continually find additional bugs (for a reasonably sized design). There is a point of diminishing returns, meaning the bugs found would never manifest, never be noticed, or never cared about at a level above.  

    Since this forum will discuss verification planning, I think that one of the most important aspects in verification planning is "bounding" the verification process at the onset. This means that we should decide what are our absolute requirements (vis-à-vis coverage and checking) and plan based on those requirements.  The earlier this is done in the process, and the more open this process is, the better the verification plan will be.

                                                            Akiva


    Originally posted in cdnusers.org by Akiva
Reply

  • Good responses.

    I'd like to add that my fist observation is that design is "bounded" while verification is "unbounded".

    To explain: When a designer has implemented the logic defined in the specification, he is "done" designing. He can improve the code, add comments etc. But aside from bug fixes (which can be considered part of verification) his job is done.

    In verification, there are always more things which could be done.. The space in infinite and the methods are multiple so you can always do more verification.

    Have you defined all possible functional coverage? Have you added in all the assertions possible? Have you achieved all the functional coverage? Have you achieved all of the structural/code coverage? Have you written all the performance tests? Have you verified it with formal verification? Have you run it with other blocks? At the system level? on an FPGA? With the production software? With other components? Etc.

    The amazing thing is that you can continually find additional bugs (for a reasonably sized design). There is a point of diminishing returns, meaning the bugs found would never manifest, never be noticed, or never cared about at a level above.  

    Since this forum will discuss verification planning, I think that one of the most important aspects in verification planning is "bounding" the verification process at the onset. This means that we should decide what are our absolute requirements (vis-à-vis coverage and checking) and plan based on those requirements.  The earlier this is done in the process, and the more open this process is, the better the verification plan will be.

                                                            Akiva


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