Posts Tagged ‘system coverage’
Tuesday, April 1st, 2014
In our last post, we discussed some details of the demo that we showed at the DVCon and SNUG Silicon Valley events, in which TrekSoC-Si generated a test case, downloaded it into a commercial SoC (a TI OMAP4430 with dual ARM cores), and ran it in the actual chip. Our focus last time was on Breker’s unique visualization for the multi-threaded, multi-processor test cases that we generate. Specifically, we provide the same display for a test case running in silicon as we do for one running in simulation or simulation acceleration.
Even more interesting is our ability to display coverage information for test cases running in silicon. You might think that this is impossible unless we’re building coverage structures into the SoC that you fabricate. Customers have been known to build specific types of coverage metrics into their hardware, for example real-time monitoring of bus bandwidth and SoC performance. But that’s not what we’re doing; we can gather highly accurate system-level overage without changing the design a bit.
Tuesday, February 25th, 2014
Next week (March 3-6) marks the return of the most important annual event for verification engineers: the Design & Verification Conference & Exhibition 2014, better known as DVCon. Its home remains the DoubleTree hotel in San Jose, a Silicon Valley landmark and site of many interesting conferences going back to its original days as the Red Lion Inn. Breker will be there in force, so we’d like to tell you about our activities as well as preview the technical program.
Of course, Breker will be participating in the exhibition portion of the show. This has expanded from previous years. The exhibit floor will be open on Tuesday (March 4) and Wednesday (March 5) from 2:30pm to 6:00pm as usual. However, a special preview on Monday from 5:00pm to 7:00pm has been added this year. You’ll have plenty of time to stop by to visit Breker in booth number 902 and (if you must) perhaps some other vendors as well.
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.
Monday, December 30th, 2013
Please allow me to start this post with a sincere wish for all of our readers to have a happy and healthy holiday season. There are many enjoyable activities both sacred and secular this time of year, something for everyone whatever your personal beliefs. I hope that you all have the chance to relax a bit and share some delicious food with family and friends.
I thought about writing a column on the top 5 holiday wishes for verification engineers, but I felt that it would be a bit presumptuous to speak for you. We do work very hard to understand what you need in order to tailor our products to gaps in your verification process and speed up your project. Therefore, I’m going to offer 5 gifts for you, the verification engineer, that are available with Breker’s products. I hope that you like them!
Tuesday, December 17th, 2013
With due apologies to Barbra Streisand, the topic of today’s blog post is the verification of SoC memories and memory subsystems. Once upon a time, memories were considered just about the easiest design structure to verify. A simple automated test doing “walking 1s” and “walking 0s” supplemented by some random reads and write to random addresses with random data seemed to be good enough.
“Can it be that it was all so simple then? Or has time re-written every line?” Actually, it really was that simple back then. But a lot of changes in memory subsystems have come along to complicate matters: memory regions, caches, multi-processor designs, shared memory, complex memory maps, etc. Verification of memories today is much more challenging, with many corner cases to be exercised, but it’s an essential part of the overall SoC verification effort.
Tuesday, September 10th, 2013
In our last technical blog post, we surveyed some of the existing forms of coverage, including their virtues and limitations, and their applicability to SoC designs. We also introduced a new type of metric, system coverage, based on application scenarios that reflect how an end user would actually run applications on the SoC. We closed by claiming that “Breker’s graph-based scenario models are ideal for establishing, measuring, and refining system coverage.” This is the next in a series of posts to explain why and how.
Another earlier post described the Breker approach of “beginning with the end in mind” using graph-based scenario models. In the graphs used by TrekSoC, outcomes appear on the left and inputs appear on the right, reflecting the way that the test case generator works from the desired result toward the setup conditions needed for a particular application scenario.