Posts Tagged ‘TrekSoC’
Thursday, October 30th, 2014
In last week’s post, we discussed in detail how Breker’s TrekSoC and TrekSoC-Si products can verify the performance of your SoC by stressing every aspect of its functionality. Shortly before that, we announced a partnership with Carbon Design Systems to complement their fast, accurate processor models with TrekSoC. About two months ago, we introduced the new Coherency TrekApp and described how it can verify multi-processor cache coherency with minimal effort.
You can see a strong theme here: multi-processor SoC designs, fast simulation models, automatic generation of multi-threaded, multi-processor test cases, and test cases powerful enough to gather realistic performance metrics from pre-silicon simulation. But what if you don’t have multiple processors or caches in your SoC design? There’s a clear sense emerging in the industry that more and more chips are becoming multi-processor SoCs, and most of these will require cache coherency for the CPU clusters and beyond. Let’s explore this topic more in this post.
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 9th, 2014
What verification engineer doesn’t love the occasional conference? It’s a chance to get out of the cubicle farm, hang out with colleagues from other companies, listen to stimulating technical talks, and catch up on what EDA, IP, and semiconductor vendors have been doing. Even in a time of tight travel budgets, the right conference can provide dividends far beyond its cost. There are a lot of smart people in the electronics industry and it’s valuable to share problems and solutions with them.
There are actually quite a few conferences and trade shows that have interesting verification content and draw significant numbers of verification engineers. One of the most-read posts in the history of The Breker Trekker blog was a discussion on which conferences verification engineers like best. We are constantly evaluating which events provide the most value to us and our customers, and find ourselves in the unusual position of having four shows scheduled in four locations over the next four weeks.
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.
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.
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.
Thursday, June 5th, 2014
The 51st Design Automation Conference (DAC) has passed into the history books with three days of exhibits and a wide range of enveloping technical sessions and tutorials. After returning home, I’m thinking back over the week fondly as I nurse feet that ache more than I thought possible. Before I get back into the usual work routine, I want to capture some of the impressions and thoughts running through my head.
There is no doubt that big forces in the industry are aligning toward our view of SoC verification with graph-based scenario models. Many of the people who stopped by our “USS Ice Breker” booth completely understood that they risked hitting an iceberg with their minimal full-chip verification efforts. Some had heard about Breker from colleagues or had seen us listed in Gary Smith’s and John Cooley’s DAC “must see” lists. Others knew little about us but were attracted by our claim as “The SoC Verification Company.” All wanted to know how we can help them.