Posts Tagged ‘EDA’
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…)
Tags: acceleration, applications, apps, Breker, coverage, EDA, emulation, FPGA prototyping, functional verification, graph, performance, portable stimulus, reuse, scenario model, SoC verification, transactional, TrekSoC, TrekSoC-Si, TrekUVM, UVC, uvm
No Comments »
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…)
Tags: ARM, Breker, Carbon, coherency, coverage, CPAK, EDA, functional verification, graph, performance, scenario model, SoC verification, TrekSoC, TrekSoC-Si, use cases
No Comments »
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…)
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
No Comments »
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…)
Tags: applications, apps, Breker, coverage, EDA, functional verification, graph, portable stimulus, reuse, scenario model, SoC verification, transactional, TrekSoC, TrekSoC-Si, TrekUVM, UVC, uvm
No Comments »
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…)
Tags: Breker, coverage, EDA, functional verification, graph, portable stimulus, reuse, scenario model, scoreboard, sequencer, SoC verification, transactional, TrekSoC, TrekSoC-Si, TrekUVM, UVC, uvm
3 Comments »
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…)
Tags: Breker, coverage, EDA, functional verification, graph, portable stimulus, reuse, scenario model, scoreboard, sequencer, SoC verification, transactional, TrekSoC, TrekSoC-Si, TrekUVM, UVC, uvm
No Comments »
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…)
Tags: Breker, coverage, EDA, functional verification, graph, portable stimulus, reuse, scenario model, scoreboard, sequencer, SoC verification, transactional, TrekSoC, UVC, uvm
No Comments »
Wednesday, July 30th, 2014
In our previous two posts, we went into considerable detail on the vertical reuse of verification information from IP block to subsystem to system. We have focused on how graph-based scenario models enable simple composition as you move up the design hierarchy. This type of reuse is not possible with traditional testbench elements such as UVM scoreboards and virtual sequencers. Once again, this is not a slam against the UVM, but rather a basic trait of constrained-random testbenches.
We skimmed over one aspect of vertical reuse: the transition from a “headless” SoC subsystem with no CPU to full-chip simulation with our automatically generated multi-threaded C test cases running on the SoC”s embedded processors. We also skipped the question of whether or not our graph-based scenario models can generate full-chip tests for chips that do not contain processors and are not classified as SoCs. This post links these ideas together and answers the question. (more…)
Tags: Accellera, Breker, coverage, EDA, functional verification, graph, portable stimulus, pwg, reuse, scenario model, scoreboard, sequencer, SoC verification, standards, UVC, uvm, working group
No Comments »
Tuesday, July 22nd, 2014
In our last post, we went into quite a detailed discussion of how the Accellera Universal Verification Methodology (UVM) has limitations on reuse. Specifically, we showed why it is not possible to compose scoreboards and virtual sequencers together as you move up the design hierarchy from verifying blocks to verifying clusters or complete chips. In the process, information about how connected blocks communicate is lost and must be recreated in the higher-level sequencer.
We also claimed that graph-based scenario models provide more effective reuse, specifically because lower-level graphs can be composed into a higher-level graph as blocks are combined and you move up the chip hierarchy vertically. Block-level graphs compose cluster-level graphs, and cluster-level graphs compose full-chip graphs. In today’s post, we take the same example used last time and show how reuse works with graph-based scenario models rather than pure UVM testbenches.
(more…)
Tags: Accellera, Breker, coverage, EDA, functional verification, graph, portable stimulus, pwg, reuse, scenario model, scoreboard, sequencer, SoC verification, standards, UVC, uvm, working group
2 Comments »
Thursday, July 17th, 2014
Over the lifetime of The Breker Trekker, we’ve published numerous posts about the inherent benefits of graph-based scenario models for verification. These models allow you to pull on a rope rather than push it. They allow you to begin with the end in mind, solving backwards to determine the necessary inputs. They support advanced verification planning and debug. They make verification modeling more pleasant. They enable both horizontal reuse over the course of a project and vertical reuse from IP block to subsystem to system.
Today we’d like to dig into a particular aspect of vertical reuse that we have not addressed in detail before. One of the goals of verification standards has been to define testbench elements that are reusable. This goal was very much in mind when the Accellera working group standardized the Universal Verification Methodology (UVM). By establishing a standard architecture, nomenclature, and application programming interface (API), UVM components are highly reusable from project to project and even company to company. However, the UVM fails at other forms of reuse.
(more…)
Tags: Accellera, Breker, coverage, EDA, functional verification, graph, portable stimulus, pwg, reuse, scenario model, scoreboard, sequencer, SoC verification, standards, UVC, uvm, working group
1 Comment »
|
