Posts Tagged ‘verilog’

4 February, 2014

Marketing teams at FPGA vendors have been busy as the silicon nanometer geometry race escalates. Altera is “delivering the unimaginable” while Xilinx is offering “all programmable SoCs” to design centers. It’s clear that the SoC has become more accessible to a broader market today and that FPGA vendors have staked out a solid technology roadmap for the near future. Do marketing messages surrounding the geometry race effect day to day life of engineers, and if so, how – especially when it comes to verification?
An excellent whitepaper from Altera, “The Breakthrough Advantage for FPGAs with Tri-Gate Technology,” covers Altera’s Stratix 10 FPGAs and SoCs. The paper describes verification challenges in this new expanded market this way: “Although current generation FPGAs require a rigorous simulation verification methodology rivaling ASICs, the additional lab testing and ability to reprogram FPGAs save substantial manpower investment. The overall cost of ownership must be considered when comparing an FPGA whose component price is higher than an ASIC of similar complexity.” I believe you can use this statement to engage your management in a discussion about better verification processes.

Xilinx also has excellent published technical resources. Its recent UltraScale backgrounder describes how they are solving the challenges in implementing a design with their reprogrammable silicon. Clearly Xilinx has made an impressive investment to make it easier to implement a design with its FPGA UltraScale products. Improvements include ASIC-like clocking and annealing dataflow bottlenecks without compromising performance. Xilinx also describes improvements when using its Vivado design suite, particularly when it comes to in-lab design bring up.

For other FPGA insights, it’s also worth checking out Electronics Engineering Journal’s recent article “Proliferating Programmability in 2014,” which claims that the long-term future of FPGAs tool flows even though, as Kevin Morris sees it, EDA seems to have abandoned the market. (Kevin, I’m here to tell you you’re wrong.)

Do you think it’s inevitable that your FPGA team will first struggle to make it across the verification finish line before adopting a more process-oriented verification flow like the ASIC market demands? It’s not. I base this conclusion on the many conversations I’ve had with FPGA designers, their managers, sales engineers and many other talented people in this market over the years. Yes, there are significant challenges in FPGA design, but not all of them are technology related. With some emotion, one engineer remarked that debugging the same type of issue over and over in the hardware lab and expecting a different outcome was insane. (He’s right.) Others say they need specific ROI information for their management to even accept their need for change. Still others state that had they only known the solutions I talked about in my seminar a year ago, they would have not spent months and months bringing up their design in the lab.
With my peers here at Mentor Graphics, I have developed a three-step verification flow that includes coverage, assertions and improved throughput. I’ll write about this flow and related issues in the weeks ahead here on this blog. The flow is built on fundamental verification technologies that benefit the broad FPGA market. The goal, in developing the technology and writing about it here, has been to provide practical solutions and help more FPGA teams cross the verification gap.

In the meantime, what are your stories? Are you able to influence your management into adopting advanced technology to aid lab bring-up? Is your management’s bias towards lower cost and faster implementation (at the expense of verification)? Let me know in the comments or, if you prefer, by e-mail: joe_rodriguez@mentor.com.

, , , , , , , , ,

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.

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

3 May, 2013

A unique concept most beginners have trouble grasping about the Verilog, and now the SystemVerilog, Hardware Description Language (HDL) is the difference between wire’s (networks) and reg‘s (variables). This concept is something that every experienced RTL designer should be familiar with, but there are now many verification engineers with no prior Verilog experience trying to pick up SystemVerilog for their testbench. Verification methodology courses tend to concentrate on the Object-Oriented programming aspects of testbench design, but do not cover this topic thinking that it is for designers only. Not true. If you have to communicate with a DUT then you need to understand the difference between wire’s and reg’s (nets and variables).

Anyone tasked with having to design or verify a piece of hardware should have some basic programming skills and understand the concept of a variable. If not, you had better stop right here and brush up on some programming basics. The key concept that you need to take away from programming is that you write a value into a variable and that value is saved until the next assignment to that variable. This concept is referred to as a procedural assignment which is part of executing an ordered set of statements. An HDL may add some notion of time in between assignments and other statements. The last assignment determines the current value of the variable.

Combinatorial Logic Sequential Logic
reg a,b,c; 
always @(b or c) 
 begin 
 a = b | c; 
 end
reg a,b,c; 
always @(posedge c) 
 begin 
 a = a + b; 
 end

Initially, Verilog used the keyword reg to declare variables representing sequential hardware registers. Eventually, synthesis tools began to use reg to represent both sequential and combinational hardware as shown above and the Verilog documentation was changed to say that reg is just what is used to declare a variable. SystemVerilog renamed reg to logic to avoid confusion with a register – it is just a data type (specifically reg is a 1-bit, 4-state data type). However people get confused because of all the old material that refers to reg. Just forget about it and use logic from now on.

Another distinctive characteristic of an HDL is that it models massive amounts of parallel processes. At the lowest level of digital design, every primitive gate (AND, OR, DFF) is an independent concurrent process. Modules are containers representing processes modeled at different levels of abstraction. Groups of primitives and modules pass values to each other via networks of signals. In Verilog, a wire declaration represents a network (net) of connections with each connection either driving a value or responding to the resolved value being driven on the net. The output of each of these concurrent processes drives a net in what is called a continuous assignment because the process continually updates the value it wants to drive on the net. There are various ways to declare a continuous assignment, all of which represent permanent behaviors:

wire A, B, C; 
assign A = B| C; // continuous assignment construct. 
or(A,B,C); // gate-level instance terminal connection 
mymodule m1(A,B,C); // module instance port connection 

Although these are all different forms of continuous assignment constructs, none of them directly assign a value to the net like a procedural assignment would. All of the values being concurrently driven onto the net are passed into a built-in resolution function. The result of that resolution function is based on the strengths of each driver representing the hardware technology in use. For example, an interrupt request signal might use the wired-or (wor) kind of net to indicate that at least one device is driving a ’1′, otherwise it will resolve to a ’0′. Some signals will have weaker pull-up/down resistors that will be overridden by the values of a stronger driver. Most technologies do not allow driving different values on the same net and the net will resolve to an unknown ‘x’ when that happens. In this case only one driver is actively assigning a ’0′ or ’1′ and the other drivers are effectively turned off by driving a high-impedance or ‘z’ state. The consequence of this is that a bi-directional port must be modeled using a net in order to have multiple drivers on either side of the port.

See my recent DVCon paper for an example of modeling bidirectional signals along with other tips for connecting the Testbench to your DUT.

It turns out that the vast majority of nets in a design will only have a single driver, so no strength information or resolution function is needed. SystemVerilog added a feature that allows a single continuous assignment to drive a variable. The expression driving the continuous assignment is assigned to the variable every time the expression changes its value. As soon as you have more than one driver or need strength information, you must go back to using a net. You cannot mix procedural and continuous assignments to the same variable. The reason for that restriction is that there is no way to resolve the “last write wins” semantics of a procedural assignment with a driver that wants to continually assign the variable (i.e. when is the last write finished and the continuous assignment supposed to take over?).

In summary, you should now be using logic for 4-state variables (or bit for 2-state variables) to represent all of your single drive signals. Any signal with more or the potential for more than one driver should be declared as a wire.

, , ,

23 April, 2013

This is the first in a series of blogs that presents the results from the 2012 Wilson Research Group Functional Verification Study.

Study Overview

In 2002 and 2004, Ron Collett International, 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. However, after the 2004 study, no other industry studies were conducted, which left a void in identifying industry trends.

To address this void, Mentor Graphics commissioned Far West Research to conduct an industry study on functional verification in the fall of 2007. Then in the fall of 2010, Mentor commissioned Wilson Research Group to conduct another functional verification study. Both of these studies were conducted as blind studies to avoid influencing the results. This means that the survey participants did not know that the study was commissioned by Mentor Graphics. In addition, to support trend analysis on the data, both studies followed the same format and questions (when possible) as the original 2002 and 2004 Collett studies.

In the fall of 2012, Mentor Graphics commissioned Wilson Research Group again to conduct a new functional verification study. This study was also a blind study and follows the same format as the Collett, Far West Research, and previous Wilson Research Group studies. The 2012 Wilson Research Group study is one of the largest functional verification studies ever conducted. The overall confidence level of the study was calculated to be 95% with a margin of error of 4.05%.

Unlike the previous Collett and Far West Research studies that were conducted only in North America, both the 2010 and 2012 Wilson Research Group studies were worldwide studies. The regions targeted were:

  • North America:Canada,United States
  • Europe/Israel:Finland,France,Germany,Israel,Italy,Sweden,UK
  • Asia (minusIndia):China,Korea,Japan,Taiwan
  • India

The survey results are compiled both globally and regionally for analysis.

Another difference between the Wilson Research Group and previous industry studies is that both of the Wilson Research Group studies also included FPGA projects. Hence for the first time, we are able to present some emerging trends in the FPGA functional verification space.

Figure 1 shows the percentage makeup of survey participants by their job description. The red bars represents the FPGA participants while the green bars represent the non-FPGA (i.e., IC/ASIC) participants.

 

Figure 1: Survey participants job title description

Figure 2 shows the percentage makeup of survey participants by company type. Again, the red bars represents the FPGA participants while the green bars represents the non-FPGA (i.e., IC/ASIC) participants.

Figure 2: Survey participants company description

In a future set of blogs, over the course of the next few months, I plan to present the highlights from the 2012 Wilson Research Group study along with my analysis, comments, and obviously, opinions. A few interesting observations emerged from the study, which include:

  1. FPGA projects are beginning to adopt advanced verification techniques due to increased design complexity.
  2. The effort spent on verification is increasing.
  3. The industry is converging on common processes driven by maturing industry standards.

A few final comments concerning the 2012 Wilson Research Group Study.  As I mentioned, the study was based on the original 2002 and 2004 Collett studies.  To ensure consistency in terms of proper interpretation (or potential error related to mis-interpretation of the questions), we have avoided changing or modifying the questions over the years—with the exception of questions that relate to shrinking geometries sizes and gate counts. One other exception relates  introducing a few new questions related to verification techniques that were not a major concern ten years ago (such as low-power functional verification).  Ensuring consistency in the line of questioning enables us to have high confidence in the trends that emerge over the years.

Also, the method in which the study pools was created follows the same process as the original Collett studies.  It is important to note that the data presented in this series of blogs does not represent trends related to silicon volume (that is, a few projects could dominate in terms of the volume of manufactured silicon and not represent the broader industry).  The data in this series of blogs represents trends related to the study pool—which is a fair proxy for active design projects.

My next blog presents current design trends that were identified by the survey. This will be followed by a set of blogs focused on the functional verification results.

Also, to learn more about the 2012 Wilson Reserach Group study, view my pre-recorded Functional Verification Study web-seminar, which is located out on the Verification Academy website.

Quick links to the 2012 Wilson Research Group Study results (so far…)

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

17 June, 2011

How do your favorites rank?

Have you ever wondered how popular the different IEEE standards for electronic design automation are? Have you ever wondered which ones show the least interest? When buying books online, popular book buying websites sites will rank customer purchases. Many newspapers manage lists that you can consult to determine what is the most popular; what has the highest demand. But if you have purchased any IEEE standards, you will know this information is not available from the IEEE Store or the IEEE XPlore platform.

On May 4th, the IEEE Standards Association announced its collaboration with Techstreet to create the New IEEE Standards Store.  Until now, anyone who wanted to order a single standard had to use a more complex system that even made it hard to share a permanent link to one’s favorite standard with another.  Just look at the Accellera homepage for an example of where to get the SystemVerilog (IEEE Std. 1800™) standard.  At the writing of this blog, it simply points to www.ieee.org.  [I will share the fact the IEEE’s new site now has fixed links that can now be used to help others find the most current SystemVerilog standard with the Accellera.]

But back to what is the most popular IEEE EDA standards… Any guesses?

Before I delve into those details, let me say the ranking is just by ordinal.  The New IEEE Standards Store shares no information on the actual number of standards purchased.  So the difference between #1 and #10 could be just 10 copies.  It probably isn’t, but it could be.  But talking about #10, why is it even on the list?  The IP-XACT standard (IEEE Std. 1685™) is available for free under the IEEE Get Program.  Under this program you can download a PDF of the IEEE standard for free.  If you want a printed version, you can print your own copy from the free one you download.  Back in December 2010, Accellera reported that since the IEEE started to offer IP-XACT for free, there had been 1200 downloads.  It also looks like many people did not want the hassle to print and simply ordered the print version directly from the IEEE.  The other IEEE EDA standard offered free is SystemC©  And this is probably the reason it is in 32nd place.  It is very popular in terms of the number of free downloads.

And yes, if you search for the those two standards on the New IEEE Standards Store, you will find you can order print copies there and if you read the small print below, you will see there is a link to take you to the free online versions.

Harry Foster has issued several research reports on the popularity of one language or format the past several months.  In his last blog, he discussed which of the design and verification languages are ranked high and those, well, not so high.  And I guess I feel best to share the correlation between his findings and these more “anecdotal” results from the New IEEE Standards Store.  I have been party to many at the top standards  (Verilog/SystemVerilog) and party to the “least highest” (yes, I can’t say the least liked) VITAL 2000.  For vindication, I will note that VITAL-95 comes in at #18.  In whole, it appears to me that the New IEEE Standards Store ordinal rankings of EDA standards matches the scientific data from the research Harry has reported.

Below is the full ranking of IEEE EDA standards.  Where are your favorites?

1 IEEE 1364-2001 Verilog Hardware Description Language
2 IEEE 1800-2009 SystemVerilog–Unified Hardware Design, Specification, and Verification Language
3 IEEE 1076-2002 VHDL Language Reference Manual
4 IEEE 1076-1993 VHDL Language Reference Manual
5 IEEE 1499-1998 Interface for Hardware Description Models of Electronic Components
6 IEEE 1364-1995 Hardware Description Language Based on the Verilog® Hardware Description Language
7 IEEE 1800-2005 SystemVerilog: Unified Hardware Design, Specification and Verification Language
8 IEEE 1076.2-1996 VHDL Mathematical Packages
9 IEEE 1076.1-1999 VHDL Analog and Mixed-Signal Extensions
10 IEEE 1685-2009 IP-XACT, Standard Structure for Packaging, Integrating, and Reusing IP within Tool Flows
11 IEEE 1850-2005 Property Specification Language (PSL)
12 IEEE 1076c-2007 VHDL Language Reference Manual – Procedural Language Application Interface
13 IEEE 1164-1993 Multivalue Logic System for VHDL Model Interoperability (Std_logic_1164)
14 IEEE 1850-2010 Property Specification Language (PSL)
15 IEEE 1076.6-2004 VHDL Register Transfer Level (RTL) Synthesis
16 IEEE 1801-2009 Design and Verification of Low Power Integrated Circuits
17 IEEE 1481-2009 Integrated Circuit (IC) Open Library Architecture (OLA)
18 IEEE 1076.4-1995 VITAL Application-Specific Integrated Circuit (ASIC) Modeling Specification
19 IEEE/IEC 61691-5-2004 IEC 61691-5 Ed.1 (IEEE Std 1076.4(TM)-2000): Behavioural Languages – Part 5: Standard VITAL ASIC (Application Specific Integrated Circuit) Modeling Specification
20 IEEE 1647-2008 Functional Verification Language e
21 IEEE 1076.1.1-2011 VHDL Analog and Mixed-Signal Extensions — Packages for Multiple Energy Domain Support
22 IEEE/IEC 61691-7-2009 Behavioural languages – Part 7: SystemC Language Reference Manual
23 IEEE 1076-1987 VHDL Language Reference Manual
24 IEEE 1076.1.1-2004 VHDL Analog and Mixed-Signal Extensions—Packages for Multiple Energy Domain Support
25 IEEE 1076.3-1997 VHDL Synthesis Packages
26 IEEE/IEC 61523-3-2004 IEC 61523-3 Ed.1 (IEEE Std 1497(TM)-2001): Delay and Power Calculation Standards – Part 3: Standard Delay Format (SDF) for the Electronic Design Process
27 IEEE 1076/INT-1991 Interpretations: IEEE Std 1076-1987, IEEE Standard VHDL Language Reference Manual
28 IEEE/IEC 62531-2007 IEC 62531 Ed. 1 (2007-11) (IEEE Std 1850-2005): Standard for Property Specification Language (PSL)
29 IEEE 1076.6-1999 VHDL Register Transfer Level Synthesis
30 IEEE 1647-2006 Functional Verification Language “e”
31 IEEE/IEC 61691-6-2009 Behavioural languages – Part 6: VHDL Analog and Mixed-Signal Extensions
32 IEEE 1666-2005 SystemC® Language Reference Manual
33 IEEE/IEC 61691-1-1-2004 IEC 61691-1-1 Ed.1 (IEEE Std 1076(TM)-2002): Behavioural Languages – Part 1-1: VHDL Language Reference Manual
34 IEEE 1364-2005 Verilog Hardware Description Language
35 IEEE/IEC 61691-4-2004 IEC 61691-4 Ed.1 (IEEE Std 1364(TM)-2001): Behavioural Languages – Part 4: Verilog® Hardware Description Language
36 IEEE 1076.4-2000 VITAL ASIC (Application Specific Integrated Circuit) Modeling Specification

Learn more about the New IEEE Standards Store

There is much more to the New IEEE Standards Store than just the rankings of the standards we use in electronic design automation.  As I mentioned, it is easier to share fixed links to IEEE standards.  And if you want to track IEEE standards development – and don’t want to have to register your email address with the actual committee developing it just to know when they are done and a standard is ready – you can register to be notified when a new standard is ready.  The New IEEE Standards Store will notify you when a new one is ready.

Check out the short, one minute, video below to learn more about the New IEEE Standards Store.

, , , , , , , , , , ,

13 May, 2011

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).

p8-slide1

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.

p8-slide2

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). p8-slide3

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.

p8-slide4

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.

survey-blog-part8

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).

p8-slide6

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.

p8-slide7

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.

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

18 December, 2009

Just in time for the holidays!  :)

IEEE Std. 1800™-2009, aka SystemVerilog 2009, is ready for purchase and download from the IEEE.  The standard was developed by the SystemVerilog Working Group and recently approved by the IEEE.  It is an entity project of the IEEE jointly sponsored by the Corporate Advisory Group (CAG) and the Design Automation Standards Committee (DASC).  The working group members represented Accellera, Sun Microsystems Inc, Mentor Graphics Corporation, Cadence Design Systems, Intel Corporation and Synopsys along with numerous other volunteers from around the world.

IEEE Std. 1800-2009 LRM

IEEE Std. 1800-2009 LRM

The publication of the standard culminates the work of representatives from the companies above along with numerous other interested parties and volunteers.  Thank you to all who made this happen!

This standard represents a merger of two previous standards: the IEEE Std 1364-2005 Verilog Hardware Description Language (HDL) and the IEEE Std 1800-2005 SystemVerilog Unified Hardware Design, Specification, and Verification Language.

In these previous standards, Verilog was the base language and defined a completely self-contained standard. SystemVerilog defined a number of significant extensions to Verilog, but IEEE Std 1800-2005 was not a self-contained standard; IEEE Std 1800-2005 referred to, and
relied on, IEEE Std 1364-2005. These two standards were designed to be used as one language.

Merging the base Verilog language and the SystemVerilog extensions into a single standard enables users to have all information regarding syntax and semantics in a single document.  The standard serves as a complete specification of the SystemVerilog language. The standard contains the following:

  • The formal syntax and semantics of all SystemVerilog constructs
  • Simulation system tasks and system functions, such as text output display commands
  • Compiler directives, such as text substitution macros and simulation time scaling
  • The Programming Language Interface (PLI) mechanism
  • The formal syntax and semantics of the SystemVerilog Verification Procedural Interface (VPI
  • An Application Programming Interface (API) for coverage access not included in VPI
  • Direct programming interface (DPI) for interoperation with the C programming language
  • VPI, API, and DPI header files
  • Concurrent assertion formal semantics
  • The formal syntax and semantics of standard delay format (SDF) constructs
  • Informative usage examples
Where to Download & Purchase

For users who have access to IEEE Xplore, free downloads are available here.

For user who purchase single-copy need to visit Shop IEEE (here) and search for “1800″ to purchase.  IEEE Member price is $260 and non-member price is $325.

, , , , , , , , , , ,

@dennisbrophy Tweets

  • Loading tweets...

@dave_59 Tweets

  • Loading tweets...

@HarryAtMentor Tweets

  • Loading tweets...