Subject: RE: [sv-ec] RE: SystemVerilog Strategy, Plans and Proposal to address issues
From: Jay Lawrence (lawrence@cadence.com)
Date: Mon Dec 16 2002 - 14:03:28 PST
Vassilios,
Thank you for your response letter below concerning Cadence's "Technical
Analysis of System Verilog" presented on Dec. 4, 2002 and thank you once
again for allowing Cadence the time to present this to the entire
SystemVerilog Technical committee in person. I must admit that we are
disheartened by your response because we continue to believe that there
are fundamental problems with the technical content of the
SystemVerilog proposals in Accellera, and unfortunately, the existing
processes do not seem to allow for these issues to be resolved.
Delving into the language minutia of attributes vs. keywords was not the
purpose of our presentation; our concerns on language specifics are
best left for the individual committees in which we will continue to
actively participate. Rather, our concern has been to expose the basic
and fundamental issues in the language itself. Unfortunately, the
merging of multiple donations, which were originally unique subset
additions to the language, into a single standard language has led to
several significant issues. The impact of these issues to the EDA
community and most importantly to our customers is severe and
long-lasting.
The current set of donations originate from many quarters: system-level
extensions from SuperLog /CoDesign (now Synopsys), testbenches from
Vera/System Science (now Synopsys), and assertions from ForSpec/Intel
(recast as OVA). In each case, these technologies made excellent
contributions to the verification portfolio available to the HDL
designer and verification engineer. These startups and internal CAD
teams found a niche that was not being addressed by other commercial
tools and developed technology to fill that niche. However, these groups
were not responsible for ensuring that these languages were
syntactically or semantically truly integrated with Verilog-1364. They
instead just needed to ensure that they did the specific job for which
they were intended and integrated to the host simulators through PLI.
If the charter of the SystemVerilog committee was to develop a new
language which was integrated with standard Verilog simulators in an
arms length fashion, then the existing implementation of these
languages might serve as proof of concept and validate the technology.
However, our understanding is that the intent is to integrate these
constructs into the entire Verilog language. Many of the donations in
both the 3.0 standard and 3.1 draft have serious issues when applied to
the entire language rather than the subset a startup needs to address to
stay in business until acquired, or an internal CAD team needs to handle
for a specific company's methodology. Simple examples include the lack
of a consistent hardware interpretation of the 'logic' type,
'interfaces' that create interconnect that cannot be back-annotated with
timing, and testbenches/assertion proposals that assume synchronous,
single clock behavior to act correctly (and only then with a very
expensive, unapproved change to add cycle simulation semantics and a
"verification phase" to Verilog).
The design and verification methodologies allowed by the individual
donations are excellent and certainly belong in the next generation of
Verilog, but a blind reliance on an implementation that only had to
satisfy an extremely limited subset of requirements to validate that the
donation is sound and can be integrated with the entire Verilog-1364
language is not a prudent course of action. Independent confirmation is
required.
Procedural Issues:
-------------------
We believe that the following set of procedural issues are preventing us
from resolving these problems, and at the same time are leading us too
quickly toward an Accellera standard that is not a firm basis for the
future of Verilog. Cadence would be interested in responses, either
directly to me (lawrence@cadence.com) or on the reflectors, from other
committee members as to whether they concur with this position.
Note also, that due to the procedural issues brought out in section IV
below, I have copied the Accellera Board of Directors on this message to
ensure that they are aware of your initial letter and the enclosed
proposal to bring a new task force into existence. As detailed in that
section below, the structure of the task force, the constraints placed
upon its activities, and the voting rules do not make sense to Cadence.
It is not clear to Cadence (and we believe others inside and outside of
Accellera) how these fundemental language issues are resolved.
I. Delay of the IEEE-1364 standardization process
-------------------------------------------------
The charter of Accellera is to accelerate IEEE standards. During the
SystemVerilog 3.0 standardization process it was Cadence's
understanding that the intent of the process was to develop a proposal
to be donated to the IEEE-1364 committee. Many compromises were made
during 3.0 development with the understanding that this donation would
be made in a timely fashion and that these compromises would be resolved
during the IEEE process.
Noone expects the IEEE process to be a rubber stamp of the Accellera
standard. It is inevitable, and required by IEEE procedures, that each
individual change to the language be reviewed and approved. This process
begins when the IEEE receives the donation. Since the current sv-bc
mandate is that there are no enhancements or deletions allowed in the
SystemVerilog 3.0 specification, we do not see any gain in further delay
of donating it to the IEEE. It is simply delaying the time at which the
IEEE can begin its work, thus delaying the time at which an approved
IEEE-1364 standard will be completed.
The further addition of 3.1 (and now you've announced 3.2) content is
not a justification for delay. The IEEE process is a serial process and
pipelining the donations from Accellera will lead to the fastest
completion of an IEEE standard. From a Cadence point-of-view, this could
have been a reasonable place to address some of the serious issues in
the language.
II. Schedule superceding the quality of the standard and the development
process
------------------------------------------------------------------------
--------
The schedule demands on the sub-committees for completion of each phase
of the standard are unproductive and not technically sound. In any
development effort there exists the need for milestones to see if you
are on track, but the dates must remain flexible in order to allow
proper development practices to proceed. The SystemVerilog milestones
have been timed to coincide with conferences such as DVCon and DAC.
Whatever the motivations for the dates, they are not conducive for
creating the best SystemVerilog language we can.
The design and enhancement of a language is no different from the design
of any other product, be it software or hardware. The phases involved
are requirements, design, implementation, verification, and iteration.
The processes and schedules being driven in Accellera today are not
allowing for this proper development methodology to take place.
There are no clear requirements documents against which either the
SystemVerilog 3.0 standard or donations to the 3.1 draft can be
measured. The first step in the committees' activities should be the
creation of these requirements, independent of the language donations
that will eventually fulfill them.
The "design" of SystemVerilog has been to glue together multiple ideas
from multiple sources without carefully making the effort to change them
so that they make a coherent whole. Our views on why this process is
flawed were given above.
The "implementation," as far as the standards bodies are concerned, is
the production of an LRM. In SV 3.0, this is complete but known to have
issues which are now procedurally blocked from being addressed by the
constraints placed on the sv-bc. For SV 3.1, the time constraints are
preventing serious review of the 3.0 issues, and will lead to an
increasingly unclear final LRM (more comments on the LRM creation
process below).
The "validation" process for SystemVerilog should be a comparison with
the requirements specification to see if the goals of language
extension are met. Since these requirements are not clearly specified,
this form of validation is impossible. Instead, the vendor companies,
and their customers, are required to push ahead and attempt
implementation and use of the language. Only after this very expensive
process is complete will we know whether the language succeeds. We are
all in the design automation business, and we should realize that
implementation is not a good validation methodology.
The final phase of product development and design is "iteration," where
lessons learned from the first generation are applied, defects in the
previous product are fixed, and enhancements requested in the next round
of development are considered. The 3.1 phase of developing the
SystemVerilog standard product is also not following this process. Once
again there is no clear specification of requirements; there is no
chance of fixing critical defects because deletion and enhancements are
precluded by committee charter; and the lesson that by rushing the 3.0
standardization an LRM was produced that is known to be incomplete and
unclear is not being heeded.
Since your response letter announced that there will now be a
SystemVerilog 3.2 standard, and you have decided that there will be no
additions in that version, we can only assume based on past behavior
that this will lead to further delay in donating the 3.1 language to the
IEEE, thus delaying validation of the standard in that way.
III. Creation of strawman LRM as a process
------------------------------------------
We find the process currently being followed by the sv-ec committee to
be backward. Rather than carefully analyzing the testbench donation and
clarification documents, voting on the components, and then adding them
to the SystemVerilog LRM, the entire contribution has been added to the
draft 3.1 LRM.
This places reviewers in a position where we must argue for deletion or
modification of constructs that have been added as a fait-accompli,
rather than requiring the donation to be clear and precise and then
voting to add portions of the donation to the draft. This should not be
taken as a criticism of Stu Sutherland for pulling the draft together,
or toward David Smith as chairman of the committee. The unrealistic
dates imposed on them to complete the LRM have left them no choice but
to attempt to assemble an LRM as quickly as possible. In email
communication on the sv-ec reflector, David has clearly stated that he
intends a review of every single construct added, and Stu has done a
yeoman-like job preserving change-bars in the draft document. However,
if we do not complete the review of the current 200-plus page draft
before the deadlines, we will be left in a position where the
unreviewed sections will simply need to be removed. This will
inevitably lead to an incomplete, inconsistent LRM.
You have stated that you are willing to delete content to preserve the
dates. When this inevitably happens the choice of creating an LRM with
unapproved content rather than only adding approved content will prove
to have been a mistake.
IV. Over-regulated and subdivided charter of sub-committees
----------------------------------------------------------
Your response letter made the following proposal:
> 3- PROPOSAL: We will select a small working group (Task Force)
to
> address one issue at a time. A proposal is developed and sent to the
> appropriate committee for debate and approval. As a start, Karen
> Pieper will lead the first task force to address enhancement to $root.
> She will select a team of people to discuss and develop a proposal.
> Formation and selection of issues will be under the
guidance and
> responsibility of SV chairs, Some rules to operate with:
> a- The chairs will select an issue and a leader. Members
should
> provide prioritised issues to their chairs.
> b- Language re-design is not allowed (e.g. attribute
versus
> keywords, libraries versus keywords).
> c- The chairs must agree with the outcome before it goes
to the
> appropriate committee.
This proposal says that you choose the committee chairs. The committee
chairs choose the committee participants and issues that can be
discussed. The discussion must result in no re-design so the committee
has no power to change anything, and that if they choose to deny this
edict and propose change, the chair (appointed by you) must agree before
the committee sees the recommendation.
This proposal does not align with well-established standards practices.
The chairs should be recommended and confirmed by the committee
participants or the board of directors, not appointed. The committee
members should be chosen based on willingness and interest in
participating, with care taken that no one company has undo influence
through proper one-company one-vote procedures, and the committee chair
should have no more vote than any other committee member.
If addressing our architectural concerns means participating in an
improperly organized committee with an overly constrained charter, then
we respectfully decline to participate in this new task force.
Immediately following our presentation at the SystemVerilog meeting, at
the very successful SystemVerilog seminar on the following day, and in
subsequent communications, we have received encouragement from many
Accellera member participants for the types of fundamental change that
we are advocating in both the Accellera process and SystemVerilog LRM.
We encourage those members to voice their concerns and work within
Accellera for change. Despite our reservations on the existing charters
and timelines, we will continue as best we can to present our ongoing
issues in the existing committee structure and work toward a useful,
integrated language that can promptly be taken to the IEEE for
standardization upon completion of work in Accellera.
Best regards,
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
978 262-6294
lawrence@cadence.com
> -----Original Message-----
> From: Vassilios.Gerousis@Infineon.Com
> [mailto:Vassilios.Gerousis@Infineon.Com]
> Sent: Thursday, December 12, 2002 3:02 AM
> To: sv-ac@eda.org; sv-bc@eda.org; sv-ec@eda.org; sv-cc@eda.org
> Subject: [sv-ec] RE: SystemVerilog Strategy, Plans and
> Proposal to address issues
>
>
> SystemVerilog 3.0 is based on a real product, co-design
implementation.
> SystemVerilog 3.1 language components are being designed with
donations
> from Synopsys. Accellera standards are always based on technologies
that
> have been implemented and used. We do not create keywords or any
> constructs based on opinions or philosophy. SystemVerilog 3.0 is based
on
> a real implementation. No language is perfect and no release of a
version
> of a standard is perfect either. EDA vendors has accepted the fact
that
> the original Verilog was not perfect and attempted to provide a
solution
> compatible to Verilog-XL, even if it was inaccurate. It is time to
stop
> negative criticism and start working positively to develop a good
> SystemVerilog 3.1 standard. There are many capability to influence and
> provide a good solution within this frame.
> I am going to provide my own comments on Cadence presentation during
SV
> committee meeting, then I am going to provide a proposal of how to
> proceed. First, I want to thank Cadence members for active
participation
> in every committee. My hope that more energy is spent to help develop
a
> good 3.1 standard and to work in helping in optimizing language
design.
> Jay and his team at Cadence have indicated their support to help in
> SystemVerilog 3.1 development.
> 1- General Comments:
> A - The presentation provides a philosophy of language design.
This
> philosophy can be summarized into two camps. One is library/package
based
> like VHDL and SystemC the second one is language-inclusion (like
> Verilog/SystemVerilog). The library/package based rely on companion
> standards. The user must combine the native standard and the companion
> standard to make models interoperable by different tools.
> Drawbacks:
> a- This have been tried in VHDL and EDIF and have known
to
> fail. Currently users of VHDL are hurting by this language
architecture
> and the message I am getting is that they would like to see one VHDL
> standard combining these companion standards with the actual VHDL
> standard.
> b- I am also seeing divergence by user of SystemC, who
are
> adding their own extensions of libraries. SystemC allows
extensibility,
> but eventually the user will finally get hurt by lack of tool support
of
> such extensions.
> B- Attributes in Verilog and properties in EDIF have one thing
in
> common. No tool support them and or can interpret their meaning. In my
> humble opinion, attribute is a bad example of a good language design.
Our
> goal for SystemVerilog 3.0 and beyond, is to provide a language with
MANY
> keywords that can be simulatable, verifiable and to certain extent
> synthesizable. Just adding syntax to a language that cannot be
verified,
> is a problem. Our focus for SystemVerilog is to stop the explosion of
> pragmas (addining comments for certain tools) and instead provide
better
> language that can be verified and synthesized.
> C- Continual criticism of SystemVerilog 3.0 and how 3.1 is being
> designed is non productive. It is a fact that SystemVerilog 3.0 has
been
> implemented. Also the different donation planned for 3.1 have been
> implemented and in use with designers. It is time to start development
of
> tools for SystemVerilog 3.0. It is more productive to help in the
design
> of SystemVerilog 3.1. Many of the technical points have been addressed
in
> each technical committee.
> D- Adding too many keywords: We are in essence merging THREE
LARGE
> languages together (Architecture (connectivity and high abstraction),
> Testbench and Assertion). We are in essence tripling the language
> capabilities. The donations will help to unify the intersection of
these
> languages and in essence minimize the keywords.
> - Users will benefit immensely with unified System
Verilog
> language and interactions of various functionality instead of wasteful
> efforts of integration. Currently the user have to learn three
different
> languages and deal possibility with at least three different products
that
> are "lossley" connected together. SystemVerilog will provide an HDVL
and
> ensure faster tool and better interaction with different verification
> strategy and plans.
> - Large efforts are being made to make sure that
> SystemVerilog is backward compatible with Verilog. This was the
fodunation
> of SystemVerilog 3.0 and we will continue to do so. I believe the EDA
> industry must rely on smart compile technology that are conext
sensitive.
> 2- Specific Comments: SystemVerilog is extending Verilog into four
major
> categories. These are:
> a- Higher abstraction: Architecture, algorithm and major
addition of
> Data Types.
> b- Testbench.
> c- Assertion.
> d- C/C++ interface.
> - There are four architectural foundations (described by Peter
> Flake) = $root, Program, etc.. The semantic and scheduling are
properly
> defined and can be refined. These plus many others like Interface, new
> operators are non-negotiable for removal. We can accept enhancement
but
> not removal.
> - The donations to these four categories are based on existing
tool
> implementations and also usage by designers. The following are facts:
> a- SystemVerilog 3.0 is a standard. The different
committees
> are making sure we are
> building on this foundation. We have provided a door for people who
can
> provide implementation feedback (ONLY).
> b- Re-design of the language is not acceptable.
> c- SystemVerilog 3.1 will intersect many different
languages
> including SystemVerilog 3.0 and will require minor modification of
> SystemVerilog 3.0. This is a natural conclusion and we will operate on
> this principle. Again modification of SystemVerilog 3.0 should be kept
at
> minimum to allow EDA vendors a chance to rely on an Accellera
standard.
> The users must rely on stable standard and depend on tools delivery in
a
> timely fashion.
> d- We have fixed milestones for planned released at DAC
> 2003. No changes to the schedule are negotiable. We will cut things
back
> rather than delay the release. This is mandatory to allow EDA vendors
a
> standard in 3.1 that can be implemented in a short period of time. The
> users community must have tools.
> c- We do plan to do 3.2, and it will address items that
was
> left from 3.1. WE WILL NOT ADD ANY NEW MAJOR COMPONENT. Our focus for
3.2
> is to get more tools to implement the 3.1 standard.
> 3- PROPOSAL: We will select a small working group (Task Force)
to
> address one issue at a time. A proposal is developed and sent to the
> appropriate committee for debate and approval. As a start, Karen
Pieper
> will lead the first task force to address enhancement to $root. She
will
> select a team of people to discuss and develop a proposal.
> Formation and selection of issues will be under the
guidance
> and responsibility of SV chairs, Some rules to operate with:
> a- The chairs will select an issue and a leader. Members
> should provide prioritised issues to their chairs.
> b- Language re-design is not allowed (e.g. attribute
versus
> keywords, libraries versus keywords).
> c- The chairs must agree with the outcome before it goes
to
> the appropriate committee.
> Best Regards
>
> Vassilios
>
------------------------------------------------------------------------
-- > ---------------------------------------------------- > Dr. Vassilios Gerousis > Chief Scientist > Infineon Technologies > DAT CS, MchB > D-81541 Munich > Germany > BalanSt. 73 > Telephone: +49-89-234-21342 > Fax: +49-89-234-23650 > email: Vassilios.Gerousis@infineon.com > Site Map: > http://www.stadtplandienst.de/query;ORT=m;PLZ=81541;STR=Balanstr%2E;HNR= 73 > ------------------------------------------------------------------------ -- > -------------------------------------------------------- > >
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 14:04:57 PST