Posts Tagged ‘C/C++’
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.
Wednesday, May 11th, 2016
The title of last week’s post was a play on a Mark Twain quote. This week I draw from a more contemporary source: The Muppets. Some episodes of the legendary family TV show featured a skit called “Pigs in Space.” In my head I’m reading “SoCs in Space!” with the same booming intonation used on the show for “Pigs in Space” to lead into a somewhat more serious discussion about the use of advanced chips in extreme conditions.
My prompt for this particular post came not from TV, but from an announcement yesterday that VORAGO Technologies is offering an ARM-based microcontroller (MCU) “designed specifically for radiation and extreme temperature operation without up-screening.” In other words, they ship an MCU that’s ready to use in such traditionally challenging environments as automobiles and industrial controllers as well as, yes, space. That got me thinking about even more complex chips such as SoCs and the extreme conditions they might have to face.
Thursday, May 5th, 2016
With a nod to Mark Twain, this week I’d like to comment on a recent three–part series with the provocative title “Are Simulation’s Days Numbered?” The articles were transcribed from one of the “experts at the table” events that SemiconductorEngineering does so well. Breker wasn’t involved in this particular roundtable, but I enjoyed reading the series and found that it stirred up some thoughts. As a blogger, of course I’m going to share them with you and I hope you enjoy them in turn.
Let’s get this out of the way immediately: in three parts and more than 5,000 words, there was no mention of portable stimulus. That might not seem too surprising given the title, but in fact verification portability both from IP to system and from simulation to hardware arose during the discussion. So I’ll comment on that but, given my background as a vendor of formal EDA tools and reusable IP blocks, there are a few other topics that also piqued my interest.
Tuesday, April 26th, 2016
Ever since Accellera started the Portable Stimulus Working Group (PSWG), this emerging technology has generated a lot of buzz both within the EDA industry and among our semiconductor and systems customers. As the pioneer in this technology we get a lot of questions about what portable stimulus is, why it is different from the Universal Verification Methodology (UVM) and other established approaches, and why anyone would need it.
We’ve devoted quite a few posts to this topic in The Brekker Treker blog, stretching back two years to when Accellera first set up a proposed working group (PWG) to survey the industry and decided whether standardization of portable stimulus was feasible and desirable. Given the many posts scattered throughout the past two years, we thought that we would take this opportunity to give readers new to this topic a guided tour of the information that we have available.
Thursday, March 24th, 2016
Last week, we used an update on the Accellera Portable Stimulus Working Group (PSWG) presented at the Design and Verification Conference and Exhibition (DVCon) as a jumping-off point to discuss the status of this standardization effort and some key aspects of the three proposals currently under consideration. We were not the only blog to cover portable stimulus topics from DVCon; Brian Bailey of SemiconductorEngineering and Bernard Murphy from SemiWiki also posted their observations.
Earlier this week, EDACafe blogger colleague Peggy Aycinena posted a thought-provoking look at PSWG and the portable stimulus challenge. In regards to the scope of the proposed standard, she noted “a distinct wow factor in all of this, it’s so comprehensive” and said “this whole effort seems massive to me.” Today we’d like to respond to Peggy’s comments and questions, noting both the challenges of a portable stimulus standard and the availability of a working solution today.
Wednesday, March 16th, 2016
As all of our regular readers are aware, the software-driven SoC verification space pioneered by Breker is becoming more of a mainstream approach every day. One good barometer for the industry shift now underway is the standardization effort in progress within the Accellera Portable Stimulus Working Group (PSWG). The amount of interest in this standard has skyrocketed recently, and portable stimulus was a hot topic at the Design and Verification Conference and Exhibition (DVCon) two weeks ago.
As we promised when we first began discussing the PSWG, we don’t believe in sharing internal details of standardization work in a public blog. However, the group was offered a slot to present an update at an Accellera-sponsored lunch during DVCon. So the PSWG put together a set of slides with information to share publicly and Vice-Chair Tom Fitzpatrick of Mentor did a nice job of presenting them. For those of you who could not attend, we’ll summarize the current status in today’s blog post.
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.