Re: [sv-bc] Generate with multiple begins

From: Paul Graham <pgraham@oasys-ds.com>
Date: Mon Jan 10 2011 - 08:09:28 PST

Brad,

Gotcha! Vhdl-2008 now has generate-else clauses :-)

Paul
----- Original Message -----
From: "Brad Pierce" <brad_pierce@acm.org>
To: sv-bc@eda.org
Sent: Monday, January 10, 2011 11:00:35 AM
Subject: Re: [sv-bc] Generate with multiple begins

Verilog would have been wise to copy VHDL generate, but instead
Verilog went its own expansive way. Arguing from analogy with VHDL now
is not much of a guide. If it is to be a guide, then let's start by
prohibiting generate 'else' clauses.

-- Brad

On Mon, Jan 10, 2011 at 7:27 AM, Paul Graham <pgraham@oasys-ds.com> wrote:
> Nested concurrent begin/end blocks correspond syntactically to vhdl
> block statements, which can be nested.  Why should vhdl have a feature
> which is not permitted in systemverilog?  Singling out begin/end blocks
> to be unnestable when all other generate constructs are nestable is
> non-orthogonal.  Furthermore, sequential begin/end blocks are nestable,
> so why not concurrent ones?
>
> Finally, a user can get around the nesting restriction by writing dummy
> if-generate statements:
>
>    if (1) begin: b1
>        if (1) begin: b2
>           ...
>        end
>    end
>
> All these clues suggest that the rule disallowing nested concurrent
> begin/end blocks is a mistake.
>
> Paul
> ----- Original Message -----
> From: "Gordon Vreugdenhil" <gordonv@model.com>
> To: "Wilson Snyder" <wsnyder@wsnyder.org>
> Cc: "SV-BC" <sv-bc@eda.org>
> Sent: Monday, January 10, 2011 9:38:17 AM
> Subject: Re: [sv-bc] Generate with multiple begins
>
>
> This dates back to the 2001 LRM.  Originally "bare" generate blocks
> were legal but were made illegal in the 2005 LRM.  Since there
> was no technical reason to make them illegal and support for "bare"
> generate blocks is strictly a superset of the current language, most
> tools likely do accept them (either by default or with a switch) in
> order to accept legacy (and ongoing) use of such blocks in current designs.
>
> Gord.
>
>
> On 1/9/2011 6:24 PM, Wilson Snyder wrote:
>> Hello all,
>>
>> I have a user that sent me the following case which seems to
>> work on several simulators, but I don't see that nested
>> begin/ends are legal in generates according to the 2009
>> grammar.  Is this an oversight in the grammar, or intended
>> to fail?  Can someone clarify please?  Thanks!
>>
>>     module t;
>>        generate
>>           if (1) begin : g1
>>              begin : g2
>>                 initial $display("Hello");
>>              end
>>              begin : g3
>>                 initial $display("World");
>>              end
>>           end
>>        endgenerate
>>     endmodule
>>
>> My reading of the grammar is thus:
>>
>>    loop_generate_construct ::=
>>       FOR '(' ... ')' generate_block
>>
>>    generate_block ::=
>>       generate_item
>>       | [ generate_block_identifier ':' ] BEGIN [ ':' generate_block_identifier ]
>>       { generate_item }
>>       yEND [ ':' generate_block_identifier ]
>>
>>    generate_item ::=
>>       module_or_generate_item
>>       | interface_or_generate_item
>>       | checker_or_generate_item
>>
>>    None of these three _item's have a path back to
>>    generate_block without hitting another generate
>>    if/case/for.
>>
>> Looking at it from the bottom up, the only relevant rules which use the
>> begin/end keywords are seq_block and generate_block.
>>
>>     generate_block called from
>>       loop_generate_construct,
>>       if_generate_construct,
>>       case_generate_item
>>
>>     seq_block called from
>>       statement_item
>>
>> We're not in a statement, so begin must be preceeded by
>> loop/if/case; there's no direct path from generate_item
>> (etc).
>>
>> Thanks
>>
>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Jan 10 08:09:56 2011

This archive was generated by hypermail 2.1.8 : Mon Jan 10 2011 - 08:10:02 PST