Subject: RE: SystemVerilog Strategy, Plans and Proposal to address issues
From: Vassilios.Gerousis@Infineon.Com
Date: Thu Dec 12 2002 - 00:01:31 PST
> 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 : Thu Dec 12 2002 - 00:03:09 PST