SoC verification and validation have traditionally been viewed as distinct parts of the development cycle: following a recent discussion with SemiEngineering which resulted in this article by Brian Bailey, we thought it would be useful to share some further thoughts on the issue.
Verification and validation are often viewed as quite separate parts of the chip development cycle. One being pre-, the other post-silicon – owned by different teams, and with different, dedicated toolsets supporting them.
More recently, considerable attention has fallen on ways of integrating the two disciplines more tightly. Portable stimulus, for example, is a powerful concept, aiming to allow chip design teams to formulate their verification / validation intent just once, and then use that single specification at any stage of the development cycle. All of the EDA companies are embracing the idea of a verification/validation model that scales end-to-end across the development process: from design, through simulation, emulation and into silicon and system validation. Synopsys calls this the ‘verification continuum’; but as I’ve said, pretty much everyone acknowledges the need and is working to fix it.
Less well recognized is the need to scale the whole process “from top to bottom”: to address systemic complexity. This is about more than the hardware. All silicon runs complex and powerful software (much as we might sometimes wish it to be otherwise!) Today, the process of getting the very best possible performance out of that hardware/software combination is where the rubber hits the road.
Newer emulation and prototyping techniques such as Cadence Palladium and Mentor Veloce can be very helpful here. But the real issues – whether they are show-stopping bugs or more subtle problems that reduce performance or increase power consumption by just a few percentage points – will only surface in real silicon, with actual code running at full speed with real world interfaces.
It’s worth unpacking that statement.
First, there’s the speed issue: in some cases we are looking for bugs that surface only after hours, days or even weeks of continuous real-life operation. A big SoC can contain a billion gates or more, and even a ‘simple’ task like booting Android takes billions of cycles. Modeling such a process would take years of processor time on even the most powerful server farm.
Second, once you’ve found an issue, are you working in an environment that can reproduce it and get anywhere close to a root-cause analysis?
And third, pretty much all of our electronics today needs to interact in some way or another with the real world. Does the real world always behave as we expect it to? No. So our prototyping and emulation efforts are typically only as good as the models of the real world that we build to exercise our designs.
That’s not so say that emulation and prototyping aren’t valuable: an emulator like Mentor’s Veloce can run 1000 – 10,000 times faster than software-based simulation, with built-in trace to support later analysis; and it can interface with external hardware, providing a step towards emulating real-world operation.
But no matter how much emulation and prototyping you do, it’s still a tough task.
Although we’re not directly involved in the verification / validation space at UltraSoC, we do believe that we’ve something to contribute, both in terms of technology and in terms of a more holistic solution to some of the problems. On-chip monitoring and analytics hardware can help to bridge the current gaps in the post-silicon world: in contrast, traditional debug tools are incompatible with those which are used pre-silicon; they are mired in silos – generally processor-centric; and last but not least they generally can’t be used ‘in the field’.
The ability to collect and utilize data from field trials and even in-life operation provides a powerful potential feedback loop that ties the whole development flow together, from top-to-bottom and end-to-end, not only making the systems and software engineering tasks easier, but also providing actionable insights back to the silicon team, allowing them to fix bugs in the silicon or IP itself, and to performance-enhance or cost-reduce future generation chips.
We will be at DAC at the end of June, so please come along and see us and discuss this in person.