Posts Tagged ‘graph-based’
Friday, February 19th, 2016
In last week’s post, we provided a preview of the program at the annual Design and Verification Conference and Exhibition (DVCon) in San Jose, coming up in ten days. We mentioned some of the interesting talks and other activities there, and focused in particular on “Using Portable Stimulus to Verify Cache Coherency in a Many-Core SoC” on Tuesday morning. The paper for this session was co-authored by Breker and Cavium, and both companies will present together at DVCon.
The paper and presentation describe the use of our Cache Coherency TrekApp and TrekSoC-Si to automatically generate self-checking, portable test cases for more than 100 CPU cores in a multi-SoC configuration in the Cavium bring-up lab. To set the stage for this story, today we’d like to revisit some of the reasons why cache coherency is so hard to verify and why an automated approach is the best solution.
Wednesday, February 10th, 2016
Regular readers of The Breker Trekker know that we like to preview, review, and dissect technical conferences and trade shows that are of interest to verification engineers. Perhaps the conference we’ve covered the most has been the annual Design and Verification Conference and Exhibition (DVCon) in San Jose. As far as we know, this is the biggest event anywhere focused on digital and system design and verification, a nice complement to the analog-ish DesignCon.
As a matter of fact, DVCon has become so successful that there are now regional conferences in India and Europe in addition to the U.S. show. We’ve strongly supported DVCon India, including serving for all three years on the Promotions Committee, and have participated in DVCon Europe as well. But those are a bit in the future; DVCon (U.S.) 2016 is coming up in a just a few weeks. The program is online now, so we thought we’d review it and suggest some sessions of possible interest.
Wednesday, February 3rd, 2016
For more than four years now, Breker has branded itself as “The SoC Verification Company” and many people acknowledge our expertise in this domain. As we have discussed before on The Breker Trekker, our initial products focused on generating purely transactional tests for a simulation testbench, usually compliant with the Accellera Universal Verification Methodology (UVM) standard. When we extended our products to generate C code that runs on the embedded processors found within SoCs, we delivered on our “tagline” promise.
Since our early focus on simulating an SoC, we have expanded our technology and our product line to generate C test cases that run on embedded processors in emulation, FPGA prototypes, and actual silicon in the bring-up lab. In talking about what we do, we struggle to choose between “SoC” and “system” since for many of our customers the terms are synonymous. But we also have users verifying multi-SoC systems, and today we’d like to address that topic.
Wednesday, January 6th, 2016
It’s been more than a year since we presented the Breker view of system coverage in detail, so it’s time to revisit the topic. We first defined the notion of system coverage as measuring which realistic, system-level application scenarios have been exercised using the existing test cases. We then demonstrated how our graph-based scenario models are ideally suited to capture system coverage metrics and fine-tune them using graph constraints if needed.
More recently, we noted that the term “use cases” has become more widespread and introduced the example of a digital camera SoC to show the types of use cases that should be exercised. The measurement for this exercise is also system coverage, so the bottom line is that all these terms are really talking about the same thing. Using a regular expression, we might say:
[application|realistic] (scenario|use-case) coverage = system coverage
Tuesday, December 22nd, 2015
In last week’s blog post, I reported from the recent 16th International Workshop on Microprocessor Test and Verification (MTV) in Austin. I focused mostly on the panel “Portable Stimulus and Testbenches – Possibilities or Wishful Thinking?” that included representatives from ARM, Cadence, Mentor, Synopsys, Freescale (now NXP), and Breker (yours truly). The panel was most enjoyable, but only one of several highlights for me at MTV.
This week, I’d like to touch briefly on some of the talks and topics on the technical program that caught my ear. These reflected a number of research frontiers for verification as well as several real-world case studies of SoC design projects tackling tough verification challenges. Perhaps the best moment for me was hearing Altera, one of our customers, describe how they used our products successfully on a recent design.
Wednesday, December 16th, 2015
Do you want to hear all the behind-the-scenes dirt from a workshop on the future of the MTV cable channel? Well, you’ll have to look elsewhere. “MTV” in this case means the International Workshop on Microprocessor Test and Verification, which celebrated its 16th incarnation in Austin two weeks ago. Although the name of the workshop has officially expanded to “Microprocessor and SOC Test and Verification” rest assured that the delightfully ambiguous abbreviation “MTV” will remain.
This was only my second time at this event, but I wish that I had been able to attend more. The setting is the top floor of the Hyatt Regency, with great views of Lady Bird Lake (formerly Town Lake) and downtown Austin. However, I noticed that recent high-rise construction has now blocked the sight of the Texas State Capitol from the hotel. The view might be distracting if not for the fact that the technical committee put together an interesting and diverse program, including a panel on portable stimulus.
Thursday, December 10th, 2015
The past two weeks, we’ve been having a bit of fun playing alchemist and letting readers in on some of the deep, dark secrets of graph-based verification technology. This week, we conclude the series by showing some additional capabilities for our scenario models that are easy to control and view in a graph visualization. Our point is, of course, that graphs are a natural way to represent data flow and verification intent with no advanced degrees from MIT, IIT, or Hogwarts required.
As a quick reminder, graph-based scenario models begin with the end in mind and show all possible paths to create each possible outcome for the design. They look much like a reversed data-flow diagram, with outcomes on the left and inputs on the right. Breker’s Trek family can traverse the graph from left to right, randomizing selections to automatically generate test cases tailored to run in any target platform. Today, we continue using our example of a scenario model to verify that an automobile can move forward or stop.
Thursday, December 3rd, 2015
Last week, we began exploring some of the ancient, mysterious powers of graph-based scenario models to show their power for verification and ability to capture the verification space, many aspects of the verification plan, and critical coverage metrics. We’re just kidding about the first part; there’s nothing at all mystical or magical about graphs. In fact, this series of posts is intended to show the opposite and demonstrate with a easy-to-follow example the value of graphs.
As we noted in our last post, graph-based scenario models are simple in concept: they begin with the end in mind and show all possible paths to create each possible outcome for the design. They look much like a reversed data-flow diagram, with outcomes on the left and inputs on the right. An automated tool such as Breker’s Trek family can traverse the graph from left to right, randomizing selections to generate test cases that can run in any target platform.
Tuesday, November 24th, 2015
If there’s one thing that Breker is known for, it’s the use of graphs for verification. From our earliest days, we harnessed the abstraction and expressive power of graph-based scenario models to capture the verification space, many aspects of the verification plan, and critical coverage metrics. As we reported in a post a few weeks ago, it looks certain that the industry will follow our lead and base the upcoming standard from Accellera‘s Portable Stimulus Working Group (PSWG) on a graph representation.
As discussions have proceeded both within the PSWG and informally with interested parties, it has become clear that “graph” may not mean the same thing to all people. Our view of graphs is precisely defined in a way that makes it easy for users to create them and feasible for our tools to generated complex, multiprocessor test cases from them. Most of the key concepts can be communicated easily by the use of a familiar example, which we will begin in today’s post and continue next week.
Friday, October 16th, 2015
We’re coming up to the two-and-a-half-year anniversary for The Breker Trekker, with 124 published posts. Initially I promised a post every other week, but after looking at the viewing patterns I quickly realized that I had to publish every week to establish a consistent audience. There’s always something to talk about in this fast-paced world, whether something new at Breker, standards activity, observations about the EDA industry, or analysis of the customers who drive our business.
Today I’d to acknowledge a second Breker blog that has actually been around longer than this one. Just over three years ago, Breker board of directors member Michel Courtoy started a series of posts in Electronic Engineering Times to offer advice to startups. He has published 28 such posts, and has covered an amazing amount of territory. I suppose that I should have done some “cross-promotion” earlier, but at this point I would like to highlight some of Michel’s sage advice. (more…)