Re: [sv-bc] Errata. always_comb description and the BNF.

From: Brad Pierce <Brad.Pierce@synopsys.com>
Date: Mon Jun 28 2004 - 09:06:26 PDT

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