Posts Tagged ‘applications’
Thursday, August 18th, 2016
When we first began offering our Trek family of products for what’s now known as portable stimulus, we talked a lot about vertical and horizontal reuse. Vertical reuse means that you can create a scenario model for individual IP blocks and generate test cases to run in their UVM testbenches, then move up to clusters and subsystems. The IP models can simply be plugged together to form a higher-level model from which appropriate higher-level test cases can be generated.
At the full-SoC level, you can generate C test cases that run on your embedded processors. Horizontal reuse is the ability to move from simulation to hardware (acceleration/emulation, FPGA prototypes, and silicon) while generating appropriate tests for these platforms from the same SoC scenario model. We generally described both forms of reuse in a unidirectional flow. However, bidirectionality is very valuable and, we believe, essential for portable stimulus. Let’s cover that topic in today’s blog post.
Wednesday, July 27th, 2016
Three weeks ago on The Breker Trekker, we published a post on “The Return of EDA Startups, Behemoths, Corner Stores, and Zombies” and saw a nice uptick in viewing. Zombies are always popular with our audience. Our post prompted some interesting observations from today’s guest blogger, Excellicon’s Sales and Operations VP Rick Eram. He has some thoughts on this way of dividing the EDA industry and suggestions on how customers should treat the different players:
The concept of corner stores is interesting since they pave the way for development and deployment of newer analysis and implementation technologies addressing today’s design challenges that are either not addressed by majors, involve much manual work despite available products, or are addressed by products that create a huge amount of data without means for interpretation. The startups develop new technologies and, while deploying their technology on their way to becoming corner stores, they master ways to deploy such new technologies. What differentiates corner stores from zombies is the deployment of the technology. These companies are the engines of innovation in today’s EDA industry and help the behemoths to cover the gaps in their traditional technologies after the newer technology catches on and adds value for customers.
Wednesday, July 20th, 2016
Few recent announcements in the EDA, IP, or semiconductor industries have had the impact of SoftBank’s proposed US$32B acquisition of ARM. Many commentators have weighed in on this news. Today’s guest blogger, OneSpin Solutions Vice President of Marketing David Kelf, shares some thoughts on how changes to the ARM universe might intersect with ongoing changes in the open source community:
One side effect of the ARM acquisition news was an increase in the debate on the fascinating RISC-V Open Source processor development. Clearly this has the interest of a number of significant ARM users, judging by the recent workshop at MIT last week as one example, and might represent a significant game changer. It also begs the question on the application of Open Source, and indeed standardization efforts in general, in verification and how programs in this area might change the dynamics of increasingly closed environments from the two largest EDA vendors. (more…)
Thursday, July 14th, 2016
Recently, SemiconductorEngineering published the three–part series “System-Level Verification Tackles New Role” as part of its ongoing “Experts at the Table” discussions. The format is simple–an editor sits down with four or five industry experts to discuss a particular topic–but the debate can be lively and the result educational. Breker participates in these roundtables as often as we can, focusing of course on verification among the many technical topics covered by the site.
In advertising a “new role” for system-level verification, this particular series was not overstating the case. We tend to talk a lot about the evolution of verification in general, especially for system-on-chip (SoC) devices and multi-SoC systems. But in some ways what is happening now with our products and the Accellera portable stimulus standardization effort is more revolutionary than evolutionary. So which is it? We’ll attempt to answer that question in today’s post here on The Breker Trekker blog.
Tuesday, July 5th, 2016
If the title of today’s post sounds familiar, that’s not surprising. The most popular post in the history of The Breker Trekker blog, by a significant margin, was “An EDA Industry of Startups, Behemoths, Corner Stores, and Zombies?” published almost three years ago. I thought that it would be fun to revisit this topic in light of the changes in the EDA industry over the past three years. Have these changes fundamentally altered our world? Please read on to see.
I’ll begin, as I did in the original post, by noting that the EDA industry used to be divided into only three categories: major leaguers, minor leaguers, and startups. Nearly all EDA startups disappeared after three or four years, with three possible endgames: acquisition, initial public offering (IPO), or bankruptcy. The major leaguers, at one time or another, included Daisy, Mentor, Valid, Cadence, Synopsys, and Avant.
Wednesday, June 29th, 2016
Over the more than three years of posts here on The Breker Trekker blog, you’ve seen us reference our TrekBox runtime component on many occasions. We mention it in many contexts: test case visualization, memory usage visualization, test case status, test case debugging, system-level coverage, performance analysis, I/O interfacing, UVM testbench control, and more. We’ve never had a post on TrekBox itself, so today we rectify that and fill in a few details that we haven’t discussed before.
Some of you are familiar with the term “trickbox” in the context of a simulation testbench. We found a nice concise definition of this term in an ARM patent: “Memory mapped (behavioral) test bench component to facilitate verification.” By writing to designated memory addresses, the processors in the design being verified can send messages to the testbench for various actions. Our TrekBox is of course a play on the “trickbox” name, and it provides many presents inside for those who open it.
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.
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.
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.