Posts Tagged ‘Standards’

1 June, 2017

Accellera’s Emerging Portable Stimulus Standard Is Pervasive at DAC 54

For the past few years, Accellera’s Portable Stimulus Working Group has been busy at work on the new standard to elevate stimulus generation to improve overall verification productivity.  As the call to attend the annual Accellera breakfast DAC 54 informs us, the Accellera Portable Stimulus early adopter release is planned to be made available prior to DAC.  I’m certain that a download of the early adopter release will make for good reading for those traveling to DAC and have not participated in the development of the standard.  I predict it will be a “page-turner.”  You will be in a much better position to attend the following events in and around DAC (some of which require DAC registration fee payment and some that are fee-free) if you download and read it when ready.  Here are some of the DAC 54 Portable Stimulus activities:

Monday June 19th

Tuesday June 20th

Wednesday June 21st

And for those who will not be attending DAC, I will update this blog with information on how you can download the Accellera Portable Stimulus early adopter release.  There is also online educational videos about the emerging Portable Stimulus standard.  You can find a two sessions at the Mentor Verification Academy on Portable Stimulus Basics. And the DVCon U.S. 2017 technical tutorial, Creating Portable Stimulus Models with the Upcoming Accellera Standard, presented in three parts is located at the Accellera website.  Both online educational video offerings require registration.

, , , ,

3 May, 2017

VIP: Accelerating SoC Design Verification

Your SoC designs have grown more complex, not just by the sheer number of transistors that can be packed into one design, but the emergence of different interconnect methods you must use to connect chip internals and to connect to the outside world.  With each of these interconnect methods, design IP blocks support a faster SoC design process.  However, being an expert on each of the interconnect methods or protocols is not likely leading to protracted SoC verification schedules, reduced design productivity and exposing your designs to bugs that might only be found when in use by the end consumer.

These complex industry standard interfaces can be more rapidly verified in your SoC design with the use of Verification IP (VIP).  You will still need to understand the specific protocols, but when VIP is used you improve design quality and reduce verification time which allows you to hit aggressive time-to-market goals.

To foster industry discussion and share best practices we invite you to the Silicon Valley Design & Verification IP Forum 2017.  The forum brings DIP and VIP designers, integrators and partners together to learn the latest in IP-driven verification trends and solutions.  The forum will have presentations on numerous protocols include MIPI CSI-2, USB 3.1, PCIe Gen 4, DDR & Flash memory and IEEE 802.3 Ethernet PHY.

The day will be full of presentation from those protocol experts and will start with an opening keynote from Mentor’s verification chief scientist, Harry Foster. Harry will explore “Conquering the New IP Economy” in his keynote.  Several of our Questa Vanguard Partners who supply design IP will also be present to show how all this works together to accelerate SoC design verification closure.

Silicon Valley Design & Verification IP Forum 2017 Details

Date: May 9, 2017
Time: 8:30 a.m. – 4:15 p.m. PT
Location: San Jose, CA USA
Register: Click here.

The event is free of charge to qualified registrants and includes lunch.  The lunch keynote will be presented by Niraj Mathur, VP High Speed Interface Products, Rambus.  Niraj will share is 20 years of experience in advanced SoC & IP design, verification, software and cross-functional, global engineering team challenges.

I look forward to seeing your there!

, , , , , , , , , ,

24 February, 2017

My last blog post was written a few years ago before attending a conference when I was reminiscing about the 10-year history of SystemVerilog. Now I’m writing about going to another conference, DVCon, and being part of a panel reminiscing about the 15-year history of SystemVerilog and envisioning its future. My history with SystemVerilog goes back much further.

Soul of a New MachineMy first job out of college was working with a group of Data General (DG) engineers made public in the book, Soul of a New Machine, by Tracy Kidder in 1981. Part of my job was writing a program that simulated the microcode of the CPUs we designed. Back then, there were no hardware description languages and you had to hard code everything for each CPU. If you were lucky you could reuse some of the code for the user interface between projects. Later, DG came up with a somewhat more general-purpose simulation language. It was general-purpose in the sense that it could be used for a wider range of projects based on the way DG developed hardware. But getting it to work in another company’s environment would have been a challenge.  By the way, Badru Agarwala was the DG simulation developer I worked with who later founded the Verilog simulation companies Frontline and Axiom. He now manages the Calypto division at Mentor Graphics.

Many other processor companies like DEC, IBM and Intel had their own in-house simulation languages or were in the process of developing one because no commercially viable technologies existed. Eventually, Phil Moorby at Gateway Design began developing the Verilog language and simulator. One of the benefits of having an independent language, although not an official standard yet, was you could now share or bring in models from outside your company. This includes being able to hand off a Verilog netlist to another company for manufacturing. Another benefit was that companies could now focus on the design and verification of their products instead of the design and verification of tools that design and verify their products.

I evaluated Verilog in its first year of release back in 1985/1986. DG decided not to adopt Verilog at that point, but I liked it so much I left DG and joined Gateway Design as one of its first application engineers. Dropping another name, Karen Bartleson was one of my first customers as a CAD manager working at UTMC. She recently took the office of President and CEO of the IEEE.

IEEEFast forward to the next decade, when Verilog became standardized as IEEE 1364-1995. But by then it had already lost ground in the verification space. Companies went back to developing their own in-house verification solutions. Sun Microsystems developed Vera and later released it as a commercial product marketed by Systems Science. Arturo Salz was one of its developers and will be on the DVCon panel with me as well. Specman was developed for National Semiconductor and a few other clients and later marketed by Verisity. Once again, we had the problem of competing independent languages and therefore limiting the ability to share or acquire verification models. So, in 1999, a few Gateway alums and others formed a startup which I joined a year later hoping to consolidate design and verification back into one standard language. That language was SUPERLOG and became the starting point for the Accellera SystemVerilog 3.0 standard in 2002, fifteen years ago.

IEEE Std 1800-2012There are many dates you could pick for the start of SystemVerilog. You could claim it couldn’t exist until there was a simulator supporting some of the features in the standard. For me, it started when I first read an early Verilog Language Reference Manual and executed my first initial block 31 years ago. I’ve been using Verilog almost every day since. And now all of Verilog is part of SystemVerilog. I’ve been so much a part of the development of the language from its early beginnings; that’s why some of my colleagues call me “The Walking LRM”. Luckily, I don’t dream about it. I hope I never get called “The Sleeping LRM”.

So, what’s next for SystemVerilog? Are we going to repeat the cycle of fragmentation and re-consolidation? Various extensions have already begun showing up in different implementations. SystemVerilog has become so complex that no one can keep a good portion of it in their head anymore. It is very difficult to remove anything once it is in the LRM. Should we start over? We tried to do that with SUPERLOG, but no one adopted it until it was made fully backward compatible with Verilog.

The Universal Verification Methodology (UVM) was designed to cut down the complexity of learning and using SystemVerilog. There are now a growing number of sub-methodologies for using the UVM because the UVM itself has exploded in complexity  (UVM Framework and Easier UVM to name a couple). I have also taken my own approach when teaching people SystemVerilog by showing a minimal subset (See my SystemVerilog OOP for UVM Verification course).

DVConI do believe in the KISS principle of Engineering and I hope that is what prevails in the next version of SystemVerilog, whether we start over or just make refinements. I hope you will be able to join the discussion with others and me at the DVCon panel next week, or in the forums in the Verification Academy, or on Twitter.

-Dave

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

15 December, 2016

Technical Program is Live

For the past several months, the DVCon U.S. Steering Committee has been meeting to craft a compelling event of technical papers, panels, keynotes, poster sessions and more for you.  With the hard work of authors who supply this content and the Technical Program Committee that reviews and selects from this content, a 4-day event schedule is now published.  You can find the event schedule here.

I am pleased to chair DVCon U.S. 2017 and work with such an august body of people – from the electronic design automation industry, design and verification practitioners and professionals from large systems houses to small consultancies – all who work hard for you to make this happen.  As has been the tradition of DVCon U.S. the past several years, the event starts with Accellera Day on Monday (Feb 27th) followed by two days of paper presentations, keynotes, panels and an exhibition.  The exhibition starts Monday, Accellera Day.  The last day of DVCon U.S. features a full day of tutorials split in to half-day parts.

Accellera Day

DVCon U.S. will feature something for advanced users and those who may be more novice.  The conference will showcase emerging standards and updates to those standards well used.  On Monday, Accellera Day, DVCon U.S. begins with a tutorial devoted to work underway within Accellera on a new standard, “Portable Stimulus,” that is set to give design and verification engineers a boost in overall design and verification productivity.  Given the work by the Accellera Portable Stimulus Working Group to put as much of the standard in place that it can, this tutorial, Creating Portable Stimulus Models with the Upcoming Accellera Standard, is sure to be an important educational opportunity.  If you are a user of UVM (Universal Verification Methodology) you will find the Portable Stimulus standard is set to remove many of the limitations of reuse at the subsystem and full-chip level and address the lack of portability across execution platforms.  Are you ready for Portable Stimulus?  You will be ready after attending this tutorial.

As the Monday luncheon evolves, I anticipate a moderated panel discussion hosted by Accellera on the emerging Portable Stimulus standard based on what you learned in the morning session.  As lunch ends, two parallel tutorials will start, one on IEEE P1800.2™ (aka UVM) and the other on System C design and verification advances.  Accellera Day is a great event to learn about the latest in the evolution of standards coming from Accellera and the IEEE.

Special Session

DVCon U.S. will make one departure from prior years’ programs and offer a special session on Tuesday on Trends in Functional Verification: A 2016 Industry Study presented by Harry Foster.  Harry has been reporting on the 2016 Wilson Research Group Study here at the Verification Horizon’s BLOG, and he has shared regional information at DVCon Europe and DVCon India on adoption and use of design and verification tools, technology and standards.  At DVCon U.S. he will pull all this together to show trends and offer predictions for the future.

There is much more to DVCon U.S. 2017 that I think you will find useful.  I leave it to you to explore the program more to discover this for yourself.  And if you can make it to DVCon U.S., registration is also open with advanced rates available until January 26th.  I hope to see you there!

, , , , , , ,

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

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

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

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

18 August, 2016

A great technical program awaits you for DVCon India 2016!  The DVCon India Steering Committee and Technical Program Committee have put together another outstanding program.  The two-day event splits itself into two main technical tracks: one for the Design Verification professional [DV Track] and the other from the Electronic System Design professional [ESL Track].  The conference will be held on Thursday & Friday, 15-16 September 2016 at the Leela Palace in Bangalore.  The conference opens with industry keynotes and a round of technical tutorials the first day.  Wally Rhines, Mentor Graphics CEO, will be the first keynote of the morning on “Design Verification – Challenging Yesterday, Today and Tomorrow.”

Mentor Graphics at DVCon India

In addition to Wally’s keynote, Mentor Graphics has sponsored several tutorials which when combined with other conference tutorials shares information, techniques and tips-and-tricks that can be applied to your current design and verification challenges.

The conference’s other technical elements (Posters, Panels & Papers) will likewise feature Mentor Graphics participants.  You should visit the DVCon India website for the full details on the comprehensive and deep program that has been put together.  The breadth of topics makes it an outstanding program.

Accellera Portable Stimulus Standard (PSS)

The hit of the first DVCon India was the early discussion about the emerging standardization activity in Accellera on “Portable Stimulus.”  In fact, at the second DVCon India a follow-up presentation on PSS standardization was requested and given as well (Leveraging Portable Stimulus Across Domains and Disciplines).  This year will be no exception to cover the PSS topic.

The Accellera Tutorial for DVCon India 2016 is on the emerging Portable Stimulus Standard.  The last thing any design and verification team wants to do is to rewrite a test as a design progresses along a path from concept to silicon.  The Accellera PSS tutorial will share with you concepts being ratified in the standard to bring the next generation of verification productivity and efficiency to you to avoid this.  Don’t be surprised if the PSS tutorial is standing room only.  I suggest if you want a seat, you come early to the room.

Register

To attend DVCon India, you must register.  A discounted registration rates available through 30 August 2016.  Click here to register!  I look forward to see you at DVCon India 2016! If you can’t join us in person, track the Mentor team on social media or on Twitter with hashtag #DVCon.

, , , , , , , ,

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.

Introduction

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.

BLOG-2016-WRG-figure-0-1

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.

BLOG-2016-WRG-figure-0-2

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

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

25 July, 2016

As I mentioned in my last UVM post, UVM allows engineers to create modular, reusable, randomized self-checking testbenches. In that post, we covered the “modularity” aspect of UVM by discussing TLM interfaces, and their value in isolating a component from others connected to it. This modularity allows a sequence to be connected to any compatible driver as long as they both are communicating via the same transaction type, or allows multiple coverage collectors to be connected to a monitor via the analysis port. This is incredibly useful in creating an environment in that it gives the environment writer the ability to mix and match components from a library into a configuration that will verify the desired DUT.

Of course, it is often the case that you may want to have multiple environments that are very similar, but may only differ in small ways from each other. Every environment has a specific purpose, and also shares most of its infrastructure with the others. How can we share the common parts and only customize the unique portions? This is, of course, one of the principles of object-oriented programming (OOP), but UVM actually takes it a step further.

A naïve OOP coder might be tempted to instantiate components in an environment directly, such as:
class my_env extends uvm_env;
  function void build_phase(…);
    my_driver drv = new("drv", this); //extended from uvm_driver
    …
  endfunction
  …
endclass

The environment would be similarly instantiated in a test:
class my_test extends uvm_test;
  function void build_phase(…);
    my_env env = new("env", this); //extended from uvm_env
  endfunction
  …
endclass

Once you get your environment running with good transactions, it’s often useful to modify things to find out what happens when you inject errors into the transaction stream. To do this, we’ll create a new driver, called my_err_driver (extended from my_driver) and instantiate it in an environment. OOP would let us do this by extending the my_env class and overloading the build_phase() method like this:
class my_env2 extends my_env;
  function void build_phase(…);
    my_err_driver drv = new(“drv”, this);
    …
  endfunction
  …
endclass

Thus, the only thing different is the type of the driver. Because my_err_driver is extended from my_driver, it would have the same interfaces and all the connections between the driver and the sequencer would be the same, so we don’t have to duplicate that other code. Similarly, we could extend my_test to use the new environment:
class my_test2 extends my_test;
  function void build_phase(…);
    my_env2 env = new(“env”, this); //extended from my_env
    …
  endfunction
  …
endclass

So, we’ve gone from one test, one env and one driver, to two tests, two envs and two drivers (and a whole slew of new build_phase() methods), when all we really needed was the extra driver. Wouldn’t it be nice if there were a way that we could tell the environment to instantiate the my_err_driver without having to create a new extension to the environment? We use something called the factory pattern to do this in UVM.

The factory is a special class in UVM that creates an instance for you of whatever uvm_object or uvm_component type you specify. There are two important parts to using the factory. The first is registering a component with the factory, so the factory knows how to create an instance of it. This is done using the appropriate utils macro (which is just about the only macro I like using in UVM):
class my_driver extends uvm_driver;
  `uvm_component_utils(my_driver) // notice no ‘;’
  …
endclass

The uvm_component_utils macro sets up the factory so that it can create an instance of the type specified in its argument. It is critical that you include this macro in all UVM classes you create that are extended (even indirectly) from the uvm_component base class. Similarly, you should use the uvm_object_utils macro to register all uvm_object extensions (such as uvm_sequence, uvm_sequence_item, etc.).

Now, instead of instantiating the my_driver directly, we instead use the factory’s create() method to create the instance:
class my_env extends uvm_env;
  `uvm_component_utils(my_env)
  function void build_phase(uvm_phase phase);
    drv = my_driver::type_id::create(“drv”, this);
    …
  endfunction
  …
endclass

The “::type_id::create()” incantation is the standard UVM idiom for invoking the factory’s static create() method. You don’t really need to know what it does, only that it returns an instance of the my_driver type, which is then assigned to the drv handle in the environment. Given this flexibility, we can now use the test to tell the environment which driver to use without having to modify the my_env code.

Instead of extending my_test to instantiate a different environment, we can instead use an extension of my_test to tell the factory to override the type of object that gets instantiated for my_driver in the environment:
class my_factory_test extends uvm_test;
  `uvm_component_utils(my_factory_test);
  function void build_phase(…);
my_driver::type_id::set_type_override(my_err_driver::get_type());
    super.build_phase(…);
  endfunction
endclass

This paradigm allows us to set up a base test that instantiates the basic environment with default components, and then extend the base test to create a new test that simply consists of factory overrides and perhaps a few other things (for future blog posts) to make interesting things happen. For example, in addition to overriding the driver type, the test may also choose a new stimulus sequence to execute, or swap in a new coverage collector. The point is that the factory gives us the hook to make these changes without changing the env code because the connections between components remain the same due to the use of the TLM interfaces. You get to add new behavior to an existing testbench without changing code that works just fine. It all fits together…

, , , ,

24 May, 2016

Join us at the 53rd Design Automation Conference

DAC is always a time of jam-packed activity with multiple events that merit your time and attention.  As you prepare your own personal calendars and try your best to reduce or eliminate conflicts, let me share with you some candidate events that you may wish to consider having on your calendar.  I will highlight opportunities to learn more about ongoing and emerging standards from Accellera and IEEE.  I will focus on a few sessions at the Verification Academy booth (#627) that feature Partner presentations.  And I will spotlight some venues where other industry collaboration will be detailed.  You will also find me at many of these events as well.

Standards

Accellera will host its traditional Tuesday morning breakfast.  Registration is required – or you might not find a seat.  As always, breakfast is free.  The morning will feature a “Town Hall” style meeting that will cover UVM (also known as IEEE P1800.2) and other technical challenges that could help evolve UVM into other areas.   Find out more and learn about all things UVM, register here.

Partners

The Verification Academy is “partner-central” for us this year.  Each day will feature partner presentations that highlight evolving design and verification methodologies, standards support and evolution, and product integrations.  Verification Academy is booth #627, which is centrally located and easy to find.  Partner presentations include:

  • Back to the Stone Ages for Advanced Verification
    Monday June 6th
    2:00 PM | Neil Johnson – XtremeEDA

    Modern development approaches are leaving quality gaps that advanced verification techniques fail to address… and the gaps are growing in spite of new innovation. It’s time for a fun, frank and highly interactive discussion around the shortcomings of today’s advanced verification methods.

  • SystemVerilog Assertions – Bind files & Best Known Practices
    Monday June 6th
    3:00 PM | Cliff Cummings – Sunburst Design

    SystemVerilog Assertions (SVA) can be added directly to the RTL code or be added indirectly through bindfiles. 13 years of professional SVA usage strongly suggests that Best Known Practices use bindfiles to add assertions to RTL code.

  • Specification to Realization flow using ISequenceSpec™ and Questa® InFact
    Tuesday June 7th
    10:00 AM | Anupam Bakshi – Agnisys, Inc.

    Using an Ethernet Controller design, we show how complete verification can be done in an automated manner, saving time while improving quality. Integration of two tools will be shown. InFact creates tests for a variety of scenarios which is more efficient and exhaustive than a pure constrained random methodology. ISequenceSpec forms a layer of abstraction around the IP/SoC from a specification.

  • Safety Critical Verification
    Wednesday June 8th
    10:00 AM | Mike Bartley – TVS

    The traditional environments for safety-related hardware and software such as avionics, rail and nuclear have been joined by others (such as automotive and medical devices) as systems become increasingly complex and ever more reliant on embedded software. In tandem, further industry-specific safety standards (including ISO 26262 for automotive applications and IEC 62304 for medical device software) have been introduced to ensure that hardware and software in these application areas has been developed and tested to achieve a defined level of integrity. In this presentation, we will be explaining some of these changes and how they can be implemented.

  • Using a Chessboard Challenge to Discover Real-world Formal Techniques
    Wednesday June 8th
    3:00 PM | Vigyan Singhal & Prashant Aggarwal – Oski Technology

    In December 2015, Oski challenged formal users to solve a chessboard problem. This was an opportunity to show how nifty formal techniques might be used to solve a fun puzzle. Design verification engineers from a variety of semiconductor companies and research labs participated in the contest. The techniques submitted by participants presented a number of worthy solutions, with varying degrees of success.

Industry Collaboration

Debug Data API: “Cadence and Mentor Demonstrate Collaboration for open Debug Data API in Action”  It was just a year ago that the project to create an open debug data API was announced at DAC 52.  Since there several possible implementation styles were reviewed, an agreed specification created and early working prototypes demonstrated.  On Tuesday, June 7th at 2:00pm we will host a session at the Verification Academy (Booth #627).  You are encouraged to register for the free session – but walkups are always welcome!  You can find more information here.

Portable Stimulus Tutorial: “How Portable Stimulus Addresses Key Verification, Test Reuse, and Portability Challenges”  As part of the official DAC program, there will be a tutorial on the emerging standardization work in Accellera.  The tutorial is Monday, June 6th from 1:30pm – 3:00pm in the Austin Convention Center, Room 15.  You can register here for the tutorial.  There is a fee for this event.  Want to know more about the tutorial?  You can find more information here.

Fun

It is always good to end the day on a light note.  To that end, on Monday June 6th, will invite you to “grab a cold one” at the Verification Academy booth and continue discussions and networking with your colleagues.  If past year’s experience is any guide to this year, you may want to get here early for your drink!  There is no registration to guarantee a drink, unfortunately!  So, come early; stay late!  See you in Austin!

And if you miss me at any of the locations above, tweet me @dennisbrophy – your message is sure to reach me right away.

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

@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