Subject: [sv-bc] RE: [sv-ec] Clarification of operating guidelines
From: Vassilios.Gerousis@Infineon.Com
Date: Mon Jul 07 2003 - 22:19:48 PDT
Hi Jay,
Thanks for the feedback. It is good to have good eyes and see things in
different perspectives.
The SV chairs have formulated this document over the last few weeks to
help us operate
in a process which is efficient and fair. In fact, several of them have
been formulated and practiced in the development of SystemVerilog 3.1
standard. The SV Chairs will meet this week and provide you with a response.
However, I would like to point out at least two principles of operations,
that will not be changed.
First Principle: Standards
===================
One principle of operation is the fact that SystemVerilog 3.1 is a
standard. And we are only opening the door of "limited change" to experts
who are implementing SystemVerilog and the user community to make
SystemVerilog 3.1 more efficient. SystemVerilog 3.1 is built on existing
technologies that have already implementation and usage within the industry.
The industry must rely on a standard to be "unchanged". SystemVerilog 3.1A
development will follow this principle.
This does not apply to enhancement. There are several enhancements that
are planned for 3.1A development. We will get proposal and follow the same
process as we did in SystemVerilog 3.1 development.
1- We prefer not to get competing proposal on the same topic. We encourage
complementary proposal.
2- If someone is planning donation, we have to follow the Accellera process
for donation (legal first, technical discussion of the donation, then we
must hold a vote to accept or reject). The donors must understand that 3.1A
is limited in scope and timeline.
Second Principle: Style.
==================
In terms of the style, there is a frame template as the main style
(i.e. IEEE acceptable Format), but also there are specific things we have
added in SystemVerilog 3.1. Stu And Stefen have provided good guidance for
us to develop a style (frame and topic description). We have spent large
amount of time, not visible to you, trying to fit donations to this style.
If you have improvement to this, please do not hesitate to help. Examples
of the style topics we included in the LRM:
1- Topic description.
2- Language exception and limitation.
3- Some English semantic.
4- Where does it fit in the simulation semantics.
5- BNF.
6- Examples.
7- etc.
-----Original Message-----
From: Jay Lawrence [mailto:lawrence@cadence.com]
Sent: Monday, July 07, 2003 5:28 PM
To: Srouji, Johny; sv-bc@eda.org; sv-ec@eda.org
Subject: [sv-ec] Clarification of operating guidelines
Since Johny included a guidelines discussion on the agenda for today, I've
been reviewing the guidelines on the sv-bc and sv-ec websites and request
clarification on the following topics:
-----------------------------------
Issues found by implementation only
-----------------------------------
Cadence continues to believe that only identifying issues through
implementation is ridiculous. If an issue can be identified simply by
inspection of the language standard then it should be addressed.
Because of the makeup of the technical committee that invents the working
group guidelines we do not expect this requirement to change but would like
to take this opportunity to go on notice that we believe the requirement is
overly restrictive and not in the best interest of producing a robust
standard. This requirement goes against the "Committee Mission" statement:
"B. Complete enhancements from 3.1 development required to make
SystemVerilog a solid foundation for HDVL"
---------------------
Issues found by users
---------------------
Under the Committee Mission section, the following statement is made:
"A. Incorporate feedback from EDA vendor implementations of 3.1 and customer
usage."
However, under the Goals/Objectives section the following statement is made:
"A. Resolve all known issues and issues found from implementation by
vendors"
One of these should be modified. I would suggest it is the second statement.
It should be modified to include comment about issues found by users when
using implementations. Otherwise there is no provision for a user problem
being addressed in the 3.1a process.
-------------------------------
Multiple donations and timeline
-------------------------------
Under the section on Donations/Proposals the following statement is made:
F. Submissions will be limited by date (both on commitment and delivery)
and multiple proposals will be resolved by vote.
Then it goes on to say:
B. vote on acceptance of the submission
a. on acceptance no other submissions will be accepted on the same
topic
Because the refining and editing of a submission happens AFTER its
acceptance, this leaves little or no room for combining multiple submissions
on a given topic into a single final LRM content.
If this rule is to remain in effect, then at least the vote on "acceptance"
of a submission should be delayed until the time at which all submissions
are due. Otherwise submissions could be rules out before they are ever made
because of an alternative proposal.
--------------------
Style of submissions
--------------------
All requirements on the style of submissions should be removed. There is no
one "Style" in the SystemVerilog LRM. Despite excellent efforts by Stu and
Stefen to make the document self-consistent the style varies widely from
different donation sources.
If a submissions is sufficiently ill-written as to be incomprehensible then
it will be rejected on the technical problems. Imagining that the
SystemVerilog LRM has some consistent "style" with which a donation should
conform is a fiction.
-----------------------------------
Champion's approval of errata fixes
-----------------------------------
The role of "champion" came into existance in the charge toward getting the
last edits into the document between drafts 4 and 5. It served to triage
incoming comments. This new regulation elevates the role of "champion"
significantly. They are now given veto power over all errata decisions. This
is not in the spirit of consensus and bypasses all established individual an
corporate voting rules.
Jay
===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
-----Original Message-----
From: Srouji, Johny [mailto:johny.srouji@intel.com]
Sent: Sunday, July 06, 2003 1:49 AM
To: sv-bc@eda.org
Subject: [sv-bc] REMINDER - our tele-call on Monday, July 7
Hi All,
This is a reminder of our tele-call tomorrow, Monday July 7th. I assume we
will be using the same bridge which was used for the separate compilation
meetings. Karen, please update/comment.
In the US: 888-635-9997
Internationally: 763-315-6815
Participant code: 53904#
Following is the agenda:
* Review of our operations guidelines and sv3.1a roadmap and schedule.
Document is located under:
http://www.eda.org/sv-bc/SV-BC-Operating_Guidelines.htm
<http://www.eda.org/sv-bc/SV-BC-Operating_Guidelines.htm>
* Review of existing issues under sv-bc. An updated list is located
under: http://www.eda.org/vlog-pp/sv-bc/issues/index.html
<http://www.eda.org/vlog-pp/sv-bc/issues/index.html>
* Gathering of new potential issues and updates for the language
* A short summary update on the "separate compilation" issue, in case
Karen is ready
* Opens
Thanks,
--- Johny.
-----Original Message-----
From: Srouji, Johny
Sent: Monday, June 23, 2003 7:11 PM
To: sv-bc@eda.org
Subject: [sv-bc] SV-BC tele-call meetings
Hi All,
Please note that we shall resume our regular SV-BC tele-call meetings on
Monday of July 7th. This week, I will also submit a document which describes
the operation guidelines and processes towards delivering LRM 3.1a. These
processes were discussed by Accellera TCC and will be consistent across all
committees.
Thanks,
--- Johny.
This archive was generated by hypermail 2b28 : Mon Jul 07 2003 - 22:25:26 PDT