Posts Tagged ‘RTL’

8 August, 2016

This is the first in a series of blogs that presents the findings from our new 2016 Wilson Research Group Functional Verification Study. Similar to my previous 2014 Wilson Research Group functional verification study blogs, I plan to begin this set of blogs with an exclusive focus on FPGA trends. Why? For the following reasons:

  1. Some of the more interesting trends in our 2016 study are related to FPGA designs. The 2016 ASIC/IC functional verification trends are overall fairly flat, which is another indication of a mature market.
  2. Unlike the traditional ASIC/IC market, there has historically been very few studies published on FPGA functional verification trends. We started studying the FPGA market segment back in the 2010 study, and we now have collected sufficient data to confidently present industry trends related to this market segment.
  3. Today’s FPGA designs have grown in complexity—and many now resemble complete systems. The task of verifying SoC-class designs is daunting, which has forced many FPGA projects to mature their verification process due to rising complexity. The FPGA-focused data I present in this set of blogs will support this claim.

My plan is to release the ASIC/IC functional verification trends through a set of blogs after I finish presenting the FPGA trends.


In 2002 and 2004, Collett International Research, Inc. conducted its well-known ASIC/IC functional verification studies, which provided invaluable insight into the state of the electronic industry and its trends in design and verification at that point in time. However, after the 2004 study, no additional Collett studies were conducted, which left a void in identifying industry trends. To address this dearth of knowledge, five functional verification focused studies were commissioned by Mentor Graphics in 2007, 2010, 2012, 2014, and 2016. These were world-wide, double-blind, functional verification studies, covering all electronic industry market segments. To our knowledge, the 2014 and 2016 studies are two of the largest functional verification study ever conducted. This set of blogs presents the findings from our 2016 study and provides invaluable insight into the state of the electronic industry today in terms of both design and verification trends.

Study Background

Our study was modeled after the original 2002 and 2004 Collett International Research, Inc. studies. In other words, we endeavored to preserve the original wording of the Collett questions whenever possible to facilitate trend analysis. To ensure anonymity, we commissioned Wilson Research Group to execute our study. The purpose of preserving anonymity was to prevent biasing the participants’ responses. Furthermore, to ensure that our study would be executed as a double-blind study, the compilation and analysis of the results did not take into account the identity of the participants.

For the purpose of our study we used a multiple sampling frame approach that was constructed from eight independent lists that we acquired. This enabled us to cover all regions of the world—as well as cover all relevant electronic industry market segments. It is important to note that we decided not to include our own account team’s customer list in the sampling frame. This was done in a deliberate attempt to prevent biasing the final results. My next blog in this series will discuss other potential bias concerns when conducting a large industry study and describe what we did to address these concerns.

After data cleaning the results to remove inconsistent or random responses (e.g., someone who only answered “a” on all questions), the final sample size consisted of 1703 eligible participants (i.e., n=1703). This was approximately 90% this size of our 2014 study (i.e., 2014 n=1886). However, to put this figure in perspective, the famous 2004 Ron Collett International study sample size consisted of 201 eligible participants.

Unlike the 2002 and 2004 Collett IC/ASIC functional verification studies, which focused only on the ASIC/IC market segment, our studies were expanded in 2010 to include the FPGA market segment. We have partitioned the analysis of these two different market segments separately, to provide a clear focus on each. One other difference between our studies and the Collett studies is that our study covered all regions of the world, while the original Collett studies were conducted only in North America (US and Canada). We have the ability to compile the results both globally and regionally, but for the purpose of this set of blogs I am presenting only the globally compiled results.

Confidence Interval

All surveys are subject to sampling errors. To quantify this error in probabilistic terms, we calculate a confidence interval. For example, we determined the “overall” margin of error for our study to be ±2.36% at a 95% confidence interval. In other words, this confidence interval tells us that if we were to take repeated samples of size n=1703 from a population, 95% of the samples would fall inside our margin of error ±2.36%, and only 5% of the samples would fall outside. Obviously, response rate per individual question will impact the margin of error. However, all data presented in this blog has a margin of error of less than ±5%, unless otherwise noted.

Study Participants

This section provides background on the makeup of the study.

Figure 1 shows the percentage of overall study FPGA and ASIC/IC participants by market segment. It is important to note that this figures does not represent silicon volume by market segment.


Figure 1: FPGA and ASIC/IC study participants by market segment

Figure 2 shows the percentage of overall study eligible FPGA and ASIC/IC participants by their job description. An example of eligible participant would be a self-identified design or verification engineer, or engineering manager, who is actively working within the electronics industry. Overall, design and verification engineers accounted for 60 percent of the study participants.


Figure 2: FPGA and ASIC/IC study participants job title description

Before I start presenting the findings from our 2016 functional verification study, I plan to discuss in my next blog (click here) general bias concerns associated with all survey-based studies—and what we did to minimize these concerns.

Quick links to the 2016 Wilson Research Group Study results

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

20 April, 2016

Using SystemVerilog to model RTL behavior in a pinch or anytime

A couple weeks ago, sitting here in California on a rainy Friday afternoon. No the drought is not over, but the hills are green again, and the reservoirs are filling up. Daydreaming about the power and flexibility of SystemVerilog and some of the trouble people can get themselves into with it. Wishing my RTL models would show up, so I could test my testbench…

I start to think about writing some SystemVerilog… SystemVerilog is a powerful language. You can write some powerful code with little or no pain. It’s just software.

In the early days of SystemVerilog, I coded some C code and some SystemVerilog code that did the same thing. Some function calls and loops and if-then-else and some adds and multiplies. Just code. Then I disassembled both sides and compared the generated code. It was basically the same generated code! Certainly I could expect the same performance. (And I got it).

That result made me feel very comfortable writing SystemVerilog code anytime I needed some “code”. I didn’t need any special C or C++ code, I could just write SystemVerilog. There are plenty of good reasons to use C and C++ alongside your SystemVerilog, but you certainly don’t need to go there FIRST.

With this in mind on that foggy Friday afternoon two weeks ago, I decided to use SystemVerilog as a stand-in or early implementation for some simple missing RTL. What I mean is that I was going to implement the functionality using high-level SystemVerilog code – not RTL. This is a case where exact timing is not so important, and complete functionality is not so important. What IS important is getting some tests running before the weekend.

In this example, we just want a block implemented that acts like a switch – two input ports and two output ports. That code is simple enough, we can just write some SystemVerilog code using queues.

Imagine a switch with two ports in and two ports out. The ports each have an 8 bit data payload, an “output address” and a ready signal.

2x2 Switch

The protocol is simple. If ready is high on the positive edge of the clock, then a transfer takes place. This transfer takes just one clock cycle. (This is just a simple example). The typedef below defines each “port” connection – or each packet that is transferred on the bus.

typedef struct packed {
    bit ready;       // Valid data ready
    bit output_port; // Send to which port? (1 or 2)
    bit [7:0] data;  // Data payload
} packet_t;

Now we can build a switch, with a simple clock and four ports (two input and two output). This switch is not too smart. It just shuttles “packets” from input port to output port, choosing one of four possible routes: 1→ 1, 1→ 2, 2→ 1 and 2→ 2. The switch ports are defined as the typedef packet – each port has a ready, a data payload and an output destination.

module switch (input clk,
     input packet_t in1,  packet_t in2,
    output packet_t out1, packet_t out2);

The module is implemented using two simple queues. We are NOT doing any reordering of the queues, nor are we supporting prioritized transfers. We could, but it is Friday afternoon, after all.

  packet_t  in_q[$];
  packet_t out_q[$];

When a packet comes into a port, it is put on the input queue. [i.e. On the clock edge, for that port, if the ready signal is high, then capture the connection into the input queue (ready, data payload and output_port)]. Do this for both input ports – in1 and in2.

  always @(posedge clk)
    if (in1.ready == 1)
  always @(posedge clk)
    if (in2.ready == 1)

When the size of the input queue is NOT zero, then a packet is popped off and put on the output queue for “other” processing.

  always begin: Input_Queue
    packet_t p;
    wait (in_q.size() != 0);
    p = in_q.pop_back();
    repeat (1) @(posedge clk);

When the size of the output queue is NOT zero, then a packet is popped off and sent out of the module – it goes out onto the bus. Check to see if it goes out on out1 or on out2.

  always begin: Output_Queue
    packet_t p;
    wait (out_q.size() != 0);
    p = out_q.pop_back();
    case(p.output_port) // Which output port?
      0: begin 
         out1 = p;
         out1.ready = 1;
         @(posedge clk);
         out1.ready = 0;
         @(negedge clk);
      1: begin 
         out2 = p;
         out2.ready = 1;
         @(posedge clk);
         out2.ready = 0;
         @(negedge clk);

The next higher level that instantiates the switches is simple. Just simple connections. The packed struct takes care of the details. A couple of switches connected together using the packed structs is quite easy to write.

  packet_t in1, in2, out1, out2;
  packet_t n1, n2;
  switch ss_A(clk, in1, in2,   n1,   n2);
  switch ss_B(clk,  n1,  n2, out1, out2);

We now have a switch implementation with certain kinds of behavior. We can implement a priority scheme, or re-order the queues as we wish. And it is still Friday afternoon! We used user defined types (typedef of packed structs), queues and multiple threads. Pretty good bang for the buck. And coded and tested in less than a day.

The moral of the story is this. If you need to implement some missing functionality, SystemVerilog is certainly capable. It’s not as exciting as a presidential race. It’s not as exciting as going away to college for the first time, nor as exciting as racing Tesla’s on the highway, but in a pinch on a rainy Friday afternoon it sure beats going home early. Or does it?

It’s up and running, and I see the queue sizes in the switch modules growing and draining, and I call it a day.

Analog Waves for Queue Sizes

Figure 2: Analog Waves for Queue Sizes

You can find some ideas on the Verification Academy along these same lines using other SystemVerilog high-level constructs like classes, associative arrays, dynamic arrays and processes by clicking here. Look for “No RTL Yet? No Problem UVM Testing a SystemVerilog Fabric Model”. If you *really* want to write RTL instead of high-level SystemVerilog, you can find some great tips and tricks at Sunburst Design, especially the FIFO 1 & 2 papers.

Happy Friday! More rain predicted for this coming Friday.


29 July, 2015

VA DAC2015 smlIf you were not one of the 100’s of visitors to the Verification Academy booth at DAC 2015 and missed an opportunity to get a printed copy of the DAC 2015 issue of Verification Horizons, don’t worry.  You can also download it as well.

Questa Vanguard Partners Highlighted

Eight of the eleven articles were authored or co-authored by our partners and represent a wide range of topics.  There are two articles on DO-254 (Partners: eInfochips and Verisense).  There is an article on Formal and ABV of MBIST MCPs (Parnter: FishTail Design Automation).  There is an article on how to start formal analysis “right” (Partner: OSKI).  For UVM users, reuse of MATLAB® functions and Simulink® functions is covered (Partner: Mathworks).  Continuing with another article for the UVM users, intelligent testbench automation with UVM and Questa® is explored (Partner: Codasip Ltd.).  For the Agile community, unit testing your way to a reliable testbench is explored (Partner: XtremeEDA & User company: NVIDIA).  Lastly, a noted emulation consultant (Lauro Rizzatti) shares part 2 of his three decades of emulation evolution and a customer paper (Marvell) covers techniques to accelerate RTL simulation.

VH DAC 2015 CoverAll of this is inside the 60-page mega-issue of Verification Horizons in 11 articles.  Direct links to each of the articles is shared below along with the article titles and authors.  The editor introduction by Tom Fitzpatrick gives even more detail and background on this issue.  If you don’t already have some summer or vacation reading, get your electronic copy today!

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

14 January, 2015

“Who Knew?” about verification IP (VIP), was the theme of a recent DeepChip post by John Cooley on December 18.  More specifically the article states, “Who knew VIP was big and that Wally had a good piece of it?”  We knew.

We knew that ASIC and FPGA design engineers can choose to buy design IP from several alternative sources or build their own, but that does not help with the problem of verification.  We knew that you don’t really want to rely on the same source that designed your IP, to test it.  We knew that you don’t want to write and maintain bus functional models (BFMs) or more complete VIP for standard protocols.  Not that you couldn’t, but why would you if you don’t have to?

We also knew that verification teams want easy-to-use VIP that is built on a standard foundation of SystemVerilog, compliant with a protocol’s specification, and is easily configurable to your implementation.  That way it integrates into your verification environment just as easily as if you had built it yourself.

Leading design IP providers such as ARM®, PLDA, and Northwest Logic knew that Mentor Graphics’ VIP is built on standards, is protocol compliant, and is easy to use.  In fact you can read more about what Jim Wallace, systems and software group director at ARM; Stephane Hauradou, CTO of PLDA; and Brian Daellenbach, president of Northwest Logic; have to say about Mentor Graphics’ recently introduced EZ-VIP technology for PCIe 4.0 (at this website ), and why they know that their customers can rely on it as well.

Verification engineers knew, too.  You can read comments from many of them (at Cooley’s website ), about their opinions on VIP.  In addition, Mercury Systems also knew.  “Mentor Graphics PCIe VIP is fully compliant with the PCIe protocol specification and with UVM coding guidelines. We found that we could drop it into our existing environment and get it up and running very quickly”, said Nick Solimini, Consulting DV Engineer at Mercury Systems. “Mentor’s support for their VIP is excellent. All our technical questions were answered promptly so we were able to be productive throughout the project”.

So, now you know,  Mentor Graphics’ Questa VIP is built on standard SV UVM, is specification compliant, is easy to get up and running and is an integral part of many successful verification environments today.  If you’d like to learn more about Questa VIP and Mentor Graphics’ EZ-VIP technology, send me an email, and I’ll let you in on what (thanks to Cooley and our customers) is no longer the best kept secret in verification.  Who knew?

, , , , , , , ,

5 August, 2013

Language and Library Trends

This blog is a continuation of a series of blogs that present the highlights from the 2012 Wilson Research Group Functional Verification Study (for a background on the study, click here).

In my previous blog (Part 7 click here), I focused on some of the 2012 Wilson Research Group findings related to testbench characteristics and simulation strategies. In this blog, I present design and verification language trends, as identified by the Wilson Research Group study.

You might note that for some of the language and library data I present, the percentage sums to more than one hundred percent. The reason for this is that some participants’ projects use multiple languages.

RTL Design Languages

Let’s begin by examining the languages used for RTL design. Figure 1 shows the trends in terms of languages used for design, by comparing the 2007 Far West Research study (in gray), the 2010 Wilson Research Group study (in blue), the 2012 Wilson Research Group study (in green), as well as the projected design language adoption trends within the next twelve months (in purple) as identified by the study participants. Note that the design language adoption is declining for most of the languages with the exception of SystemVerilog whose adoption continues to increase.

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 blind study can be executed related to architectural modeling and virtual prototyping.

Figure 1. Trends in languages used for Non-FPGA design

Let’s now look at the languages used specifically for FPGA RTL design. Figure 2 shows the trends in terms of languages used for FPGA design, by comparing the 2012 Wilson Research Group study (in red) with the projected design language adoption trends within the next twelve months (in purple).

Figure 2. Languages used for Non-FPGA design

It’s not too big of a surprise that VHDL is the predominant language used for FPGA RTL design, although we are starting to see increased interest in SystemVerilog.

Verification Languages

Next, let’s look at the languages used to verify Non-FPGA designs (that is, languages used to create simulation testbenches). Figure 3 shows the trends in terms of languages used to create simulation testbenches by comparing the 2007 Far West Research study (in gray), the 2010 Wilson Research Group study (in blue), and the 2012 Wilson Research Group study (in green).

Figure 3. Trends in languages used in verification to create Non-FPGA simulation testbenches

The study revealed that verification language adoption is declining for most of the languages with the exception of SystemVerilog whose adoption is increasing. In fact, SystemVerilog adoption increased by 8.3 percent between 2010 and 2012.

Figure 4 provides a different analysis of the data by partitioning the projects by design size, and then calculating the adoption of SystemVerilog for creating testbenches by size. The design size partitions are represented as: less than 5M gates, 5M to 20M gates, and greater than 20M gates. Obviously, we find that the larger the design size, the greater the adoption of SystemVerilog for creating testbenches. Yet, probably the most interesting observation we can make from examining Figure 4 is related to smaller designs that are less than 5M gates. Here we see that 58.8 percent of the industry has adopted SystemVerilog for verification. In other words, it is safe to say that SystemVerilog for verification has become mainstream today and not just limited to early adopters or leading-edge design projects.

Figure 4. SystemVerilog (for verification) adoption by design size

Let’s now look at the languages used specifically for FPGA RTL design. Figure 5 shows the trends in terms of languages used for FPGA design, by comparing the 2012 Wilson Research Group study (in red) with the projected design language adoption trends within the next twelve months (in purple).

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

In my next blog (click here), I’ll continue the discussion on design and verification language trends as revealed by the 2012 Wilson Research Group Functional Verification Study.

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

26 July, 2010

For years one of the objectives in EDA has been to make formal property checking easy to use and its results easy to understand. With the Automatic formal check feature in the June release of the 0-In Formal tool version 3.0, I think we have made significant progress in this area.

The feature, which predefines a set of assertion rules to look for design issues automatically, makes formal technology accessible to users who are not yet ready to write properties in System Verilog Assertion (SVA) or Property Specification Language (PSL). To make it easier to comprehend problems in the design, the tool highlights the violations back to the RTL code.

Automatic formal check focuses on three areas inadequately addressed by dynamical simulation:

The first area is functional coverage. Today, when constrained random simulation fails to achieve the targeted coverage goal, engineers have to fine tune the environment or add new tests. These efforts, often attempted relatively late in the verification cycle, can consume vast amounts of time and resources while still failing to reach parts of the design. In contrast, automatic formal check can be used to identify unreachable code early in the verification cycle. These targets can be eliminated from the coverage model. As a result, the coverage measurement is more accurate and you know when you are done.

The next area is design initialization. If a design cannot be initialized reliably in silicon, it will not function correctly. An obvious precursor then is making sure all the registers are initialized correctly at RTL. If X’es are used, we need to monitor the X creation, propagation and usage cycle. Dynamic simulation does not interpret X’es accurately as in silicon, which has only 1s and 0s. Automatic formal check is ideal in verifying register initialization under different modes or configurations. Then, with internal assertions and formal technologies, we can check that although X’es are created, they are not used by downstream registers.

The final area is corner case design issues. Time and time again, designers unintentionally write code that violates logical correctness. Examples include combinational loops, full case violations, parallel case violations, undriven logic, finite-state machine (FSM) deadlocks and FSM livelocks. Unless tests are written to specifically target these corner case design issues are, such issues are difficult to exercise. On the other hand, by formally analyzing the design semantics, automatic formal check identifies these design issues statically and creates the stimuli to highlight them to the users.

If you are interested to know more about the automatic formal check feature in 0-In Formal, please feel free to register for our upcoming seminar in San Jose.


, , , , , ,

7 June, 2010

After spending years verifying ASICs with dynamic simulation, I started working on static verification 10 years ago in a startup called 0-In Design Automation. I firmly believe that static verification can complement dynamic simulation. Static verification uses synthesis and formal technologies to find bugs in the design. It does not rely on simulation stimulus. You do not need to exercise the bugs, propagate the results, and check the outputs to detect them.

Static verification includes RTL lint, static checks, formal checks, automated and assertion-based formal property checking. To read more on static verification, you can take a look at my white paper: Getting Started With Static Verification. If you are interested in formal methods, you can take a look at Harry Foster’s white paper: Why Now for Formal Property Checking. Both can be found in the Knowledge Center of

In the future, we are going to talk about individual static verification technologies and its application in areas such as RTL verification, clock domain crossing verification, low power verification, timing constraint verification, etc. Your feedback and comments are most welcome.

, , , , ,

22 April, 2010

Noted EDA analyst and guru Gary Smith delivered keynote address: “ESL: Where We Are and Where We’re Going”

OSCI sponsored the first annual SystemC Day at DVCon 2010.  The presentations were video recorded and are available for free for those who missed DVCon or who may wish to see them again.  Gary Smith’s presentation (registration required) and OSCI chair, Eric Lish’s OSCI Update lead the video set from SystemC Day.

The 12th North American SystemC Users Group (NASCUG) meeting was part of SystemC Day at DVCon and featured technical presentations on architectural modeling, verification, and analog/mixed-signal design using SystemC.

OSCI ON YOUTUBE: More videos of users and their perspectives on SystemC events and activities can be found via the OSCI channel on YouTube:

Click here for completing listing of the following technical presentations.

The Metaport: A Technique for Managing Code Complexity
Jack Donovan, HighIP Design, Texas, USA

The metaport is a coding style that can effectively manage code complexity for complex ESL models, especially models that are intended for high-level synthesis. This presentation will give an overview of the metaport concept and dive into the details of a possible implementation.

OCP Socket Modeling with TLM-2.0
Hervé Alexanian, Sonics Inc., California, USA

This presentation discusses work performed by the OCP-IP Committee, specifically modeling that OCP built upon the TLM-2.0 standard.

ADL Synthesis using ArchC
Samuel Goto, Master student at UNICAMP

The design and implementation of processors is a complex task. Architecture Description Languages (ADLs) were created to extend existing HDLs, to ease the process of developing and prototyping an architecture by providing a set of tools and algorithms to optimize and automate some of the tedious parts. While much has been done on the specification and business levels of ADLs, there is a huge gap between ADL specifications/simulators and real life processors written in RTL. This project addresses the issues of bringing an ADL description to the RTL level, and reports the development of an extension of ArchC to support this level.

Look Ma, No Clocks! Improving Model Performance
David Black, XtremeEDA, Texas, USA

This tutorial-style presentation illustrates some techniques to avoid the inclusion of clocks in SystemC simulations and provide results of simple experiments showing the simulation performance benefits. Concepts discussed include synchronization, clock-free timers, and the effects of clocks on performance. A proposal is made for a simple SystemC class that can simplify coding when clocks are thought to be needed.

TLM-driven Design and Verification Methodology
Brian Bailey, independent consultant

SystemC is well on the road to adoption in a number of areas within the Electronic System Level (ESL) space, but many of those are separated islands today. Virtual Prototyping has seen a huge leap forward with the standardization of TLM 2.0. SystemC is also being used successfully for high-level synthesis at the module level, but to make SystemC pervasive, there must be a link between the applications. In addition, to reap the maximum productivity gains from a migration to a higher-level of abstraction, the verification methodology must also change in significant ways. In this presentation we will explore a new TLM-driven design and verification methodology that is being developed within Cadence, critiqued by their customers and documented in a book, which will be released over a number of months as pieces of it mature.

, , , , , ,

11 September, 2009

I have lots of blog entries about 95% ready to publish. This entry is from an e-mail I wrote a few months ago when somebody asked about SystemVerilog coding guidelines. I thought it would make a good article. It’s been sitting as a draft because I always have trouble finding the right title or opening words to catch people’s attention. I couldn’t come up with anything better, so here it is: SystemVerilog Coding Guidelines

My official position about this is that you pick a style and stick to it.

Which style you pick is far less important than developing the required culture that will follow it. People can spend hours arguing over the merits of camelCaps versus under_score, but once the decision is made, people on the project need to document it, adhere to it, and police it. Otherwise you’re just wasting everyone’s time.

Why are coding guidelines so important? So someone else can read your code, or maybe you can read your own code six months after you wrote it. Good comments and documentation are an import part, but you still need to be able to read the code.

This concept of reading someone else’s code without understanding the underlying conventions reminds me of the classic short article “Meihem In Ce Klasrum” by Dolton Edwards. The article was written as a satirical response to George Bernhard Shaw’s final wishes to simplify the English language. See how easy the last paragraph is to read once you understand the new writing conventions. Reading your code should be just like that (although not as cryptic).

My advice would be to pick a style from industry and adapt it to fit SystemVerilog. For example, from Google: or from the Free Software Foundation:

All of these rules for naming conventions, indentation, and file organization still apply to SystemVerilog. Additional rules would be for unsupported constructs, which should be in the release notes for the tool(s) you are using. Finally, there are a few constructs to avoid, like program blocks and wildcard indexes for associative arrays, most of which might be worth hours of debate, each.

Dave Rich

, ,

7 July, 2009

I’ve been around simulation and synthesis languages for a while; back when you needed an NDA to see the Verilog LRM, and again with SUPERLOG, the predecessor to SystemVerilog.  It’s easy for those like me to get caught up in the features of the language and forget that any programming language is just a tool. With any technology, people pick the tools they think will get the job finished most effectively. Tools evolve to meet the challenges and requirements of their users. Verilog and VHDL have clearly evolved to become the prevailing languages for hardware design.

But before the language wars came the methodology wars. At the time when Verilog and VHDL were being introduced in the late 1980s, most hardware design was by schematic gale-level entry. We would come to our clients with our simulators and synthesis tools and try to change their design methodology by writing RTL. They would bring their best engineers to compete with our tools – and the engineer would always win by producing a design with better area and timing! However, once the productivity of synthesizing large designs with practical quality of results prevailed over the manual effort, the methodology shift was an easier sell.

Fast forward a decade – although designs have increased exponentially as predicted by Moore’s Law, RTL design has not changed in any significant way during that time. Why? Because it takes the same number of lines of RTL code to write an 8-bit adder as it does a 64-bit adder. 🙂 OK, so that’s an over-simplification, but number of lines of RTL code written by a single design engineer has remained manageable. However, for every registered bit added to the design, the state space doubles, and the transition space for testing all permutations of the state space quadruples. Again that’s a simplification, but the correct order of magnitude.

During that period, a number of technologies have addressed the increasing complexities of verification, such as constrained random generation, coverage driven verification, and object-oriented programming. These technologies require a change in verification methodology from writing a linear set of test patterns.

Success in captivating verification engineers to these new methodologies is taking the same path of those earlier design engineers. A single verification engineer may find a single test to exercise a specific piece of functionally much quicker than it takes a constrained random test to reach that same function. But eventually, a constrained random test will exercise more functionality faster than an engineer can write individual tests. Functional Coverage fits into Constrained Random generation to help measure the quality of your tests by telling you if your constraints are working to exercise the functionality you are required to hit.  It takes the randomness out of Constrained Random generation.

Since the verification environment is more software design than hardware, Object-Oriented Programming is a technology that helps you write re-usable code, which in turn keeps your verification code manageable.

SystemVerilog has become the prevailing language that incorporates all these technologies. But does that mean the need for writing directed tests goes away. No. Designers still layout transistors or gates by hand where it’s critical to their project. Verification engineers should use the technology that is best suited to verify their design.

Firmware tests will continue to be written in C/C++ and SystemVerilog’s DPI can help link C based tests to the RTL. SystemC has become the prevailing modeling language for DSP and algorithmic based design. Most simulation tools can seamlessly link those models to RTL to either drive the test or compare results.

So next time you’re thinking about which language to choose to verify your design, step back and think about the methodology first.

Dave Rich

, , ,

@dennisbrophy tweets

Follow dennisbrophy

@dave_59 tweets

Follow dave_59

@jhupcey tweets

Follow jhupcey