Subject: Re: [sv-ec] RE: SystemVerilog Strategy, Plans and Proposal to address issues
From: Alec Stanculescu (alec@fintronic.com)
Date: Mon Dec 16 2002 - 16:19:14 PST
Jay,
Your presentation of Cadence's Technical Analysis of System Verilog
was very valuable, as is this letter. I would like to encourage the
first 80% part of the letter and consider that some of the final 20%
criticism of the Schedule as a tribute paid to the difficulty of the
task at hand, namely to support all the language features under
consideration.
> 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.
The current situation is very well described.
> 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).
>
I have the same concerns.
> 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.
>
The situation is potentially worse, since there is no implementation
for several of the donated constructs operating on the entire
Verilog-1364. Also, just the implementation is not sufficient. It is
the implementation together with it's "successful usage by a
sufficient number of users" that ultimately validates the language.
Such features will be specifically discussed by the respective
sub-committee chairs and the proper decision regarding their presence
or removal from the language will be made.
>
> 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.
>
Indeed, a big problem must be solved here: a solid Accellera standard
must be created and given to the IEEE. It is very good that Cadence is
bringing up this issue, and it the difficult task of the management of
the SV Committee to solve it.
> 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.
>
You made good points here. I believe that the plan was to try to add
as much as possible into System Verilog and deliver to the IEEE a
solid version by Summer time, by adding a lot of new constructs by
January and then remove anything that is not well defined.
The advantage of this method compared to adding one feature at a time is
that the Committee members get more used with removed features than
they would otherwise and these features have a better chance of making
it in the next version of the standard. To use your own terms, the
first stage of the pipeline is better filled this way.
> 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.
>
Vassilios' approach to the management of the process of transforming
language donations into IEEE standard candidates has been very
successful in the past (IEEE 1364 from Cadence's Verilog) and could
work well now, if he gets the support of all involved. His approach
cuts through red tape, as much as possible, as one should do to get
things done, and uses practical validation principles.
We must continue to trust Vassilios' management, as we enter into the
new phase of removing features which are not thought through enough
due to lack of time.
> 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.
>
The entire donation was put in the draft LRM because there was not
enough time to sort the various features. How it is done does not make
much of a difference (there are advantages and disadvantages for both
ways of doing things) provided that the goal is reached, and it is not
fair to blame it on management for having had this approach if
anything goes wrong. However, your proposal to separate the 3.0
donation from the 3.1 donation is something that the management
ought to consider seriously, as I cannot find any fault with it,
and it provides obvious advantages.
> 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.
>
System Verilog cannot become a standard without the participation of
Cadence. I do not believe that Accellera will lightly approve a
standard without Cadence's support. However, I want to point out that
it is easier to block a standard than to create a good one, and the
EDA community and its customers will benefit only from the creation of
good standards.
> 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.
>
Excellent news!
> 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
> >
> ------------------------------------------------------------------------
> --
> > --------------------------------------------------------
> >
> >
>
Best regards,
Alec Stanculescu, PhD
President of Fintronic USA, Inc.
1119 Chess Dr
Foster City, CA 94404
Tel: 650 349 0108 x 105
Fax: 650 349 1150
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 16:15:40 PST