-------- Original Message --------
Subject: SVDB Process document
Date: Fri, 01 Oct 2004 15:00:54 -0700
From: Karen Pieper <Karen.Pieper@synopsys.com>
To: <johny.srouji@intel.com>, <Karen.Pieper@synopsys.com>,
<matthew.r.maidment@intel.com>, Brad.Pierce@synopsys.com,
Mehdi.Mohtashemi@synopsys.com, <Neil.Korpusik@sun.com>, chas,
<Ghassan.Khoory@synopsys.com>, <fhaque@cisco.com>,
<Arif.Samad@synopsys.com>, David.Smith@synopsys.com
Hi, all,
I've developed a draft document describing the SVDB Bug
Process. Please review and send me feedback at your earliest convenience.
Thanks,
K
SystemVerilog Database Operating Procedures
September 28, 2004
Issue Lifecycle
1. Creating an issue
1. Issues can be created at any point in the revision cycle. The
revision process may have dates after which issues are not
guaranteed to be examined for a particular revision of the LRM. 2.
For everyone with write access to the SV DB, they should file issues
directly in the database 3. If the filer does not have access to the
SV DB, the filer can send mail to the appropriate SV-* committee,
and the Chair will take the responsibility of entering the issue in
the database. If an issue is to be filed this way, the Subject line
of the issue must read Errata: <issue title>. 4. Newly filed issues
will have status:new
2. Accepting an issue
1. Once an issue has been added to an SV-* committee?s list of new
stars, it is examined by the committee. The following actions are
possible:
1. The issue description is determined to be incomplete
1. The Chair will assign someone to communicate with the filer of
the issue to get a better description 2. The issue will move to
status:feedback
2. The issue is determined by vote of the committee to require no
change to the LRM
1. Some issues may not require changes to the LRM, questions, etc
Note: Questions should be answered in the bugnotes section and
communicated to the filer.
2. The issue will be moved to status:resolved with resolution:not a
bug
3. The issue is determined to belong to another committee
1. In the database, the owner for the issue will be updated to the
correct category with status:new. 2. The Chair of the current
committee will inform the Chair of the new committee that this
action has happened
4. The issue is accepted by the committee
1. The issue is moved to status:confirmed 2. The type field is
updated to reflect whether the issue is an Errata, Clarification, or
Enhancement 3. The issue is prioritized
1. Priority:immediate for issue that must be addressed before the
next revision of the LRM 2. All other priorities can be used by
each team as they deem necessary to prioritize issues that are not
required for the next revision of the LRM
3. Assigning an issue
1. When the committee is ready to work on an issue, it is marked as
status:assigned, and the assigned-to field is updated to reflect the
assignee
4. Proposal for an issue
1. Every proposal must completely describe every change required by
the LRM. Descriptions like: find every reference to byte and change
it to char is not acceptable 2. To describe a proposal, indicate
the section of the LRM that the change needs to be made in.
1. Indicate the old wording with the label ?REPLACE?, and copy the
relevant text, including some context. This can be done in Acrobat
Reader, for example, by using the Text Select Tool. 2. Indicate
the new wording with the label ?WITH,? and again copy the relevant
text, including some context. Then add text using blue and delete
text using red strikethrough. 3. Finally, save in a widely
readable format, such as HTML. 4. Templates reflecting this method
can be found at http://www.eda.org/sv
3. Proposals should be added to an issue using the upload file
button. The appropriate SV-* committee should then be sent an email
indicating that a proposal exists.
4. Approval of an issue by an SV-* Committee
1. Once a proposal exists, the assigned SV-* Committee discuss the
issue, and vote for its acceptance.
1. If a proposal is not passed, new proposals are developed as
above and the approval process restarts
2. Once a vote resolving an issue has passed 1.
The issue is moved to status:resolved , resolution:fixed
2. Several pieces of data need to be recorded for each issue in the
additional information field to allow groups of similar errata to be
approved by the P1800 in batches:
1. The date the issue is resolved 2. Whether or not the vote was
unanimous 3. Categories of the change
1. BNF 2. Simple text change: typo, etc 3. LRM change or
clarification 4. Usage errata enhancements
5. Review by the Champions
1. Prior to the presentation to the P1800, the Champions should
review all of the SV-* approved changes. The additional information
field should be updated with
1. Champions unanimously approve 2. Champions unanimously
recommend a specific alternative 3. Champions cannot reach concensus
6. Approval of issue by the P1800
1. All issues in the status:resolved must be approved by the P1800
whether they are resolution:fixed or resolution:not a bug. 2. The
P1800 will consider an issue using their voting process.
1. For issues that are not approved
1. The issue goes to status:assigned and the appropriate SV-*
committee is informed.
2. For issues that are approved
1. If the issue has resolution:not a bug it goes to
status:closed
2. If the issue has resolution:fixed
1. The issue is assigned to category:SV-LRM, status:new 2. The
date of the approval vote is recorded in the additional information
field
7. Addition to the LRM
1. If the LRM Committee does not have sufficient information to
incorporate a change into the LRM, it will send the issue back to
the appropriate SV-* Committee by
1. Assign the issue to category:SV-* with status:assigned,
priority:immediate 2. Mail is sent to the Chair of the SV-*
indicating that the issue is reopened
2. If the LRM Committee successfully incorporates the change, it will:
1. Publish a draft of the LRM including the changes 2. Update the
issue to status:acknowledged
3. Record Fixed draft version in the additional
information field
6. LRM Review by the SV-* Committees
1. Once an issue has status:acknowledged, the appropriate SV-*
committee must review the changes for correctness
1. If the change is currect, the issue is moved to status:closed
2. If the change is not correct and the description was correct,
the issue is moved to category:SV-LRM and status:new, and mail is
sent to the LRM team 3. If the change is not correct and the
description of the change needs to be modified, the issue is changed
to status:assigned
Common Queries Possible With This Process
Is an SV-* committee done?
An SV-* Committee is done with their work for a particular revision
of the LRM when the following conditions are true:
1. No issue entered before the submission deadline for a revision
of the LRM has priority:none 2. No issue has priority:immediate 3.
No issue has status:acknowledged
There are issues for the P1800 to consider when the following
condition is true:
1. There are issues with status:resolved
The LRM reflects all resolved issues when the following
conditions are true:
1. No issue has category:SV-LRM 2. No issue has status:acknowledged
The LRM ready to be sent to ballot when the following conditions
are true:
1. No issue entered before the submission deadline for a revision
of the LRM has priority:none 2. No issue has priority:immediate 3.
No issue has status:acknowledged 4. No issue has status:resolved
1. No issue has category:SV-LRM
Database Access
1. Read only access
Anyone can read the status of the database. They need to log on
with user id: guest and password: guest
2. Member company access
All companies that are members of the P1800 have an account that
will allow them to file issues in the database. The Chair of the
P1800 approves the addition of new companies to this class of
database access
3. Developer access
Chairs of the SV-* committees can nominate to the Technical Chair
members of their committees who will be making proposals to have
Developer access. This access style allows the developer the
ability to update the issues in the database.
4. Manager access
The Chairs of the SV-* committees have permission to update issues.
Enhancements requested
1. A status to record that a proposal has been made.
2. Category SV-LRM needs to be added.
-- Charles Dawson Senior Engineering Manager NC-Verilog Team Cadence Design Systems, Inc. 270 Billerica Road Chelmsford, MA 01824 (978) 262 - 6273 chas@cadence.comReceived on Wed Oct 13 09:10:24 2004
This archive was generated by hypermail 2.1.8 : Wed Oct 13 2004 - 09:10:39 PDT