The Breker Trekker 
Tom Anderson, VP of Marketing
Tom Anderson is vice president of Marketing for Breker Verification Systems. He previously served as Product Management Group Director for Advanced Verification Solutions at Cadence, Technical Marketing Director in the Verification Group at Synopsys and Vice President of Applications Engineering at … More » Using Scenario Models to Capture Use CasesJuly 30th, 2015 by Tom Anderson, VP of Marketing
One of the signs that a technological domain is still fairly young is frequently evolving terminology as the pioneers attempt to explain to the mainstream what problem needs to be solved and what solutions can be brought to bear on the problem. Such is the case with SoC verification. At Breker we used to start explaining what we do by talking about graphs, but shifted to “graph-based scenario models” to emphasize that graphs are perfect for expressing scenarios of real-world behavior. Our friends at Mentor, also strong advocates for graphs, began using the term “software-driven verification” to describe their approach. We rather like this description, but feel that it can only be applied accurately when embedded test code is being generated and when the embedded processors are in charge of the test case. Now our friends at Cadence have been sprinkling the term “use case” throughout their discussions on SoC and system verification. Let’s try to sort out what all this means.
As a reminder, our Trek family of products generates test cases from graph-based scenario models of the design to be verified. These models “begin with the end in mind” by moving from possible outcomes and tracing back to required inputs. Along the way there may be many options or variations available. As the Trek engine walks the graph, it randomizes the options to produce a unique test case every time. Over time, we can generate enough test cases to walk all the nodes and paths in the graph.
Traditionally, we have called each of these graph walks a scenario. Thus a complete scenario model captures all possible scenarios for the design being verified. The really important point is that these scenarios represent the sort of behaviors that a user would exercise while using the SoC. Let’s return to an example we’re used before in this blog: a chip for a digital camera. A graph-based scenario model captures all the different user-level scenarios that are possible. As our Trek family of products analyzes this graph, it can produce a series of test cases that walk through all the different scenarios. These include:
Note that these tests can be generated in C code to run on the embedded processors (software-driven verification), in pure UVM transactions to run on a subsystem or a “headless” system with the CPUs replaced by bus models, or using a mix of both. Each user-level scenario is the same as “use case” and, in fact, we’ve often used the term “realistic use cases” ourselves. Among the tasks to be tackled by Accellera’s Portable Stimulus Working Group (PWSG) as SoC verification matures is settling the industry terminology. Beyond wording, the key question is whether or not the specification can handle the full range of behavior that a user needs to describe. Breker’s graph-based scenario models fit the bill, generating portable test cases while providing use-case system coverage metrics so you know that your design and verification intent is fully represented. The truth is out there … sometimes it’s in a blog. Tom A. Tags: Accellera, Breker, Cadence, EDA, functional verification, graph, graph-based, mentor, portable stimulus, PSWG, realistic use case, scenario model, simulation, SoC verification, test generator, Universal Verification Methodology, use case, uvm, VIP Warning: Undefined variable $user_ID in /www/www10/htdocs/blogs/wp-content/themes/ibs_default/comments.php on line 83 You must be logged in to post a comment. |
|
|
|||||
|
|
|||||
|
|||||
