Open side-bar Menu
 The Breker Trekker

Posts Tagged ‘SystemVerilog’

Riding the Portable Stimulus Wave

Wednesday, September 16th, 2015

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.

(more…)

Breker, Cadence, and Mentor Accelerate Portable Stimulus Standard

Tuesday, September 8th, 2015

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.

(more…)

Portable Stimulus Layer 3: Test Randomization

Thursday, May 28th, 2015

Over the lifetime of this blog, we’ve covered a lot of diverse topics regarding Breker’s products and technology, trends in SoC verification, and the EDA industry in general. For the last month, we’ve offered our longest series of posts ever on a single topic: portable stimulus. There’s a very good reason for this: Accellera’s Portable Stimulus Working Group (PSWG) is making good progress on defining a standard in this area. As one of the group’s leaders, Breker has been leveraging our many years of experience in SoC verification to develop the best possible industry solution. We’ve been using The Breker Trekker blog to share our thoughts and to encourage your feedback.

We begin the fifth, and perhaps most important, post in our series by reminding you that we split portable stimulus into three layers: defining the tests using abstract primitive operations, scheduling the tests across multiple threads and multiple processors, and randomizing the control flow to verify the full range of realistic use-case scenarios. We have shown over the last two posts that both the first and second layers can be defined easily by a simple application programming interface (API) providing access to a base-class library. This library includes the basic building blocks needed for a directed or automated test as well as scheduling control for processors, threads, and resources. It is natural to wonder whether the randomization layer can be handled in a similar way.

(more…)

Portable Stimulus Layer 2: Test Scheduling

Wednesday, May 20th, 2015

Last week, we continued our  series of posts on the topic of “portable stimulus” as defined by Accellera’s Portable Stimulus Working Group (PSWG) and the standard they are working to define. We should say “we are working to define” since Breker is very much a part of the effort and is providing our many years of experience in this area to develop the best possible industry solution. As a reminder, we at Breker split the definition of a standard for portable stimulus into three parts: defining the tests using abstract primitive operations, scheduling the tests across multiple threads and multiple processors, and randomizing the control flow to verify the full range of realistic use-case scenarios.

Our most recent post dealt with the first layer: defining abstract tests using primitive operations and other elements within a base-class library, with access defined by a simple application programming interface (API). This week we consider the second layer: scheduling of tests and resources. If a verification engineer is writing a directed test for a single-processor SoC using the API calls from the first layer, then little of the second layer may apply. However, as we have discussed before, there is a clear trend of SoC designs moving to multi-processor designs with complex memory and cache subsystems and a rich variety of I/O protocols. These chips require automated test generation and the features provided by the test scheduling layer.

(more…)

Portable Stimulus Layer 1: Test Abstraction

Thursday, May 14th, 2015

From the number of blog views, it’s clear that the topic of “portable stimulus” is of considerable interest to our readers. As a reminder, Accellera’s Portable Stimulus Working Group (PSWG) is developing a standard in this area and Breker is helping to lead this effort. In our last two posts on this topic, we have outlined our guiding principles for any proposed standard, based on our own experience over the years with our most advanced customers. We also split the goal of the portable stimulus effort into three parts: defining the tests using abstract primitive operations, scheduling the tests across multiple threads and multiple processors, and randomizing the control flow to verify the full range of realistic use-case scenarios.

For this post, we’re going to explore the first level in more detail. We made the statement in our last post that the test abstraction level can be standardized using a simple application programming interface (API) to specify the abstract steps of the test. The API defines the access to a base-class library providing the primitive operations used to create portable tests. First of all, let’s be clear that this is not a theoretical proposal. We have provided a library with a defined API for several years and this is a key building block of our own portable stimulus and test solution. We know that this approach works from our own customers and believe that it would be an excellent foundation for a standard.

(more…)

Options for a Portable Stimulus Specification Format

Thursday, May 7th, 2015

In our last blog post we provided some updates on the ongoing effort by Accellera to standardize “portable stimulus” in its Portable Stimulus Working Group (PSWG). We mentioned our three guiding precepts as we participate in, and help lead, this industry effort:

  • Portable stimulus is not enough;  portable tests must encompass stimulus, results checking, and coverage
  • Test portability must encompass both vertical reuse from IP to SoC and horizontal reuse across all verification platforms
  • The tests themselves are not portable, but are generated for multiple targets from an abstract specification of the verification space

We stated our view that the goal of the portable stimulus effort can be split into three parts: defining the tests using abstract primitive operations, scheduling the tests across multiple threads and multiple processors, and randomizing the control flow to verify the full range of realistic use-case scenarios. We mentioned that the first part can be can be standardized using a simple application programming interface (API) to specify the abstract steps of the test. We have also found that the scheduling part can be handled by an expanded API. The user might want to specify the available resources and how they should be used in a particular test, for example, the number of threads running on each processor. When it comes to the third part, the randomization, an API might be feasible but there a number of candidate formats. We’d like to spend the remainder of this post examining these options.

(more…)




© 2024 Internet Business Systems, Inc.
670 Aberdeen Way, Milpitas, CA 95035
+1 (408) 882-6554 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise