 | Maheen Hamid CFO of Breker Verification Systems |
Bugs have a way of turning up in an SoC design in the most inopportune time, much like the long-presumed dead relative and heir apparent who showed up recently at Downton Abbey, disfigured but hoping to be recognized.
While chaos may seem like a way of life for a verification engineer, in the PBS soap opera drama currently riveting the U.S. each Sunday evening, the Grantham family has been thrown into an unexpected state of chaos. Lord Grantham turned to a slew of lawyers to uncover the truth. In our world, when a major bug is found, the manager of the verification group throws a slew of verification engineers at it who are often forced to deal with it through manual tests. And, that’s just the way it’s been.
On Downton Abbey, a survivor of the “unsinkable” Titanic arrives disfigured from an explosion during World War I, supposedly a relative of the Grantham Family declared dead six years earlier. SoC functional verification challenges are big and complex and often resemble an iceberg that dwarfs the unprepared chip, not unlike the sinking of the Titanic. Way too many verification teams sink after their SoC design hits an iceberg (or bug) of Titanic proportions. That’s because they are using traditional methods, manually developing tests only able to address the tip of the verification iceberg. As a result, they often miss system functional and performance problems that aren’t apparent until first silicon. That verification manager ends up with a dilemma the size of Lord Grantham’s, though his or hers is related to time to market and the impact of revenue, and not the search for a male heir.
The solution for verifying an SoC is only now becoming clear since block-level testbench-based verification has been proven to be ineffective for SoC designs containing embedded processors. Complex SoC use cases that cross multiple concurrent applications with shared resources and on-board power and clocking management systems offer up an overwhelming number of possible scenarios. Automation software can assess what to verify and rapidly generate test cases needed to adequately cover the wide spectrum of verification objectives. Automated self-verifying C test cases running on embedded processors exercise a range of functional scenarios to ensure that the SoC can support concurrency, system-level and software functionality while meeting performance requirements.
The SoC verification problem is as daunting as the challenges facing Downton Abbey, though in today’s chip verification world, that it will be solved through automation. We’re heading into DVCon later this month. Expect to see a solution that automates the generation of portable self-verifying tests for multi-threaded SoC devices. Visit the Breker Verification Systems exhibit at DVCon in booth #1002 to learn more. While we can’t promise a visit from Lord Grantham or anyone else from Downton Abbey, we can offer something much more: relief from the demands of SoC verification.
And, don’t miss our breakfast to be held from 7:30-8:30 a.m. Tuesday, February 28, during DVCon. It will include a panel discussion titled, “Do We Have What It Takes for Full-SoC Verification?” Open to all full DVCon conference and Tuesday conference-only registrants, it will be moderated by Brian Bailey of Brian Bailey Consulting and editor of EETimes’ EDA DesignLine.
Special thanks to the host of the Real Talk Blog, Real Intent. Don’t miss an opportunity to stop by its booth (#902) during DVCon to see demonstrations of Meridian and Ascent, software that accelerates Early Functional Verification and Advanced Sign-off of electronic designs. Real Intent Verification Expert Lisa Piper will present, “X-Propagation Woes: Masking Bugs at RTL and Unnecessary Debug at the Netlist,” at a Technical Program session on Formal Techniques Tuesday, February 28, at 11 a.m.