At the meeting where Accellera first decided to define a set of extensions to Verilog, Vassilios Gerousis, the Accellera Technical Committees Chair, was asked why Accellera should define these extensions instead of the IEEE 1364 Verilog Standards Group. Gerousis stated that the purpose was to "do [a] quick cycle in Accellera, and then pass [ownership] to IEEE. We don't want to get into ownership issues between 1364 " [we] must smoothly work between Accellera and 1364" (minutes of the first Accellera Verilog++ committee meeting, April 16, 2001).

This separation of SystemVerilog and Verilog will result in two Verilog standards that may or may not remain compatible as each standard evolves. I have a strong personal bias on this decision, which I will not try to hide. My purpose for this article, however, to present as objectively as I can my observations as to why the Accellera Board of Directors made this decision. The observations, opinions, and statements expressed in this article are strictly my own, and should not be taken as an official statement by the IEEE 1364 Verilog Standards Group or Accellera.

My observations are based from a unique perspective. I am the only person who has simultaneously been an active member of the IEEE 1364 Verilog Standards Group, the Accellera SystemVerilog standards committee, and the Accellera Board of Directors. Although there are many other engineers that are also working on both the IEEE 1364 Verilog standard and the Accellera SystemVerilog standard, I am the only one to also be a member of the Accellera Board.

My role on the Accellera Board is a passive one. I was appointed to the board 12 months ago to represent the "Accellera Designers Forum." This is a non-voting position, but it allows me to attend board meetings and to receive e-mail sent to the Accellera Board of Directors.

There are 14 members of the Accellera Board of Directors with voting privilege. 12 members attended the meeting to vote on the future of SystemVerilog. Two votes were taken, one to transfer SystemVerilog to the IEEE 1364 standard, and one to make SystemVerilog a separate IEEE standard, separating the extensions from the standard they extend. The voting record is as follows. This record is taken directly from the minutes of the meeting.

Motion: Accellera will transfer SystemVerilog to the IEEE under the 1364 VSG.
Proposed: Victor Berman (Cadence)
Seconded: Steve Wang (Verisity)

• ARM — John Goodenough not present
• Artisan — Edward Lechner no
• Cadence — Victor Berman yes
• IBM — Yaron Wolfsthal abstain
• Intel — Igal Iancu no
• Mentor — Dennis Brophy no
• NEC — Wolfgang Roethig abstain
• Novas — Dave Kelf abstain
• NVIDIA — Dan Smith no
• Real Intent — Prakash Narain not present
• Sun — Shrenik Mehta no
• Synopsys — Karen Bartleson no
• Verisity — Steve Wang yes
  The motion does not pass with seven no votes, two yes votes, and three abstentions.
  

  Motion: Accellera will transfer SystemVerilog 3.1a to the IEEE under the Corporate Advisory Group.
  Proposed: Karen Bartleson
  Seconded: Igal Iancu
  

• ARM — John Goodenough not present
• Artisan — Edward Lechner yes
• Cadence — Victor Berman no
• IBM — Yaron Wolfsthal abstain
• Intel — Igal Iancu yes
• Mentor — Dennis Brophy yes
• Motorola — Bill Read yes
• NEC — Wolfgang Roethig abstain
• Novas — Dave Kelf abstain
• NVIDIA — Dan Smith yes
• Real Intent — Prakash Narain not present
• Sun — Shrenik Mehta yes
• Synopsys — Karen Bartleson yes
• Verisity — Steve Wang no
  The motion passed by majority with two no votes, seven yes votes, and three abstentions.
  

• IEEE standards participation requirements
• IEEE standards voting rules
• Potential changes to SystemVerilog by the IEEE
• Time to release a standard to the public
• Time it has taken EDA companies to implement the 1364-2001 standard
• The person who chairs the IEEE 1364 standards group

IEEE Standards participation requirements

The IEEE has many organizational branches. One of these is the Design Automation Standards Committee (DASC). This branch was created to oversee standards involving design automation, such as VHDL 1076, Verilog 1364, and several other standards we, as design and verification engineers, use in our jobs.

DASC standards groups have been very open as to who can participate on the definition of a standard. There is a nominal fee of $40 per year to DASC, plus the dues to belong to the IEEE. Actually, one can participate in the standards meetings without being a member of either the IEEE or DASC, but those who do not belong to DASC cannot vote within the committee meetings.

I have been involved with the IEEE 1364 Verilog standards group since shortly after its inception in 1993. I have always been impressed with the diversity of participants that work on the Verilog standard. There is a balanced cross section of expert engineers who use Verilog, small EDA companies, and large EDA companies. Everyone on the 1364 standards group has had the best interest of the standard at heart. In the 11 year history of the IEEE 1364 Verilog Standards Group, corporate "politics" has never been an issue in the decision process.

Accellera has chosen to donate SystemVerilog to a completely different branch of the IEEE, the Corporate Advisory Group (CAG). CAG is a relatively new branch, having been formed mid-2000. The goal of CAG is stated as "...the composition of the CAG underscores industry's commitment to foster a company-focused standards program within the IEEE. The program...meets the need for an open, company-only standards environment..."

The cost of participating in standards that are under CAG is based on the size of a company. A one-person company must pay well over $1,000 each year. Larger companies must pay tens of thousands of dollars each year. Since CAG has no history of sponsoring EDA standards, it is not possible to judge what the balance of participation on the IEEE SystemVerilog standard will be like.

Certainly the high annual cost will mean that there will not be the diversity that defined and is maintaining the IEEE 1364 Verilog standard. Indeed, the stated purpose of CAG is to prevent such diversity, by limiting the definition of standards to just corporations. In fairness, just as with DASC, it is possible to attend committee meetings under CAG without being a member of CAG. But to be able to vote within the committee, one must first pay thousands of dollars each year. In board meetings, e-mails and personal conversations, a marginal majority of the Accellera board (7 out of 12 at the final vote) felt that the restricted diversity of CAG would be better for the standardization of SystemVerilog.

IEEE standards voting requirements

Another major difference between DASC and CAG is who can vote within the standards committees. The way the VDHL 1076 and Verilog 1164 standards groups are structured, every active member of the committee (who has paid their $40 DASC membership fee) can vote on each decision that affects the standard. The definition of what makes an active member is defined by the standards group, but must fall within guidelines established by DASC. In the 1364 Verilog Standards Group, the general rule is that an active member is one who has participated in at least 2 of the last 3 meetings.

CAG voting rights are very different. In addition to requiring a membership fee of thousands to tens of thousands of dollars to have voting rights, only one vote per corporation is allowed. If several members of the same company participate in the standard, only one of those members can vote, which is to represent the opinion of all other members of that company (whether they concur or not).

Accellera also operates under one-vote-per company policy, and the Accellera Board felt that this policy of CAG more closely matches Accellera methodology. Based on the Accellera board meetings I attended and the e-mail exchanges between board members, Accellera Board members did not take into consideration a critical difference between Accellera and CAG. That difference is that members of the Accellera SystemVerilog committee did not have to first pay thousands of dollars each year to actively participate on the committee.

In fact, at the subcommittee level where all the work was done, Accellera SystemVerilog was mostly developed in the same way as the IEEE DASC committees; where every active participant had voting privilege. It was only at the top-level SystemVerilog committee level, where approval of subcommittee decisions were voted on, that the one-vote-per-company policy was strictly followed.

It is important to note that the chair IEEE 1364 Verilog standards group informed Accellera Board that the 1364 committee was willing to consider changing its voting policy to one vote per company, the same as CAG. Such a change is within the rules of DASC, but to make the change would require approval by the 1364 Verilog Standards Group members and the DASC board. In this observer's eyes and ears, the willingness of the IEEE 1364 group to change to meet the voting rule preference of Accellera was completely ignored by the Accellera Board.

Potential changes to SystemVerilog by the IEEE

Some members of the Accellera Board expressed concerns that the IEEE 1364 Standards Group would make changes to the SystemVerilog extensions to Verilog, as these extensions were defined by Accellera. Such changes could be problematic to the companies on the Accellera Board who had already released SystemVerilog products, and to the companies on the Accellera Board who were already using SystemVerilog extensions in design projects.

The IEEE 1364 Verilog Standards Group does not share this concern. There were at least 14 members of the 1364 group that also actively participate in the Accellera SystemVerilog standards committees, including the author of this article. On Accellera committee meetings, we have already ensured that SystemVerilog extensions are fully compatible with Verilog without the need for changes.

On IEEE 1364 committee meetings, we have been taking all of the SystemVerilog extensions to Verilog into consideration as we define the next IEEE 1364 Verilog standard. The IEEE 1364 standards group authorized the 1364 chair, Mike McNamara, to assure Accellera that the 1364 committee would strive to add the SystemVerilog extensions to the Verilog standard with no changes that would affect the compatibility of existing tools supporting SystemVerilog (the 1364 committee does have additional extensions to add to those of SystemVeirlog). This was presented to the Accellera Board one week prior to the Accellera Board's decision of how to transfer SystemVerilog to the IEEE.

Time to release a standard to the public

Many engineers over the years have expressed concern about how long it has taken the IEEE 1076 and IEEE 1364 standards committees to enhance and release new versions of the respective standards. The IEEE committee process is thorough, and the balloting process and responding to ballot comments can be time consuming.

I have been, and still am, noted for being outspoken that the IEEE process has not kept pace with Moore's law for how rapid our design and verification needs have grown. Some Accellera board members expressed the concern that after Accellera had completed the specification of SystemVerilog, it would take the IEEE 1364 Verilog Standards Group several more years to incorporate these extensions into the Verilog standard, and to approve the integrated whole as an IEEE standard. The Accellera Board felt that by keeping SystemVerilog as a separate standard under CAG instead of DASC, it could be ratified within a few months to two years.

In reality, CAG and DASC must both follow the same IEEE procedures for balloting and approval of a standard. The IEEE ratification process will not be made more efficient or faster by splitting the child (SystemVerilog extensions) from its parent (the Verilog language). In fact, it may take longer.

CAG has no organization formed to receive the transfer of SystemVerilog. A committee will need to be formed, and solicitation for participation will need to go out. Due to the high cost of membership, interested participants who are not already paying members of CAG will first need to get financial authorization to join CAG. On the other hand, the IEEE 1364 Verilog Standards Group is well established, and is meeting on a very frequent basis, with about ten 1364 meetings each month.

The 1364 committee has already been working on incorporating SystemVerilog into the 1364 standard, and is well into that process. The 1364 standards group authorized its chair to present to the Accellera four options for how the 1364 Verilog Standards Group could expedite the integration of SystemVerilog into the full IEEE Verilog standard.

The details of the options cannot be given here, but the simple summary is that the 1364 standards committee assured Accellera that the 1364 committee could have an IEEE approved published document with SystemVerilog within six months of the transfer.

Time taken to implement the 1364-2001 standard

One member of the Accellera Board expressed concern that the IEEE 1364 Verilog Standards Group released its last set of extensions to the Verilog standard in 2001, and yet three years later many EDA companies have still not implemented all of those extensions. The concern is that this indicates that EDA companies do not consider the IEEE 1364-2001 standard to be important, and therefore, EDA companies would also not consider the SystemVerilog extensions to be important if SystemVerilog is integrated into 1364 standard.

There are well documented theories of logic (and false logic) that classify this concern. The "logic" in this concern is the similar to stating, "This seashell is red, therefore all seashells are red." Or, perhaps as engineers, it is easier to relate to the statement "When Stu Sutherland goes to Fry's Electronics, he spends money. Stu did not go to Fry's Electronics last month, therefore Stu did not spend any money last month."

It is false logic, just as is this concern about transferring SystemVerilog to the IEEE 1364 standard. First, even the company of the representative that expressed this concern has yet to implement all of the Verilog-2001 standard (I, personally, praise that company for having implemented more that any other major EDA company, but it is not complete — especially the implementation of the 1364-2001 PLI standard).

Second, the lack of support from EDA companies has nothing to do with whether EDA companies feel that the 1364-2001 standard is important. Nor was it an indication that Verilog users did not want the extensions in 1364-2001. The slow adoption of 1364-2001 by EDA companies is simply a matter that, in difficult economic times, EDA companies did not have the resources to implement the 1364-2001 standard as quickly as their customers would have liked.

The person who chairs the IEEE 1364 standards group

One final concern that I frequently heard expressed by certain Accellera Board members is that the chair of the IEEE 1364 Verilog Standards Group, Mike McNamara ("Mac"), also happens to be an executive of Verisity. In the early days of the development of SystemVerilog, Verisity, with its "e" verification language, was openly opposed to the verification extensions in SystemVerilog, which are largely based on the competing Vera language. The concern is that Mac will use his position within 1364 to remove or change SystemVerilog's testbench features.

Those of us who have worked with Mac for 10+ years on the IEEE 1364 standard know that these fears are ungrounded, and show that the members of the Accellera Board, as a whole, do not know Mac, and that they lack understanding of the IEEE 1364 standards process. First, as chair, Mac has no voting rights on the standard, except if a tie vote needs to be resolved. Second, the diversity of 1364 standards group ensures that no one person has undo influence on the standard. (Will CAG, with its high cost of membership, have that same self-regulating diversity?)

Third, Mac has been an adamant proponent of Verilog much, much longer that his involvement with Verisity. Mac has been involved with the IEEE Verilog standard for over 10 years. Everyone who has worked with Mac on the IEEE Verilog standard knows of his dedication to the success of Verilog and ensuring that Verilog meets the needs of today's and future designs, regardless of the origin of an idea or enhancement.

Finally, while Verisity (the company, not Mac, the 1364 chair) was once opposed to some aspects of SystemVerilog, they have since acquired Axis, a simulator company that was already implementing SystemVerilog. Verisity's new customer base expects — and will insist on — full SystemVerilog support. Accellera's concerns about Mac's involvement in the IEEE 1364 Verilog standard were always unfounded, and concerns about Verisity's acceptance of SystemVerilog are now history.

What now

SystemVerilog began as a way to extend the Verilog-2001 standard in ways to model and verify larger designs more efficiently. SystemVerilog is not a stand-alone language standard. It is built on top of the Verilog-2001 standard. Without the parent (Verilog 1364), the child (SystemVerilog) cannot be used.

The entire reason that many of us on the IEEE 1364 Verilog group turned to Accellera to define the SystemVerilog was to see if this process of defining the next IEEE Verilog standard could be accelerated. It was a bold experiment, which, in retrospect, failed to achieve its goals. It still took 3 years to define the SystemVerilog extensions to Verilog, and the work will not be finished until these extensions are fully integrated into their parent standard.

Now, Accellera has voted to terminate the work on SystemVerilog before it is complete. Accellera itself anticipates the IEEE CAG committee will take 6 months to 2 years to ratify SystemVerilog as a separate, non-integrated, standard. The total "accelerated" time to define these extensions to Verilog will take as long or longer than if it had been done through the IEEE 1364 standards group. The experiment of using Accellera to "accelerate" the definitions of extensions to the IEEE Verilog standard did not work.

There are only two possible outcomes that have any viability, now that Accellera has chosen to transfer SystemVerilog over to another branch of the IEEE.

The first possibility is that the SystemVerilog extensions and their parent standard will evolve in different directions. While SystemVerilog is fully compatible with Verilog-2001, the Verilog standard must and will evolve. The IEEE 1364 committee, under DASC, is already a significant way into defining the next generation of the IEEE 1364 standard, with a goal of having a Verilog-2005 or Verilog-2006 standard.

Will CAG be able to keep a separate standards document updated with the latest IEEE 1364 Verilog standard? If not, the extensions will rapidly become obsolete, since they will only work with old software tools based on an old Verilog standard. If CAG cannot keep a separate SystemVerilog standard synchronized with its parent standard, then users will quickly lose confidence in SystemVerilog, and the standard will die.

A second viable possibility is that the IEEE 1364 standards group will need to duplicate the SystemVerilog extensions in the 1364 standard. Some have suggested that this can be done by the 1364 standard simply pointing to the separate SystemVerilog standard.

This will not work, however, due to the complexity of the two documents, as well as the fact that the two standards, which are maintained by separate branches of the IEEE, will be revised at different times, and released on different dates. If the IEEE 1364 standard does duplicate the extensions in the SystemVerilog standard — which I feel is the most likely outcome of Accellera's decision — then, eventually, there will be no need for a separate SystemVerilog standard, and it will die.

The outcome, either way, is that Accellera has chosen to doom SystemVerilog for political reasons and personal biases of some members of the Accellera Board of Directors.

There are other outcomes of Accellera's decision than the two presented above, but I do not consider them viable outcomes. One possible outcome is for the 1364 Verilog standard to just cross reference to the SystemVerilog standard, and for the SystemVerilog standard to cross reference to the 1364 standard.

Indeed, since SystemVerilog is merely a set of extensions to Verilog, it already contains dozens of explicit cross references to the 1364-2001 Verilog standard. And that is why cross referencing is not a viable outcome. The IEEE 1364 standard, under IEEE rules, must be updated every few years. Each update automatically makes previous versions of the standard obsolete. The IEEE 1364 Verilog Standards Group is already preparing the next edition of the 1364 Verilog standard.

As soon as that is ratified, the document that the SystemVerilog standard cross references will be obsolete, and no longer available. New users or companies implementing SystemVerilog will be forced to find illegal copies (illegal because the obsolete version of the standard is still copyrighted material) in order to implement or use the SystemVerilog extensions.

Obsolescence aside, if the two standards cross reference each other, to which document does one turn for a list of reserved keywords? Which document has the proper BNF (Backus-Naur Format) that is the core definition of Verilog? Which document is correct, should there be any ambiguity in how the syntax or semantics of Verilog or a SystemVerilog extension is to be interpreted? The idea that two separate documents will merely cross reference each other is simply not viable.

In the same meeting in which the Accellera Board decided to transfer SystemVerilog to a different arm of the IEEE, the Board also passed a motion that the IEEE appoint a liaison between the two standards committees. A liaison, however, does not solve the problem of synchronizing the two standards.

First, both documents are far too complex for a single liaison to track all changes being considered for each standard, and communicate those changes to the other organization. Second, both the IEEE 1364 Verilog Standards Group and the Accellera SystemVerilog committees operate with several subcommittees. It can be assumed that a CAG SystemVerilog committee would do the same.

The standards are far too complex and there are too many specialized aspects of Verilog and SystemVerilog to keep do all work under a single committee. Subcommittees also permit work on different aspects of the standard to be done in parallel. A liaison, even if it were that person's full-time job, would not be able to attend all subcommittee meetings or both standards organizations.

Accellera did not specify if the liaison should be purely passive, or play an active role in each of the standards. To be an active participant, the liaison, or multiple liaisons, would be required to pay the membership fees of both organizations (a very high cost for CAG). Two cross-referenced standards that must both be dynamic and evolve with the electronic design and verification industry is not viable.

Another possible outcome is for the separate SystemVerilog standard to duplicate the entire Verilog 1364 standard, so that the base language and the SystemVerilog standard are in the same document. This is just a variation of the 1364 standard duplicating all of the SystemVerilog extensions.

It would take longer, however, because first the new committee has to be formed, find members that can pay the many thousands of dollars to participate, and then begin the thousands of man hours of effort to duplicate an existing standard. I do not consider this a viable outcome of Accellera's decision. Under CAG, there would likely be a shortage of volunteers to put in these thousands of man hours. The cost of participation is too great, and many of those who actively put in countless hours of volunteer effort on the 1364 standards committees would not be able to do so under CAG.

The 1364 Verilog Standards Group is already formed and has been actively preparing the 1364 Verilog standard for integrating SystemVerilog extensions into the Verilog standard. If something has to be duplicated, as now seem inevitable, it would be faster and more efficient to duplicate the extensions, not the base language definition.

Recap

SystemVerilog is not a stand-alone standard. It is a set of extensions to the IEEE 1364 Verilog standard. These extensions were defined by Accellera with the express purpose of accelerating the process of defining the next generation of the IEEE 1364 standard. More than a dozen members of the IEEE 1364 Verilog Standards Group actively dedicated hundreds and hundreds of man hours to Accellera, while continuing to volunteer time to the 1364 standards group as well.

Accellera has reneged on its commitment to transfer the SystemVerilog extensions to the IEEE 1364 standard so that the extensions can be integrated into the parent language. Instead, Accellera has chosen to transfer the extensions to a different branch of the IEEE, making it a separate IEEE standards document.

This will create two disjointed standards that will be difficult, if not impossible to keep synchronized. The only viable outcomes from Accellera's decision are that the extensions will become obsolete and die, or the parent language will need to duplicate all the extensions (in which case, the separate SystemVerilog standard will also eventually die).

The decision of the Accellera Board of Directors to renege on its commitment to transfer SystemVerilog to the IEEE 1364 Verilog Standards Group was based purely on political reasons, and not technical ones. The IEEE 1364 Verilog Standards Group provided solutions to all of the legitimate concerns of the Accellera Board.

Accellera expressed concern that the 1364 standards group would change the SystemVerilog extensions. The 1364 group assured Accellera it would not.

Accellera expressed concern about how long the 1364 group would take to define an IEEE ratified version of the SystemVerilog extensions. The 1364 group discussed this, and provided detailed plans to the Accellera Board to have a ratified version in 6 months — which is faster than the route that the Accellera Board ultimately chose.

Accellera expressed concern about the one-vote-per-active-participant policy of the 1364 Verilog Standards Group versus the one-vote-per-corporation of the CAG branch of the IEEE. The 1364 committee offered to have the group vote on changing its procedures to one-vote-per-company, the same as CAG.

The Accellera Board expressed concerns about the number of companies and individual engineers that participate on the definition of the 1364 Verilog standard. The 1364 Verilog Standards Group did not consider this a legitimate concern. It takes thousands of man hours to define complex standards, and it takes the viewpoints and experience of a wide variety of engineers to ensure the standard is robust, usable and can be implemented.

The 1364 standards group has such a team, and this team has, and does, work together extremely well. Ironically, many of the diverse Verilog 1364 team also participated on the Accellera committees that defined SystemVerilog, and the Accellera Board never raised concerns about the time, effort and skills these 1364 members brought to the definition of the SystemVerilog extensions to Verilog.

Finally, some members of the Accellera Board expressed a personal distrust of the chair of the IEEE 1364 standards group. This, too, is not a legitimate concern. The chair has more than 15 years of experience in using Verilog, and has been involved in the IEEE 1364 Verilog Standards Group since its formation in 1993.

Coincident with the Accellera Board's expression of concern about the 1364 chair, the 1364 Verilog Standards Group held its elections to all executive positions. The chair was re-elected by an overwhelming majority, showing that the 1364 group has great confidence in their chair, even when aware of the personal objections of some members of the Accellera Board of Directors, and the known possibility that the Accellera Board would decide to renege on its commitment to transfer SystemVerilog to the 1364 Verilog Standards Group.

The Accellera Board is literally reneging (going back on its promise or commitment) on its stated purpose and goal to transfer SystemVerilog to the IEEE 1364 standards group. The following is taken from the minutes of the very first Accellera meeting where the SystemVerilog committee was formed (originally known as the "Verilog++" committee), dated 16 April 2001:

Mike [McNamara]: there is a 1364 committee - IEEE owns Verilog, question - is this group to formulate proposals that the IEEE can then standardize?

Vassilios [Gerousis, Accellera Technical Committees Chair] - yes, do quick cycle in Accellera, and then pass to IEEE. We don't want to get into ownership issues between 1364 - must smoothly work between Accellera and 1364.

Since there was no other IEEE standards group involved with Verilog other than 1364, it was assumed that "IEEE" and "IEEE 1364" were synonymous. If there was ever any intent on the part of Accellera that the references to "IEEE" meant anything other than the IEEE 1364 Verilog Standards Group, that intent was kept secret from those working on defining SystemVerilog.

Originally, the transfer of SystemVerilog to the IEEE 1364 Verilog Standards Group was to be done as soon as the definition of SystemVerilog 3.0 was complete, which was in June of 2002. Accellera reneged on that commitment, however, and said the transfer would happen in December of 2002, as SystemVerilog 3.1. The reason was to give EDA companies time to review the SystemVerilog 3.0 extensions and provide feedback.

Accellera then decided to greatly extend the scope of SystemVerilog 3.1, and pushed the completion and transfer date out to June 2002. In June 2003, Accellera again reneged on its commitment to transfer the SystemVerilog extensions to the IEEE 1364 standard, giving the same reason as before. The transfer date was pushed out to June 2004.

Readers of EE Times and EEdesign may recall some articles in the summer of 2003 of some confrontations between the chair of IEEE 1364 Verilog Standards Group and the chair of the Accellera SystemVerilog standards committee. These confrontations were simply that the IEEE 1364 Verilog Standards Group had already begun work on the next generation of the IEEE 1364 Verilog standard, with the assumption that the transfer of the SystemVerilog extensions was to take place in June of that year.

Accellera's decision to postpone the transfer for a full year would cause considerable delay in the IEEE standardizing those extensions. The chair of 1364 Verilog Standards Group formally requested that at least the stable portions of SystemVerilog (the synthesizable constructs) be transferred in 2003, so that IEEE standardization of SystemVerilog could continue in parallel with the Accellera work to finalize the specification of other portions of the SystemVerilog extensions to Verilog.

A call for action

It is not too late for Accellera to reverse its decision, but doing so would require rapid and overwhelming input from those that read this article. The vote cast by the Accellera board to transfer SystemVerilog to a different branch of the IEEE states their intended course of action. The official transfer of SystemVerilog to the IEEE is to take place at the Design Automation Conference on June 8th.

I encourage everyone who managed to read clear to the end of this article to write a short e-mail to Accellera, and those companies that are represented on the Accellera Board. If not to all the companies on the Accellera Board, then I encourage readers to at least write to Aart de Geus of Synopsys and Wally Rhines of Mentor Graphics, the CEOs of the two biggest proponents of making the SystemVerilog extensions a separate standard from the language they extend.

Your e-mails should let Accellera and these companies know that you either support their decision, or that you feel severing the child (SystemVerilog) from its parent (Verilog 1364) is a serious mistake. Accellera's e-mail contact can be found at www.accellera.org. You will have to do just a little research for the other contacts. Time is of the essence! DAC is just a few days away. Do not procrastinate sending an e-mail to Accellera and its member companies!

Stuart Sutherland is an independent Verilog and SystemVerilog consultant. He is an active member of the IEEE 1364 Verilog Standards Group, where he has served as co-chair of the Verilog PLI Task Force for many years. He is also one of the founding members of the Accellera SystemVerilog standards committee, where he has served as the editor the SystemVerilog Language Reference Manual for all three versions of the manual. He also holds a non-voting seat of the Accellera Board of Directors as the representative to the board for design engineers in general. Stuart is considered an industry expert on Verilog standards, and has authored books on the Verilog-2001, the Verilog PLI, and SystemVerilog standards.