Home > Community > Blogs > System Design and Verification > verification hierarchy of needs
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the System Design and Verification blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Verification Hierarchy of Needs

Comments(0)Filed under: System Design and Verification, Verification planning and management, Run and Debug

Verification consultant Brian Bailey recently started blogging for Chip Design Magazine. One of his first posts was to define verification. He did a great job and I encourage people to read over what he wrote.

What you realize when you read his post is that verification is not directly related to two other topics that are often discussed as part of verification. These topics are important to verification, but are not verification. I call these topics Run and Debug.

I often meet with engineers to talk about system verification and almost always we spend much of the time discussing ways to execute the hardware design, ways to execute the software, and methods to debug the combination of hardware and software.

My conclusion is that there is a verification hierarchy of needs, and just like Maslow's hierarchy of needs there is a pyramid that represents the hierarchy. Also just like Maslow, the higher needs in this hierarchy only come into focus when the lower needs in the pyramid are satisfied. The verification hierarchy of needs is Run, Debug, and Verify.

 

 Engineers say things like:

  • My simulator is too slow to execute enough cycles to run meaningful software
  • How can I boot my operating system in a shorter time?
  • Fitting the hardware design into a set of FPGAs on a board is complicated and debugging visibility is poor
  • It is possible to correlate the software debugger with what is happening in the hardware?
  • I want to use abstract models of my design to run embedded software, but I'm missing models and I don't have time to create them

I'm sure many of you are struggling with similar questions and have figured out some ways to overcome the Run and Debug issues in your projects. Even if you have achieved the needs of Run and Debug, remember from Brian's post that verification is about metrics (and preferably using as much automation as possible to gather and analyze those metrics).  

Before you can Verify anything, you need to be able to Debug it. Before you Debug anything you need to be able to Run it.

Remember, Run != Verify

Feel free to share ways you have overcome issues with Run and Debug, and better yet share ways you have automated the gathering of verification metrics to reach the Verify level of the pyramid, especially at the system level where performance and visibility can be real challenges.

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
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.