Posts Tagged ‘1800’

30 July, 2015

Accellera Handoffs UVM to IEEE

It has been a long path from Mentor’s AVM to IEEE P1800.2.  But the moment has arrived: Accellera has formally announced UVM 1.2 will be submitted as a contribution to the IEEE P1800.2™ working group.

Verification Methodology Beginnings

As the IEEE finalized approval of the initial release of SystemVerilog (IEEE Std. 1800™) in 2005, I floated the idea of the need for a methodology that would be a companion to it.  At the time there was little to no industry desire to explore this opportunity in earnest – apart from interest by Mentor Graphics – so we launched our Advanced Verification Methodology (AVM) and set a new direction for an open functional verification methodology.  We built implementations of AVM based on SystemVerilog and SystemC (IEEE Std. 1666™).  We also pioneered an open-source mechanism based on the Apache 2.0 license which is now the accepted license to foster global and rapid open-source adoption in the EDA industry.  And as others joined with us in this journey, AVM grew to become OVM, then UVM.  Now UVM is set to become an IEEE standard.  The IEEE has assigned it project number 1800.2.

imagePath to IEEE

To say we are pleased to see UVM move to the IEEE is an understatement.  We congratulate the Accellera UVM team on its accomplishment and look forward to participate in this phase of UVM’s standardization. Since our first public announcement on May 8, 2006 when we introduced the world to AVM and announced support for it from 19 of our Questa Vanguard Partners, to our announced collaboration with Cadence Design Systems on the development of the Open Verification Methodology (OVM) on August 16, 2007 and the eventual announcement January 8, 2010 that Accellera adopts OVM as the basis of its Universal Verification Methodology, we have guided its development and supported a path for the Big-3 EDA to voice positive public support.  We are thrilled Accellera has announced its delivery of UVM to the IEEE for ongoing standardization and maintenance.

IEEE Standardization

What comes next?  The IEEE P1800.2 (UVM) project has announced a Call for Participation and kickoff meeting to be held August 6, 2015 from 9am – 11am PDT.  The first meeting will be held via teleconference.  In order to attend, you will need to register for the meeting.  Membership in the IEEE project will be “entity-based” with one company, one vote.  The call for participation has details on membership requirements in order to observe or actively participate.  The 1800.2 project will only focus on the written specification and not the open-source base class library (BCL).  The Accellera UVM TSC will continue to update the BCL.  Accellera has committed to keep the BCL implementation current with changes proposed and approved by the IEEE 1800.2 working group.  This is just like the arrangement Accellera has with the IEEE for SystemC.

Join us at the upcoming meeting and remember to register in order to attend!

 

, , , , , , , , , ,

27 July, 2015

ASIC/IC Language and Library Adoption Trends

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

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 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, with the exception of SystemVerilog.

2014-WRG-BLOG-ASIC-10-1

Figure 1. ASIC/IC Languages Used for RTL Design

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, with the exception of SystemVerilog. Nonetheless, the data suggest that SystemVerilog adoption is starting to saturate or level off at about 75 percent.

2014-WRG-BLOG-ASIC-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.

2014-WRG-BLOG-ASIC-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 UVM3, whose adoption increased by 56 percent between 2012 and 2014. Furthermore, our study revealed that UVM is projected to grow an additional 13 percent within the next year.

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

2014-WRG-BLOG-ASIC-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 2014 Wilson Research Group Study results

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

3 June, 2015

FPGA Language and Library Trends

This blog is a continuation of a series of blogs related to the 2014 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 2014 Wilson Research Group study. In this blog, I’ll present FPGA design and verification language trends, as identified by the Wilson Research Group study.

You might note that the percentage for some of the language and library data 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 Wilson Research Group study (in dark blue), the 2014 Wilson Research Group study (in light blue), as well as the projected design language adoption trends within the next twelve months (in purple). 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.

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 the projected trend is that Verilog will likely overtake VHDL in terms of the predominate language used for FPGA design in the near 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 Wilson Research Group study (in dark blue), the 2014 Wilson Research Group study (in light blue), as well as the projected verification language adoption trends within the next twelve months (in purple).

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

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 Wilson Research Group study (in dark blue), the 2014 Wilson Research Group study (in light blue), as well as the projected verification language adoption trends within the next twelve months (in purple).

Figure 3. FPGA methodology and class library adoption trends

Today, we see a downward trend in terms of adoption of all testbench methodologies and class libraries with the exception of UVM, which has increased by 28 percent since 2012. 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 20 percent.

FPGA Assertion Language and Library Adoption Trends

Finally, let’s examine assertion language and library adoption for FPGA designs. The 2014 Wilson Research Group study found that 44 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 2010 Wilson Research Group study (in dark blue), the 2012 Wilson Research Group study (in green), and the projected adoption trends within the next 12 months (in purple). The adoption of SVA continues to increase, while other assertion languages and libraries either remain flat or decline.

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 2014 Wilson Research Group Functional Verification Study.

Quick links to the 2014 Wilson Research Group Study results

, , , , , , , ,

19 September, 2013

It’s hard for me to believe that SystemVerilog 3.1 was released just over 10 years ago. The 3.1 version added Object-Oriented Programming features for testbench development to a language predominately used for RTL design synthesis. Making debug easier was one of the driving forces in unifying testbench and design features into a single language. The semantics for evaluating expressions and executing statements would be the same in the testbench and design. Setting breakpoints and stepping through the code would be seamless. That should have made it easier for either a verification or a design engineer to understand a complete verification environment. Or maybe it would enable either one to at least understand enough of the environment to isolate a particular problem.

Ten years later, I have yet to see that promise fulfilled. Most design engineers still debug their simulations the same way they debug in the lab: they look at waveforms. During simulation, they rarely look at the design source code, and certainly never look at the testbench code (unless it’s just basic pin wiggling like a waveform). Verification engineers are not much different. They rely on waveform debugging because that is what they were brought up on, and many do not even realize source-level debugging is available to them. However the test/testbench is more like a piece of software than a hardware description, and there are many things about a modern testbench that is difficult to display in a waveform (e.g. call stacks, local variables, and random constraints). And methodologies like the UVM add many layers of source-level complexity that most users do not have the time to wade through.

Next week I will be presenting as part of an Industry Special Session during the Forum on specification & Design Languages (FDL September 24-26,2013) that will discuss these issues and try to get more involvement from the academic and user communities to help resolve them. Was combining constructs from many languages into one a success? Can tools provide representations of source-level constructs in an easier graphical form? We hopefully will not need another decade.

, , , ,

12 August, 2013

Language and Library Trends (Continued)

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 8 click here), I focused on design and verification language trends, as identified by the Wilson Research Group study. This blog presents additional trends related to verification language and library adoption trends.

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

Testbench Methodology Class Library Adoption

Now let’s look at testbench methodology and class library adoption for IC/ASIC designs. Figure 1 shows the trends in terms of methodology and class library adoption by comparing the 2010 Wilson Research Group study (in blue) with the 2012 study (in green). Today, we see a downward trend in terms of adoption of all testbench methodologies and class libraries with the exception of UVM, which has increased by 486 percent since the fall of 2010. 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 46 percent.

Figure 1. Methodology and class library trends

Figure 2 show the adoption of testbench methodologies and class libraries for FPGA designs (in red). We do not have sufficient data to show prior adoption trends in the FPGA space, but we anticipate that our future studies will enable us to do this. However, we did ask the FPGA study participants which testbench methodologies and class libraries they were planning to adopt within the next 12 months. Based on these responses, we anticipate that UVM adoption will increase by 40 percent, and OVM increase by 24 percent in the FPGA space.

Figure 2. Methodology and class library trends

Assertion Languages and Libraries

Finally, let’s examine assertion language and library adoption for IC/ASIC designs. The Wilson Research Group study found that 63 percent of all the IC/ASIC participants 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 trend related to those participants who have adopted ABV.

Figure 3 shows the trends in terms of assertion language and library adoption by comparing the 2010 Wilson Research Group study (in blue), the 2012 Wilson Research Group study (in green), and the projected adoption trends within the next 12 months (in purple). The adoption of SVA continues to increase, while other assertion languages and libraries either remain flat or decline.

Figure 3. Assertion language and library adoption for Non-FPGA designs

Figure 4 shows the adoption of assertion language trends for FPGA designs (in red). Again, we do not have sufficient data to show prior adoption trends in the FPGA space, but we anticipate that our future studies will enable us to do this. We did ask the FPGA study participants which assertion languages and libraries they planned to adopt within the next 12 months. Based on these responses, we anticipate an increase in adoption for OVL, SVA, and PSL in the FPGA space within the next 12 months.

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

In my next blog (click here), I plan to focus on the adoption of various verification technologies and techniques used in the industry, as identified by the 2012 Wilson Research Group study.

, , , , , , , , , ,

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.

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

29 July, 2013

Testbench Characteristics and Simulation Strategies

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

In my previous blog (click here), I focused on the controversial topic of effort spent in verification. In this blog, I focus on some of the 2012 Wilson Research Group findings related to testbench characteristics and simulation strategies. Although I am shifting the focus away from verification effort, I believe that the data I present in this blog is related to my previous blog and really needs to be considered when calculating effort.

Time Spent in full-chip versus Subsystem-Level Simulation

Let’s begin by looking at Figure 1, which shows the percentage of time (on average) that a project spends in full-chip or SoC integration-level verification versus subsystem and IP block-level verification. The mean time performing full chip verification is represented by the dark green bar, while the mean time performing subsystem verification is represented by the light green bar. Keep in mind that this graph represents the industry average. Some projects spend more time in full-chip verification, while other projects spend less time.

Figure 1. Mean time spent in full chip versus subsystem simulation

Number of Tests Created to Verify the Design in Simulation

Next, let’s look at Figure 2, which shows the number of tests various projects create to verify their designs using simulation. The graph represents the findings from 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). Note that the curves look remarkably similar over the past five years. The median number of tests created to verify the design is within the range of (>200 – 500) tests. It is interesting to see a sharp percentage increase in the number of participants who claimed that fewer tests (1 – 100) were created to verify a design in 2012. It’s hard to determine exactly why this was the case—perhaps it is due to the increased use of constrained random (which I will talk about shortly). Or perhaps there has been an increased use of legacy tests. The study was not design to go deeper into this issue and try to uncover the root cause. This is something I intend to informally study this next year through discussions with various industry thought leaders.

Figure 2. Number of tests created to verify a design in simulation

Percentage of Directed Tests versus Constrained-Random Tests

Now let’s compare the percentage of directed testing that is performed on a project to the percentage of constrained-random testing. Of course, in reality there is a wide range in the amount of directed and constrained-random testing that is actually performed on various projects. For example, some projects spend all of their time doing directed testing, while other projects combine techniques and spend part of their time doing directed testing—and the other part doing constrained-random. For our comparison, we will look at the industry average, as shown in Figure 3. The average percentage of tests that were directed is represented by the dark green bar, while the average percentage of tests that are constrained-random is represented by the light green bar.

Figure 3. Mean directed versus constrained-random testing performed on a project

Notice how the percentage mix of directed versus constrained-random testing has changed over the past two years.Today we see that, on average, a project performs more constrained-random simulation. In fact, between 2010 and 2012 there has been a 39 percent increase in the use of constrained-random simulation on a project. One driving force behind this increase has been the maturing and acceptance of both the SystemVerilog and UVM standards—since two standards facilitate an easier implementation of a constrained-random testbench. In addition, today we find that an entire ecosystem has emerged around both the SystemVerilog and UVM standards. This ecosystem consists of tools, verification IP, and industry expertise, such as consulting and training.

Nonetheless, even with the increased adoption of constrained-random simulation on a project, you will find that constrained-random simulation is generally only performed at the IP block or subsystem level. For the full SoC level simulation, directed testing and processor-driven verification are the prominent simulation-based techniques in use today.

Simulation Regression Time

Now let’s look at the time that various projects spend in a simulation regression. Figure 4 shows the trends in terms of simulation regression time by comparing the 2007 Far West Research study (in gray) with the 2010 Wilson Research Group study (in blue), and the 2012 Wilson Research Group study (in green). There really hasn’t been a significant change in the time spent in a simulation regression within the past three years. You will find that some teams spend days or even weeks in a regression. Yet today, the industry median is between 8 and 16 hours, and for many projects, there has been a decrease in regression time over the past few years. Of course, this is another example of where deeper analysis is required to truly understand what is going on. To begin with, these questions should probably be refined to better understand simulation times related to IP versus SoC integration-level regressions. We will likely do that in future studies—with the understanding that we will not be able to show trends (or at least not initially).

Figure 4. Simulation regression time trends

In my next blog (click here), I’ll focus on design and verification language trends, as identified by the 2012 Wilson Research Group study.

, , , , , , , , , ,

16 July, 2013

It is often said that the English language is one of the most difficult languages to learn: inconsistent spelling rules; the same words are used with different meanings in different contexts. “Why does a farmer produce produce?

Working on the SystemVerilog IEEE 1800 standard, I understand that even more clearly now. The word class is used many times in different contexts to mean slightly different things that the reader is expected to understand. With brevity, but little more attention to clarity, I will explain some of these different contexts.

Class Types

When you declare a class, you are declaring set of members and a set of methods that operate on those members.

class MyClass; bit [7:0] member1; 
 bit member2;
 function void method; 
   $display("members are %h %b", member1, member2); 
 endfunction 
endclass 

Consider this a user defined type, like a typedef. We are declaring the form and behavior of a type, but nothing is allocated to store the values of this type.

Class Objects

A class object is a particular instance of a class type. Each instance is an allocation of the members defined by the class type. The only way to create an object is to call the class constructor using the built-in new() method of a class. We classify class objects as dynamic objects because executing a procedural statement is the only way to create them.

Class Handles

Each time you call the new() method, it constructs a new class object and the method returns a class handle to the class object. A handle is an indirect reference to a class object, like a pointer to an address in memory. Unlike pointers in other languages such as C/C++, you are very limited in what you can do with a handle in SystemVerilog.

Class Variables

A class variable is where you store the class handle that references a particular class object of a particular class type. Declaring a class variable does not create a class object, only the space to hold the class handles. This contrasts with other data types where the declaration of a variable creates an object of that type and gives you a symbolic name to reference those objects. For example:

typesef struct {bit [7:0] member1; bit member2;} MyStruct; 
MyStruct StructVar1, StrucVar2

This creates and allocates the space for two MyStruct type objects and you can use StructVar1.member1 to access one of its members. On the other hand:

MyClass ClassVar1, ClassVar2;

This creates and allocates the space for two MyClass variables, but only allocates the space to hold handles to MyClass objects, not the objects themselves. If you tried to access ClassVar1.member1 now, you would get a null handle reference error because the initial value of a class variable is the special value null. One of the nice things about handles instead of pointers is that they remove the possibility of corrupt object references that access uninitialized or de-allocated memory.

Class Types, Objects, Handles, and Variables

Once you have a class variable, you can call the new() method to construct a class object

ClassVar1 = new();

This calls the constructor of the MyClass type that returns a handle to a MyClass object and then stores that handle in the MyClass variable, ClassVar1. You can now access ClassVar1.member1 because ClassVar1 references an actual object. If you then do:
ClassVar2 = ClassVar1;
Both class variables reference now the same class object – but there is still only one object of MyClass. ClassVar1.member1 and ClassVar2.member1 refer to the same class member.

Class Dismissed

Just remember to add a few extra words when mentioning classes and it will make things much clearer to the reader.

There are whole other classes of class thingy’s I could have explored, but I hope this class on classes will motivate you to learn more of the subtle meanings behind the words.

, ,

5 December, 2012

IEEE Std. 1800™-2012 Officially Ratified

The IEEE Standards Association (SA) Standards Board (SASB) officially approved the latest SystemVerilog revision, Draft 6, as an IEEE standard.  The SASB Review Committee (RevCom) agenda and the SASB agenda include review and formal approval of the latest work by the IEEE Computer Society Design Automation Standards Committee’s (DASC) SystemVerilog Working Group at their December 2012 meeting series.

What’s New?

The new standard has many new features, numerous clarifications and various corrections to improve the standard and keep pace with electronic system design and verification.  DVCon 2012 included a session presentation, Keeping Up with Chip – The Proposed SystemVerilog 2012 Standard Makes Verifying Ever-Increasing Design Complexity More Efficient” that detailed the standard.  The paper was written by Stuart Sutherland (Sutherland HDL, Inc.) and Tom Fitzpatrick (Mentor Graphics).  You can find a copy of the paper here at the DVCon 2012 archive and the presentation can be found at Sutherland HDL’s site here.

For users of Mentor Graphics’ Questa Verification Platform, many of the major SystemVerilog 2012 features can be used today, like multiple inheritance.  As Stu and Tom said in their presentation, “This is BIG!”  If you read their full paper, they discuss some ways this new feature might be useful for a UVM testbench.

Major work was done to augment the current notion of constraints in SystemVerilog.  In past versions of the standard they were known as hard constraints.  What this meant was all the conditions of the constraints had to be met otherwise there would be an error.  There was no built-in method to relax the need to satisfy the constraints.  Given the world of multiple constraints is the norm for testbenches today the potential for conflicts between them is high.  To alleviate this the SystemVerilog Working Group introduced soft constraints to the standard.  If you are interested in the details of what was proposed to be added the standard, you can reference the full proposal here that is included in the standard.  Stu and Tom said that “This is also a big enhancement!”

Availability

IEEE 1800™-2012 has only now been approved.  The standard itself is not ready to be published yet.  Plans are to have it ready to be published before DVCon 2013, which is scheduled for late February 2013.  I will  share publication information as it becomes available.  And, I hope you join me and attend DVCon 2013 where we can plan to celebrate the unveiling of the published standard.

sva3rdE_cover-wsWhile the IEEE publication will be the authoritative source on the standard, I have pointed to the presentation and paper by Stu Sutherland and Tom Fitzpatrick for information on the new standard that you can reference now.  For those who depend on assertions, you will find SystemVerilog-2012 has a major update with enhancements for properties and sequences in the area of immediate assertions, data type support, argument passing, vacuity definitions, global clock resolution and inferred clocking in sequences and much more.  You may find the SystemVerilog Assertions Handbook 3rd Edition by Ben Cohen, et. al. to be of value as well.  You can find more information about it on Amazon.com here.

The Story Continues…

There is much more to the SystemVerilog-2012 story I will share more of that in the months ahead.  The global team of experts who have put this together has been an outstanding collection of individuals ranging from producers and suppliers of electronic design automation software to consumers of said technology who have ensured the language can be used to design and verify the most demanding of electronic systems.

Stay tuned!  For now, I encourage you to get informed!

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

10 September, 2012

OVM Bridges SystemVerilog and SystemC Languages

When UVM Connect was first released, the multilingual connection between IEEE Std. 1800™ (SystemVerilog) and IEEE Std. 1666™ (SystemC) standards bridged the two languages to allow design and verification engineers to access UVM from SystemC or SystemVerilog to exploit native languages advantages.  OVM users wondered if it was possible to support them as well since OVM is a derived from UVM.

It is possible and UVM Connect has been extended to allow OVM users to enjoy the same benefits.  An update to UVM Connect now allows it to be compiled to run with the OVM.  And since the extensions are based on IEEE standards, they can be used in your simulator of choice.

OVM Thrives

The thriving OVM community is of no surprise.  Last year, Harry Foster blogged about research on the use and adoption of verification methodologies.  The research was done after UVM was established as an Accellera standard, and showed OVM continued its leading position as shown in one of the charts from Harry’s blog (see below).  The chart even showed OVM was predicted to have a modest growth in adoption as well.

Mentor continues to bring many of the UVM additions back to the OVM user community in a way that does not disturb the upgrade path from OVM to UVM.  The major addition to UVM in the first round of Accellera standardization was the addition of a register and memory package.  This was back ported to OVM.  (The OVM register and memory kit can be found here, if you are interested.)  Now, UVM Connect has been extended to provide full OVM use.

Download

The UVM Connect 2.2 kit supports multilingual use of OVM and can be found at the Verification Academy and the Accellera UVM World contributions download site.

If you find issues or have other suggestions that we should consider, you can always share your input at the OVM Forum or UVM Forum.  In addition to interacting with other users, the Verification Academy is a good site for online resources like the UVM/OVM Cookbook, basic and advanced OVM/UVM training, and more.

, , , , , , , , , , ,

@dennisbrophy Tweets

  • Loading tweets...

@dave_59 Tweets

  • Loading tweets...

@jhupcey Tweets

  • Loading tweets...