Open side-bar Menu
 The Breker Trekker
Tom Anderson, VP of Marketing
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 Cases

July 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.

Big Camera Block Diagram

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:

  • Reading an existing Big Camera Scenario Modelphoto or video from the SD card
  • Reading an existing photo or video from the USB stick
  • JPEG-decoding an existing photo for display
  • MPEG-decoding an existing video for display
  • Capturing a new photo or video from the camera
  • Displaying a new photo or video on one of the displays
  • JPEG-encoding a new photo to save on the SD card or USB stick
  • MPEG-encoding a new video to save on the SD card or USB stick
  • Displaying the camera and an existing photo or video on the two displays
  • Trying all variations of photo/video quality, file, size, etc.
  • Randomizing data in photos and videos
  • Randomizing memory addresses as data is read or written via DMA

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.

Related posts:

Tags: , , , , , , , , , , , , , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

S2C: FPGA Base prototyping- Download white paper
TrueCircuits: UltraPLL

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy