Posts Tagged ‘emulation’
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, December 16th, 2015
Do you want to hear all the behind-the-scenes dirt from a workshop on the future of the MTV cable channel? Well, you’ll have to look elsewhere. “MTV” in this case means the International Workshop on Microprocessor Test and Verification, which celebrated its 16th incarnation in Austin two weeks ago. Although the name of the workshop has officially expanded to “Microprocessor and SOC Test and Verification” rest assured that the delightfully ambiguous abbreviation “MTV” will remain.
This was only my second time at this event, but I wish that I had been able to attend more. The setting is the top floor of the Hyatt Regency, with great views of Lady Bird Lake (formerly Town Lake) and downtown Austin. However, I noticed that recent high-rise construction has now blocked the sight of the Texas State Capitol from the hotel. The view might be distracting if not for the fact that the technical committee put together an interesting and diverse program, including a panel on portable stimulus.
Wednesday, September 23rd, 2015
Anyone who reads The Breker Trekker from time to time needs no convincing from me that verification is a huge challenge for today’s complex chips. Breker’s Trek family of products exists, along with dozens if not hundreds of other EDA products, specifically to address functional verification. There are more technologies, tools, platforms, libraries, and methodologies than any one verification engineer can possibly learn and use on a day-to-day basis.
Why this diversity of solutions? As I first observed in Electronic Engineering Times nearly a decade ago, there is no silver bullet for verification. The problem is both so broad and so deep that no single tool or technology will ever satisfy the need. It takes a mix of solutions, guided by methodologies, to have any chance of first-silicon success. Low-power verification is an area where this is especially true, and unfortunately there is no silver bullet to be found here either.
Wednesday, February 11th, 2015
As you may have seen this morning, the EDA standards organization Accellera officially announced the formation of the Portable Stimulus Working Group (PSWG). This group has the charter to “develop the electronic industry’s first standard for portable test and stimulus. When completed and adopted, this standard will enable a single specification that will be portable from IP to full system and across multiple target implementations.”
Regular readers will note that this wording sounds very familiar. At Breker, we’ve been talking about vertical reuse from IP to SoC and horizontal reuse across all verification platforms for years. At times we’ve felt like pioneers with arrows in our back. The formation of the PSWG is a validation that we’ve been heading in the right direction. We’re excited to see the industry embracing the challenges of SoC verification and starting to work on a new standard to address these challenges.
Thursday, February 5th, 2015
Two recent blog posts discussed what you should run when you first map your system-on-chip (SoC) design into an emulation platform and when you have your first fabricated chips from the foundry in your bring-up lab. We pointed out that trying to boot an operating system and run applications should not be the first step because production software is not designed to find and debug lingering hardware design errors. We recommended running the multi-threaded, multi-processor, self-verifying C test cases generated and optimized for hardware platforms by our TreSoC-Si product.
As you may know, TrekSoC uses the same graph-based scenario models as TrekSoC-Si, but optimizes the generated test cases for virtual prototypes, simulation, and simulation acceleration. In this post, we ask a similar question: what should you run in simulation when you first have the RTL for your SoC assembled and ready to be verified? Of course our answer will be the test cases generated by TrekSoC. However, there are some advantages of simulation over hardware platforms that foster a more extensive methodology for verification with Breker’s products.
Tuesday, January 20th, 2015
Last week’s blog post raised the question of what you should run when you first map your system-on-chip (SoC) design into an emulation platform. We pointed out that trying to boot an operating system and applications immediately was a challenge because these are complex pieces of production software not designed to find lingering hardware design errors or to debug such errors easily even if detected. On many projects, the production software isn’t even available early enough to be used for design verification.
We strongly recommended running the multi-threaded, multi-processor, self-verifying C test cases generated by our Trek family of products. These “bare metal” test cases run on your SoC’s embedded processors at every stage of the project. TreSoC-Si specifically generates test cases tuned for emulation and FPGA prototype platforms. But what should you run when your fabricated chip first arrives back from the foundry? The answer is the same. TrekSoC-Si also generates test cases for silicon, ideal for use in your bring-up lab. Let’s explore this idea a bit more.
Wednesday, January 14th, 2015
Many of you are probably familiar with Lauro Rizzatti, who has written countless articles on the value of emulation for verifying system-on-chip (SoC) designs and been an occasional guest blogger here on The Breker Trekker. Lauro recently published an article in Electronic Engineering Times that really caught our attention. We could not possibly agree more with the title: “A Great Match: SoC Verification & Hardware Emulation” and, as we read through the article, were very pleased with the points he made.
Emulation involves mapping the RTL chip design into a platform that runs much like an actual chip, albeit considerably more slowly. The industry is not always consistent on its terminology, but generally if the platform is connected to a software simulation it’s being used as a simulation accelerator. In this case, the design’s inputs and outputs are connected to the simulation testbench much as they would be when running software simulation of the RTL. In emulation, there’s no simulator or testbench, and so the question becomes what to run on the design.
Tuesday, December 16th, 2014
Much as we like informing you about the latest technical advances at Breker and weighing in on various industry topics, we love to take a break every so often and welcome a guest blogger. The EDACafé statistics show that these usually draw very well, and doubtless they attract a varied set of readers. This week we’re delighted to welcome back emulation expert and verification consultant Lauro Rizzatti, who has chosen to provide us with a fun look at the art and science of naming EDA companies and their products:
What’s in a name? Apparently, plenty. Let’s dispense some holiday cheer, kick back and forgo any technical discussion for a look at how a few companies in our industry got their names. Naming companies and products is big business. In fact, an entire industry is devoted to coming up with the perfect name to neatly express a company’s mission and the product portfolio. In some cases, though, companies stick closer to their employees and have contests where they can suggest names. That’s how OneSpin Solutions got its name. An R&D consultant in the U.K. came up with the name and won a case of beer for his efforts.
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.