“In any book-to-movie endeavor, the book is the specification and we as consumers judge how well the filmmakers did in implementing the story.”
I admit it. I’m a huge Harry Potter fan. I own a complete first-edition set of the books and actually drove over an hour and a half each way to pick up my niece and nephew as my “excuse” to see the first movie when it came out, since my own children were too young at the time. I have read all the books (or listened to the audiobooks) and watched all the movies more times than I can count. When my son got older I read the books to him at bedtime, and later with my daughter.
My rule has always been that you have to read the book before you can see the movie — a rule that I scrupulously apply to any book-to-movie endeavor. If you see the movie first, then when you read the book all you will see in your mind is the corresponding scene from the movie. But if you read the book first, then your imagination can run wild and bring the story to life in a way that a movie simply can’t match. Also, there are usually details in the book that they can’t fit into the movie (with the possible exception of the 9-hour trilogy version of The Hobbit). So, in a way, the book is the specification and we as consumers judge how well the filmmakers did in implementing the story. So, we’re kind of like verification engineers! You knew I’d bring it around to verification, didn’t you?
This issue of Verification Horizons is more “intimate” than usual, but I’m sure you’ll still find plenty of helpful insights throughout these articles. We start with our featured article, “Why Hardware Emulation Is Necessary to Verify Deep Learning Designs,” by my Mentor colleague Jean-Marie Brunet and noted verification expert Lauro Rizzatti. Before making the case as to why emulation is required, they provide one of the best overviews of what “deep learning” actually means and what’s involved in designing hardware to implement such a system. When you consider the requirements for scalability, virtualization and determinism in verifying a deep learning system, the need for emulation is obvious.
In “Deadlock Prevention Made Easy with Formal Verification,” a team of our formal verification experts at Mentor explore the intricacies of safety and liveness properties to identify deadlocks in formal verification. As you’ll see, the way to automate deadlock detection is by using some unique capabilities of Questa® PropCheck and AutoCheck. The article actually walks you through a real use case to illustrate these powerful additions to your formal verification toolkit. You’ll have to read the article to see how raccoons and koalas fit into the discussion.
In “Exercising State Machines with Command Sequences,” my Mentor colleague and Portable Stimulus guru, Matthew Ballance, shows us how Questa® inFact can generate command sequences that will exhaustively exercise a complex state machine. The key is to use inFact’s Coverage Creator feature to auto-generate a complex SystemVerilog covergroup from a relatively simple specification which, coupled with a straightforward set of constraints, will let inFact automatically create a set of sequences to exercise the state machine. This is a great example of how inFact can let you take advantage of Portable Stimulus technology in your existing simulation-based verification environment.
As a special treat in this issue, we’re sharing two articles that were recently presented at DVCon Europe. In “Designing a Portable Stimulus Reuse Strategy,” Matthew shares some critical insights on how to apply the new Portable Test and Stimulus Standard in a way that maximizes the reuse benefits when sharing test intent and IP between teams and projects. Just as UVM formalized a methodology for SystemVerilog, this article outlines a methodology and accompanying planning process that will enable you to take full advantage of this exciting new technology.