Posts Tagged ‘API’
Wednesday, August 10th, 2016
As some of you may have seen, two years ago the IEEE created an app that ranks the popularity of dozens of programming languages. They use twelve different metrics, from search results and social media mentions to technical publications and requirements listed in job openings. If you don’t like the way that they use these metrics, you can create your own ranking using your own mix. It’s really quite a clever idea and it generates lots of discussion every year.
For 2014 and 2015, C held the #2 spot, just below Java in the rankings. The big news this year is that C has edged into first place, although the top two spots remain very close as measured by the metrics the IEEE has chosen to use. C++ was in the #3 spot for the past two years, but for 2016 flipped places with Python. As you all know, we are strong advocates of C/C++ for verification and so we’d like to share some thoughts on these results and what they mean for our industry.
Tuesday, November 17th, 2015
In last week’s post, we dissected the results for verification languages and methodologies from a recent survey by Mentor Graphics and Wilson Research Group. The main result was that SystemVerilog is growing in popularity on all fronts, but we observed that C/C++ has a significant presence. We also argued that the survey’s focus on simulation likely resulted in C/C++ being under-represented since these languages are widely used for verification with hardware platforms and for silicon validation in the lab.
We see C/C++ as the common link for many types of programming activities, and so widely known that many consider it the lingua franca of software. Just type “lingua franca C/C++” into your favorite search engine and scan the results for some interesting arguments and a few counter-arguments. To be fair, some observers consider C the lingua franca and downplay C++. We tend to group them together since object-oriented programming is now widespread and so moving from C to C++ should be a natural transition.
Wednesday, November 11th, 2015
One of the cliches we hear from time to time in the industry is “designers want to stick with a single language, but verification engineers love learning new things.” The implication seems to be that because verification engineers have diverse jobs that require them to juggle lots of different tools and models, they necessarily have to learn new languages and methodologies on a regular basis. Of course, they may not actually love learning new languages; doing so may just be in the nature of their work.
Regardless of whether or not they “love” new languages, it is clear that most verification projects involve multiple languages and multiple approaches. One way to gauge the current situation is to turn to the excellent survey that Mentor Graphics performs with Wilson Research Group every couple of years. Harry Foster wrote a series of posts on the Mentor verification blog that give considerable insight into what verification (and design) engineers are doing on real projects.
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.
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.
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.
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.
Wednesday, April 29th, 2015
We’ve discussed at some length in past blog posts the recent effort by Accellera to standardize “portable stimulus” in its Portable Stimulus Working Group (PSWG). As a reminder, this group has been chartered by Accellera to “develop the electronic industry’s first standard for portable test and stimulus. When completed and adopted, this standard will enable a single specification that will be portable from IP to full system and across multiple target implementations.” At trade shows and customer meetings, we’re often asked to explain more about what the concept of portable stimulus means and how it relates to our products. We’ve also been asked for details on the workings of the PSWG and what is likely to happen in terms of a possible standard.
Let us be clear that neither this post nor future posts will reveal the inner workings of the PSWG or share non-public information. We believe strongly that standards bodies must do their jobs with a minimum of distraction. Members must be able to propose and discuss ideas that might seem crazy to those not actually doing the work and without the proper context. There are also IP rights and patent implications to some portions of the standardization process. So this won’t be a “kiss and tell” opportunity. If you want to know what’s happening on the standard right now, we invite your company to join Accellera and contribute a member of two to the PSWG. But for this post, we will take this opportunity to provide some background on the portable stimulus arena and share what we think is important.