From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Fri May 14 2004 - 12:05:33 PDT
I too feel that Gabe was a bit inaccurate in his article. I have asked him
to run the following "rebuttal article" that is based on my personal
perspective.
Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
A rebuttal from an IEEE 1364 and Accellera SystemVerilog committee member on
Gabe Moretti's article, "Gabe's Commentary: Verilog, SystemVerilog, or
both",
EDN on EDA newsletter, EDN, 5/13/2004,
http://www.reed-electronics.com/ednmag/article/CA417185?industryid=2813
<http://www.reed-electronics.com/ednmag/article/CA417185?industryid=2813&nid
=2017> &nid=2017
by Stuart Sutherland, Sutherland HDL, Inc.
Gabe really missed the mark this time! I have known Gabe personally for
many years. I consider him to be a brilliant software engineer for EDA
tools, and a top-notch editorialist. I have a lot of respect for Gabe. In
this article, however, I feel Gabe has made a number of errors. It is
important to set the record straight. I assume Gabe's mistakes are simply
because he is standing on the outside looking in on the IEEE 1364 and
Accellera standardization committees. Gabe's comments show that from this
outside perspective, he has not seen all that has happened, and what is
happening.
Note that all opinions expressed in this rebuttal are strictly my own, and
should not be taken as official statements from the IEEE 1364 Verilog
Standards Group or from Accellera.
The most important misconception to clarify is that SystemVerilog is NOT an
independent language. SystemVerilog is a set of extensions to the IEEE
1364-2001 Verilog standard. In and of itself, SystemVerilog is useless. It
is only useful in conjunction with Verilog. Gabe's misunderstanding of this
critical positioning of the two standards is apparent in statements such as:
Gabe wrote: "Warning bells went off all over the Verilog camp. Here was a
[SystemVerilog] language that could coexist with present Verilog and could
take seats away from the Verilog installed base."
With a correct understanding of how SystemVerilog fits with the Verilog
standard, let's look at some of the other misunderstandings in Gabe's
article. Gabe falsely states:
Gabe wrote: "The Verilog camp, and in particular the 1364 Working Group ...
of the IEEE, has been busy extending the Verilog language using VHDL as the
blueprint to provide some of the facilities that SystemC has. This version
is referred to as Verilog 2005. By the time they are finished Verilog will
be more complex to use than VHDL ever was."
I have been actively involved with the IEEE 1364 Verilog standards group
since shortly after its inception in 1993. Gabe is not an active member of
the Verilog standards group, and never has been. He is standing outside,
looking through windows with a limited view of the real work that is going
on. While it is true that both the both the VHDL and Verilog standards
groups have leveraged good ideas from the other language, it is absolutely
false to say that VHDL is the "blueprint" for work being done on the next
IEEE Verilog standard. Indeed, almost none of the current work within the
standards group is based on concepts that are in VHDL. The truth is that
all of our current work is heavily based on the expectation that the
SystemVerilog extensions will be part of the Verilog standard. We are
defining other extensions to Verilog that complement and add to
SystemVerilog's extensions, while we wait for Accellera to turn over
SystemVerilog to the IEEE 1364 working group. We are carefully avoiding
anything that would duplicate or conflict with what we know is in
SystemVerilog.
Gabe wrote: "Superlog is the legitimate extension of Verilog, only
redesigned, not patched up. For reasons that only Synopsys
marketing wizards can even verbalize ..., the language was renamed
SystemVerilog and donated to the most efficient standard development
organization in the EDA space, Accellera, for the purpose of making it an
industry standard."
I have also been a member of the Accellera SystemVerilog standards group
since its inception. Gabe is not a member of this committee, and never has
been. Gabe has his facts reversed. The Accellera effort began with a
donation of the synthesizable subset of SUPERLOG by Co-design Automation.
The committee was originally called the "Verilog++" committee, under the
Accellera HDL+ committee. The Verilog language extensions we were defining
were referred to as the "ESS", for "Extended Synthesis Subset". As our
efforts to define these synthesizable extensions to Verilog drew close to
conclusion, it was decided to give the extensions the name "SystemVerilog
3.0". It was felt that the name would communicate the intent of the
extensions, which was to be able to model very large designs, and yet still
be synthesizable with current synthesis technologies. The "3.0" had
significance. It showed that these extensions were to become the third
generation of the Verilog standard (1364-1995 and 1364-2001 being the first
and second generations, respectively). Synopsys did not have any
representatives on the Verilog++ committee, and had nothing whatsoever to do
with the name "SystemVerilog". It is absolutely false to imply that
Synopsys changed the name "SUPERLOG" to "SystemVerilog, or that Synopsys
donated SystemVerilog to Accellera.
Gabe neglected to point out that most of the original Verilog++ standards
group were also active members of the IEEE 1364 Verilog standards group. We
had just finished defining the Verilog-2001 standard, and recognized that
there was a need for immediately continuing towards defining the next
generation of the language. The SUPERLOG ESS donation to Accellera provided
a good starting point. Our intent was "accelerate" the definition of next
IEEE Verilog standard. Gabe also neglected to remind his readers that
Accellera has been sponsoring the development of the IEEE 1076 and 1364 VHDL
and Verilog standards for many, many years, as well as other IEEE standards
such as SDF. Without Accellera's financial support, we would not have many
of the IEEE standards that we enjoy today. Accellera's active role in
defining the SystemVerilog extensions to Verilog was never to be a competing
standard's group with the IEEE. Accellera's role was, and is, to be a think
tank and financial backer for IEEE standards, and to promote the adoption of
EDA standards.
Gabe wrote: "Victor's [Victor Berman of Cadence] task is to slow down the
industry acceptance of SystemVerilog while Cadence's engineering group
develops the equivalent capabilities for the company's simulation platform."
Gabe gives no justification for his biting remarks. I have also known
Victor for many years, and have worked closely with Cadence engineering on
both the IEEE 1364 and Accellera SystemVerilog standards groups. There is
no justification for Gabe's comments. Cadence, Synopsys, Mentor Graphics
and a number of other EDA companies have dedicated hundreds, even thousands,
of man hours towards the definition of the current SystemVerilog standard.
All of these EDA companies have made significant contributions towards
SystemVerilog, and all of them have a vested interest in users successfully
adopting SystemVerilog into current design flows.
Gabe wrote: "The 1364 committee first tried to strong arm Accellera by
demanding that SystemVerilog, which at the time was not finished, be turned
over to them for 'incorporation into Verilog'."
When is a standard ever finished? The only finished standard is one that is
no longer being used. Once again, most of the original Accellera Verilog++
standards group were also members of the IEEE 1364 standards group. From
the IEEE perspective, we were very well aware of the state of the
SystemVerilog standard. In June 2001, Accellera ratified SystemVerilog 3.0
as a stable set of extensions to Verilog, and began the process of defining
another set of extensions, to become part of SystemVerilog 3.1. Because
Accellera had ratified the 3.0 extensions, it was both a reasonable and
logical request from the IEEE 1364 group that these ratified extensions be
transferred to the 1364 standards group so that they could be integrated
into the 1364 LRM. Remember, the stated purpose of SystemVerilog 3.0 is
that it was "a set of extensions to the IEEE 1364-2001 Verilog Hardware
Description Language..." (SystemVerilog 3.0 LRM, cover and title page).
Gabe wrote: "So now the 1364 committee is resorting to religion, proclaiming
to all that will listen that there is only one Verilog, it is Verilog, and
that SystemVerilog is a false prophet."
Gabe gives no references for this so-called proclamation, and I am not aware
of any such statement. I am, however, very well aware of the goal we had
since day one within the Accellera standards group. That goal is that the
SystemVerilog extensions to Verilog were to become part of the next IEEE
1364 Verilog standard. Since many members of the 1364 standards group are
also on the Accellera SystemVerilog standards committee, it is absurd to say
that we think "SystemVerilog is a false prophet".
Gabe wrote: "The 1364 Working Group is looking in the wrong direction.
Instead of trying to extend Verilog into behavioral constructs, they should
make sure that they provide Verilog with the capabilities the language needs
to deal with verification problems encountered below the RTL level. Such a
language could co-exist with a behavioral language that also provides
support for assertions and testbenches, such as SystemVerilog. The two
languages share many syntax and semantics pimitives, so the designers have a
powerful tool that can be used from architectural design to layout."
Here again, Gabe is promoting the false notion that SystemVerilog is a
stand-alone language. It is not. SystemVerilog is a set of extensions to
Verilog. Without the base of the IEEE 1364-2001 Verilog standard,
SystemVerilog would be incomplete. Gabe's inference that Verilog needs
extensions to verify designs "below the RT level" makes no sense. Verilog
has been a capable gate-level verification language since 1984.
Gabe wrote: "Thus the combination of SystemVerilog and Verilog is what
designers really need. ... The stubbornness of the DASC 1364 Working Group
is not only difficult to understand, it is anachronistic as well. The 1364
Working Group is desperately holding on an old idea that has been proven
unworkable by the VHDL experiment."
Gabe got the first part of his statement correct. It is the combination of
SystemVerilog and Verilog that is useful. This is why the original intent
of those of us on the Accellera Verilog++ (later SystemVerilog) committee is
both correct and necessary. That intent is that the SystemVerilog
extensions are to become fully integrated into the IEEE 1364 Verilog
standard.
Gabe wrote: "The present battle is being fought in the IEEE. On one corner
you have Accellera with SystemVerilog, ... and on the other you have Verilog
2005..."
There is a battle, but it is not within the IEEE. It is between members of
the Accellera Board of Directors. Not one of these board members actively
participated in the definition of the SystemVerilog standard. I may be
wrong, but I would bet that most members of the board have not thoroughly
read the Accellera SystemVerilog LRM that they just ratified. There are
some members on the Accellera board that do not understand the original--and
still valid--intent of those of us that defined the standard. That intent,
if I have not emphasized it enough yet, is that SystemVerilog is a set of
extensions to the IEEE 1364 Verilog standard, and are to become part of the
IEEE 1364 standard. The battle Gabe is referring to is between those that
understand that SystemVerilog is merely a set of extensions to Verilog
(albeit a substantial and important set) and those that mistakenly think
SystemVerilog is a separate, stand-alone language.
Gabe wrote: "Accellera has joined the Corporate Society of the IEEE, with
Synopsys and Mentor, and can develop a working group under this umbrella to
make SystemVerilog an IEEE standard much faster than the DASC 1364 can get
its new version of Verilog developed."
As a long standing member of the IEEE 1364 standards group, I will be the
first to admit that the IEEE DASC process does not meet the needs of today's
rapidly evolving electronic engineering industry. It took 5 years to define
the enhancements that went into the 1364-2001 standard. Verilog-2001 ended
up the proverbial "too little too late". Perhaps Gabe and Accellera are
right, and moving HDL standards to a different arm of the IEEE is the cure.
Personally, however, I am not optimistic that any arm of the IEEE will be
able to keep pace with Moore's law. I am even more concerned about a
corporate arm of the IEEE defining engineering standards. Under DASC, the
Verilog standard is defined by individual members, including both small and
large EDA companies, user companies, and independent experts. This mix
helped ensure a standard that was both useful and implementable. The cost
of participating in the definition the standard was a modest annual DASC
membership fee (and the donation of lots of hours). Under the Corporate
Society, the cost of participating in the definition of a standard is $1,000
a year. Only large EDA companies would be defining the standard. The user
perspective of what is needed in the standard would be lost.
Gabe, and some members of Accellera, are promoting the idea that the IEEE
DASC define Verilog, and that the IEEE Corporate Society define the
extensions to Verilog. This would be a disaster! It would be difficult, if
not impossible, for the extensions to stay coordinated with their base
language, and hence the extensions would become worthless. It is essential
that there be one standards group defining both the base language and any
extensions. It only makes sense for the extensions to be ultimately become
part of the base standard.
Gabe wrote: "The DASC still does not know how much it would take to
incorporate the SystemVerilog capabilities into its Verilog project..."
Wrong again. I can state with first-hand knowledge that most of the members
of IEEE 1364 standards group have thoroughly studied the Accellera
SystemVerilog standard. There are over 15 active members of the IEEE 1364
group that are also active members of the Accellera SystemVerilog standards
group. Throughout the definition of the SystemVerilog extensions to
Verilog, we ensured that these extensions were fully compatible with
Verilog, and would integrate well into the IEEE 1364 Verilog LRM. The
SystemVerilog BNF is proof of both how dependent SystemVerilog is on
Verilog, and how compatible the SystemVerilog extensions are with Verilog.
The IEEE 1364 working group does know what it will take to integrate the
SystemVerilog extensions into the 1364 standard. More than just having the
knowledge, the 1364 working group is capable and ready to complete the
intent of those that defined the SystemVerilog extensions to Verilog--to
make these extensions part of the next generation of the IEEE 1364 standard.
I would encourage Gabe and all members of the Accellera board to at least
read paragraph 1 on page 1 of the SystemVerilog 3.1a LRM. It states
unambiguously that SystemVerilog is not a stand-alone standard, it is an
extension of the IEEE 1364-2001 Verilog standard. The next step in the
standardization process is to integrate these extensions into the 1364
standard.
In conclusion, I would like to re-emphasize my respect for Gabe and his
insightful articles on EDN. Gabe provides a valuable service to the
electronic design industry. His articles almost always are accurate and
poignant. This time, however, my perspective is quite different than
Gabe's, based on my experiences as an independent Verilog consultant,
coupled with my long experience and inside knowledge as a member of both the
IEEE Verilog and Accellera SystemVerilog standards organizations.
SystemVerilog is not a stand-alone standard, and cannot be treated that way.
SystemVerilog is a set of extensions to the IEEE 1364-2001 Verilog standard,
and depends wholly on that version of the Verilog standard. The intent and
expectation of most, if not all, of the many engineers that defined
SystemVerilog was that it would be transferred to the IEEE 1364 Verilog
Standards Group to be integrated into the next generation of the Verilog
standard. That integration of the extensions into their parent standard is
the only logical course that Accellera and the IEEE should consider. Any
other course would result in disjointed and nonsynchronized standards as
either the parent or the extensions evolved independent of the other.
Stuart Sutherland is the founder and principal consultant at Sutherland HDL,
Inc., a company that specializes in Verilog, SystemVerilog, and PLI training
and consulting services. He can be reached at stuart@sutherland-hdl.com or
at 503-692-0898.
~~~~~~~~~~~~~~~~~~~~~~~~~
> -----Original Message-----
> From: owner-btf@boyd.com [mailto:owner-btf@boyd.com] On
> Behalf Of Kurt Baty
> Sent: Friday, May 14, 2004 8:55 AM
> To: 1364@accellera.org; Btf@boyd.com; stds-dasc@eda.org
> Subject: Yellow Journalism ?
>
> The Sensational Beginnings of Yellow Journalism
>
> in 1898, newspapers provided the major source of news in
> America. At this time, it was common practice for a
> newspaper to
> report the editor's interpretation of the news rather than
> objective journalism. If the information reported was
> inaccurate
> or biased, the American public had little means for
> verification. With this sort of influence, the newspapers
> wielded much political power. In order to increase
> circulation,
> the publishers of these papers often exploited their
> position by
> sponsoring a flamboyant and irresponsible approach to news
> reporting that became known as "yellow journalism." Though the
> term was originally coined to describe the journalistic
> practices of Joseph Pulitzer, William Randolph Hearst proved
> himself worthy of the title. Today, it is his name that is
> synonymous with "yellow journalism."
>
>
> http://www.reed-electronics.com/ednmag/article/CA417185?indust
> ryid=2813
>
> Gabe Moretti, EDA editor, EDN magazine
>
> May be giving Joseph Pulitzer and William Randolph Hearst a run for
> their money!
>
> kurt
>
>
>
This archive was generated by hypermail 2.1.4
: Fri May 14 2004 - 11:47:05 PDT
and
sponsored by Boyd Technology, Inc.