Accellera SV-CC Technical Committee


Home

Committee Mission

Goals/Objectives

Process

Donations/Proposal

Errata

Voting Rules

Milestones

Deliverables

SV-CC 3.1 Web

 

Operating Guidelines

Committee Mission

  1. Address remaining issues from System Verilog 3.0/3.1
  2. Address issues exposed in SystemVerilog 3.1 standard through implementation
  3. Handle all design modeling issues, such as refinements of the language as well as design enhancements to solidify System Verilog as RTL design language

Goals/Objectives

  1. Resolve all known issues in the RTL design language and new issues found either through implementation by vendors or customer usage.
  2. Process any donations or proposals that are made according to the defined process
  3. Any extension, enhancement or modifications of the modeling language must be consistent with SystemVerilog 3.1
  4. Be complete with 3.1A release by DVCON 2004

Process

  1. Request proposals/donations on a specific list of topics that must be committed to by a specified date and provided by a specified date (see milestones)
  2. Review all appropriate errata, proposals, and/or donations and incorporate into the 3.1a LRM
  3. All work will be voted on as per the voting guidelines
  4. The SV-CC web site will be the primary repository or all work and communication

Donation/Proposals

The list of enhancements for 3.1a will be based on the list created by the SystemVerilog committee chairs. This will be refined, prioritized, and approved during the first month of operations. The preference is that only complimentary donations or proposals are submitted.

All donations or proposals must be submitted according to the following guidelines:

  1. Submissions must be based on at least a prototype in an EDA tool (internal or commercial vendor).
  2. The submitter will need to make a statement that the submission meets and will be trusted without having to provide proof.
  3. The submission must be consistent with SystemVerilog 3.1 design. This will be determined by the committee.
  4. The submission must be described in terms of SystemVerilog 3.1 syntax and semantics.
  5. The submission must be in a form that is in the style of the SystemVerilog 3.1 Language Reference Manual (LRM), including the relevant BNF changes.
  6. Submissions will be limited by date (both on commitment and delivery) and multiple proposals will be resolved by vote.

Failure to meet any of items A-F will be grounds for a submission to be rejected. Rejection sends the submission back to the submitter after which they have one more opportunity to resubmit, without prejudice. The original submission deadline must still be met.

The committee must process each qualified submission using the following process:

  1. Review the submission for:
    1. Does it meet address the topic?
    2. Is there any missing information?
    3. Is there any design, syntactic, and semantic consistency/conflicts with SystemVerilog 3.1 and Verilog 1364-2001
    4. Style of the submission consistent with SystemVerilog 3.1 LRM.
    5. The review of a submission must take at least a week.
  2. Vote on acceptance of the submission
    1. on acceptance no other submissions will be accepted on the same topic
  3. Refine the submission
    1. detailed analysis and editing of submission description
  4. vote on approval of the submission
    1. Once the submission is approved then it becomes part of the 3.1a LRM.

Errata

All changes to the existing LRM to fix errors, refine concepts, or clarify descriptions will be handled as errata. All errata will be created using a web based interface (in planning). The committee will:

  1. review all submitted issues
  2. resolve them as appropriate
  3. generate change notices for all changes
  4. notify submitter of the resolution

This will require each errata to include the following information:

  • Problem description
  • Example of problem
  • Submitter's name
  • Submitter's email
  • Section(s) of LRM related to issue

The appropriate SystemVerilog champion (as defined by the SV chair) must participate in all discussions of technical proposals to change 3.1 content.

Any removal of 3.1 technical content must be approved by the chairs of the SystemVerilog committees.

Voting Structure

Voting is used to resolve issues in a number of areas; process, technical discussions, acceptance and approval of submissions, resolution of errata, approving the LRM and sending it to the board, etc. In general this can be divided into two categories.

Company based votes:

These votes are for issues where Accellera membership is required. The following are examples of company based votes:

  1. Committee procedural rules
  2. Acceptance and approval of submissions
  3. Errata that make either major or inconsistent changes to the SystemVerilog 3.1 LRM
  4. Approving the SystemVerilog 3.1a LRM and sending to the board

Member based votes:

These votes are for issues that are primarily in technical in nature and do not require Accellera membership. The following are examples of individual based votes:

  1. Resolution of errata
  2. Technical decisions in the review and refinement of submissions

Voting Rules

Voting guidelines are as follows:

  • Attendance
    • Voting attendance is reset as of the first meeting of the 3.1a effort.
    • Individuals that were eligible to vote at the end of 3.1 will be eligible to vote at the beginning of 3.1a (with the assumption that they have 3 out of the last 4 meetings attended).
    • Individuals must attend 3 out of the last 4 regularly scheduled meetings to be able to be eligible to vote or must have attended at least 75% of the meetings during the 3.1a effort.
    • Company votes are based on a designated individual's attendance record (including proxy specification).
  • Committee Vote
    • All votes require majority of the eligible votes attending the meeting to pass. A quorum of 50% of the eligible companies must be present for company votes and a quorum of 50% of the eligible individuals must be present for individual votes.
    • The Chair of the committee is not eligible to vote on individual votes unless there is a tie in which case the chair's vote is used to break the tie. Co-chair can vote as an individual except in the case where the co-chair is acting as the chair due to the chair not being present.
    • The Chair of the committee is not eligible to vote on company votes (unless he is the only company representative on the committee). If there is a tie then the TCC chair's vote is used to break the tie.
  • Email vote
    • A vote for email can be called by the chair/co-chair.
    • The period for response will be one week (can be adjusted by agreement before the vote to a different period within committee)
    • Any negative vote will force the issue to be discussed and voted on at a committee meeting. A negative vote must be accompanied with a clear description of the reasoning behind it.
    • If there are no negative votes and half of the eligible voters respond with an accept vote then the motion will be passed (the Chair of the committee is not eligible to vote on email votes)
    • The purpose of this is to pass items that are non-controversial and to reduce the time required to handle them in meetings

Milestones

  • 7 July 2003: Committees start operating
  • 4 August 2003: Close of submission commitments
  • 15 September 2003: Close of submissions
  • 1 December 2003: Complete technology errata, freeze technology of submissions, close implementation feedback
  • 24 December 2003: End of LRM development, start of LRM review
  • 24 January 2004: Send to board
  • 24 February 2004: Release 3.1a LRM

Deliverables

System Verilog 3.1a LRM.