IP/SoC Verification With Assertions

There’s been a lot of excitement here in Silicon Valley these past weeks with the opening of the new 49ers stadium. I’ve always found it amazing to see how so many complex, fundamentally different technologies — mechanical, electrical, HVAC, plumbing, audiovisual, food catering, etc. — can be put together to create a functioning ballpark. It all but takes a mastermind to bring all these engineering disciplines together efficiently.

Now imagine if you were building a ball park where every component was developed by different teams and managed independently; where there was little or no communication between teams; where documentation was on paper, if there was any; where some systems were designed to perfection and others not so well; and you didn’t know which. In this situation, when something goes wrong, you have no idea why, and nowhere to go to get help.

Sound familiar? No? Substitute USB for mechanical, PCIe for electrical, and SoC for ball park. Ring a bell now?

Today’s SoC designs are so large and sophisticated that necessity drives the need to build them by integrating a mix of new and reused IP from many sources – internal and external. This is great from an efficiency perspective and enables a division of labor. But this also creates a division of knowledge, which makes it incredibly difficult for SoC verification engineers to debug IP integration challenges. Without immediate access to IP engineers nor electronic specifications that police integration, IP-SoC integration validation can become a long, painful process.

Embedded assertions were invented some time ago to address this problem. But these required manually written assertions that comprehensively capture expected functionality. Even when combined with commercially available VIP, engineers simply don’t have the time to create sufficient assertions.

Figure 1: Automated Methodology for Assertion Reuse in SoC

A solution to this challenge is a combination of automation and methodology. With automation, functional properties can be captured during IP-level simulation, in sufficient numbers to comprehensively capture the known-good state-space of an IP. These can then be synthesized into assertions that will trigger whenever an IP steps outside its known-good state-space. These assertions are then passed, along with the IP’s RTL, to the SoC team for use as an “executable specification”. During SoC simulation, an assertion will not trigger so long as all is working as expected. When an assertion does trigger, it will be for one of 3 reasons:

1. Specification Violation: Incorrect I/O wiring, illegal handshakes, illegal configurations, etc.
2. IP-level Verification Coverage Hole: Functionality that has never been tested.
3. Corner-case Bug: Design error.

By combining automated property generation and assertion synthesis, and making these part of an ‘IP kit’ passed on to the SoC team, we can implement a methodology that automatically detects actionable issues to guide efficient SoC integration/debug. Now if only we could create assertions that automatically alert us when the ball-park concession stands are running out of beer, we’d have paradise.