Posts Tagged ‘coverage’
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.
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.
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:
Tuesday, December 30th, 2014
Last year, we wound up in December with a post on the “Top 5 Holiday Gifts for the Verification Engineer” and it proved very popular despite the holiday timing. To refresh your memory (and ours), here is the 2013 list:
#5: Relief from hand-writing verification test code.
#4: Relief from hand-writing validation diagnostics.
#3: Vertical verification IP reuse from block to system.
#2: Horizontal verification IP reuse from electronic system level (ESL) to silicon.
#1: Effortless system coverage reflecting end-use applications.
As you might expect, every one of these gifts is still available today for users of our Trek family of products. But over the last year we have added two new products, many new features, and deeper integration into existing verification flows. So we’d like to wrap up 2014 with an all-new list of holiday gifts for the verification engineer. We hope you like them as much as you liked last year’s offerings:
Tuesday, December 2nd, 2014
This blog focuses mostly on verification, but from time to time we like to take a look at other aspects of the EDA industry. Today we’d like to discuss high-level synthesis (HLS), its progress and status, and what’s keeping it from being a mainstream technology used for every chip design. It turns out that this topic has a lot to do with verification, so we’re not straying too far from our primary focus.
To start, let’s define what we mean by HLS in contrast to the mainstream technology of logic synthesis. Generating gates from a hardware description language (HDL) moved from a research problem to viable products around 1988. The ultimate winner among several promising companies was Synopsys, in part because they chose a register-transfer level (RTL) subset of the popular Verilog HDL as their input format. Their tools generated a gate-level netlist using the cells available in an ASIC vendor’s library.
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.
Tuesday, September 23rd, 2014
This morning, our good friends at Carbon Design Systems announced a new Web portal to provide system-level solutions for system-on-chip (SoC) developers. The Carbon System Exchange provides a wide range of Carbon Performance Analysis Kits (CPAKs), pre-built systems or subsystems with software at the bare metal or operating system level. CPAKs are key building blocks for SoC teams creating complete virtual prototypes for their designs.
Breker is one of nine announced IP and EDA partners who are working with Carbon to create new CPAKs or enhance current offerings. Some partners, such as ARM, Arteris, and Cadence, are providing processor models or other forms of IP commonly found in SoCs. Others, such as Kozio and Breker, are providing software to run on the CPAKs. As you might expect, what we’re actually providing is not a fixed set of software, but rather the ability for CPAK users to generate multi-processor, multi-threaded, self-verifying C test cases.
Wednesday, September 17th, 2014
One of the many challenges faced by small software companies is evolving their product lines in ways that make sense. New products must mesh with existing products so that customers can quickly understand what they might want. Products must be differentiated enough to stand separately, yet should leverage some of the same technology and expertise. Small companies have limited resources and it’s usually a mistake to develop multiple unrelated products requiring separate engineering teams.
Breker is no exception; we have a bunch of smart people with lots of ideas about how graphs can be applied to a wide range of problems. However, by focusing on the functional verification of large, complex chips using graph-based scenario models we are able to target a fairly specific group of companies and users. We also get tremendous productivity from a small R&D team because their collective knowledge spans the limited but important product range that we cover. This blog post is an attempt to describe that range more precisely.
Tuesday, September 2nd, 2014
Three weeks ago, we introduced our TrekUVM product, a solution for automatically generating test cases to improve coverage of chips in transactional testbenches. We don’t sit still for long at Breker; today we’re introducing the first of a series of TrekApp (application) products that will address specific problems in the verification of SoCs and other large designs. The term “app” is well-known from smartphones and tablets, but also used more and more in EDA.
Apps are attractive for several reasons. They provide turnkey access to new technologies without the user having to become an expert. They solve problems that are well established as project bottlenecks, so a return-on-investment (ROI) analysis tend to be easy. They provide immediate value to the project team, reducing the cost of deployment and increasing the ROI. For SoC verification, we’ve chosen cache coherency as the first app to make available.
Wednesday, August 20th, 2014
Several posts back, we introduced the idea of “composing” higher-level verification elements from low-level elements with little or no effort. We discussed how this was not possible with traditional testbench elements such as virtual sequencers and scoreboards. We showed that Breker’s graph-based scenario models can be simply combined from the block level to the cluster level, and from the cluster level to the full-chip level.
Last week, we took the unusual step of announcing a new EDA product via social media rather than a traditional press release. The news about TrekUVM clearly spread; we had a nice spike in blog readership and an even bigger spike in traffic to our Web site. Since our readers have interest in this new product, we’d like to continue talking about it and, specifically, show how it fosters model composition and vertical reuse.