BOUNCE etf@boyd.com: Non-member submission from [Dave Rich <David.Rich@synopsys.com>]

From: Stefen Boyd (stefen@boyd.com)
Date: Thu Jul 10 2003 - 22:48:46 PDT

  • Next message: Stefen Boyd: "Fwd: Re: [sv-bc] Re: implicit instantiation of top-level modules?"

    Precedence: bulk

    > >From owner-etf@boyd.com Wed Jul 9 10:36:05 2003
    >Received: from kiruna.synopsys.com (us01smtp2.synopsys.com [198.182.44.80])
    > by max.boyd.com (8.11.0/8.11.0) with ESMTP id h69Ha4q00808
    > for <etf@boyd.com>; Wed, 9 Jul 2003 10:36:05 -0700
    >Received: from crone.synopsys.com (crone.synopsys.com [146.225.7.23])
    > by kiruna.synopsys.com (Postfix) with ESMTP
    > id 9990EF737; Wed, 9 Jul 2003 10:35:49 -0700 (PDT)
    >Received: from synopsys.com (localhost [127.0.0.1])
    > by crone.synopsys.com (8.9.1/8.9.1) with ESMTP id KAA00011;
    > Wed, 9 Jul 2003 10:35:28 -0700 (PDT)
    >Message-ID: <3F0C5274.9010809@synopsys.com>
    >Date: Wed, 09 Jul 2003 10:35:48 -0700
    >From: Dave Rich <David.Rich@synopsys.com>
    >Organization: Synopsys VTG
    >User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
    >Gecko/20030312
    >X-Accept-Language: en-us, en
    >MIME-Version: 1.0
    >To: mac@verisity.com
    >Cc: Shalom Bresticker <Shalom.Bresticker@motorola.com>, sv-bc@eda.org,
    > etf@boyd.com
    >Subject: Re: [sv-bc] Re: implicit instantiation of top-level modules?
    >References:
    ><200307072349.h67NnaZJ009789@server.eda.org>
    ><5.1.0.14.2.20030708085821.00a8b9f0@pophost.synopsys.com>
    ><3F0B75CF.1020101@synopsys.com> <3F0BBD68.77AE7AE5@motorola.com>
    ><16140.15471.133845.747601@gargle.gargle.HOWL>
    >In-Reply-To: <16140.15471.133845.747601@gargle.gargle.HOWL>
    >Content-Type: text/plain; charset=us-ascii; format=flowed
    >Content-Transfer-Encoding: 7bit
    >
    >Must be a slow work week for you guys! :-)
    >
    >My interpretation of the sentence ( and I believe Verilog-XL, VCS, and
    >all other simulators is
    >
    >Top-level modules are modules that are included in the source text but
    >are not instantiated/ by any other module and are therefore implicitly
    >instantiated at the root level.
    >/
    >If I have the following description, how else would the simulator know
    >to create only one copy of r, not two.
    >-----------------
    >module top;
    >bot bot();
    >endmodule
    >
    >module bot;
    >reg r;
    >endmodule
    >------------------
    >
    >I believe the original question posed by the SV-BC has been answered
    >sufficiently, and we now have a mechanism to recursively define module
    >instances inside of nested module definitions.
    >
    >Dave
    >
    >
    >Michael McNamara wrote:
    >
    > >Shalom Bresticker writes:
    > > > Precedence: bulk
    > > >
    > > > Yes, and it does not say anything about implicit instantiation. It
    > > > talks about module names, not instance names.
    > > >
    > > > Similarly, 12.1.1 says, "Top-level modules are modules that are
    > > > included in the source text but are not instantiated."
    > > >
    > > > But the main place to look at is 12.5:
    > >
    > > > "The name of a module or module instance is sufficient to identify
    > > > the module and its location in the hierarchy. A lower-level module
    > > > can reference items in a module above it in the hierarchy.Variables
    > > > can be referenced if the name of the higher-level module or its
    > > > instance name is known."
    > > >
    > > > Now see the Example. In the example, there are two top-level
    > > > modules, a and d. Both a and d instantiate b, with instance names
    > > > a_b1 and d_b1 respectively.
    > > >
    > > > Module b instantiates c. c contains a reference to "b.i", where i
    > > > is an integer declared in module b. The example states that this
    > > > references both a.a_b1.i and d.d_b1.i by upwards name referencing.
    > > >
    > > > But note that b is explictly instantiated and it is not a top-level
    > > > module. Yet c can still refer to it by its module name even though
    > > > it is not the module instance name.
    > > >
    > > > I believe that the same mechanism is used for full hierarchical
    > > > names which start with the top-level module name. That is why it
    > > > works even though the top-level module is not instantiated.
    > > >
    > > > Shalom
    > >
    > >
    > >I believe Shalom is correct here, in stating that the top level
    > >modules are never instantiated.
    > >
    > >However, as I recall in VCS, we in truth created an instance of each
    > >top level module, with the instance name being the name of the module;
    > >then the code to implement things like $display("%m"); was very
    > >simple.
    > >
    > >However, one does need to pay attention to the ability to use a module
    > >name as an element in a hierarchial path.
    > >
    > > > Dave Rich wrote:
    > > >
    > > > > Actually, I did find the wording in section 12.4 of 1364-2001, second
    > > > > paragraph
    > > > >
    > > > > "At the top of the name hierarchy are the names of one or more root
    > > > > modules of which no instances have been
    > > > > created. This root or these parallel root modules make up one or more
    > > > > hierarchies in a design description or
    > > > > description."
    > > > >
    > > > > Karen Pieper wrote:
    > > > >
    > > > > > Verilog 2K does have implicit instantiation at the $root level
    > > > > > creating top-level modules. We believe
    > > > > > there must be language in the V2K spec indicating that the implicit
    > > > > > name for those modules is
    > > > > > the same as the module name. There is another issue that addresses
    > > > > > implicit instantiation of
    > > > > > modules declared within other modules.
    > > > > >
    > > > > > K
    > > > > >
    > > > > > At 01:12 PM 7/8/03 +0300, you wrote:
    > > > > >
    > > > > >> Regarding "11. Is there wording on the Verilog 2K spec for this?":
    > > > > >>
    > > > > >> I don't understand the question. The feature does not exist in
    > > > > >> 1364-2001, so
    > > > > >> there is no wording on it.
    > > > > >>
    > > > > >> Shalom
    > > > > >>
    > > > > >>
    > > > > >>
    > > > > >> "Karen L. Pieper" wrote:
    > > > > >>
    > > > > >> > Hi, all,
    > > > > >> >
    > > > > >> > The minutes for the 7/7/03 meeting have been posted to the sv-bc
    > > > > >> website.
    > > > > >> >
    > > > > >> > http://www.eda.org/sv-bc/minutes
    > > > > >> >
    > > > > >> > K
    > > >
    > > >
    > > > --
    > > > Shalom
    > Bresticker Shalom.Bresticker@motorola.com
    > > > Design & Reuse Methodology Tel: +972 9
    > 9522268
    > > > Motorola Semiconductor Israel, Ltd. Fax: +972 9
    > 9522890
    > > > POB 2208, Herzlia 46120, ISRAEL Cell: +972 50
    > 441478
    > > >
    > > >
    > >
    > >
    > >
    > >
    >
    >--
    >--
    >Dave Rich
    >Principal Engineer, CAE, VTG
    >Tel: 650-584-4026
    >Cell: 510-589-2625
    >DaveR@Synopsys.com

    This archive was generated by hypermail 2.1.4 : Thu Jul 10 2003 - 22:53:51 PDT and
    sponsored by Boyd Technology, Inc.