[sv-bc] Re: [sv-ec] Doubt in external name generation for unnamed generate blocks

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Mon Mar 31 2008 - 07:33:14 PDT
Moumita, some of your examples appear incorrect in terms
of naming in general.  Let me answer your question in light
of a correct example.

    module top;
       parameter p = 1;
       if (p) begin
         wire x;
       end
       integer genblk1;
    endmodule

In this case the gen block name should be "genblk01".  The
existence of any name in the scope should be taken into
account.  Basically, the "external naming" of the blocks
should never interfere with an otherwise valid design.

Gord.


Moumita wrote:
> Hi,
> I have a doubt regrading External name generation for unnamed generate 
> blocks.
> In the LRM -IEEE Std 1364-2005 sec 12.4.3 says that "
> If such a name would conflict with an explicitly declared name, then
> leading zeroes are added in front of the number until the name does not 
> conflict."
> 
> So if we have a testcase-
> *module top;
> parameter genblk2 = 0;
> genvar i;
> if (genblk1) reg b; // top.genblk1.b
> if (genblk2) reg a;  // then  name should be top.genblk02.a as genblk2 
> exists before the generate block.
> endmodule*
> 
> But LRM does not say anything if name conflicts with any explicit 
> declared name
> which is declared later . For example-
> 
> *module top;
> parameter genblk2 = 0;
> genvar i;
> generate
> if (genblk1) reg b; // top.genblk1.b
> endgenerate
> integer  genblk1 //conflicts
> endmodule*
> 
> What will be the expected behavior?
> 
> Thanks and regards,
> Moumita
>  
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
--------------------------------------------------------------------
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.
Received on Mon Mar 31 07:35:14 2008

This archive was generated by hypermail 2.1.8 : Mon Mar 31 2008 - 07:35:53 PDT