Posts Tagged ‘FPGA prototyping’
Wednesday, August 24th, 2016
Three weeks ago, we published a post on The Breker Trekker blog that previewed some of the talks and tutorials on the technical program at the upcoming third Design and Verification Conference and Exhibition (DVCon) India on September 15-16 in Bangalore. More of the details on the conference are now available online, and for today we’d like to highlight some of the keynote addresses, panels, and poster sessions on the agenda that also stand out for us.
As always, the program and steering committees have put a lot of thought into keynote speakers who will take a wide view of not just the EDA industry, but the larger electronics industry that we serve. Mentor CEO Wally Rhines is always a great speaker who comes armed with lots of charts and statistics to support his positions. His talk on “Design Verification: Challenging Yesterday, Today and Tomorrow” will survey the history and evolution of verification while predicting some of the future challenges
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.
Wednesday, August 10th, 2016
As some of you may have seen, two years ago the IEEE created an app that ranks the popularity of dozens of programming languages. They use twelve different metrics, from search results and social media mentions to technical publications and requirements listed in job openings. If you don’t like the way that they use these metrics, you can create your own ranking using your own mix. It’s really quite a clever idea and it generates lots of discussion every year.
For 2014 and 2015, C held the #2 spot, just below Java in the rankings. The big news this year is that C has edged into first place, although the top two spots remain very close as measured by the metrics the IEEE has chosen to use. C++ was in the #3 spot for the past two years, but for 2016 flipped places with Python. As you all know, we are strong advocates of C/C++ for verification and so we’d like to share some thoughts on these results and what they mean for our industry.
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.
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.
Wednesday, December 30th, 2015
It’s becoming somewhat of a tradition here on The Breker Trekker blog to close each year with a list of gifts available from us to verification engineers. We started the series two years ago with an initial list focusing on our core benefits of automatic test case generation, system coverage, and reuse both vertically (IP to system) and horizontally (simulation to silicon). Last year’s post offered five more gifts reflecting additional products and new features added to our overall solution:
#5: Easier sequence specification in UVM testbenches.
#4: Faster coverage closure in UVM testbenches.
#3: Integration of system coverage with other coverage metrics.
#2: Debug of automatic test cases using standard tools.
#1: A fully automated solution for cache coherency verification.
Every one of the ten gifts from 2013 and 2014 is still available today for our customers. In addition, we have continued to evolve our Trek family of products and to deploy it on ever more challenging SoC verification projects. Without further ado, here is our all-new list of holiday gifts for the verification engineer in 2015:
Wednesday, October 22nd, 2014
For those unfamiliar with the expression in the title, bringing someone (or something) to its knees means making it submissive. It’s a metaphor possibly derived from the act of hitting someone so hard that his knees buckle and he falls to a kneeling position. Why such a nasty term to start this post? Because when you want to verify the performance of your SoC you want to stress every aspect of it. You want to be mean to it. You want to bring it to its knees.
The most common way to do this is to run production software (operating systems plus applications) on a virtual prototype, a high-level system model created by architects before RTL implementation begins. This is not easy; it takes effort to set up workloads that will stress the design and often production software is not ready at this early stage of the SoC project. Further, this verifies only the high-level model, but RTL simulates too slowly to replicate the same tests, or often to boot the operating system at all.
Monday, June 16th, 2014
We hope you enjoyed last week’s guest post from Jonah McLeod of Kilopass with his experiences at this year’s Design Automation Conference (DAC) in San Francisco. We’ve offered several of our friends in the EDA industry to write in with their assessments of the show. Next up is Lauro Rizzatti, another industry veteran perhaps best-known as general manager of EVE-USA. These days he’s a verification consultant, and he shares his story of going to DAC as a conference attendee rather than as a vendor:
This is the first DAC where I wasn’t responsible for an exhibitor booth and it was exhilarating. I was able to attend sessions, walk the exhibit floor and, generally, get a feel for what’s going on in our industry. I’m pleased to report the news is good. Very good, in fact.