Open side-bar Menu
 The Breker Trekker

Posts Tagged ‘scenario model’

Verification Needed to Take High-Level Synthesis Mainstream

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.

(more…)

Will Breker Become an IP Company?

Tuesday, November 18th, 2014

In last week’s blog post, we talked about the emergence of the commercial IP industry and shared some personal experiences. Although Breker is an EDA company and not known for IP products, we intersect with semiconductor IP (SIP) and verification IP (VIP) in important ways as we work with our customers. We’re also starting to offer our own scenario model IP (SMIP) as part of accelerating and improving verification even more. We’d like to expand on these topics in today’s post.

We have few if any customers or prospective customers who don’t use commercial VIP in their testbenches. After all, if you’re designing a standard interface you want the best verification possible that you’re meeting the standard. A VIP model that’s been used by dozens or hundreds of other projects serves as a pre-silicon “plugfest” where you get to verify your implementation of the standard against what others have done. Now that the Universal Verification Methodology (UVM) is nearly ubiquitous, most VIP is developed in a fairly consistent manner.

(more…)

Some Thoughts on SIPs, VIPs, and SMIPs

Thursday, November 13th, 2014

In my recent report from the Silicon Valley IP Users Conference, I passed on the prediction that the compound annual growth rate (CAGR) of semiconductor (SIP) is expected to be 12% for the next five years. Clearly there is a growing need for portions of huge SoCs to be pre-designed, pre-verified, and delivered as reusable SIP. This is a trend that started about 20 years ago with the earliest SIP vendors selling libraries and cores for standardized functions along with verification IP (VIP) to support their use.

The IP (SIP and VIP) industry has evolved a lot since then. The most obvious change is that it has been largely consumed by the major EDA companies. Synopsys and Cadence, in particular, have made many acquisitions in this space over the past few years. Some of the price tags have been quite impressive:  US$380M  for Tensilica, US$315M for Virage, and about the same price for Denali. In this post, I’d like to share some thoughts on the evolution of the IP business.

(more…)

Performance Verification: Bringing Your SoC to Its Knees

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.

(more…)

Breker and Carbon Team Up to Provide Fast, Accurate SoC Verification

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.

(more…)

A Concise History of the Breker Product Line

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.

(more…)

Cache Coherency? Breker Provides An App for That

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.

(more…)

Composition, Chaining, and Vertical Reuse with TrekUVM

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.

(more…)

Introducing TrekUVM: Enhancing Transactional UVM Testbenches

Thursday, August 14th, 2014

In our previous four posts, we have woven a story quite different from the way we’ve talked about Breker and our technology for the past few years. Regular readers know that our focus has been on verifying system-on-chip (SoC) designs by generated multi-threaded, self-verifying C test cases to run on the SoC’s embedded processors. TrekSoC generates these test cases for simulation with RTL or ESL models; TrekSoC-Si generates test cases for emulator, FPGA prototypes, and actual silicon.

The last few posts have pointed out that TrekSoC has had to handle running in a transactional testbench since many test cases send data on or off the chip. We’ve worked hard to ensure that we can integrate easily into testbenches compliant with the Universal Verification Methodology (UVM) standard. Today we leverage this knowledge as we introduce TrekUVM, which generates multi-threaded, self-verifying test cases for a purely transactional UVM testbench.

(more…)

Transactional Design Verification with TrekSoC

Thursday, August 7th, 2014

In our last blog post, we worked our way up the conclusion that our TrekSoC product can be used to verify designs that do not contain embedded processors. As we noted, there is not a widely accepted industry term for such devices. For the moment, let’s call them “transactional designs” since the majority of them take transactions in at one end and generate transactions at the other end, sometimes for two very different protocols, and are often bidirectional in nature.

The technological argument is simple. Most SoCs also have I/O ports, both standard buses and proprietary protocols, and TrekSoC must be able to talk to them, coordinate among them, and synchronize their transactions with generated C code running in the embedded processors. A purely transactional chip and testbench form a subset of the challenge for which TrekSoC is designed, so it’s not surprising that we can help. Today’s post fills in some more details.

(more…)




© 2024 Internet Business Systems, Inc.
670 Aberdeen Way, Milpitas, CA 95035
+1 (408) 882-6554 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise