Open side-bar Menu
 The Breker Trekker

Posts Tagged ‘system coverage’

DAC is Back! A Preview of the San Francisco Show

Wednesday, May 28th, 2014

DAC is back, Jack! The big show returns to San Francisco for two years before heading back to Austin. Last year was a special one for Breker, with our 10th anniversary as a company, the 50th year of DAC, and the first time for the show in Austin, our birthplace. But no location draws more visitors and more buzz than San Francisco. It’s a short train ride from traditional Silicon Valley and arguably part of an extended definition of Silicon Valley that includes a fair chunk of the Bay Area.

This year’s show promises plenty of excitement, and we’d like to fill you in. Of course, we will be there as part of the always lively exhibit floor. Those of you who attended DAC in Austin will surely remember our naval-themed “USS Ice Breker” booth, which we loved so much we’re shipping it to San Francisco. No visit to the DAC exhibits would be complete without stopping by to see Breker in booth 2602 and taking a “cruise” with us. You can request a meeting at a specific time by visiting our DAC signup page.

(more…)

Coverage from Running SoC Silicon? How Is That Possible?

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.

(more…)

Sound the Trumpets! It’s DVCon Time Again!

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.

(more…)

Bugged about Debug? We Can Help!

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.

(more…)

More on the UVM: Processor or Verification Component?

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

(more…)

We Like the UVM, Really We Do!

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.

(more…)

Do Graph-Based Scenario Models Qualify as Formal?

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.

(more…)

Can Graphs Make Modeling More Pleasant?

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.

(more…)

Top 5 Holiday Gifts for the Verification Engineer

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!

(more…)

Memories … Light the Corners of My Verification Space

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.

(more…)




© 2024 Internet Business Systems, Inc.
670 Aberdeen Way, Milpitas, CA 95035
+1 (408) 882-6554 — 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 PolicyAdvertise