Posts Tagged ‘test generation’
Tuesday, December 30th, 2014
Last year, we wound up in December with a post on the “Top 5 Holiday Gifts for the Verification Engineer” and it proved very popular despite the holiday timing. To refresh your memory (and ours), here is the 2013 list:
#5: Relief from hand-writing verification test code.
#4: Relief from hand-writing validation diagnostics.
#3: Vertical verification IP reuse from block to system.
#2: Horizontal verification IP reuse from electronic system level (ESL) to silicon.
#1: Effortless system coverage reflecting end-use applications.
As you might expect, every one of these gifts is still available today for users of our Trek family of products. But over the last year we have added two new products, many new features, and deeper integration into existing verification flows. So we’d like to wrap up 2014 with an all-new list of holiday gifts for the verification engineer. We hope you like them as much as you liked last year’s offerings:
Tuesday, July 8th, 2014
Last week we talked once again about our familiar mantra to “begin with the end in mind” when performing SoC verification. We described the enormous value that graph-based scenario models provide by enabling automatic test case generation from desired results. TrekSoC can walk the graph backwards, from result to inputs, and generate the C code necessary to exercise true user-level test cases across multiple threads and multiple heterogenous processors.
It’s clear even to the biggest fans of the Universal Verification Methodology (UVM) that this standard breaks down at the full-chip level for an SoC containing one or more embedded processors. The UVM, for all its good points, does not encompass code executing on processors and does not provide any guidance on how to link such code with the testbench that connects the chip’s inputs and outputs. The value of scenario models for SoCs is clear. But what about large chips without embedded processors? Does Breker have a role to play there as well?
Monday, June 30th, 2014
I’ve written about formal analysis rather frequently in this blog, although I do not consider Breker’s products to be formal in nature. There are several reasons for this. After ten years working with formal tools, I remain personally interested in that market. I also see interesting parallels between the adoption of formal and graph-based technologies. Further, whenever we cover formal analysis we get a great response. Clearly our readers like the topic as well.
I’m returning to formal this week because of a provocative comment made by one of our customers at DAC a few weeks ago. Wolfgang Roesner from IBM participated on the show floor in a Pavilion Panel called “The Asymptote of Verification.” Among several astute observations about the attributes of graph-based scenario models, he made a comparison with formal analysis that I found especially perceptive.
Tuesday, May 13th, 2014
As regular readers know, Breker’s claim to fame is the automatic generation of multi-threaded, self-verifying test cases that run on multiple heterogeneous processors within an SoC. The source for the generation process is a graph-based scenario model that captures the design intent and verification space. We chose graphs as an enabling technology more than ten years ago for a number of reasons, some of which we’ll discuss in this post.
The catalyst for this discussion is a new effort within the Accellera standards body to form the Portable Stimulus Specification Proposed Working Group (PWG). Basically, Accellera has formed a proposed working group to determine whether a technical working group should be established to start developing a specification for a standard. What does this have to do with graphs, and Breker? We’ll do our best to explain the history and current status.
Monday, March 10th, 2014
In our last two posts, we talked about the 2014 edition of the Design & Verification Conference & Exhibition, DVCon, in San Jose. Now that the show is history, lots of bloggers are summarizing their experience. Since I thought that this was an excellent event all around, allow me to join the chorus of voices praising DVCon 2014.
Here at Breker, our biggest effort goes toward the exhibition. Although it’s a relatively small booth and exhibit floor, we do want to put our best foot forward. So we had all-new signage this year updating attendees on our products and their capabilities. We also showed a very different demo from last year, with our TrekSoC-Si product generating a test case, downloading it into a commercial SoC (a TI OMAP4430), and running in the actual chip. We chose to repeat our very popular giveaway from DAC: a combined flashlight and distress whistle that will come in handy if you perform inadequate SoC verification and hit an iceberg.
Tuesday, February 11th, 2014
For today’s blog post, we use as our text a recent article on SemiWiki by well-known verification expert Hemendra Talesara. He provides a nice summary of a recent talk given in Austin by another verification expert, Harry Foster from Mentor. Many of you have probably seen Harry’s blog posts dissecting in great detail the results of a bi-annual survey that Mentor commissions from Wilson Research Group. There is much less coverage and analysis of the EDA world available today than there used to be, so we all applaud Mentor’s willingness to fund this survey and share the results.
Hemendra’s focus is on the well-known phenomenon of verification consuming more and more of a chip project’s resources. It is not uncommon to find that SoC projects have two or three verification engineers for every design engineer. So what do these verification engineers do with all their time and resources? The interesting result from the Mentor survey is that verification engineers spend 36% of their time on debug. At Breker, we’ve given a lot of thought about how to reduce debug time and effort, so we’d like to share some thoughts.
Tuesday, February 4th, 2014
Our last post on the relationship between the Universal Verification Methodology (UVM) and Breker’s technology was very popular. In only a week, it has become the fifth-most-read post in the nine-month history of The Breker Trekker blog. Clearly people are interested in the UVM and what strengths and weaknesses it brings to the ever more complex world of SoC verification.
This week we’d like to continue the discussion with a topic that we did not address last week: how the UVM offers an alternative to running embedded code by replacing one or more of the processors in the SoC with a verification component (VC). Our CEO, Adnan Hamid, addressed this topic in an Electronic Design article last November. We’d like to revisit some of the key points of that article in the context of last week’s UVM discussion
Tuesday, January 28th, 2014
When people first start reading about Breker and what we do, we make the point that transactional simulation testbenches are breaking down at the full-SoC level. Usually, we specifically mention the Universal Verification Methodology (UVM) standard from Accellera as not being up to the challenge of full-chip verification for SoC designs. We sometimes worry that someone will read into this that we don’t like the UVM, or Accellera, or even standards in general. Nothing could be further from the truth!
We have great respect for the UVM and other EDA-related standards developed by Accellera, IEEE, and other organizations. In this post, we’d like to discuss specifically what we see as the strengths and weaknesses of the UVM and explain how Breker’s technology complements rather than replaces this methodology. Yes, the UVM has limitations, and we address those with our tools and technologies. But the UVM forms a stable and standard base on which nearly all of our customers build their simulation-based verification environments.
Tuesday, January 21st, 2014
Recently on this blog, a series of related posts from Breker, Jasper, and OneSpin discussed formal analysis and its potential for playing a greater role in the verification process. We think that it’s important for The Breker Trekker to address topics in verification beyond our own technology and to provide occasional commentary on technology and the world of EDA in general. However, this recent focus on formal has caused some readers to wonder whether we consider ourselves to be in the formal market.
The short answer is “no” but there is some overlap in the technologies that we use and the techniques employed for formal analysis. Regular readers know that the foundation for our products is a graph-based scenario model that captures both the intended behavior of your SoC design and your system-level test plan. We can automatically extract system coverage from this model, with the model and coverage interacting in interesting ways. Let’s consider to what extent this is formal technology.
Tuesday, January 7th, 2014
This week’s blog post is inspired by Brian Bailey’s recent article “Making Modeling Less Unpleasant.” I noted with amusement that the link to his article ends with “making-modeling-pleasant” which I suspect was automatically generated from an early draft. So perhaps Brian started with the idea that modeling could be pleasant, but concluded that “less unpleasant” is as good as it can get? Is he too pessimistic? Can modeling actually be pleasant?
It depends in part on what aspect of design or verification modeling we consider. Brian’s primary focus is on system-level models of the design, also called electronic system-level (ESL) models, architectural models, or virtual prototypes. The appeal of a simulatable SoC model fast enough to run compiled code, capable of both functional and performance verification, is easy to understand. There have been many attempts to establish standard approaches, such as transaction-level modeling (TLM), and languages, such as SystemC.