[sv-bc] SV-BC BNF issues review

Hello All,

I reviewed the changes for the issues that were assigned to me in the
last meeting.

Also found some additional issued regarding the BNF.

Thanks

Dan Jacobi

ID : 0000012

(Editorial) Footnote 29 : spacing between words in the first line
of the footnote does not match the rest of the footnotes

(the same is true for footnote 15)

ID : 0000020

In this case there was an errata in the proposal (that was fixed by Stu
in the LRM itself)

The original proposal read

In A.8.4, in primary_constant, ADD the following FOOTNOTE to
genvar_identifier

                A genvar_identifier shall be legal in a constant_primary
only within a genvar_expression.

It should have been

In A.8.4, in constant_primary, ADD the following FOOTNOTE to
genvar_identifier

                A genvar_identifier shall be legal in a constant_primary
only within a genvar_expression.

ID : 0000034

Mostly suppressed by proposal #322

ID : 0000091

See my comments for issue #322 regarding the $bits system function usage

ID : 0000164

No comments

ID : 0000322

1) The Following amendment is not complete

In A.1.1, DELETE

                file_path_spec ::= file_path

Although the file_path_spec toke is removed it is still used 3 times in
section A.1.1 Library sources text

When parsing the tokens library_declaration and include_statement . (The
BNF is broken)

2) the amendment

In Syntax 23-3, in size_function, as amended by erratum 91, REPLACE

                | $bits( ps_type_identifier )

                | $bits( integer_type )

WITH

                | $bits( ps_type_identifier )

                | $bits( integerdata_type )

Supersedes the amendment from proposal #91

size_function ::=

                $bits( expression )

| $bits( type_identifer )

WITH

                size_function ::=

                                $bits( expression )

                | $bits( ps_type_identifier )

                | $bits( integer_type )

In my opinion the amendment in proposal 91 is more specific and is does
not allow the usage of problematic data types as the argument to the
$bits system function such as $bits(chandle)

ID : 0000323

1) The following amendment is suppressed

"In A.1.5 and Syntax 17-17, REPLACE

                bind_directive ::= bind hierarchical_identifier
constant_select bind_instantiation ;

WITH

                bind_directive ::= bind hierarchical_identifier
constant_bit_select constant_select bind_instantiation ;

"

2) I'm not sure but do the new parsing rules of the select and
constant_select allow the parsing of multiple PART selects such as

reg array1[10:0][6:0][1:0];

...

If (array1[10:0][2:0] =array1[10:0][6:4]);

The new parsing rule: (note that the part_select_range can only appear
ONCE in the end of the expression)

            select ::= [ { . member_identifier bit_select } .
member_identifier ] bit_select { [ expression ] } [ [ part_select_range
] ]

Illegal use of the net_type_or_trireg token in the BNF - is the BNF
broken ?

The token net_type_or_trireg token was removed from section A.2.2.1 (Net
& Variable types) due to the fact that trireg is now parsed using the
token net_type.

(Or in other words there is no definition of the token
net_type_or_trireg)

However the token net_type_or_trireg is used in the following sections
of the BNF (and the corresponding text boxes):

Section A.2.1.3 (Type Declarations) when parsing the net_declaration
token

Footnote 32

One more friendly amendment

The example in the bottom of page 224 (chapter 17.3 Concurrent
assertions overview) is missing a semicolon after the statement
'pass_stat'

base_rule1: assert property (cont_prop(rst,in1,in2)) pass_stat else
fail_stat;

Should be:

base_rule1: assert property (cont_prop(rst,in1,in2)) pass_stat; else
fail_stat;

Dan Jacobi,

Intel Corporation
Received on Mon Jan 24 01:15:48 2005