We've been trying to avoid enforcing semantic restrictions
via the syntax description. This always_comb issue is
a good example of why. It wouldn't suffice to factor
statement_item. One kind of statement is a seq_block,
and these can include any of those kinds of statements
that are not allowed in always_comb. So we'd have to
split seq_block, too.
1364 went down this same kind of road with function_statement
and then backtracked. See
http://www.eda.org/sv/F2F_14_Nov_2003/BNF_status.pdf
-- Brad
-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of Krishna
Garlapati
Sent: Monday, June 28, 2004 2:42 AM
To: Sv-Bc
Subject: [sv-bc] Errata. always_comb description and the BNF.
Section 9.2 (page 96) of the System Verilog 3.1a LRM says:
"Statements in an always_comb shall not include those that block, have
blocking timing or event controls,
or fork...join statements."
However, the BNF seems to allow productions that reduce to event controls,
fork-join statements, wait
statements etc. Here is the BNF snippet:
always_construct ::= always_keyword statement
always_keyword ::= always | always_comb | always_latch | always_ff
statement ::= [ block_identifier : ] { attribute_instance } statement_item
statement_item ::=
| (other productions)
| par_block
| procedural_timing_control_statement
| wait_statement
| (other productions)
I think the production for statement_item should be split as into 2 parts
and the control jumps
to the appropriate rule depending on the context.
Thanks,
- Krishna.
Received on Mon Jun 28 09:06:29 2004
This archive was generated by hypermail 2.1.8 : Mon Jun 28 2004 - 09:06:37 PDT