Posts Tagged ‘IEEE 1800’
Part 1: The 2012 Wilson Research Group Functional Verification Study
Design Trends
In my previous blog, I introduced the 2012 Wilson Research Group Functional Verification Study (click here). The objective of my previous blog was to provide background on this large, worldwide industry study. I will present the key findings from this study in a set of upcoming blogs.
This blog begins the process of revealing the 2012 Wilson Research Group study findings by first focusing on current design trends. Let’s begin by examining process geometry adoption trends, as shown in Figure 1. Here, you will see trend comparisons between the 2007 Far West Research study (gray line), the 2010 Wilson Research Group study (blue line), and the 2012 Wilson Research Group study (green line).
Figure 1. Process geometry trends
Worldwide, the median process geometry size from the 2007 Far West Research study was about 90nm, while the median process geometry size is about 65nm in 2010. Today, the mean process geometry size for a typical project is about 45nm—although you can see that over a third of projects today are designing below 32nm.
In addition to the industry moving to smaller process geometries, the industry is also moving to larger design sizes as measured in number of gates of logic and datapath, excluding memories (which should not be a surprise). Figure 2 compares design sizes from the 2002 Collett study (dark blue line), the 2007 Far West Research study (gray line), the 2010 Wilson Research Group study (light blue line), and the 2012 Wilson Research Group study (green line).
Figure 2. Number of gates of logic and datapath trends, excluding memories
The study revealed that about a third of the non-FPGA designs today are less than 5M gates, while a third range in size between 5M to 20M gates, and about a third of all designs are larger than 20M gates.
It’s important to note here that the data on the mean design size trends does not reflect volume in terms of semiconductor production. For example, you could have fewer projects designing at a small geometry, yet they have higher volume in terms of production.
In Figure 3, I show the mean design size trends between the 2002 Collett study (dark blue line), the 2007 Far West Research study (gray line), the 2010 Wilson Research Group study (light blue line), and the 2012 Wilson Research Group study (green line). Obviously, gate counts have increased over the years, yet a significant number of designs continue to be developed with smaller (and larger) gate counts as indicated by the mean calculation. Another observation is that, as you would expect, the mean gate count trend is essentially following Moore’s law.
Figure 3. Mean design size trends
Figure 4 presents the current design implementation trends for non-FPGAs as identified by the survey participants.
Figure 4. Non-FPGA current design implementation trends
The data in Figure 4 presents trends in design implementation approaches for non-FPGA designs, ranging from the 2002 Collett study (dark blue bar), the 2004 Collet study (dark green bar), the 2007 Far West Research study (gray bar), the 2010 Wilson Research Group study (blue bar), and the 2012 Wilson Research Group study (green bar). Note that the study seems to indicate that there is a downward trend in standard cell design implementation.
Figure 5. FPGA design implementation trends
For the 2012 study, we decided that we wanted to get a sense of the percentage of FPGA projects that target the very complex programmable SoC FPGAs that have recently emerged, which is shown in Figure 5. Examples of these programmable SoC FPGAs include: Xilinx’s Zynq, Altera’s Arria/Cydone, and Microsemi’s SmarFusion.
In my next blog (click here), I’ll continue discussing current design trends, focusing specifically on embedded processors, power, and clock domains.
Tags: accellera, functional verification, IEEE, IEEE 1800, Verification, Verification Academy
IEEE 1800™-2012 SystemVerilog Standard Is Published
Download the standard now – at no charge!
The IEEE has published the latest update to the SystemVerilog standard. And courtesy of Accellera, the standard is available for download without charge directly from the IEEE.
The latest update to the SystemVerilog standard is now ready for download. It joins other EDA standards, like SystemC in the IEEE Get™ program that grants public access to view and download current individual standards at no charge as a PDF. (If you wish to have an older, superseded and withdrawn version of the standard or if you wish to have a printed copy or have it in a CD-ROM format, you can purchase older and alternate formats from IEEE for a fee.)
Over the years Accellera came to understand that many people continued to use the freely available version that seeded the initial IEEE 1800 SystemVerilog standard. Since it is significantly out of date, Accellera collaborated with the IEEE Standards Association to ensure the latest version of the SystemVerilog standard would be freely available in electronic form to all whom wish to download it. Accellera now hopes all those old 3.1a versions that everyone has and uses can now be placed in the archives.
The new version of standard should be used by the UVM (Universal Verification Methodology) community as the definitive specification of the SystemVerilog standard upon which UVM is built. It goes very well with the UVM Cookbook and the Coverage Cookbook.
From Mentor’s perspective, it also makes a good companion to the Questa verification platform and complements our latest product update in which we announced support for the IEEE 1800-2012 SystemVerilog standard among other things.
If you have not done so already, download your copy now by clicking here.
Tags: Coverage Cookbook, IEEE 1800, IEEE Get, Standards, systemc, SystemVerilog, UVM, UVM Cookbook
Coverage Cookbook Debuts
Verification Academy Adds Major New Technical Resource
The Verification Academy adds another major methodology cookbook to focus on effective coverage adoption. The Coverage Cookbook describes the different types of coverage that are available to track your verification process progress, how to create a functional coverage model from a specification, and provides examples to implement functional coverage for different types of designs.
Verification Academy “full access” members have access to the free Coverage Cookbook and the UVM/OVM Cookbooks as well. Are you a registered full access member? If not, register now to become a full access member. (Restrictions apply.)
Coverage is not a new topic. It was one of major additions to the SystemVerilog (IEEE Std. 1800™-2009) standard. But the SystemVerilog functional coverage extensions were left to the verification engineer to use in such as way to return meaningful measurements of how much of the design specification was being tested. The Universal Verification Methodology (UVM) offers greater structure for coverage over SystemVerilog, but it too, is still only a piece of the puzzle.
As verification teams have come to generate greater amounts of information from use of SystemVerilog, UVM and other verification tools, the data from the verification runs needs to be easily used to drive coverage closure. Within the Mentor Graphics Questa verification platform, this resulted in the development of the Unified Coverage Database (UCDB) and associated verification management and planning features.
Since verification teams use a variety of tools and technology from many sources, it was an imperative that verification information could be easily shared and combined to help drive faster coverage closure across the industry. This is why Mentor Graphics donated its UCDB API to Accellera where it became the Unified Coverage Interoperability Standard (UCIS).
It would be great to think that we are done; but we’re not. Tools and data are just two dimensions of the three dimensions to any IC design project. A comprehensive approach to verification management that handles all of this adds the third dimension. The Mentor Graphics Questa Verification Management features handle all this.
Now the question is how to best adopt and use all the capabilities at hand from the standards to the verification technology at your finger tips.
The Verification Academy Coverage Cookbook is one of the important tools you now have to help pull all the information into a single place where you can learn the theory and put that theory into practice. The Coverage Cookbook is much like the OVM/UVM Cookbooks in that it is web friendly, while supporting the ability for you to generate a PDF file of the whole document in case you want to have a printed copy or have it available for offline reference.
The Theory section covers:
|
The Practice section shows three examples you can use today:
|
The Coverage Cookbook is a live document. You can expect continued extensions and contributions to enhance it. As Harry Foster, Mentor Graphics’ Chief Scientist Verification put it, “Methodology is the bridge between tools and technologies, which creates a productive, predictable, and repeatable solution.” We should expect that our collective use of this technology will help hone the methodology which is the heart of the Coverage Cookbook. And with this use, we should expect the Coverage Cookbook to evolve as we achieve greater verification productivity.
Let us know what you think about the Coverage Cookbook and what we might be able to do to improve it. In the meantime, Happy Coverage Closing!
Tags: accellera, Coverage, Coverage Closure, Coverage Cookbook, functional coverage, Harry Foster, IEEE 1800, OVM, SystemVerilog, UCDB, UCIS, UVM, Verification Academy
Part 8: The 2010 Wilson Research Group Functional Verification Study
Language and Library Trends
This blog is a continuation of a series of blogs, which present the highlights from the 2010 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 2010 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 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 perticipant’s projects use multiple languages and multiple methodologies.
Design Languages
Let’s begin by examining the languages used for design, as shown in Figure 1. Here, we compare the results for languages used to design FPGAs (in grey) with languages used to design non-FPGAs (in green).
Figure 1. Languages used for design
Not too surprising, we see that VHDL is the most popular language used for the design of FPGAs, while Verilog and SystemVerilog are the most popular languages used for the design of non-FPGAs.
Figure 2 shows the trends in terms of languages used for design, by comparing the 2007 Far West Research study (in blue) with the 2010 Wilson Research Group study (in green), as well as the projected design language adoption trends within the next twelve months (in purple). Note that the design language adoption is declining for most of the languages with the exception of SystemVerilog whose adoption is increasing.
Figure 2. Trends in languages used for design
Verification Languages
Next, let’s look at the languages used for verification (that is, languages used to create simulation testbenches). Figure 3 compares the results between FPGA designs (in grey) and non-FPGA designs (in green). 
Figure 3. Languages used in verification to create simulation testbenches
And again, it’s not too surprising to see that VHDL is the most popular language used to create verification testbenches for FPGAs, while SystemVerilog is the most popular language used to create testbenches for non-FPGAs.
Figure 4 shows the trends in terms of languages used to create simulation testbenches by comparing the 2007 Far West Research study (in blue) with the 2010 Wilson Research Group study (in green), as well as the projected language adoption trends within the next twelve months (in purple). Note that verification language adoption is declining for most of the languages with the exception of SystemVerilog whose adoption is increasing.
Figure 4. Trends in languages used in verification to create simulation testbenches
Now, let’s look at methodology and class library adoption. Figure 5 shows the future trends in terms of methodology and class library adoption by comparing the 2010 Wilson Research Group study (in green) with the projected adoption trends within the next twelve months (in purple). Previous studies did not include data on methodology and class library adoption, so we are unable to show previous trends.
Figure 5. Methodology and class library future trends
The study indicates that the only methodology adoption projected to grow in the next twelve months are OVM and UVM.
Assertion Languages and Libraries
Finally, let’s examine assertion language and library adoption, as shown in Figure 6. Here, we compare the results for FPGA designs (in grey) and non-FPGA designs (in green).
Figure 6. Assertion language and library adoption
SystemVerilog Assertions (SVA) is the most popular assertion language used for both FPGA and non-FPGA designs.
Figure 7 shows the trends in terms assertion language and library adoption by comparing the 2007 Far West Research study (in blue) with the 2010 Wilson Research Group study (in green), as well as the projected adoption trends within the next twelve months (in purple). Note that the adoption of most of the assertion languages is declining, with the exception of SVA whose adoption is increasing.
Figure 7. Trends in assertion language and library adoption
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 2010 Wilson Research Group study.
Tags: 1076, 1364, 1666, 1800, accellera, Add new tag, Assertion-Based Verification, functional verification, IEEE 1800, OVM, Standards, SystemVerilog, UVM, Verification Methodology, verilog, vhdl, vmm
SystemVerilog Coding Guidelines: Package import versus `include
Another frequently asked question: Should I import my classes from a package or `include them? To answer this properly, you need to know more about SystemVerilog’s type system, especially the difference between its strong and weak typing systems.
In programming languages, weak typing is characterized by implicit or ad-hoc conversions without explicit casting between values of different data types. Verilog’s bit vectors, or integral types, represent these weak typing aspects by implicitly padding and truncating values to be the proper bit lengths – at least proper by Verilog standards. If you perform a bitwise AND of a 7-bit and 8-bit vector, Verilog implicitly zero pads an 8th bit to the 7-bit operand and returns an 8-bit result. In contrast using VHDL, you would have to explicitly state whether you wanted the 7-bit operand to be padded, or the 8-bit operand to be truncated so that you have an expression with operands of equal size.
With a few exceptions, all other types in SystemVerilog follow strong typing rules. Strong typing rules require explicit conversions or casts when assigning or expressing operands of unequal types. And understanding what SystemVerilog considers equivalent types is key to understanding the effect of importing a class from a package versus including it from a file.
Inheritance aside, SystemVerilog uses the name of a type alone to determine type equivalence of a class. For example, suppose I have these two class definitions A and B below:
class A; |
class B; |
SystemVerilog considers these two class definitions unequal types because they have different names, even though their contents, or class bodies, are identical. The name of a class includes more than just the simple names A and B; the names also include the scope where the definition is declared. When you declare a class in a package, the package name becomes a prefix to the class name:
package P; |
package Q; |
Now there are two definitions of class A, one called P::A and the other called Q::A. And the variables P::a1 and Q::a1 are type incompatible referencing two different class A’s. Re-writing the above example using an include file creates the same situation – two incompatible class definitions.
| File A.sv | File P.sv | File Q.sv |
class A; |
package P; |
package Q; |
After `including class A into each package, you wind up with two definitions of class A. Using `include is just a shortcut for cut and pasting text in a file. Importing a name from a package does not duplicate text; it makes that name visible from another package without copying the definition.
| File A.sv | File P.sv | File R.sv | File S.sv |
class A; |
package P; |
package R; |
package S; |
Class A is declared in package P, and only in package P. The variables R::a1 and S::a1 are type compatible because they are both of type P::A. The fact that class A was `included from another file once it is expanded is no longer relevant once you consider the placement of the text from the file.
When you get compiler errors claiming that two types are incompatible even though they appear to have the same name, make sure you consider the scope where the types are declared as part of the full name. Class names declared in a module are prefixed by the module instance name, so the same module instantiated multiple times will create unique class names, all incompatible types.
For further information about packages, check out the June Verification Horizons article entitled “Using SystemVerilog Packages in Real Verification Projects”.
Dave Rich
Tags: IEEE 1800, S, SystemVerilog, Verification
The Final Signatures (the meeting during the meeting)
Accellera and The SPIRIT Consortium Merger is Complete
An open SystemVerilog requirements gathering meeting sponsored by the IEEE Design Automation Standards Committee’s (DASC) SystemVerilog Study Group was hosted at Mentor Graphics after DVCon 2010. While the meeting room was packed with many of the world’s SystemVerilog cognoscenti – as well as many from around the world on the phone.
Dave Rich posted his blog on the meeting and shared a link that allowed everyone to see the top-3 items Users and Producers sought from the next version of SystemVerilog. But while Cliff was making his presentation on “Design Connectivity Features,” a few people slipped out of the room into the “Victory” room next door.
What can now be disclosed was the Accellera and The SPRIRIT Consortium representatives were signing final documents to ensure the merger of the two organizations, announced at DAC 2009, would become final.
Shrenik Mehta, for Accellera and Stan Krolikoski, for The Spirit Consortium could be seen taking pen to paper as the final signatures were done to cement the merger. With final legal and governmental reviews complete, the merger became official and was announced today. The press release crossed the wires this morning. The merged organization will retain the Accellera name and have 8 active standards projects. It has also recommitted that is is aligned to create formal standards through the IEEE Standards Association.
Congratulations to the merger teams and staff that worked hard to make it a smooth merger process. Mentor Graphics looks forward to the benefits of the electronics industry when electronic design language-based standards are brought together with Intellectual Property (IP) standards.
Tags: accellera, IEEE 1800, IEEE-SA, SPIRIT, SystemVerilog, The SPIRIT Consortium
The Art of Deprecation
At a recent SystemVerilog requirements gathering meeting,I was quite amused to see “deprecating features” come out as one of the top 10 user requested priorities for the next revision of the IEEE 1800 standard. Even more amazing was that this request came out without listing which features were to be considered for deprecation.
P1800 Requirements Gathering Meeting 2/27/2010
I’m sure most people don’t understand the meaning of the word deprecate. I thought I understood until I looked it up in a dictionary. According to Merriam-Webster:
Deprecate:
1 a archaic : to pray against (as an evil) b : to seek to avert <deprecate the wrath…of the Roman people — Tobias Smollett>
2 : to express disapproval of
3 a : play down : make little of <speaks five languages…but deprecatesthis facility — Time> b : belittle, disparage<the most reluctantly admired and least easily deprecated of…novelists — New Yorker>
In computer science standards and documentation, deprecation has come to mean to supersede or discourage use of a feature. It does not mean a feature has to be removed to be compliant with the standard. You can’t remove a feature from an existing standard; you can only remove a feature from being documented in a future standard. No vendor is going to immediately remove a feature from a tool that it has already implemented and in widespread use without ample warning and without providing a practical alternative to the user. Typically, a deprecated feature is never removed from support in a tool unless in the rare case it’s needed to allow for a future enhancement.
The current standard lists in Annex C.4 the defparam and the procedural continuous assignment statements as candidates for deprecation. Listing candidates for deprecation seems to be almost the same as actually deprecating them without removing the LRM. No tool will remove support for these statements regardless of whether they are candidates or actually removed from the LRM.
Q: So why go though the trouble of deprecating a feature in a standard?
A: Well, to discourage use of that feature.
Q: And why is that a good thing to do?
A: It makes learning the language and maintaining existing code much easier.
Take an example from the current Verilog and SystemVerilog LRMs. The logic data type was added to supersede the reg data types; they both have the same semantics. Anyone with a history of Verilog will understand the change in keywords, but someone new to SystemVerilog will be left wondering why there are two keywords for the same thing. And then there is the issue of trying to maintain the LRM so that all references to reg also include logic and the other way around. If someone misses that in one place, people will begin to think the two keywords have different behaviors.
It seems it’s always easier to add new features than to remove them. There are many places to create lists of your favorite enhancements. At the same time, people complain about the size of the Language Reference Manual – it’s over 1200 pages. Doug Smith of Doulos writes “Will this language ever stop exploding?”
So here is my list for deprecation, as well as a place for other to add their list by commenting here.
- Program blocks
- Reg data type – see above
- Wildcard associative array index types
- Un-typed mailboxes
- Dynamic array copy A = new[]B redundant with A = B
- always @(*) – superseded by always_comb
Tags: IEEE 1800, Standards, SystemVerilog
IEEE Standards Meetings in India
EDA & VLSI Standards Focus Meeting on 12 March 2010
As part of its continuing program to reach out to global technologists, the IEEE Standards Association will be conducting a series of outreach sessions throughout Bangalore from 10-12 March 2010. The IEEE-SA will also visit key governmental agencies in Delhi this week as well. While there is a focal technical point for each outreach session, the outreach sessions will address technical subjects in a general manner.
The use of IEEE standards in India, like IEEE 1800™ (SystemVerilog), is quite strong. In a SystemVerilog Users Group meeting I participated in and blogged about last year, we had 100’s of users at both the Noida and Bangalore events participate. Given the large number of users of IEEE standards to do electronic design and verification in India, it is fitting that the IEEE come and share the standards development process and update the community of users on the current status of many areas in a series of outreach meetings.
Not only are there a large number of users in India, many people in India contribute to the development of EDA standards as well. It is also fitting that the IEEE recognize the importance of the large community of standards supporters and developers in India.
The EDA & VLSI standards focus outreach is scheduled for Friday morning, 12 March 2010 at the IBM’s Embassy Golf Links location. There are other outreach meetings scheduled that cover Networking and Communication, Industrial Electronics, Power/Smart Grid, Academic research and standardization, and lastly, Security and Software standardization. For more information about the other outreach meetings, click here.
IEEE-SA Open Seminar: “Global Standards at IEEE”
To begin the week the IEEE-SA Corporate Advisory Group will present “Global Standards at IEEE ” on Tuesday, 9 March 2010, in Bangalore, India at the Royal Ballroom, Leela Palace Hotel.
The seminar is a premier event for those in industry and government who are involved in the advancement of technology and interested to learn more about the global impact of IEEE standards. It will provide an overview of several technical areas undergoing standardization at IEEE, as well as illustrate how local entities can participate in and make use of IEEE’s standards and best practices.
Leaders from industry will provide their insight through presentations and case studies on areas such as smart grid, software life cycle, IEEE 802®, and electronic design automation.
If you want to attend any of the meetings, please register. I look forward to see many familiar faces this coming week in India.
Tags: IEEE, IEEE 1800, IEEE-SA, Standards, SystemVerilog
About Verification Horizons BLOG
This blog will provide an online forum to provide weekly updates on concepts, values, standards, methodologies and examples to assist with the understanding of what advanced functional verification technologies can do and how to most effectively apply them. We're looking forward to your comments and suggestions on the posts to make this a useful tool.
Latest Posts
- Part 1: The 2012 Wilson Research Group Functional Verification Study
- What’s the deal with those wire’s and reg’s in Verilog
- Getting AMP’ed Up on the IEEE Low-Power Standard
- Prologue: The 2012 Wilson Research Group Functional Verification Study
- Even More UVM Debug in Questa 10.2
- IEEE Approves New Low Power Standard
Subscribe to the Verification Horizons Newsletter