Subject: Re: Simple edits for Voting
From: Dave Rich (David.Rich@synopsys.com)
Date: Thu Dec 19 2002 - 15:34:51 PST
Karen,
BC42-6, -7, -8 will be replaced as part of BC18i and h
Karen Pieper wrote:
> Hi, all,
>
> I've attached 22 issues that looked like they could be passed
> without any discussion. Please
> review them. Voting will close Friday 12/20/02 at 12 Noon PST (so I
> can get all the passed edits to
> Stu before Christmas.). If you have issues with any change, please
> note the issue number. Any
> issues discussed will be removed for later discussion by the entire
> committee. Anyone not voting
> will be assumed to approve the changes.
>
> Thanks all, and Happy Holidays!
>
> Karen
>
>------------------------------------------------------------------------
>
>Proposed simple modifications to close some open issues. Please be specific
>to on any issues that you wish to discuss, so that we can pass any that do
>not require any discussion. The vote will close 12 Noon PST Friday, December
>20, 2002. Any issues without discussion will be sent on to Stu for inclusion
>in the next version of the standard.
>
>Thanks,
>
>K
>
>SV-BC19-36: remove ;
>
> In A.6.8:
> REPLACE:
>
> variable_decl_or_assignment ::=
> data_type list_of_variable_identifiers_or_assignments ;
> | variable_assignment
>
> WITH:
> variable_decl_or_assignment ::=
> data_type list_of_variable_identifiers_or_assignments
> | variable_assignment
>
>SV-BC19-59:(B) keywords transition/endtransition not used
>
> In Annex B:
> REMOVE: transition and endtransition
>
>
>SV-BC22-2: Example issue
>
> In all examples in Section 13.4:
>
> ADD: () to the interface instantiations in each example (4 places).
>
>
>SV-BC27: Use interface_identifier rather than identifier
>
> In A.2.1.2:
> REPLACE:
> | identifier(BOLD) list_of_interface_identifiers
> | identifier(BOLD).modport_identifier list_of_interface_identifiers
>
> WITH:
> | interface_identifier(NOT BOLD) list_of_interface_identifiers
> | interface_identifier(NOT BOLD).modport_identifier list_of_interface_identifiers
>
>SV-BC28: A.2.9 modport_declaration bold modport
>
> In A.2.9
> REPLACE:
> modport_declaration ::= modport list_of_modport_identifiers;
> WITH:
> modport_declaration ::= modport(BOLD) list_of_modport_identifiers;
>
>SV-BC35: task port declarations in BNF
>
> In A.2.7
> REPLACE:
> task_item_declaration ::=
> block_item_declaration
> | {attribute_instance} input_declaration ;
> | {attribute_instance} output_declaration ;
> | {attribute_instance} inout_declaration ;
> WITH:
> task_item_declaration ::=
> block_item_declaration
> | {attribute_instance} tf_input_declaration ;
> | {attribute_instance} tf_output_declaration ;
> | {attribute_instance} tf_inout_declaration ;
>
>
>SV-BC42-4: change "may" to "can"
> SV 3.0 section 4.2, next to last paragraph, last sentence:
> Change "may" to "can".
>
>SV-BC42-6:
> SV 3.0 section 5.6, third paragraph, first sentence:
> Change "A logic variable can be written by one continuous assignment..."
> to "A logic variable can be written by one explicit continuous assignment
> using an assign statement...".
>
>SV-BC42-7:
> SV 3.0 section 5.6, third paragraph, last sentence:
> Change "The assign statement..." to "A procedural continuous assign
> statement (also called a quasi-continuous assign statement)...".
>
>SV-BC42-8:
> SV 3.0 section 5.6, fourth paragraph:
> Change "Note the difference between a net declaration with assignment
> and a variable initialization:" to "Note that the logic type cannot
> have an implicit continuous assignment as part of the declaration, the
> way a net data type can. An assignment as part of the logic declaration
> is a variable initialization, not a continuous assignment. For example:".
> This clarification came by way of a comment from a training class, where
> every single student was confused by the meaning of the original wording.
>
>SV-BC42-12:
> SV 3.0 section 8.9, third paragraph:
> Change signal name "clk" to "a".
>
>SV-BC42-14:
> SV 3.0 section 9.1, first paragraph:
> Change "always_ff" to bold keyword font
>
>SV-BC42-17:
> SV 3.0 section 9.3, last paragraph:
> "always_latch" should be in the bold keyword font.
>
>SV-BC42-18:
> SV 3.0 section 11.9, first bullet:
> Delete the first occurrence of the word "only".
>
>SV-BC42-20:
> SV 3.0 section 12.2, last bullet under "The $root top level":
> Change "shall" to "can". It is not mandatory that $root have procedural
> statements.
>
>SV-BC42-25:
> SV 3.0 section 12.7.5, first paragraph:
> Change "simulator is not required to report..." to "standard does not
> require..." (I assume this rule applies to more than just simulators).
>
>SV-BC42-26:
> SV 3.0 section 12.7.5, second paragraph:
> Change "SystemVerilog will run this simulation..." to "SystemVerilog
> shall..." (again, assuming this rule applies to more than just simulators).
>
>SV-BC42-27:
> SV 3.0 section 12.7.5, third paragraph:
> Change "Verilog run this simulation without warning..." to "shall now
> generate a warning..." (again, assuming this rule applies to more than
> just simulators).
>
>SV-BC42-28:
> SV 3.0 section 12.7.5, fourth paragraph:
> Change "Verilog simulators shall issue a warning..." to "shall result
> in a warning..." (again, assuming this rule applies to more than just
> simulators).
>
>SV-BC42-29:
> SV 3.0 section 13.1, fifth paragraph:
> Change "modelling" to "modeling".
>
>SV-BC42-34:
> SV 3.0 section A.6.2:
> The initial, always, always_comb, always_latch and always_ff keywords
> should be in bold.
>
>SV-BC42-35:
> SV 3.0 section A.6.4:
> The keyword "process" should be in bold.
>
>
>
> ------------------------------------------------------------------------
>
-- -- Dave Rich Principal Engineer, CAE, VTG Tel: 650-584-4026 Cell: 510-589-2625 DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Thu Dec 19 2002 - 15:36:41 PST