Meta

Posts Tagged ‘graph-based’

Anyone who has followed Breker for any length of time knows that our key technology is the ability to generate both Universal Verification Methodology (UVM) testbench transactions and C test cases running on SoC embedded processors automatically from graph-based scenario models. Yes, that’s a long sentence but it’s most of the “elevator pitch” that we might deliver to a potential investor or to a visitor at a trade show booth asking what we do.

For the purposes of today’s post, note that graphs are the root of the solution we provide. Ten years ago, when we first began talking about the idea of graphs as the basis for functional verification of complex chip designs, we were the proverbial pioneer with arrows in our back. But many successful customer engagements and the ever-rising need for better verification have validated our position. Graphs are clearly the “next big thing” in verification and we’d like to explain why.

Anyone who reads The Breker Trekker from time to time needs no convincing from me that verification is a huge challenge for today’s complex chips. Breker’s Trek family of products exists, along with dozens if not hundreds of other EDA products, specifically to address functional verification. There are more technologies, tools, platforms, libraries, and methodologies than any one verification engineer can possibly learn and use on a day-to-day basis.

Why this diversity of solutions? As I first observed in Electronic Engineering Times nearly a decade ago, there is no silver bullet for verification. The problem is both so broad and so deep that no single tool or technology will ever satisfy the need. It takes a mix of solutions, guided by methodologies, to have any chance of first-silicon success. Low-power verification is an area where this is especially true, and unfortunately there is no silver bullet to be found here either.

Last week, we discussed the details of a noteworthy press release that we issued with Cadence and Mentor Graphics announcing a joint contribution to the Portable Stimulus Working Group (PSWG) of Accellera Systems Initiative. As we expected, this release stirred up a lot of interest in portable stimulus. The timing was perfect, both because of today’s deadline for contributions to the PSWG and because of last week’s DVCon India conference. I’d like to provide some updates on both activities.

First of all, the three companies did upload our joint contribution document to the PSWG internal Web site today in time for the deadline. Please note that, as per the rules for Accellera and most other standards groups, working documents are not available to the general public. If you’d like to see the contribution and follow the evolution of the standard, please consider joining the PSWG. If your company is not yet a member of Accellera, then please alert your standards manager to the benefits of participation.

This morning, Breker issued a press release with Cadence and Mentor Graphics announcing a joint contribution to the Portable Stimulus Working Group (PSWG) of Accellera Systems Initiative. We expect that this news may be surprising to much of the EDA world, so we’d like to take today’s post on The Breker Trekker to fill in some background and offer you the opportunity to ask questions. Please note that we are speaking only for Breker in this post although we doubtless share many opinions with our co-contributors.

Let’s start with a quick summary of how Accellera works so that all readers understand the context for this major contribution. The portable stimulus effort started with a Proposed Working Group last year that assessed the interest in a standard and defined a set of more than 100 requirements that such a standard would have to satisfy. Accellera approved the formation of the PSWG and we began meeting in March of this year. We have refined the requirements list and also developed a set of “use cases” showing the sort of real-world verification problems that a standard would have to address.

A month ago, our blog post on The Breker Trekker concerned life on the hardware-software frontier. We discussed the ever-shifting line between hardware and software and how we at Breker seem to be straddling that line as we generate embedded C/C++ test cases for hardware verification. Yesterday we published an article on the ongoing merger between the worlds of embedded systems and EDA. We made a number of observations about how the two industries are drawing closer together.

We didn’t talk about Breker in yesterday’s article, but today we’d like to connect these two threads and talk about how we are now straddling the increasingly fuzzy line between embedded and EDA verification. This is a topic we’ve discussed internally from time to time, and we have taken some steps into the embedded world by exhibiting at ARM TechCon and publishing articles in magazine and on sites geared toward embedded designers and programmers.

For the most part, the terms “verification” and “validation” are used interchangeably in the electronics industry. However, there are many who argue that these are distinct activities in the development of SoC s and systems, performed at different times in the schedule and usually by different groups of engineers. We refer to ourselves as “The SoC Verification Company” and this is a deliberate choice we made. So we thought that it would be useful to define the two terms as we see them and talk about the similarities and differences.

This post was inspired by an article from 2010 that our CFO and co-founder Maheen Hamid discovered recently. It opens with the “usual definitions” as follows:

Last week we discussed some of the drivers in the electronics industry influencing the program for the upcoming DVCon India, September 10-11 in Bangalore. The Technical Program Committee has completed its arduous task of selecting among many worthy proposals for sessions and has posted a near-final program. Today we’d like to highlight some of the most interesting aspects of the packed two days, focusing on sessions that we believe will be a particular draw for those who follow Breker and SoC verification.

There are four conference-wide keynote speeches, from Atul Bhatia (formerly of nSys), Harry Foster of Mentor, Manoj Gandhi of Synopsys, and Vinay Shenoy of Infineon. They will set the tone for the event by discussing the high-level challenges in designing and verifying leading-age semiconductor devices. Nick Heaton of Cadence will keynote the Design and Verification Track (DV) while Pankaj Singh of Infineon and Dr. Sacha Loitz of Continental will give invited talks in the Electronic System Level (ESL) track.

Many of our readers may recall that Breker aggressively promoted the inaugural DVCon India last year. We supported the show itself by sponsoring a booth in the exhibition and delivering three conference talks. It turned out, much to our delight, that that hottest topic at the show was portable stimulus. There was a great deal of interest in the newly formed Accellera Portable Stimulus Working Group (PSWG) and how Breker’s products provided a well-tested solution meeting all of the PSWG’s requirements.

The second DVCon India is less than a month away, on September 10-11 at Leela Palace in Bangalore. I have every expectation that portable stimulus will be a major theme again. We’re also very busy promoting the event to ensure its success, especially since I am co-chair of the Promotions Committee. I will be covering the details of the sessions and our own participation in next week’s blog post. For today, I’d like to focus on some of the industry drivers that are influencing the interest of potential attendees and the selection of content for the technical program.

In last week’s post, we spent quite a bit of time talking about the concept of a (realistic) use case that reflected how actual users will eventually manipulate the design being verified. Our focus was on Breker’s graph-based scenario models and how they can easily and concisely capture such use cases. We did some research on the term “use case” and found that it seems to be morecommon in software design and verification than in hardware verification. That caused us to think about how we at Breker seem to be living on the hardware-software frontier.

It’s not uncommon for hardware designers and software engineers to borrow ideas from each other. Code coverage, for example, was well established in software before it was adopted for hardware design and verification languages. With the move from gates to RTL, hardware became just another form of code and therefore more amenable to software techniques. This is just one example showing that the boundary between hardware and software is fuzzy and changing over time.

One of the signs that a technological domain is still fairly young is frequently evolving terminology as the pioneers attempt to explain to the mainstream what problem needs to be solved and what solutions can be brought to bear on the problem. Such is the case with SoC verification. At Breker we used to start explaining what we do by talking about graphs, but shifted to “graph-based scenario models” to emphasize that graphs are perfect for expressing scenarios of real-world behavior.

Our friends at Mentor, also strong advocates for graphs, began using the term “software-driven verification” to describe their approach. We rather like this description, but feel that it can only be applied accurately when embedded test code is being generated and when the embedded processors are in charge of the test case. Now our friends at Cadence have been sprinkling the term “use case” throughout their discussions on SoC and system verification. Let’s try to sort out what all this means.