Subject: [sv-bc] Clarification of operating guidelines
From: Jay Lawrence (lawrence@cadence.com)
Date: Mon Jul 07 2003 - 08:28:22 PDT
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
* Review of existing issues under sv-bc. An updated list is
located under: 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 - 08:33:50 PDT