Posts Tagged ‘Verification’

3 January, 2017

Deeper Dive into First Silicon Success and Safety Critical Designs

This blog is a continuation of a series of blogs related to the 2016 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I presented verification results in terms of schedules, number of required spins, and classification of functional bugs. In this blog, I conclude the series by having a little fun with some of the findings from our recent study.

You might recall from our 2014 study we did a deeper dive into the findings made a non-intuitive observation related to design size and first silicon success. That is, the smaller the design the less likelihood of achieving first silicon success (see 2014 conclusion blog for details). This observation still holds true in 2016.

For our 2016 study, we decided to do a deeper dive related to the following:

  1. Verification maturity and silicon success, and
  2. Safety critical designs and silicon successes.

Verification Maturity and Silicon Success

Figure 1 presents the findings for ASIC/IC first silicon success, and Figure 2 presents the findings for FPGA non-trivial bug escapes into production. It is important to note that only 33 percent of ASIC/IC projects are able to achieve first silicon success, and only 22 percent of FPGA projects go into production without a non-trivial bug.

BLOG-2016-WRG-figure-Con-1

Figure 1. ASIC/IC required spins before final production

BLOG-2016-WRG-figure-Con-2

Figure 2. FPGA non-trivial bug escapes into production

A question worth asking is if there might be some correlation between project success (in terms of preventing bugs) and verification maturity. To answer this question we looked at verification technology adoption trends related to a project’s silicon success.

Figure 3 presents the adoption of various verification techniques related to ASIC/IC projects, and then correlates these results against achieving first silicon success. The data suggest that the more mature an ASIC/IC project is in its adoption of verification technology the more likelihood of achieving first silicon success.

BLOG-2016-WRG-figure-Con-3

Figure 3. ASIC/IC spins and verification maturity.

Similarly, in Figure 4 we examine the adoption of various verification techniques on FPGA projects, and then correlate these results against preventing non-trivial bug escapes into production. Again, the data suggest that the more mature an FPGA project is in its adoption of verification technology the more likelihood that a non-trivial bug will not escape into production.

BLOG-2016-WRG-figure-Con-4

Figure 4. FPGA non-trivial bug escapes into production and verification maturity.

Safety Critical Designs and Silicon Success

The second aspect of our 2016 study that we decided to examine a little deeper relates to safety critical designs and their silicon success. Intuitively, one might think that the rigid and structured process required to adhere to one of the safety critical development processes (such as, DO-254 for mil/aero, ISO 26262 for automotive, IEC 60601 for medical, etc.) would yield higher quality in terms of preventing bugs and achieving silicon success.

Figure 5 shows the percentage of ASIC/IC and FPGA projects that claimed to be working on a safety critical design.

BLOG-2016-WRG-figure-Con-5

Figure 5. Percentage of projects working on safety critical designs

Keep in mind that the findings in Figure 5 do not represent volume in terms of silicon production—the data represents projects that claim to work under one of the safety critical development process standards.  Using this partition between projects working on non-safety critical and safety critical designs we decided to see how these two classes of projects compared in terms of preventing bugs.

Figure 6 compares the number of required spins for both safety critical and non-safety critical ASIC/IC designs. While Figure 7 compares the FPGA designs with non-trivial bug escapes for both safety critical and non-safety critical designs.

BLOG-2016-WRG-figure-Con-6

Figure 6. Requires ASIC/IC spins for safety critical vs. non-safety critical designs

 BLOG-2016-WRG-figure-Con-7

Figure 7. Non-trivial bug escapes for safety critical vs. non-safety critical FPGA designs

Clearly, the data suggest that a development process adopted to ensure safety does not necessarily ensure quality. Perhaps this is non-intuitive. However, to be fair, many of the safety critical features implemented in today’s designs are quite complex and increase the verification burden.

This concludes the findings from the 2016 Wilson Research Group Study.

Quick links to the 2016 Wilson Research Group Study results

, , , , , ,

6 December, 2016

Emulation technology has been around for a long time—more than four decades by my count—and industry observers believe more than ever that it’s a key ingredient in the IC verification strategy, albeit with a rebirth. The question is, what is this new era of emulation all about and why is hardware emulation, which remained on the fringes of IC design ecosystem with a small customer base for many years, now becoming a mainstream design tool for system-on-chip (SoC) verification? The answer can be found in the advent of bigger and more complex chips that often contain multiple processor cores and exceed 100 million gates.

In a nutshell, a register-transfer-level (RTL) simulator, a go-to verification tool is being challenged as design capacity surpasses 100 million gates.  Greater gate counts are possible because of the scaling roadmap for processors.  After all, there is only so much you can do with multi-threading. Next, even hardware-description-language (HDL) software simulators running in parallel over PC farms don’t create a viable option because design-under-test (DUT) environments are sequential in nature.

On the other hand, hardware emulation, once the staple of large IC designs like processors and graphic chips, is now becoming a popular verification tool precisely because it runs faster than HDL simulators for full-chip verification. A hardware emulation tool can run the verification of large, SoC designs over 10 times and sometimes much greater than 10 times faster than software simulation.

Graphic 1 for blog

The view of the key verification modes supported by Mentor Graphics’ Veloce emulator platform.

Hardware emulation has been steadily evolving over the past decade or so, as the cost of ownership is coming down while emulation tools are becoming easier to install and operate. And with the changing equation of emulator ROI and SoC design imperatives, an increasing number of IC designers are inclined to use emulation tools for debugging the hardware and testing hardware and software integration. Moreover, emulation tools are becoming more versatile, ranging from in-circuit emulation (ICE), where physical devices are cabled to the emulator, to more innovative co-emulation solutions like Veloce VirtuaLAB that virtualizes the interfaces amid the growing functionality of today’s SoC designs.

Software simulation or hardware emulation

A simulator tries to model the behavior of the SoC or system-level design while an emulator creates an actual implementation of the design. Here, it’s important to note that both software simulators and hardware emulators are employed for design verification—a stage also known as design-under-test or DUT—where a compiler converts the design model into a data structure stored in memory.

However, in the case of simulation, a software algorithm processes the data representing a design model using a design language, while an emulator processes the data structure using a compute engine enabled by a processor array. Although hardware emulation is growing beyond a $300 million market, it doesn’t mean that it’s going to be the end of the road for HDL simulation tools.

 large SoC graphic

The Veloce emulator, which supports both traditional ICE and transaction-based verification, runs verification of SoCs with multiple protocol interfaces.

HDL-based software simulation will most likely remain the verification engine of choice, especially at the early stage of verification process—for instance, at the IP and subsystem levels—as it represents an economical, easy-to-use, and quick-to-setup EDA tool. On the other hand, emulation will gain traction in larger SoC designs that encompass millions of verification cycles and where hardware bugs are difficult to find. In other words, the two EDA tool markets for SoC and system-level design verification will co-exist for the foreseeable future.

, , , , , , , , ,

2 December, 2016

ASIC/IC Verification Results

This blog is a continuation of a series of blogs related to the 2016 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I provided data related to designs that actively manage power. In this blog, I present verification results findings in terms of schedules, number of required spins, and classification of functional bugs.

BLOG-2016-WRG-figure-12-1

Figure 1. Design Completion Compared to Original Schedule

Figure 1 presents the design completion time compared to the project’s original schedule. While the data suggest that in 2014 there might have been a slight improvement in projects meeting their original schedule, the 2016 findings are consistent with the 2007 and 2012 studies. The bottom line is that meeting the originally planned schedule is still a challenge for most of the industry.

BLOG-2016-WRG-figure-12-2

Figure 2. Required Number of Spins

Other results trends worth examining relate to the number of spins required between the start of a project and final production. Figure 2 shows this industry trend from 2012 through 2016. Even though designs have increased in complexity, the data suggest that achieving first silicon success is not getting any worse in terms of the number of required spins before production. Still, only a little more than 30 percent of today’s projects are able to achieve first silicon success. In addition, it is worth noting that achieving second silicon success is getting worse.

Figure 3 shows various categories of flaws that are contributing to respins. Again, you might note that the sum is greater than 100 percent on this graph, which is because multiple flaws can trigger a respin.

BLOG-2016-WRG-figure-12-3

Figure 3. Types of Flaws Resulting in Respins

Logic and functional flaws remain the leading causes of respins. One observation from the 2016 study is that there seems to have been a spike in the number of respins due to power issues.

Figure 4 examines the root cause of logical or functional flaws (previously identified in Figure 3) by various categories. The data suggest design errors are the leading cause of functional flaws, and the situation is worsening. In addition, problems associated with changing, incorrect, and incomplete specifications are a common theme often voiced by many verification engineers and project managers.

BLOG-2016-WRG-figure-12-4

Figure 4. Root Cause of Functional Flaws

In my next blog (click here), I provide some concluding remarks and observations.

Quick links to the 2016 Wilson Research Group Study results

,

21 November, 2016

ASIC/IC Power Trends

This blog is a continuation of a series of blogs related to the 2016 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I presented our study findings on various verification language and library adoption trends. In this blog, I focus on power trends.

Today, we see that about 72 percent of design projects actively manage power with a wide variety of techniques, ranging from simple clock-gating, to complex hypervisor/OS-controlled power management schemes (see Figure 1). This is essentially unchanged from our 2014 study.

BLOG-2016-WRG-figure-11-1

Figure 1. ASIC/IC projects working on designs that actively manage power

Figure 2 shows the various aspects of power-management that design projects must verify (for those 72 percent of design projects that actively manage power). The data from our study suggest that many projects are moving to more complex power-management schemes that involve software control. This adds a new layer of complexity to a project’s verification challenge, since these more complex power management schedules often require emulation to fully verify.

BLOG-2016-WRG-figure-11-2

Figure 2. Aspects of power-managed design that are verified

Since the power intent cannot be directly described in an RTL model, alternative supporting notations have recently emerged to capture the power intent. In the 2016 study, we wanted to get a sense of where the industry stands in adopting these various notations and what we found was essentially no change from our 2014 study. For projects that actively manage power, Figure 3 shows the various standards used to describe power intent that have been adopted. Some projects are actively using multiple standards (such as different versions of UPF or a combination of CPF and UPF). That’s why the adoption results do not sum to 100 percent.

BLOG-2016-WRG-figure-11-3

Figure 3. Notation used to describe power intent

In an earlier blog in this series, I provided data that suggest a significant amount of effort is being applied to ASIC/IC functional verification. An important question the various studies have tried to answer is whether this increasing effort is paying off. In my next blog (click here), I present verification results findings in terms of schedules, number of required spins, and classification of functional bugs.

Quick links to the 2016 Wilson Research Group Study results

, , , , , ,

31 October, 2016

ASIC/IC Language and Library Adoption Trends

This blog is a continuation of a series of blogs related to the 2016 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I focused on I various verification technology adoption trends. In this blog I plan to discuss various ASIC/IC language and library adoption trends..

Figure 1 shows the adoption trends for languages used to create RTL designs. Essentially, the adoption rates for all languages used to create RTL designs is projected to be either declining or flat over the next year.

BLOG-2016-WRG-figure-10-1

Figure 1. ASIC/IC Languages Used for RTL Design

As previously noted, the reason some of the results sum to more than 100 percent is that some projects are using multiple languages; thus, individual projects can have multiple answers.

Figure 2 shows the adoption trends for languages used to create ASIC/IC testbenches. Essentially, the adoption rates for all languages used to create testbenches are either declining or flat. Furthermore, the data suggest that SystemVerilog adoption is starting to saturate or level off in the mid-70s range.

BLOG-2016-WRG-figure-10-2

Figure 2. ASIC/IC Languages Used for  Verification (Testbenches)

Figure 3 shows the adoption trends for various ASIC/IC testbench methodologies built using class libraries.

BLOG-2016-WRG-figure-10-3

Figure 3. ASIC/IC Methodologies and Testbench Base-Class Libraries

Here we see a decline in adoption of all methodologies and class libraries with the exception of Accellera’s UVM, whose adoption continued to increase between 2014 and 2016. Furthermore, our study revealed that UVM is projected to continue its growth over the next year. However, like SystemVerlog, it will likely start to level off in the mid- to upper-70 percent range.

Figure 4 shows the ASIC/IC industry adoption trends for various assertion languages, and again, SystemVerilog Assertions seems to have saturated or leveled off.

BLOG-2016-WRG-figure-10-4

Figure 4. ASIC/IC Assertion Language Adoption

In my next blog (click here) I plan to present the ASIC/IC design and verification power trends.

Quick links to the 2016 Wilson Research Group Study results

, , , , , , , , , , , , , , , , , , ,

10 October, 2016

ASIC/IC Verification Technology Adoption Trends

This blog is a continuation of a series of blogs related to the 2016 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I focused on the growing ASIC/IC design project resource trends due to rising design complexity. In this blog I examine various verification technology adoption trends.

Dynamic Verification Techniques

Figure 1 shows the ASIC/IC adoption trends for various simulation-based techniques from 2007 through 2016, which include code coverage, assertions, functional coverage, and constrained-random simulation.

BLOG-2016-WRG-figure-9-1

Figure 1. ASIC/IC Dynamic Verification Technology Adoption Trends

One observation from these adoption trends is that the ASIC/IC electronic design industry has matured its verification processes. This maturity is likely due to the growing complexity of designs as discussed in the previous section. Another observation is that constrained-random simulation and code coverage adoption appears to have declined. However, as I mentioned in Part 7 (click here) one interesting observation for this year’s study is that there was a large increase in design projects working on designs less than 100K gates, perhaps is due to an increased number of projects working on smaller sensor chips for IoT devices. Nonetheless, it is important to keep in mind that very small projects do not apply advanced verification techniques, which can bias the overall industry verification technique adoption trends in some cases. Hence, in reality the adoption of constrained-random simulation and code coverage has actually leveled off (versus declined) if you ignore these very small devices.

Another reason constrained-random simulation has leveled off is due to its scaling limitations. Constrained-random simulation generally works well at the IP block or subsystem level, but does not scale to the entire SoC integration level.

ASIC/IC Static Verification Techniques

Figure 2 shows the ASIC/IC adoption trends for formal property checking (e.g., model checking), as well as automatic formal applications (e.g., SoC integration connectivity checking, deadlock detection, X semantic safety checks, coverage reachability analysis, and many other properties that can be automatically extracted and then formally proven). Formal property checking traditionally has been a high-effort process requiring specialized skills and expertise. However, the recent emergence of automatic formal applications provides narrowly focused solutions and does not require specialized skills to adopt. While formal property checking adoption is experiencing incremental growth between 2012 and 2014, the adoption of automatic formal applications increased by 62 percent during this period. What was interesting in 2016 was that formal property checking experience a 31 percent increase since the 2014 study, while automatic formal applications was essentially flat, which I suspect is a temporary phenomenon. Regardless, if you calculate the compounded annual growth rate between 2012 and 2016, you see healthy adoption growth for both, as shown in Figure 2.

BLOG-2016-WRG-figure-9-2

Figure 2. ASIC/IC Formal Technology Adoption

Emulation and FPGA Prototyping

Historically, the simulation market has depended on processor frequency scaling as one means of continual improvement in simulation performance. However, as processor frequency scaling levels off, simulation-based techniques are unable to keep up with today’s growing complexity. This is particularly true when simulating large designs that include both software and embedded processor core models. Hence, acceleration techniques are now required to extend SoC verification performance for very large designs. In fact, emulation and FPGA prototyping have become key platforms for SoC integration verification where both hardware and software are integrated into a system for the first time. In addition to SoC verification, emulation and FPGA prototyping are also used today as a platform for software development.

Figure 3 describes various reasons why projects are using emulation, while Figure 4 describes why FPGA Prototyping was performed. You might note that the results do not sum to 100 percent since multiple answers were accepted from each study participant.

BLOG-2016-WRG-figure-9-3

Figure 3. Why Was Emulation Performed?

BLOG-2016-WRG-figure-9-4

Figure 4. Why Was FPGA Prototyping Performed?

Figure 5 partitions the data for emulation and FPGA prototyping adoption by the design size as follows: less than 5M gates, 5M to 80M gates, and greater than 80M gates. Notice that the adoption of emulation continues to increase as design sizes increase. However, the adoption of FPGA prototyping levels off as design sizes increase beyond 80M gates. Actually, the level-off point is more likely around 40M gates or so since this is the average capacity limit of many of today’s FPGAs. This graph illustrates one of the problems with adopting FPGA prototyping of very large designs. That is, there can be an increased engineering effort required to partition designs across multiple FPGAs. However, better FPGA partitioning solutions are now emerging from EDA to address these challenges. In addition, better FPGA debugging solutions are also emerging from EDA to address today’s lab visibility challenges. Hence, I anticipate seeing an increase in adoption of FPGA prototyping for larger gate counts as time goes forward.

BLOG-2016-WRG-figure-9-5

Figure 5. Emulation and FPGA Prototyping Adoption by Design Size

In my next blog (click here) I plan to discuss various ASIC/IC language and library adoption trends.

Quick links to the 2016 Wilson Research Group Study results

, , , , , ,

4 October, 2016

ASIC/IC Resource Trends

This blog is a continuation of a series of blogs related to the 2016 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I focused on FPGA design and verification trends.  I now will shift the focus of this series of blogs from FPGA trends to ASIC/IC trends. In this blog, I plan to discuss the growing ASIC/IC design project resource trends due to rising design complexity.

Figure 1 shows the percentage of total project time spent in verification. As you would expect, the results are all over the spectrum; whereas, some projects spend less time in verification, other projects spend more. The average total project time spent in verification in 2016 was 55 percent, which did not change significantly from 2012 and 2014. The data suggest that although Moore’s Law continues in terms of growing design complexity the industry isn’t getting any worse in terms of project time spent in verification.

BLOG-2016-WRG-figure-8-1

Figure 1. Percentage of ASIC/IC Project Time Spent in Verification

Perhaps one of the biggest challenges in design and verification today is identifying solutions to increase productivity and control engineering headcount. To illustrate the need for productivity improvement, we discuss the trend in terms of increasing engineering headcount. Figure 2 shows the mean peak number of engineers working on a project. Again, this is an industry average since some projects have many engineers while other projects have few. You can see that the mean peak number of verification engineers today is greater than the mean peak number of design engineers. In other words, there are, on average, more verification engineers working on a project than design engineers. This situation has changed significantly since 2007.

BLOG-2016-WRG-figure-8-2

Figure 2. Mean Number of Peak Engineers per ASIC/IC Project

Another way to comprehend the impact of today’s project headcount trends is to calculate the compounded annual growth rate (CAGR) for both design and verification engineers. Between 2007 and 2016 the industry experienced a 3.6 percent CAGR for design engineers and a 10.4 percent CAGR for verification engineers, as shown in Figure 3. Although the data suggest that the demand for verification engineers is starting to slow down in 2016, clearly, the double-digit increase in required verification engineers has become a major project cost management concern, and is one indicator of growing verification effort.

BLOG-2016-WRG-figure-8-3

Figure 3. Peak Engineers CAGR per ASIC/IC Project

But verification engineers are not the only project stakeholders involved in the verification process. Design engineers spend a significant amount of their time in verification too, as shown in Figure 4. In 2014 and 2016, design engineers spent on average 53 percent of their time involved in design activities and 47 percent of their time in verification.

BLOG-2016-WRG-figure-8-4

Figure 4. Where ASIC/IC Design Engineers Spend Their Time

However, this is a reversal in the trends observed from the 2010 and 2012 studies, which indicated that design engineers spent more time in verification activities than design activities. The data suggest that design effort has risen significantly in the last four years when you take into account that: (a) design engineers are spending more time in design, and (b) there was a nine percent CAGR in required design engineers between 2012 and 2014 (shown in Figure 2), which is a steeper increase than the overall 3.7 CAGR for design engineers spanning 2007 through 2016. We will discuss a few factors that might be contributing to this increased design effort in upcoming blogs.

Figure 5 shows where verification engineers spend their time (on average). We do not show trends here since this aspect of project resources was not studied prior to 2012, and there were no significant changes in the results between 2012, 2014, and 2016. Our study found that verification engineers spend more of their time in debugging than any other activity. This needs to be an important research area whose future solutions will be necessary for improving productivity and predictability within a project.

BLOG-2016-WRG-figure-8-5

Figure 5. Where ASIC/IC Verification Engineers Spend Their Time

In my next blog (click here) I plan to discuss various ASIC/IC verification solutions adoption trends.

Quick links to the 2016 Wilson Research Group Study results

,

25 September, 2016

ASIC/IC Design Trends

This blog is a continuation of a series of blogs related to the 2016 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I focused on FPGA design and verification trends.  I now will shift the focus of this series of blogs from FPGA trends to ASIC/IC trends.

In this blog, I present trends related to various aspects of design to illustrate growing design complexity. Figure 1 shows the trends from the 2014 and 2016 studies in terms of active ASIC/IC design project by design sizes (gates of logic and datapath, excluding memories). Keep in mind that Figure 1 represents design projects, not silicon volume.

One interesting observation from this year’s study is that there appeared to be a large increase in design projects working on designs less than 100K gates. This was somewhat of a surprise. Perhaps it is due to a number of projects working on smaller sensor chips for IoT devices. At any rate, it is important to keep this in mind when observing some of the verification technology adoption trends. The reason is typically these very small projects do not apply advanced verification techniques, which can bias the overall industry verification technique adoption trends in some cases.

BLOG-2016-WRG-figure-7-1

Figure 1. ASIC/IC Design Sizes

The key takeaway from Figure 1 is that the electronic industry continues to move to larger designs. In fact, 31 percent of today’s design projects are working on designs over 80M gates, while 20 percent of today’s design projects are working on designs over 500M gates.

But increased design size is only one dimension of the growing complexity challenge. What has changed significantly in design since the original Collett studies is the dramatic movement to SoC class of designs. In 2004, Collett found that 52 percent of design projects were working on designs that includ one or more embedded processors. Our 2012 study found that the number of design projects working on designs with embedded processors had increased to 71 percent, and has been fairly consistent since that point in time as shown in Figure 2.

Another interesting trend is the increase in the number of embedded processes in a single SoC. For example, 49 percent of design projects today are working on designs that contain two or more embedded processors, while 16 percent of today’s designs include eight or more embedded processors. SoC class designs add a new layer of verification complexity to the verification process that did not exist with traditional non-SoC class designs due to hardware and software interactions, new coherency architectures, and the emergence of complex network on-a-chip interconnect.

BLOG-2016-WRG-figure-7-2

Figure 2. ASIC/IC Design Sizes

In addition to the increasing number of embedded processors contained within an SoC, it is not uncommon to find in the order of 120 integrated IP blocks within today’s more advanced SoCs. Many of these IP blocks have their own clocking requirements, which often present new verification challenges due to metastability issues involving signals that cross between multiple asynchronous clock domains.

In Figure 3, we see that 91 percent of all ASIC/IC design projects today are working on designs that have two or more asynchronous clock domains.

BLOG-2016-WRG-figure-7-3

Figure 3. Number of Asynchronous Clock Domains in ASIC/IC Designs

One of the challenges with verifying clock domain crossing issues is that there is a class of metastability bugs that cannot be demonstrated in simulation on an RTL model. To simulate these issues requires a gate-level model with timing, which is often not available until later stages in the design flow. However, static clock-domain crossing (CDC) verification tools have emerged as a solution used to automatically identify clock domain issues directly on an RTL model at earlier stages in the design flow.

In my next blog (click here) I plan to discuss the growing ASIC/IC design project resource trends due to rising design complexity.

Quick links to the 2016 Wilson Research Group Study results

, ,

22 September, 2016

Join us for the Verification Academy Live Seminar on Enterprise Debug & Analysis

Your designs are larger and more complex than ever and your verification solutions are generating more information that needs to be managed and analyzed.  Your need to build and validate systems with pre-built design IP that comes from multiple sources places time-to-market burdens on you that need to be addressed. Your ability to debug your system from the design described in RTL running on simulation farms to emulators and FPGA prototypes with eventual debug of post silicon implementation drives even more complexity.  And in the face of the adoption of newer methodologies like UVM, often embraced in unstructured ways, poses its own productivity burdens.

This pressure shows itself in our annual semi-annual industry survey results that illustrates there are now more verification engineers than design engineers for a team (a recent phenomena) and the time spent on debug now approaches 40% of an engineer’s total project time budget.

Clearly, improving debug productivity for an enterprise flow from block to system pre-silicon verification, virtual prototyping, emulation, as well as post-silicon validation is critical to stay on schedule and at the same time meet your end product quality goals.

We invite you to join us for a comprehensive seminar to learn the very latest verification techniques to address these challenges.  Harry Foster, Mentor Graphics Chief Verification Scientist, will review the 2016 Wilson Research Group Functional Verification Study in his featured keynote to open the seminar.  The seminar will review enterprise-level requirements, solutions and offer additional end-user keynotes that will help address your key challenges.  Click here for more information about the seminar and how to register.  Event details are below:

Verification Academy Live Seminar

  • Location: Santa Clara, CA USA
  • Date: Thursday – October 6, 2016
  • Agenda:
    • 08:30 – 09:00 Check in and Registration
    • 09:00 – 09:50 Industry Trends in Today’s Functional Verification Landscape
    • 09:50 – 10:10 Enterprise Verification Required
    • 10:15 – 11:00 Enterprise Debug for Simulation & Formal
    • 11:00 – 11:15 Break
    • 11:15 – 12:00 Shortcut to Productive Enterprise Verification with VIP, a UVM framework and a configuration GUI
    • 12:00 – 12:40 Lunch
    • 12:40 – 13:10 User Keynote Session
    • 13:10 – 13:40 Enterprise System Level Analysis
    • 13:40 – 14:00 Break
    • 14:00 – 14:40 System-Level Debug with Emulation
    • 14:40 – 15:10 User Keynote Session
    • 15:10 – 15:50 FPGA Prototyping: Maximize your Enterprise Debug Productivity
    • 15:50 – 16:00 Closing Remarks and Prize Drawing

, , , , , , ,

21 September, 2016

FPGA Language and Library Trends

This blog is a continuation of a series of blogs related to the 2016 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I focused on FPGA verification techniques and technologies adoption trends, as identified by the 2016 Wilson Research Group study. In this blog, I’ll present FPGA design and verification language trends.

You might note that the percentage for some of the language that I present sums to more than one hundred percent. The reason for this is that many FPGA projects today use multiple languages.

FPGA RTL Design Language Adoption Trends

Let’s begin by examining the languages used for FPGA RTL design. Figure 1 shows the trends in terms of languages used for design, by comparing the 2012, 2014, and 2016 Wilson Research Group study, as well as the projected design language adoption trends within the next twelve months. Note that the language adoption is declining for most of the languages used for FPGA design with the exception of Verilog and SystemVerilog.

Also, it’s important to note that this study focused on languages used for RTL design. We have conducted a few informal studies related to languages used for architectural modeling—and it’s not too big of a surprise that we see increased adoption of C/C++ and SystemC in that space. However, since those studies have (thus far) been informal and not as rigorously executed as the Wilson Research Group study, I have decided to withhold that data until a more formal study can be executed related to architectural modeling and virtual prototyping.

BLOG-2016-WRG-figure-6-1

Figure 1. Trends in languages used for FPGA design

It’s not too big of a surprise that VHDL is the predominant language used for FPGA RTL design, although it is slowly declining when viewed as a worldwide trend. An important note here is that if you were to filter the results down by a particular market segment or region of the world, you would find different results. For example, if you only look at Europe, you would find that VHDL adoption as an FPGA design language is about 79 percent, while the world average is 62 percent. However, I believe that it is important to examine worldwide trends to get a sense of where the industry is moving in the future.

FPGA Verification Language Adoption Trends

Next, let’s look at the languages used to verify FPGA designs (that is, languages used to create simulation testbenches). Figure 2 shows the trends in terms of languages used to create simulation testbenches by comparing the 2012, 2014, and 2016 Wilson Research Group study, as well as the projected verification language adoption trends within the next twelve months.

BLOG-2016-WRG-figure-6-2

Figure 2. Trends in languages used in verification to create FPGA simulation testbenches

What is interesting in 2016 is that SystemVerilog overtook VHDL as the language of choice for building FPGA testbenches. But please note that the same comment related to design language adoption applies to verification language adoption. That is, if you were to filter the results down by a particular market segment or region of the world, you would find different results. For example, if you only look at Europe, you would find that VHDL adoption as an FPGA verification language is about 66 percent (greater than the worldwide average), while SystemVerilog adoption is 41 percent (less than the worldwide average).

FPGA Testbench Methodology Class Library Adoption Trends

Now let’s look at testbench methodology and class library adoption for FPGA designs. Figure 3 shows the trends in terms of methodology and class library adoption by comparing the 2012, 2014, and 2016 Wilson Research Group study, as well as the projected verification language adoption trends within the next twelve months.

BLOG-2016-WRG-figure-6-3

Figure 3. FPGA methodology and class library adoption trends

Today, we see a basically a flat or downward trend in terms of adoption of all testbench methodologies and class libraries with the exception of UVM, which has been growing at a healthy 10.7 percent compounded annual growth rate. The study participants were also asked what they plan to use within the next 12 months, and based on the responses, UVM is projected to increase an additional 12.5 percent.

By the way, to be fair, we did get a few write-in methodologies, such as OSVVM and UVVM that are based on VHDL. I did not list them in the previous figure since it would be difficult to predict an accurate adoption percentage. The reason for this is that they were not listed as a selection option on the original question, which resulted in a few write-in answers. Nonetheless, the data suggest that the industry momentum and focused has moved to SystemVerilog and UVM.

FPGA Assertion Language and Library Adoption Trends

Finally, let’s examine assertion language and library adoption for FPGA designs. The 2016 Wilson Research Group study found that 47 percent of all the FPGA projects have adopted assertion-based verification (ABV) as part of their verification strategy. The data presented in this section shows the assertion language and library adoption trends related to those participants who have adopted ABV.

Figure 4 shows the trends in terms of assertion language and library adoption by comparing the 2012, 2014, and 2016 Wilson Research Group study, and the projected adoption trends within the next 12 months. The adoption of SVA continues to increase, while other assertion languages and libraries are not trending at significant changes.

BLOG-2016-WRG-figure-6-4

Figure 4. Trends in assertion language and library adoption for FPGA designs

In my next blog (click here), I will shift the focus of this series of blogs and start to present the ASIC/IC findings from the 2016 Wilson Research Group Functional Verification Study.

Quick links to the 2016 Wilson Research Group Study results

, , , , , , , , , , , , , , ,

@dennisbrophy tweets

Follow dennisbrophy

@dave_59 tweets

Follow dave_59

@jhupcey tweets

  • #ARM now hiring formal verification engineers in Austin: exciting tech challenge + Ram is a great guy to work with.…https://t.co/uwIXLHWqvg
  • Attention all SF Bay Area formal practitioners: next week Wednesday 7/26 on Mentor's Fremont campus the Verificatio…https://t.co/9Y0iFXJdYi
  • This is a very hands-on, creative role for a verification expert -- join us! https://t.co/jXWFGxGrpn

Follow jhupcey