Posts Tagged ‘cache coherency’
Thursday, September 1st, 2016
For those unfamiliar with the idiom, “hitting the town” or “going out on the town” means heading out to make the rounds of bars, restaurants, theaters, clubs, etc. It’s usually used in a city where such entertainment options abound. The topic of today’s post on The Breker Trekker blog is a particular club, DVClub, that packs in plenty of solid technical information along with entertainment. You may not have to go far to hit one; a DVClub event is likely to be coming to your city soon.
The history of the Design Verification Club (DVClub) is quite interesting, stretching back more than ten years. It started as an informal event for verification engineers to get together to share stories and talk about new technologies to help them do their jobs. You might have noticed that, unlike DVCon, the title means “design verification” and not “design and verification.” This gathering is intended for semiconductor functional verification engineers.
Thursday, August 18th, 2016
When we first began offering our Trek family of products for what’s now known as portable stimulus, we talked a lot about vertical and horizontal reuse. Vertical reuse means that you can create a scenario model for individual IP blocks and generate test cases to run in their UVM testbenches, then move up to clusters and subsystems. The IP models can simply be plugged together to form a higher-level model from which appropriate higher-level test cases can be generated.
At the full-SoC level, you can generate C test cases that run on your embedded processors. Horizontal reuse is the ability to move from simulation to hardware (acceleration/emulation, FPGA prototypes, and silicon) while generating appropriate tests for these platforms from the same SoC scenario model. We generally described both forms of reuse in a unidirectional flow. However, bidirectionality is very valuable and, we believe, essential for portable stimulus. Let’s cover that topic in today’s blog post.
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.
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.
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 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.