You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

Learning to Live with the Gaps Between Design and Verification

Whenever I am asked to explain how chip design works by someone who is unfamiliar with the process, I struggle to explain the different steps in the flow. It also makes me aware of the discrete separations between each phase of activities. Of course, when you speak to a novice it is not even possible to get more than one layer down in the explanation. For folks in in the industry we are painfully aware of the separate steps and partitions in the process. Not only does the design flow from high level front end representations through transformations to silicon transistors and geometry, there are also parallel processes that involve internal and external IP. Woven throughout this is the design verification process, which must work within each step of the process and also across the entire flow.

As designers, the first urge is to smooth over all the gaps and try to make them disappear. However, in a paper given by Mentor at DVCON in Silicon Valley this year they suggest acknowledging the gaps in the design flow and in some cases embracing them to improve the speed and effectiveness of the verification process. I had a chance to talk to Chris Giles, one of the coauthors of the paper along with Kurt Takara, on their view of the issue of gaps and his approach to dealing with them. Fortunately, in light of present-day circumstances, Mentor is offering a replay of the paper online for anyone interested in seeing its entire contents.

In their presentation they cover the main sources of gaps, such as documentation issues, models that are not accurate or incomplete, changes to any aspect of the project, organizational boundaries or team member skill sets. They point back to the time when RTL was first coming into use where designers would code the design and test benches in RTL sequentially. Without a gap between design and verification they would run these to verify the design. Of course, things are much different today with design teams and verification teams working as separate entities and using different tools for their jobs.

There is a stark choice to make. Do you throw the design over the wall and assume that the information needed to fully and properly verify the design intent and functionality made it through the gap? Or do you hope you have sufficient numbers of engineers that have expertise in design and verification to pull the project through? Chris spoke of taking this gap and embracing it by moving the intent verification into the design group and handing the functional verification to the verification team. Mentor tools play a role in this by ensuring that the tools each team would use are suited to the task and expertise of the users.

The presentation in the video goes into detail discussing which techniques are useful for various verification tasks by each prospective user. These include tools to help with code writing, static and formal lint tools, and CDC and RDC checkers. During the video Chris highlights each of these activities and how they might work when design gaps are used constructively.

Because all designs are hierarchical, verification flows need to not only work with hierarchy, but work to resolve issues that can arise due to the use of hierarchy. Mentor has worked out flows for hierarchical verification that work not only with black box views, but also use white box models to manage convergence issues efficiently and accurately. The presentation talks about their Hierarchical Data Model (HDM) for intent verification. The video also covers situations where designers need to handle intent verification, yet subsequent design transformations and optimization alter the design such that the intent is lost. This is a case where there is an unavoidable gap that must be acknowledged and dealt with. Chris and Kurt provide examples of how this can be done by applying specific techniques.

Verification is a huge topic with many facets. It is incumbent on engineering teams to understand potential sources of errors and methods of addressing them. Because gaps in the flow are unavoidable, being savvy about minimizing or taking advantage of them is a necessity. The video shows a range of specific cases and how they can be handled. Mentor is making the DVCON presentation available for viewing through the web. It goes into much more detail than is possible here and I strongly suggest checking it out.