A Concise History of the Breker Product Line

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.

Let’s start with a bit of history. Breker began life in 2003 as a services company, with co-founder Adnan Hamid leveraging his background in graph-based verification to apply this technology on a consulting basis. In his “spare” time, he was productizing his software with an eye toward evolving Breker into an EDA company. Just before the Design Automation Conference (DAC) in 2007, we announced our Trek engine, a graph-based constraint solver capable of generating transactional tests to supplement existing simulation testbenches.

As the company worked with its initial set of customers, Trek was successful at helping chip development teams hit deep behaviors and achieve coverage goals automatically, much faster and with much less effort than hand-writing tests. We made a successful transition from a services company to a product company. Over time, we found that developers of system-on-chip (SoC) devices had an additional problem: there was no industry methodology for coordinating a testbench with the code running in the SoC’s embedded processors.

At the start of 2012, we introduced TrekSoC, which generates multi-processor, multi-threaded test cases and provides automatic closure for system-level coverage. TrekSoC generates transactions for the testbench as well as C code for the embedded processors, and ties them together in the TrekBox run-time component. This opened the benefits of graph-based verification to SoC developers and launched us into supporting some amazing customer projects, including one chip with nearly 100 processors.

At ARM TechCon last October, we announced TrekSoC-Si, which generates test cases optimized for performance in hardware platforms such as emulation, FPGA prototyping, and actual silicon in the lab. This also led us into more interesting projects, including silicon validation of an x86 server chip using the first chips back from the foundry. We have a case study of this project available on request.

Although we didn’t talk about it as much, since 2012 the original Trek product has continued to be used by a number of customers. A lot of new technology was developed for TrekSoC, including multi-threading, debug displays, and easy connection to testbenches and VIP compliant with the Universal Verification Methodology (UVM). We felt that it was important to make these benefits available to customers not designing SoCs, and so in August this year we introduced our TrekUVM product.

TrekUVM provides all the benefits of TrekSoC for verifying chips in transactional testbenches, except that we don’t generate C code since there are no embedded processors on which to run it. We generate multi-threaded test cases, easily connected to existing UVM testbenches, and provide the same system coverage features as TrekSoC. The original Trek engine is still available for those who want to do custom graph-based applications. Trek also sits at the heart of TrekUVM, TrekSoC, and TrekSoC-Si.

To complete the picture, two weeks ago we introduced the Coherency TrekApp, the first in a series of “apps” that will address specific verification problems. This app is focused on providing out-of-the-box verification of multi-processor cache coherency. Our TrekApp line will grow over time, likely covering such areas as low-power verification and compliance to standard interface protocols.

So the scope of our current product line stretches from IP block through complete system, from simulation through silicon, and from transactional testbenches to software-driven verification for SoCs. We should note that the “simulation” category includes electronic system-level (ESL) models such as virtual prototypes, high-level synthesis models, RTL models, and even gates. Our test cases will run on any platform used by anyone in the development process, from systems architects through silicon validation engineers.

We hope that this post has clarified our current product line and staked out the turf where we want to be the vendor of choice for functional verification. In a future post, we’ll attempt to distill all this information down into a simple product line diagram. That may prove challenging…

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: applications, apps, Breker, coverage, EDA, ESL, functional verification, graph, portable stimulus, products, reuse, scenario model, SoC verification, software-driven verification, transactional, Trek, TrekSoC, TrekSoC-Si, TrekUVM, UVC, uvm

This entry was posted on Wednesday, September 17th, 2014 at 6:42 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.