VSG meeting on Monday 3/10/03

From: Stefen Boyd (stefen@boyd.com)
Date: Fri Mar 07 2003 - 23:07:41 PST

  • Next message: Stefen Boyd: "There were a few more..."

    I've finally put together a little bit of a page for
    the 1364 at http://boyd.com/1364

    It's not much, but it's what you get for free ;-}

    You will find links to the minutes from all the past
    meetings and links to just the PASSED pages for the
    VSG, ETF, and PTF. I've attached the passed items from
    the etf to this email for those who may not be near
    the web at the time of the call...

    Stefen

    --------------------
    Stefen Boyd Boyd Technology, Inc.
    stefen@BoydTechInc.com (408)739-BOYD
    www.BoydTechInc.com (408)739-1402 (fax)


    ETF PASSED

    Fri Mar 7 01:01:54 2003 PST

    55 ETF PASSED ISSUES

    ReleaseMeaning
    2001aIssue against 1364-2001 First Edition
    2001bIssue against 1364-2001 Second Edition (Possibly also issue in First Edition)
    2001a, 2001bIssue against both 1364-2001 First and Second Editions (i.e. errata partial fix in 2001b, but more changes required)

    ISSUE Release Synopsis Fix
    20 2001b: A.2.8, 2.8.2, 9.8.1-2, 10.2.1, 10.3.1
    		A.2.8 should prevent all variable declaration assignments in named blocks

    REPLACE the following BNF rules of section A.2.8: 

     
     block_item_declaration ::=
         { attribute_instance } block_reg_declaration
       | { attribute_instance } event_declaration
       | { attribute_instance } integer_declaration
       | { attribute_instance } local_parameter_declaration
       | { attribute_instance } parameter_declaration
       | { attribute_instance } real_declaration
       | { attribute_instance } realtime_declaration
       | { attribute_instance } time_declaration
 
     block_reg_declaration ::=
         "reg" [ "signed" ] [ range ] list_of_block_variable_identifiers ";"
 
     list_of_block_variable_identifiers ::=
         block_variable_type { "," block_variable_type }
 
     block_variable_type ::=
         variable_identifier
       | variable_identifier dimension { dimension }


    WITH the following new rules for section A.2.8: 

    block_item_declaration ::=
    {attribute_instance} "reg" ["signed"] [range] list_of_block_variable_identifiers ";"
  | {attribute_instance} "integer"  list_of_block_variable_identifiers ";"
  | {attribute_instance} "time"     list_of_block_variable_identifiers ";"
  | {attribute_instance} "real"     list_of_block_real_identifiers ";"
  | {attribute_instance} "realtime" list_of_block_real_identifiers ";"
  | {attribute_instance} event_declaration
  | {attribute_instance} local_parameter_declaration
  | {attribute_instance} parameter_declaration

list_of_block_variable_identifiers ::=
    block_variable_type { "," block_variable_type }
  
list_of_block_real_identifiers ::=
    block_real_type     { "," block_real_type }
  
block_variable_type ::= variable_identifier { dimension }
block_real_type ::=     real_identifier     { dimension }


    These notations are not part of the proposal and should not
    be included in the updated section A.2.8.

    Note: Syntax items that appear in "quotes" should be
    interpreted as being in BOLD font.

    These same updates should also be made to the following
    syntax boxes which appear within IEEE 1364-2001:

    1. Section 2.8.2, Syntax 2-7: The rule for "block_item_declaration"
    should be updated as proposed above.

    2. Section 9.8.1, Syntax 9-13: The rule for "block_item_declaration"
    should be updated as proposed above.

    3. Section 9.8.2, Syntax 9-14: The rule for "block_item_declaration"
    should be updated as proposed above.

    4. Section 10.2.1, Syntax 10-1: The rules for "block_item_declaration",
    "block_reg_declaration", "list_of_block_variable_identifiers",
    and "block_variable_type" should all be replaced with the
    entire set of proposed rules above.

    5. Section 10.3.1, Syntax 10-3: The rules for "block_item_declaration"
    "block_reg_declaration", "list_of_block_variable_identifiers",
    and "block_variable_type" should all be replaced with the
    entire set of proposed rules above.

    34 2001b: 17.2.3
    		17.2.3: "Formatting data to a string"

    A. In 17.2.3, in Syntax 17-6, in the first production, change

    "string_output_tasks_name"

    to

    "string_output_task_name"

    ************************************************************
    Shalom's additions:

    B. In the last line of Syntax 17-6, CHANGE

    $sformat (output_reg ,format ,list_of_arguments );

    TO

    $sformat (output_reg ,format_string ,list_of_arguments );

    **

    C. Following Syntax 17-6, DELETE the following lines:

    "The syntax for the string output system tasks is

    $swrite (output_reg , list_of_arguments );
    $sformat (output_reg , format_string , list_of_arguments );
    length = $sformat (output_reg , format_string , list_of_arguments );"

    **

    D. Delete the following paragraph (which appears two
    paragraphs after the preceding), as it also appears at the
    end of 17.2.3:

    "The variable output_reg is assigned using the Verilog's
    string assignment to variable rules,as specified in 4.2.3."

    **

    E. CHANGE the last paragraph of 17.2.3 FROM

    "The variable output_reg is assigned using the Verilog's
    string assignment to variable rules, as specified in 4.2.3."

    TO

    "The variable output_reg is assigned using the
    string assignment to variable rules, as specified in 4.2.3."

    ************************************************************
    64 2001b: 9.3 (Syntax 9-3), A.6.2, A.6.3
    		A.6.2-3: variable_assignment BNF production is in wrong place

    Move variable_assignment from A.6.3 to A.6.2.

    Remove reference to A.6.3 from Syntax 9-3 (9.3).
    65 2001b: A.2.7, 10.2.1 (Syntax 10-1)
    		error in task_declaration syntax


    Modified by Shalom:

    In Syntax 10-1 of 10.2.1 and in A.2.7,
    change each of the four occurrences of

    "statement"

    to

    "statement_or_null"

    Note that this change applies ONLY to tasks and NOT to
    functions, because functions MUST contain at least one
    statement, an assignment to the function output.
    67 2001b: A.6.5
    		A.6.5: "event_trigger" production in BNF does not allow array indexing


    CHANGE

    event_trigger ::=
    -> hierarchical_event_identifier ;

    TO

    event_trigger ::=
    "->" hierarchical_event_identifier {"[" expression "]"} ";"

    in A.6.5 and Syntax 9-10.

    70 2001b: 4.4.1 (Table 29)
    		Table 29: Logical operator (&& ||) sizing rules incorrect

    The (&&, ||) operators should be removed from the 5th row,
    and a new row should be inserted for them stating that their
    operands are "self-determined" in the "Comments" column.

    The modified 5th row, and the new row should look like the
    following: 

    +-----------------------------+------------+--------------------------+
| Expression                  | Bit Length | Comments                 |
+-----------------------------+------------+--------------------------+
| i op j, where op is         |   1        | operands are sized to    |
|   === !== == != > >= < <=   |            | max(L(i), L(j)           |
+-----------------------------+------------+--------------------------+
| i op j, where op is         |   1        | All operands are         |
|   && ||                     |            | self-determined          |
+-----------------------------+------------+--------------------------+

    75 2001b: 6 (Table 30), 9.2
    		Table 30 omits nested concatenations

    1. In Table 30, CHANGE last lines in right-hand column of both
    rows to say,

    "Concatenation or nested concatenation of any of the above LHS".


    2. Also, MOVE line

    "Memory word"

    after line

    "Indexed part select of a vector reg, integer, or time variable".


    3. In 9.2, para. 2, dashed item 5, CHANGE from:

    "Concatenation of any of the above:
    a concatenation of any of the
    previous four forms can be specified, which effectively
    partitions the result of the right-hand side expression and
    assigns the partition parts, in order, to the various parts
    of the concatenation."

    TO:

    "Concatenation or nested concatenation of any of the above:
    a concatenation or nested concatenation of any of the
    previous four forms can be specified, which effectively
    partitions the result of the right-hand side expression and
    assigns the partition parts, in order, to the various parts
    of the concatenation or nested concatenation."


    4. Widen right-hand column of table to be large enough to
    prevent line wraps.

    76 2001b: 4.1.14
    		4.1.14: unclear examples of illegal concatenations

    In 4.1.14,

    CHANGE FROM:

    Another form of concatenation is the replication operation.
    The first expression shall be a non-zero, non-X and non-Z
    constant expression, the second expression follows the rules
    for concatenations. This example replicates "w" 4 times.

    {4{w}} // This is equivalent to {w, w, w, w}
    a[31:0] = {1'b1, {0{1'b0}} }; //illegal. RHS becomes {1'b1,;
    a[31:0] = {1'b1, {1'bz{1'b0}} }; //illegal. RHS becomes {1'b1,;
    a[31:0] = {1'b1, {1'bx{1'b0}} }; //illegal. RHS becomes {1'b1,;


    TO:


    Another form of concatenation is the replication operation.
    The first expression shall be a positive, non-X and non-Z
    constant expression, the second expression follows the rules
    for concatenations.

    The following example replicates "w" 4 times. 

    {4{w}} // This is equivalent to {w, w, w, w}


    The following examples show illegal concatenations. 

    {   0{1'b0}}  //illegal 
{1'bz{1'b0}}  //illegal 
{1'bx{1'b0}}  //illegal

    77 2001b: 6 (Table 30)
    		Table 30: Last LHS line is not clear

    ************************************************************
    Shalom: 2002-01-07

    Propose to close this issue as being supreceded by # 75.
    78 2001b: passim
    		passim: Inconsistent spelling of "bit-select" and "part-select"

    Change all "bit select" to "bit-select".
    Change all "part select" to "part-select".

    Change all "bit and part selects" and "bit- and part-selects"
    to "bit-selects and part-selects".

    Change all "bit or part selects" and "bit- or part-selects"
    to "bit-selects or part-selects".

    Change all "bit or part select" and "bit- or part-select"
    to "bit-select or part-select".
    85 2001b: 9.7 (Syntax 9-8), A.6.5
    		A.6.5: repeat event_control grammar ambiguity

    In A.6.5, after event_expression add the following
    new nonterminal and definition --

    procedural_timing_control ::=
    delay_control
    | event_control

    and change the definition of
    procedural_timing_control_statement from 

       procedural_timing_control_statement ::=
         delay_or_event_control   statement_or_null


    to 

       procedural_timing_control_statement ::=
         procedural_timing_control   statement_or_null



    And in Syntax 9-8 (9.7),

    DELETE: delay_or_event_control
    event_expression

    ADD at the top the new definitions of
    procedural_timing_control_statement and
    procedural_timing_control.
    87 2001b: 17.2.8
    		17.2.8: $readmem default start_addr should be lowest address


    Changes based on
    http://boydtechinc.com/btf/archive/btf_1998/0395.html

    1. CHANGE 1st sentence in para. 7 FROM:

    If no addressing information is specified within the system
    task, and no address specifications appear within the data
    file, then the default start address shall be the left-hand
    address given in the declaration of the memory.

    TO:

    If no addressing information is specified within the system
    task and no address specifications appear within the data
    file, then the default start address shall be the lowest
    address in the memory.


    2. CHANGE 3rd sentence FROM:

    If the start address is specified in the task without the
    finish address, then loading shall start at the specified
    start address and shall continue towards the right-hand
    address given in the declaration of the memory.

    TO:

    If the start address is specified in the task without the
    finish address, then loading shall start at the specified
    start address and shall continue upward towards the highest
    address in the memory.


    3. CHANGE para. 8 FROM:

    If both start and finish addresses are specified as
    parameters to the task, then loading shall begin at the
    start address and shall continue toward the finish address,
    regardless of how the addresses are specified in the memory
    declaration.

    TO:

    If both start and finish addresses are specified as
    parameters to the task, then loading shall begin at the
    start address and shall continue toward the finish address.
    Note that if the start address is greater than the finish
    address, then the address will be decremented between
    consecutive loads rather than being incremented. Loading
    shall continue to follow this direction even after an
    address specification in the data file.


    4. CHANGE para. 10 FROM:

    A warning message shall be issued if the number of data
    words in the file differs from the number of words in the
    range implied by the start through finish addresses.

    TO:

    A warning message shall be issued if the number of data
    words in the file differs from the number of words in the
    range implied by the start through finish addresses and no
    address specifications appear within the data file.

    89 2001b: 2.8.1
    		2.8.1: Multiple Attribute Instances in BNF

    Multiple attribute instances are OK.
    Nested attributes are the subject of issue #218.

    Change one of the example to show multiple instances:

    In 2.8.1, Example 1 contains three examples of full_case, parallel_case:

    (* full_case, parallel_case *)
    (* full_case=1, parallel_case=1 *)
    (* full_case, // no value assigned
    parallel_case=1 *)

    CHANGE the second from:

    (* full_case=1, parallel_case=1 *)

    TO:

    (* full_case=1 *) (* parallel_case=1 *) // Multiple attribute instances also OK

    (including the comment)
    92 2001b: 17.10.2
    		17.10.2 should talk about leading plus sign

    Add the following sentence after the second sentence of the
    first paragraph of section 17.10.2:

    "This string should not include the leading plus sign of
    the command line argument."

    ************************************************************
    Shalom:

    1. That should be:

    "This string shall not ..." instead of "should not".

    Also:

    2. In para. 2,

    CHANGE: "as well as a leading 0 forms"
    TO : "as well as leading 0 forms".


    3. In para. 3, end of line 3,

    CHANGE: "users plusarg_string"
    TO : "user's plusarg string".


    4. In para. 4, end of line 1,

    CHANGE: "zero (0) padded"
    TO: "zero-padded".

    ************************************************************
    Shalom (added 2003-01-06):

    CHANGE THE 3rd and 4th sentences in the first paragraph
    FROM:

    "If the string is found, the remainder of the string is
    converted to the type specified in the user_string and the
    resulting value stored in the variable provided. If a string
    is found, the function returns a non-zero integer."

    TO (incorporating wording from 17.10.1):

    "The plusargs present on the command line are searched in
    the order provided. If the prefix of one of the supplied
    plusargs matches all characters in the provided string,
    the function returns a non-zero integer,
    the remainder of the string is
    converted to the type specified in the user_string and the
    resulting value is stored in the variable provided."

    ************************************************************

    103 2001b: Index
    		Index missing

    Return Index.

    Work together with IEEE Editor.

    Index must refer to Subclause #, not page #.

    Note: there may not be time to add index references to text
    added in 2001c.
    109 2001b: 10.3.5
    		10.3.5: redundant restriction on system functions

    In 10.3.5, in the 2nd constraint, delete the sentence "System functions shall not be invoked."
    115 2001b: 9.8
    		9.8: "block statement" definition

    In the first sentence of 9.8, delete

    "two or more"
    119 2001b: 2.6.3 (Table 1), 17.1.1.1 (Table 66)
    		2.6.3 (Table 1): Octal escape sequences

    In Table 1 of section 2.6.3


    REPLACE:

    A character specified in 1-3 octal digits (0<= d <= 7)

    WITH:

    A character specified in 1-3 octal digits (0 <= d <= 7).
    If less than three characters are used, the following
    character must not be an octal digit. Implementations
    may issue an error if the character represented is
    greater than \199.

    ***********************
    Shalom's addition:

    Same change in Table 66 in 17.1.1.1
    ***********************

    123 2001b: A.8.4, 4.3 (Syntax 4-2)
    		identifier and indexing syntax

    In 181, we passed a change to replace the existing
    alternatives of hierarchical_identifier in the primary
    production with the following:

    hierarchical_identifier [ { '[' expression ']' } '[' range_expression ']' ]

    If this change is accepted,
    then presumably the same change should be made to
    net_lvalue and variable_lvalue modifying the already
    passed fixes to 53.

    CHANGE from (after the fixes in #53):

    net_lvalue ::=
    hierarchical_net_identifier {'['constant_expression']'}
    ['['constant_range_expression']']
    | '{' net_lvalue { ',' net_lvalue } '}'

    variable_lvalue ::=
    hierarchical_variable_identifier {'['expression']'}
    ['['range_expression']']
    | '{' variable_lvalue { ',' variable_lvalue } '}'


    TO:


    net_lvalue ::=
    hierarchical_net_identifier [{'['constant_expression']'}
    '['constant_range_expression']']
    | '{' net_lvalue { ',' net_lvalue } '}'

    variable_lvalue ::=
    hierarchical_variable_identifier [{'['expression']'}
    '['range_expression']']
    | '{' variable_lvalue { ',' variable_lvalue } '}'

    ************************************************************
    129 2001a,b: passim
    		unordered list dashes (em dash) did not print in 2001a

    Make sure all dashed lists come out in PDF.

    Find dashed lists which still did not come out in 2001b,
    and fix them as well.

    ************************************************************
    Update by Shalom:

    See issue #169.

    Apparently problem occurred with TimesNewRoman fonts.
    The "em dashes" did not print in IEEE.
    When these are converted to Times font, which appears
    almost identical, it comes out OK.

    On my Unix FrameMaker, TimesNewRoman gets converted to
    Times anyway, so it still comes out OK.

    However, in 2001b, IEEE did not fix all the places.

    In particular, some of the NOTEs are still in TimesNewRoman,
    so they did not come out even in 2001b.

    The solution is to convert all paragraphs with "em dashes"
    in TimesNewRoman to Times.

    ************************************************************

    133 2001b: 4.1.2
    		Table 12: Precedence rules for operators

    Change subclause name
    FROM: "Binary operator precedence"
    TO : "Operator precedence".


    Change the first paragraph
    FROM:
    "The precedence order of binary operators and the
    conditional operator (?:) is shown in Table 12.
    The Verilog HDL has two equality operators.
    They are discussed in 4.1.8."

    TO:
    "The precedence order of the Verilog operators
    is shown in Table 12."


    Change Table 12 as follows:

    Change top row
    FROM: "+ - ! ~ (unary)"
    TO : "Unary + - ! ~ & ~& | ~| ^ ~^ ^~"

    Change rows 8-10
    FROM:
    & ~&
    ^ ^~ ~^
    | ~|

    TO:
    & (binary)
    ^ ^~ ~^ (binary)
    | (binary)

    In last row (conditional operator), delete "Lowest precedence".

    Add new row at bottom: "{} {{}} Lowest precedence".

    REMOVE: last line of Table-10 and last line of Table-9
    and Section 4.1.15
    136 2001b: 12.4 (Syntax 12-7), 13.2.1 (Syntax 13-2), 13.3.1.5 (Syntax 13-8), A.1.1, A.1.2, A.9.4
    		Annex A et al: BNF: redundant [] around {}

    Remove redundant square brackets as follows:

    1. In Syntax 13-2 (13.2.1) and A.1.1, CHANGE: 

    library_declaration ::= 
library library_identifier file_path_spec [ { , file_path_spec } ]
    [ -incdir file_path_spec [ { , file_path_spec } ] ;  

TO:

library_declaration ::= 
library library_identifier file_path_spec { , file_path_spec }
    [ -incdir file_path_spec { , file_path_spec } ] ;


    Note that a right square bracket was missing at the end to
    close the -incdir option. Now it is there.


    2. In Syntax 13-8 (13.3.1.5) and A.1.2, CHANGE: 

    liblist_clause ::= liblist [{library_identifier}]  

TO:

liblist_clause ::= liblist { library_identifier }



    3. In Syntax 12-7 (12.4), CHANGE:
    (Note: it is already correct in A.9.3) 

    escaped_hierarchical_identifier ::= (From Annex A - A.9.3)
  escaped_hierarchical_branch 
    [ { .simple_hierarchical_branch | .escaped_hierarchical_branch } ]

TO:

escaped_hierarchical_identifier ::= (From Annex A - A.9.3)
  escaped_hierarchical_branch 
    { .simple_hierarchical_branch | .escaped_hierarchical_branch }



    4. In Syntax 12-7 (12.4) and A.9.4, CHANGE: 

    simple_hierarchical_branch ::=  
          simple_identifier [ [ unsigned_number ] ]  
                [ { .simple_identifier [ [ unsigned_number ] ] } ]  

escaped_hierarchical_branch ::=  
          escaped_identifier [ [ unsigned_number ] ]  
                [ { .escaped_identifier [ [ unsigned_number ] ] } ]  

TO:

simple_hierarchical_branch ::=  
          simple_identifier  [ [ unsigned_number ] ]  
                { .simple_identifier  [ [ unsigned_number ] ] }

escaped_hierarchical_branch ::=  
          escaped_identifier [ [ unsigned_number ] ]  
                { .escaped_identifier [ [ unsigned_number ] ] }

    137 2001b
    		Fwd: IEEE Std 1364-2001, 19.2 and Annex B -- 'none' keyword

    Propose that this is not a bug and that we close the
    issue.
    138 2001b
    		IEEE Std 1364-2001, Syntax 19-2 -- formal_argument_identifier

    Propose this issue be closed as the issue raised here
    is also raised in issue #139, along with a few other
    issues in the same section.
    140 2001b
    		Section 4.1.5: Definition of power operator result type

    Part I:

    REPLACE (3rd paragraph of 4.1.5):
    The result of the power operator shall be real if either operand is a
    real, integer or signed. If both operands are unsigned then the
    result shall be unsigned. The result of the power operator is
    unspecified if the first operand is zero and the second operand is
    non-positive, or if the first operand is negative and the second
    operand is not an integral value.

    WITH (new 3rd and 4th paragraphs of 4.1.5):
    If either operand of the power operator is real, then the result type
    shall be real. The result value is undefined if the first operand
    is zero and the second operand is non-positive, or if the first operand
    is negative and the second operand is not an integral value.

    If neither operand of the power operator is real, then the result type
    shall be determined as outlined in 4.4.1 and 4.5.1, with the second
    operand treated as self-determined. In this case, the power operator
    shall always interpret the second operand as an unsigned value, and the
    result value shall be 1 if both operands are zero.

    ------------------------------------------------------------------------

    Part II:

    REPLACE (Title of Table 15 in 4.1.5):
    Examples of modulus operators

    WITH (new Title of Table 15 in 4.1.5):
    Examples of modulus and power operators

    ------------------------------------------------------------------------

    Part III:

    REPLACE (The sentence immediately prior to Table 15):
    Table 15 gives examples of modulus operations.

    WITH
    Table 15 gives examples of some modulus and power operations.

    ------------------------------------------------------------------------

    Part IV:

    REPLACE (heading of first column in Table 15):
    Modulus expression

    WITH (new heading of first column in Table 15):
    Expression

    ------------------------------------------------------------------------

    Part V:

    Append the following power operator examples to Table 15: 

       Expression         Result       Comments
   3**2               9            3*3
   2**3               8            2*2*2, same result as 1<<3
   2**0               1            By definition, and same result as 1<<0
   2**-3'sb1          128          -3'sb1 treated as unsigned 7, same as 1<<-3'sb1
   2.0**-3'sb1        0.5          -3'sb1 coerced to -1.0, giving real reciprocal
   0.0**-1            Undefined    Division by zero is undefined
   9**0.5             3.0          Real square root
   9.0**(1/2)         1.0          Integer division truncates exponent to zero
   -9.0**0.5          Undefined    Square root of negative number is undefined
   -3.0**2.0          9.0          Defined, because real 2.0 is still integral value
   2**(-3'so4/3'so2)  64           Exponent is -3'so2, but is interpreted as 3'o6
    145 2001b: 19.2 (Syntax 19-1)
    		19.2: Syntax 19-1 defines net_type differently than A.2.2.1

    In Syntax 19-1 of section 19.2 change both occurrences of

    "net_type"

    to

    "default_nettype_value"



    146 2001b: 3.9
    		3.9: poor cross-reference to $time section


    Change 17 to 17.7.1

    149 2001b: 2.7.4
    		2.7.4: System tasks and functions

    Proposal:

    1) Change the first bullet following paragraph 3 of
    section/clause 2.7.4:

    REPLACE:
    - A standard set of $identifier system tasks and
    functions, as defined in Clauses 17 and 19.

    WITH:
    - A standard set of $identifier system tasks and
    functions, as defined in Clauses 17 and 18.

    ************************************************************
    Shalom: The above was already handled in issue #27.
    ************************************************************

    2) Change the second sentence of paragraph 4 of
    section/clause 2.7.4:

    REPLACE:
    The system tasks and functions described in
    Clause 17 are part of this standard.

    WITH:
    The system tasks and functions described in
    Clauses 17 and 18 are part of this standard.
    153 2001b: 12.3.3 (Syntax 12-6), A.2.1.2
    		12.3.3, A.2.1.2: output_declaration is ambiguous

    Brad's proposal looks good:

    Delete the 2nd and 4th alternatives of the output_declaration BNF rule
    of section A.2.1.2.

    REPLACE:
    output_declaration ::=
    "output" [ net_type ] [ "signed" ] [ range ] list_of_port_identifiers
    | "output" [ "reg" ] [ "signed" ] [ range ] list_of_port_identifiers
    | "output" "reg" [ "signed" ] [ range ] list_of_variable_port_identifiers
    | "output" [ output_variable_type ] list_of_port_identifiers
    | "output" output_variable_type list_of_variable_port_identifiers

    WITH:
    output_declaration ::=
    "output" [ net_type ] [ "signed" ] [ range ] list_of_port_identifiers
    | "output" "reg" [ "signed" ] [ range ] list_of_variable_port_identifiers
    | "output" output_variable_type list_of_variable_port_identifiers

    Note: Quoted items should be interpreted as being in BOLD font.
    154 2001b: 2.8.2 (Syntax 2-6), 12.1 (Syntax 12-1), 12.1.3 (Syntax 12-3), A.1.5
    		A.1.5: attribute ambiguity in non_port_module_items

    REPLACE the following two BNF rules of section A.1.5
    (Also in Syntax 2-6 (2.8.2), Syntax 12-1 (12.1),
    and Syntax 12-3 (12.1.3):

    module_item ::=
    module_or_generate_item
    | port_declaration ";"
    | { attribute_instance } generated_instantiation
    | { attribute_instance } local_parameter_declaration
    | { attribute_instance } parameter_declaration
    | { attribute_instance } specify_block
    | { attribute_instance } specparam_declaration

    non_port_module_item ::=
    { attribute_instance } generated_instantiation
    | { attribute_instance } local_parameter_declaration
    | { attribute_instance } module_or_generate_item
    | { attribute_instance } parameter_declaration
    | { attribute_instance } specify_block
    | { attribute_instance } specparam_declaration

    WITH:
    module_item ::=
    | port_declaration ";"
    | non_port_module_item

    non_port_module_item ::=
    module_or_generate_item
    | { attribute_instance } generated_instantiation
    | { attribute_instance } local_parameter_declaration
    | { attribute_instance } parameter_declaration
    | { attribute_instance } specify_block
    | { attribute_instance } specparam_declaration


    NOTE: Items enclosed in "" should be interpreted as being in BOLD font.
    156 2001b: 10.3.1, A.2.6
    		10.3.1,A.2.6:In function, block_item_declaration is optional

    In Syntax 10-3 (10.3.1) and in A.2.6,
    in BNF of function_declaration with function_port_list,

    CHANGE:

    "block_item_declaration { block_item_declaration }"

    TO:

    "{ block_item_declaration }".
    160 2001a,b
    		PDF bookmarks


    Make PDF bookmarks for all levels of
    sub-clauses in all clauses.

    161 2001a,b: passim
    		hyperlink cross-references


    1. Fix all unresolved cross-references.

    2. Find (as much as possible) and fix references which are
    just text and change them into FrameMaker cross-references
    with hyperlinks.

    166 2001b: 1.4
    		1.4: "Clause 2" missing clause title


    In 1.4, change Clause 2 reference to:

    "Clause 2--Lexical conventions: This clause
    describes the lexical tokens used in Verilog HDL source
    text and their conventions. It describes how to specify
    and interpret the lexical tokens."

    168 2001b: 12.3.2
    		12.3.2: Bad grammar

    In the last sentence in section 12.3.2, change

    "Use of named port connections shall not be
    used for..."

    to

    "Named port connections shall not be used for ..."


    and in the first sentence in the same paragraph
    add commas to

    "The first type of module port with only a
    port_expression is an implicit port."

    as follows:

    "The first type of module port, with only a
    port_expression, is an implicit port."
    173 2001b: 1.4, 2.5.1, 3.1, 7.10.1, 7.10.2, passim
    		misc typos

    The first typo on Clause 2 is covered by issue 166, so
    I deleted it from this proposal--Karen 2/10/03
    *******************************************************

    Section 1.4: Paragraph beginning "Clause 21": The title should end with colon. Next sentence should begin on same line.

    **********************************************************
    This piece of the proposal is covered by 116, so I deleted
    it from this proposal--Karen 2/10/03
    **********************************************************

    Section 3.1: End of paragraph. Change ".." to "." .

    Section 7.10.1, last sentence: Change "pull 1" to "pull1" and change both occurrences of "strong 0" to "strong0", and change all three to bold Times, as shown at beginning of 7.9.
    ************************************************************
    Shalom: Note - the format of strength indications is
    inconsistent elsewhere as well.
    ************************************************************

    Section 7.10.2, 1st paragraph, 2nd bullet: In "strength1" and "strength0", change the "0" and "1" to Times font, not fixed font, as in bullets 3 and 4.

    Entire document: Change all Clause titles to Helvetica 14 point including the number.
    176 2001b, 12.1.3.2
    		12.1.3.2, Example 5: wrong generate name 

    In section 12.1.3.2 example 5: 

Change the for loop condition  on the first line after the 
generate <bold generate> from:

 (i=0; i<SIZE+1; i=i+1) to:
 (i=0; i<SIZE; i=i+1)  

On the next line in the comment change:

B1[i].N1[i]  to:
B1[i].N1

    179 2001b, 12.3.3
    		12.3.3 Port declarations

    Change the first sentence in 12.3.3

    "Each port_expression
    in the list of ports for the module declaration shall also be
    declared
    in the body of the module as one of the following port declarations:
    input, output, or inout (bidirectional)."

    to
    "Each port_identifier in a port_expression
    in the list of ports for the module declaration shall also be
    declared
    in the body of the module as one of the following port declarations:
    input, output, or inout (bidirectional)."
    181 2001b: 4.3 (Syntax 4-2), 9.2.1 (Syntax 9-1), 9.2.2 (Syntax 9-2), 9.2.3 (Syntax 9-3), A.8.4, A.8.5
    		4.3, 9.2.1-3, A.8.4-5: 12 productions better expressed with 3

    In A.8.4 and Syntax 4-2

    REPLACE:
    bnf production for primary

    WITH

    primary ::=
    number
    | hierarchical_identifier { [ expression ] } [ [ range_expression ] ]
    | concatenation
    | multiple_concatentation
    | function_call
    | system_function_call
    | constant_function_call
    | ( mintypmax_expression )
    182 2001b, 9.7 (Syntax 9-8), 9.7.7 (Syntax 9-12), A.6.5
    		Syntax 9-8: event_control

    In A.6.5 and Syntax 9-8 change

    event_control ::= @ event_identifier
    | @ ( event_expression )
    | @ *
    | @ ( * )

    event_expression ::= expression
    | hierarchical_identifier
    | posedge expression
    | negedge expression
    | event_expression or event_expression
    | event_expression , event_expression

    to

    event_control ::= @ hierarchical_event_identifier
    | @ ( event_expression )
    | @ *
    | @ ( * )

    event_expression ::= expression
    | posedge expression
    | negedge expression
    | event_expression or event_expression
    | event_expression , event_expression

    193 2001b: 3.2.1 (Syntax 3-1), 9.7.3 (Syntax 9-9), A.2.3
    		3.2.1, 9.7.3, A.2.3: simplification of list BNFs

    A. In Syntax 9-9 and A.2.3,

    CHANGE 

    list_of_event_identifiers ::= 
  event_identifier [ dimension { dimension }] 
    { , event_identifier [ dimension { dimension }] }


    TO 

    list_of_event_identifiers ::= 
  event_identifier { dimension }
    { , event_identifier { dimension } }



    B. In Syntax 3-1 and A.2.3,

    CHANGE 

    list_of_net_identifiers ::= 
  net_identifier [ dimension { dimension }] 
    { , net_identifier [ dimension { dimension }] }


    TO 

    list_of_net_identifiers ::= 
  net_identifier { dimension }
    { , net_identifier { dimension } }

    194 2001b: 2.8 (Syntax 2-3), A.9.1
    		2.8, A.9.1: simplify attr_spec BNF

    Change --

    attr_spec ::= attr_name = constant_expression
    | attr_name

    to

    attr_spec ::= attr_name [ = constant_expression ]

    196 2001b: 8.6 (Syntax 8-2)
    		8.6 -- udp_instantiation BNF different in 8.6 than in Annex A

    In Syntax 8-2, remove "[attribute_instance]"
    from udp_instantiation, making it the same
    as in Annex A.5.4.

    udp_instantiation ::= udp_identifier
    [ drive_strength ] [ delay2 ]
    udp_instance { , udp_instance } ';'

    200 2001b: 7.1 (Syntax 7-1), 8.6 (Syntax 8-2), 12.1.2 (Syntax 12-2), A.3.1, A.4.1, A.5.4, A.9.3
    		A.3.1, A.4.1, A.5.4, A.9.3 et al: extra [range]


    1. In A.9.3, CHANGE

    gate_instance_identifier ::= arrayed_identifier
    udp_instance_identifier ::= arrayed_identifier
    module_instance_identifier ::= arrayed_identifier

    TO

    gate_instance_identifier ::= identifier
    udp_instance_identifier ::= identifier
    module_instance_identifier ::= identifier

    2. In A.9.3, DELETE

    arrayed_identifier
    escaped_arrayed_identifier
    simple_arrayed_identifier

    3. NO CHANGE TO

    name_of_gate_instance ::= gate_instance_identifier [ range ]
    name_of_udp_instance ::= udp_instance_identifier [ range ]
    name_of_instance ::= module_instance_identifier [ range ]

    216 2001b: 9.5
    		9.5: when is case default executed

    After the sentence

    "The case item expressions shall be evaluated
    and compared in the exact order in which they
    are given."

    insert the following sentence

    "If there is a default case item, it is ignored
    during this linear search."


    218 2001b, 2.8
    		Nested attributes should be prohibited

    Append the following paragraph to the end
    of section 2.8 (before section 2.8.1) --

    "Nesting of attribute instances is disallowed.
    It shall be illegal to specify the value of
    an attribute with a constant expression that
    contains an attribute instance."
    219 2001b: 17.9.3
    		17.9.3: wrong bolding in C code

    In section 17.9.3 remove all bolding from the C code,
    in particular from each occurrence of 'if', 'else', 'end',
    'while', and 'for'.
    221 2001b
    		passim: right-hand and left-hand misspelled

    Throughout the document change "right hand" and "righthand"
    to "right-hand" and change "left hand" and "lefthand" to
    "left-hand". Specifically, in 3.11.1, 9.7.5, 12.1.3.2
    change "right hand" to "right-hand", in 3.3.1 change
    "righthand" to "right-hand", in 9.7.5, 16.6 change
    "left hand" to "left-hand". In C.2 change "lefthand"
    to "left-hand".
    224 2001b: 10.2 (Syntax 10-1), A.2.7
    		10.2, A.2.7: tf port declarations

    In A.2.7 and in Syntax 10-1 of 10.2, delete
    the square brackets from each occurrence of

    [ task_port_type ]

    228 2001b: 4.2.1
    		4.2.1: indexed part-select with width-expression of -5


    1. Legal values for the width expressions should be a
    semantic restriction. Specifically, after the sentence,
    "The width_expr shall be a constant expression.",
    add the following:

    "The value of the width_expr shall be a positive integer."


    2. Change the Examples preceding Example 1,
    from "reg [31:0] big_vect;" to
    "dword[8*sel +:8] = big_vect[7:0]; // Replace the byte selected."

    with the following: 

    reg [31: 0] big_vect;
reg [0 :31] little_vect;
reg [63: 0] dword;
integer sel;

big_vect[ 0 +: 8]    // == big_vect[ 7 : 0]
big_vect[15 -: 8]    // == big_vect[15 : 8]

little_vect[ 0 +: 8] // == little_vect[0 : 7]
little_vect[15 -: 8] // == little_vect[8 :15]

dword[8*sel +: 8]    // variable part-select with fixed width


    ("reg" and "integer" keywords in bold)

    229 2001b: 9.6 (Syntax 9-7), 9.8.1 (Syntax 9-13), A.6.3, A.6.8
    		A.6.3, A.6.8: some function_statement should be function_statement_or_null


    CHANGE "function_statement" to "function_statement_or_null"
    in following places:

    function_loop_statement (Syntax 9-7 (9.6), A.6.8)
    function_seq_block (Syntax 9-13 (9.8.1), A.6.3)

    231 2001b: A.6.2, A.6.4
    		A.6.2: function_statement_or_null should be in A.6.4


    Move function_statement_or_null from A.6.2 to A.6.4.

    232 2001b: 2.7.4 (Syntax 2-2), A.6.9
    		Syntax 2-2, A.6.9: system_task_enable with null arguments


    In Syntax 2-2 (2.7.4) and A.6.9, CHANGE

    system_task_enable ::=
    system_task_identifier [ ( expression { , expression } ) ] ;

    TO:

    system_task_enable ::=
    system_task_identifier [([expression] {,[expression]})] ;

    238 2001b: 12.1 (Syntax 12-1), 12.3.1 (Syntax 12-5), 14.2.2 (Syntax 14-3), A.1.4, A.7.3
    		A.1.4, A.7.3: Should range_expression be constant_range_expression? 

    REPLACE:

port_reference ::= (A.1.4, Syntax 12-1, 12-5)
  port_identifier 
| port_identifier [ constant_expression ] 
| port_identifier [ range_expression ] 

specify_input_terminal_descriptor ::= (A.7.3, Syntax 14-3)
  input_identifier 
| input_identifier [ constant_expression ] 
| input_identifier [ range_expression ]  

specify_output_terminal_descriptor ::= (A.7.3, Syntax 14-3)
  output_identifier 
| output_identifier [ constant_expression ] 
| output_identifier [ range_expression ]  

WITH:
              
port_reference ::= (A.1.4, Syntax 12-1, 12-5)
  port_identifier [ [ constant_range_expression ] ] 

specify_input_terminal_descriptor ::= (A.7.3, Syntax 14-3)
  input_identifier [ [ constant_range_expression ] ] 

specify_output_terminal_descriptor ::= (A.7.3, Syntax 14-3)
  output_identifier [ [ constant_range_expression ] ]

    243 2001b: 10.3.1
    		10.3.1: Call functions "reentrant", not "recursive"


    In 10.3.1, change

    "The keyword automatic declares a recursive function with
    all the function declarations allocated dynamically for
    each recursive call."

    TO:

    "The keyword automatic declares an automatic function that
    is reentrant with all the function declarations allocated
    dynamically for each concurrent function call."

    Hosted by Boyd Technology

    This archive was generated by hypermail 2.1.4 : Fri Mar 07 2003 - 23:09:25 PST and
    sponsored by Boyd Technology, Inc.