"While we may not be able to reach that (Bill Belichick) level of focus, we can always try to be better at planning and preparing for success."
Our remarkable run here in New England continues. The New England Patriots just won their fifth Super Bowl championship. After falling behind 28-3, they staged a record-setting come-back to win in overtime. It was incredibly exciting, and I'm not ashamed to admit that my family and I were literally jumping up and down and screaming when the Patriots scored the winning touchdown. No team had ever come back in a Super Bowl from a deficit of more than ten points, so going by past performances, the Patriots' comeback was "impossible." My daughter actually turned to me at one point and said, "They're going to lose, aren't they?" I replied that it would require an historic comeback, but I never counted them out. In the end, it took an incredible combination of plays (and, admittedly, some bad decisions by the Falcons) for them to pull it off, but they did it! The emotion of this win is just what we need to keep us warm as we face yet another snow storm while I write this.
The morning after the victory, Patriots coach Bill Belichick was asked how he felt about the game. After admitting how special the game was and how proud he was of his team, he said something that shows why he's now considered the greatest coach of all time. When asked what his plans were, he said, "As far as I'm concerned, we're now five weeks behind all the other teams in preparing for next season." His constant devotion to preparation, planning, and teaching his players is what sets him apart. While we may not be able to reach that level of focus, we can always try to be better at planning and preparing for success.
In our feature article this issue, my longtime friend and colleague, Mentor Graphics Chief Scientist Verification Harry Foster, shares some interesting data from the latest round of his biannual Functional Verification survey in "Will Safety Critical Design Practices Improve First Silicon Success?" After sharing some general data, which shows some counter-intuitive results, Harry does a deeper dive to see what effect verification process maturity and safety critical design practices have on first-pass success. I won't spoil it, but you'll likely be surprised by the results.
Continuing with the theme of safety critical practices, our friends at Optima Design Automation share with us "A Practical Methodology for Meeting ISO 26262 Random Faults Safety Goals in Automotive Semiconductor Products." As you can imagine, automotive safety verification is especially challenging because the ISO 26262 standard requires ensuring that the design will function safely when exposed to random faults, which obviously can occur in a car whose lifespan can be expected to be up to ten years or more. This article explains the fault-injection problem and how their accelerator can help you satisfy the requirements of the standard on your safety-critical project.
Next, we move on to the subject of Portable Stimulus, with "Bridging UVM to the Portable Stimulus Standard with Questa® inFact" from our friends at CVC. The new Portable Stimulus Standard being worked on in Accellera uses a graph-based approach to specify stimulus at a higher level of abstraction, but in a way that can be mapped to UVM environments, among other target implementations. This article shows how CVC used Questa inFact to create a portable graph-based stimulus model that they used to verify a memory controller design. You should find a lot of great information and encouragement to use a similar approach on your next project.
One of the advantages of the Portable Stimulus Standard is its ability to specify SoC-level stimulus scenarios that are often difficult to express with UVM sequences. In "Automating Tests with Portable Stimulus from IP to SoC Level," my colleague — and our resident Portable Stimulus guru — Matthew Ballance introduces some of the concepts and language constructs of the proposed standard. You'll see how the declarative nature of the standard makes it easier to specify complex scenarios for block-level verification and also to combine those into SoC-level scenarios.