-----------------------------------------------------------------------
           Extension Guidelines Checklist Template (EGCT)
-----------------------------------------------------------------------

The EG Checklist/Template, is a survey that is completed by the
proponent of a language enhancement proposal. The proponent might be an
individual, a company, a BTF subcommittee, or any another organization.

This Checklist would be used in the context of EGG Proposed Guidelines
and the Process Flow Document.
------------------------------------------------------------------------

Section [1]
-----------
ID:
   [1.1]  -- [number to identify the extension]

Name:
   [1.2]  -- [name of the extension proposal]

Synopsis:
   [1.3]  -- [explanation in one line]

PROBLEM:
   [1.4]  -- [what problem is the extension trying to solve]

Section [2]
-----------
EXTENSION:
   [detailed explanation of the extension]

     Checklist / Questions
 [2.1] -could it be solved with current Verilog? if so what's the drawbacks?
 [2.2] -what are the improvements that the extension provides
 [2.3] -Does the extension introduce a new behavior?
            Why is the new behavior important or desirable?
 [2.4] - What requirements were imposed on the solution?
 [2.5] - What alternatives or workarounds were considered?
 [2.6] - What is the urgency of solving this problem?
 [2.7] - Are there any copy rights Issues?
 [2.8] - Is there an  accompanying drawing, (if yes, is it in the
            BTF frame maker format )
 [2.9] - Has this extension been Implemented for the proposed use ?

Section [3]
-----------
Examples:
   [usage examples]

Section [4]
-----------
BNF:
   [BNF form of the extension]

Section [5]
-----------
KEYWORD:
   [list of new keyword if any]

     Checklist/Questions
   [5.1]  - Is this keyword already commonly used in user designs?
   [5.2]  - Does the extension introduce new syntax or lexical elements?

Section [6]
-----------
COMPATIBILITY:
     [6.a] - Verilog 1364-1995
     [6.b] - Verilog 1364-2001
     [6.c] - Verilog-AMS
     [6.d] - System Verilog

     Checklist / Questions
     [6.1]  - Does the extension make any existing Verilog illegal?
     [6.2]  - Does the extension change the behavior of an existing design?

CONSISTENCY:

      Checklist / Questions
      [6.3]  - Does the extension introduce something that is similar to an
               existing aspect of the language? If so, is the form and use
               consistent?
Section [7]
-----------
IMPACT: (Check list)
 [7.a] -- Impact on LRM

   [7.a.1]    - What LRM sections are affected by this extension?
   [7.a.2]    - Does the extension introduce new terms or concepts?
   [7.a.3]    - Is the extension an addition to an existing class
                of constructs?
   [7.a.4]    - How does the new construct interact with
                existing constructs?
   [7.a.5]    - Are there Timing implications? How is the extension handled
                with SDF?

   [7.a.6]    - Does the extension introduce a new kind of object
                or datatype? if yes

          [7.a.6.1] -- what operators are applicable and what are their
effects.
          [7.a.6.2] -- Can it have x or z values or other special values?
          [7.a.6.3] -- Can it have zero or negative values?
          [7.a.6.4] -- Can the new data type be passed as a port ?

   [7.a.8]    - Does the extension add a new kind of design unit? How is the
                design unit handled by a configuration?

   [7.a.9]    - Does the extension add a new kind of operator?
                To what can it be applied? What is its behavior?

              [7.a.9.1] -- How does the operator relate to x, z, 0,
                           negative, and real values?
              [7.a.9.2] -- What is the bit-length of the result?
              [7.a.9.3] -- How are operands extended?
              [7.a.9.4] -- How does it handle signed operands?
              [7.a.9.5] -- Is the result signed or unsigned?
              [7.a.9.6] -- What is its precedence in order of evaluation?

   [7.a.10]    - Does the extension add a new kind of statement? Where
                 can it appear? What are its execution semantics?

   [7.a.11]    - Does the extension introduce a new structural element?
                 What is the form of a hierarchical name for the element?

   [7.a.12]    - Does the extension introduce a new kind of declaration?
                 To what name space do the new kind of names belong?

   [7.a.13]    - How is the new extension is scheduled for execution.


 [7.b] Impact on VPI

   7.b.1]   - Are there VPI implications? Is the information model
                updated? Are new routines introduced?

 [7.c] Impact on VCD

    [7.c.1]   -VCD affected by this extension?
    [7.c.2]   -How is the new item handled with VCD?
    [7.c.3]   -How is the item referenced, and in what contexts
               can references appear?

 [7.d]   Impact on other donations

 [7.e]   Impact on other Task Force(s)

 [7.f]   Possible impact on existing implementations

Section [8]
-----------
OTHER INFORMATION:

   [8.1]  Dependent Extension IDs:

   [8.2]  Folded Extension IDs:

   [8.3]  Related Extension IDs:

   [8.4]  Priority:

   [8.5]  Other:

Section [9]
-----------
COMMENTS / OPINIONS:

   [Record various comments and opinions on the extension]

Section [10]
-----------

ISSUES and Action Items:

   [List of issues to be discussed and solved]

==================================================================