Posts Tagged ‘Breker’
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.
Thursday, May 19th, 2016
As engineers, we take great pride in defining our terms carefully and using them precisely to try to avoid ambiguity or confusion. Many engineering specifications start with a glossary of terms and sometimes even a taxonomy showing how they are related. Sometimes though, natural language being inherently ambiguous, we find that we have overloaded the meaning of certain words in a way that can lead to precisely the confusion we seek to avoid.
One such word is “constraint” because it is used in several different contexts in chip design and verification. In today’s post we would like to discuss path constraints on a graph-based scenario model. We will explain how they differ from other forms of constraints and why path constraints are essential for any portable stimulus solution, including the Trek family of products from Breker.
Wednesday, May 11th, 2016
The title of last week’s post was a play on a Mark Twain quote. This week I draw from a more contemporary source: The Muppets. Some episodes of the legendary family TV show featured a skit called “Pigs in Space.” In my head I’m reading “SoCs in Space!” with the same booming intonation used on the show for “Pigs in Space” to lead into a somewhat more serious discussion about the use of advanced chips in extreme conditions.
My prompt for this particular post came not from TV, but from an announcement yesterday that VORAGO Technologies is offering an ARM-based microcontroller (MCU) “designed specifically for radiation and extreme temperature operation without up-screening.” In other words, they ship an MCU that’s ready to use in such traditionally challenging environments as automobiles and industrial controllers as well as, yes, space. That got me thinking about even more complex chips such as SoCs and the extreme conditions they might have to face.
Thursday, May 5th, 2016
With a nod to Mark Twain, this week I’d like to comment on a recent three–part series with the provocative title “Are Simulation’s Days Numbered?” The articles were transcribed from one of the “experts at the table” events that SemiconductorEngineering does so well. Breker wasn’t involved in this particular roundtable, but I enjoyed reading the series and found that it stirred up some thoughts. As a blogger, of course I’m going to share them with you and I hope you enjoy them in turn.
Let’s get this out of the way immediately: in three parts and more than 5,000 words, there was no mention of portable stimulus. That might not seem too surprising given the title, but in fact verification portability both from IP to system and from simulation to hardware arose during the discussion. So I’ll comment on that but, given my background as a vendor of formal EDA tools and reusable IP blocks, there are a few other topics that also piqued my interest.
Tuesday, April 26th, 2016
Ever since Accellera started the Portable Stimulus Working Group (PSWG), this emerging technology has generated a lot of buzz both within the EDA industry and among our semiconductor and systems customers. As the pioneer in this technology we get a lot of questions about what portable stimulus is, why it is different from the Universal Verification Methodology (UVM) and other established approaches, and why anyone would need it.
We’ve devoted quite a few posts to this topic in The Brekker Treker blog, stretching back two years to when Accellera first set up a proposed working group (PWG) to survey the industry and decided whether standardization of portable stimulus was feasible and desirable. Given the many posts scattered throughout the past two years, we thought that we would take this opportunity to give readers new to this topic a guided tour of the information that we have available.
Tuesday, April 19th, 2016
As I discussed at last week, there are many different engineering roles involved in the development of a large, complex semiconductor device. The EDA industry attempts to serve nearly all of these groups, from the architects and product marketing engineers who dream up the new ideas to the technicians who test production parts on the factory floor. Today I’m focusing on the work of two of EDA’s most traditional customer bases: hardware designers and hardware verification engineers.
Perhaps I’d better explain my title. It comes from an old expression “we went to different schools together” that I remember hearing as a youngster. Sometimes this refers to two people who didn’t actually attend the same school but who are nevertheless longtime close friends. But I’ve also heard it used to refer to two people who did in fact go to school together but had very different experiences. This latter context is the one I have mind for design and verification engineers who work on the same project yet inhabit different worlds.