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

I am not sure why you would call this is a semantic restriction. The LRM
says:

"Statements in an always_comb */shall not/* include those that block, have
blocking timing or event controls, or fork...join statements."

and if I interpret it correctly, it is incorrect (syntactically) for always_comb block
to contain a sub-set of statements. AFAIK, semantics is about analysis on a syntactically correct program. If it's illegal to have some constructs within a block, I am wondering
how it can be treated as a semantic restriction. That said, I do understand that 1364 grammar is far from being ideal, and this restriction would require huge changes.

Thanks,
- Krishna.

Brad Pierce wrote:

>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 Tue Jun 29 23:15:36 2004