Posts Tagged ‘uvm’
Wednesday, August 3rd, 2016
As many of you know, in 2014 the longstanding Design and Verification Conference and Exhibition (DVCon) expanded beyond Silicon Valley to India. The first year of DVCon India was very successful for a new event, drawing more than 450 attendees from more than 80 companies and universities. Last year’s show grew to more than 600 engineers attending the technical program, visiting the vendor exhibition, and enjoying the numerous opportunities to network with their peers.
The third annual DVCon India will be held on September 15 and 16, once again at the Leela Palace in Bangalore. From our perspective, the show just keeps getting better and better every year. The full program is now available online, and for today’s post we’d like to mention some of the technical sessions that we think look especially interesting. In a future post, we’ll discuss other aspects of the program, including the keynote addresses.
Wednesday, July 27th, 2016
Three weeks ago on The Breker Trekker, we published a post on “The Return of EDA Startups, Behemoths, Corner Stores, and Zombies” and saw a nice uptick in viewing. Zombies are always popular with our audience. Our post prompted some interesting observations from today’s guest blogger, Excellicon’s Sales and Operations VP Rick Eram. He has some thoughts on this way of dividing the EDA industry and suggestions on how customers should treat the different players:
The concept of corner stores is interesting since they pave the way for development and deployment of newer analysis and implementation technologies addressing today’s design challenges that are either not addressed by majors, involve much manual work despite available products, or are addressed by products that create a huge amount of data without means for interpretation. The startups develop new technologies and, while deploying their technology on their way to becoming corner stores, they master ways to deploy such new technologies. What differentiates corner stores from zombies is the deployment of the technology. These companies are the engines of innovation in today’s EDA industry and help the behemoths to cover the gaps in their traditional technologies after the newer technology catches on and adds value for customers.
Thursday, July 14th, 2016
Recently, SemiconductorEngineering published the three–part series “System-Level Verification Tackles New Role” as part of its ongoing “Experts at the Table” discussions. The format is simple–an editor sits down with four or five industry experts to discuss a particular topic–but the debate can be lively and the result educational. Breker participates in these roundtables as often as we can, focusing of course on verification among the many technical topics covered by the site.
In advertising a “new role” for system-level verification, this particular series was not overstating the case. We tend to talk a lot about the evolution of verification in general, especially for system-on-chip (SoC) devices and multi-SoC systems. But in some ways what is happening now with our products and the Accellera portable stimulus standardization effort is more revolutionary than evolutionary. So which is it? We’ll attempt to answer that question in today’s post here on The Breker Trekker blog.
Tuesday, July 5th, 2016
If the title of today’s post sounds familiar, that’s not surprising. The most popular post in the history of The Breker Trekker blog, by a significant margin, was “An EDA Industry of Startups, Behemoths, Corner Stores, and Zombies?” published almost three years ago. I thought that it would be fun to revisit this topic in light of the changes in the EDA industry over the past three years. Have these changes fundamentally altered our world? Please read on to see.
I’ll begin, as I did in the original post, by noting that the EDA industry used to be divided into only three categories: major leaguers, minor leaguers, and startups. Nearly all EDA startups disappeared after three or four years, with three possible endgames: acquisition, initial public offering (IPO), or bankruptcy. The major leaguers, at one time or another, included Daisy, Mentor, Valid, Cadence, Synopsys, and Avant.
Wednesday, June 29th, 2016
Over the more than three years of posts here on The Breker Trekker blog, you’ve seen us reference our TrekBox runtime component on many occasions. We mention it in many contexts: test case visualization, memory usage visualization, test case status, test case debugging, system-level coverage, performance analysis, I/O interfacing, UVM testbench control, and more. We’ve never had a post on TrekBox itself, so today we rectify that and fill in a few details that we haven’t discussed before.
Some of you are familiar with the term “trickbox” in the context of a simulation testbench. We found a nice concise definition of this term in an ARM patent: “Memory mapped (behavioral) test bench component to facilitate verification.” By writing to designated memory addresses, the processors in the design being verified can send messages to the testbench for various actions. Our TrekBox is of course a play on the “trickbox” name, and it provides many presents inside for those who open it.
Wednesday, June 22nd, 2016
We have a saying here at Breker that the fundamental job of any EDA company in the functional verification space is to “find more bugs, more quickly.” A good verification solution increases design quality by finding more bugs, improves time to market by closing verification faster, or reduces project cost by requiring fewer resources. A great verification solution, which we strive to offer, does all three. Accordingly, we talk a lot about the type of design bugs we can find with less time and effort than traditional methods.
We have another saying at Breker: “A performance shortfall is a functional bug.” A lot of people differentiate between these two cases, but we don’t agree. The specification for your SoC describes its performance goals as well as its functionality. Not meeting your requirements for latency or throughout can render your SoC unsellable just as surely as a broken feature. So we also talk a lot about how our portable stimulus techniques generate test cases for performance verification.
Wednesday, June 15th, 2016
In the last few days before DAC, as I was worrying about booth setup and demo practice, an important press release flashed by. The opening paragraph really should have caught my eye immediately: “Arrow Electronics, Inc. (NYSE: ARW) announced today that it has signed a definitive agreement to acquire the global internet media portfolio focused on technology and electronic design from UBM, including EE Times, EDN, ESM, Embedded, EBN, TechONline, and Datasheets.com.”
Perhaps this news doesn’t seem especially important to many readers, but to observers of the electronics trade press this is a big deal. The titles listed above are some of the best-known brands in the business. Arrow is an electronics distributor and services provider with a fine reputation, but it is not a traditional publisher. This industry transition has given me pause so I will make a few observations and then solicit your thoughts.
Thursday, June 9th, 2016
We’ve just wrapped up the 53rd annual Design Automation Conference (DAC), held for just the second time in Austin. As we mentioned in our show preview last week, Breker was founded in Austin so it’s always nice to return to our roots. With its live music, countless good BBQ joints, and sense of history, Austin is always a fun place to visit. The city has a large high-tech workforce, so we expected crowds similar to those in San Francisco or San Diego.
To be honest, the exhibition floor looked rather quiet at times. With the wide aisles and many attendees clustered around the Big Three EDA vendors and those booths with entertainment or giveaways, other parts of the floor seemed forgotten. Fortunately, our booth was on the major cross aisle and we had the industry momentum around portable stimulus in our favor, so we had a very good show. We’ll discuss our results as we fill in a few highlights from the four days we were there.
Wednesday, June 1st, 2016
The Design Automation Conference (DAC) us nearly upon us once again, this year returning to Austin in just a few days. The first-ever DAC in Austin was held three years ago and it was by all accounts a really good show. It was nice seeing new faces who could carve out an afternoon to visit the exhibit floor but who couldn’t get permission to travel when DAC is elsewhere. We were very pleased by both the number of people who stopped by our booth and their level of interest in what we do.
As you may know, Breker was born in Austin and so it will be a bit of a homecoming for us to return again. Austin features many fun activities, especially musical in nature, and great BBQ restaurants. We’ll be glad to provide suggestions and pointers for these if you ask, but for today’s post we’d like to fill you in what we will be doing at the show this year. We welcome any comments or questions that you may have.
Wednesday, May 25th, 2016
Last week on The Breker Trekker, we talked about path constraints and how they differ from other kinds of constraints commonly used in SoC design and verification. Our whole approach to verification is based on graph-based scenario models, and constraints on the paths through the graph are a natural way to control how our Trek family of products automatically generates test cases. It’s easy to eliminate some paths, focus on others, or bias the randomization of selections. We believe that path constraints should be a part of any portable stimulus solution that meets the forthcoming Accellera standard.
We have heard some people in the industry argue that path constraints are not needed, and that value constraints would suffice. While we agree that value constraints are a familiar concept from the UVM and other constrained-random approaches, we do not feel that they are the best way to control the scenarios generated from a portable stimulus model. In today’s post we will expand on the example from last week and show how path constraints can handle a more complex design better than value constraints.