From: Stefen Boyd (stefen@boyd.com)
Date: Thu Jul 10 2003 - 22:51:48 PDT
Precedence: bulk
>Date: Thu, 10 Jul 2003 10:43:14 -0700
>From: owner-etf@boyd.com
>X-Authentication-Warning: max.boyd.com: majordomo set sender to
>owner-etf@boyd.com using -f
>To: owner-etf@boyd.com
>
>Subject: BOUNCE etf@boyd.com
>: Non-member submission from [Greg Jaxon <Greg.Jaxon@synopsys.com>]
>
> >From owner-etf@boyd.com Thu Jul 10 10:43:04 2003
>Received: from boden.synopsys.com (us01smtp1.synopsys.com [198.182.44.79])
> by max.boyd.com (8.11.0/8.11.0) with ESMTP id h6AHgwq10802
> for <etf@boyd.com>; Thu, 10 Jul 2003 10:43:04 -0700
>Received: from mother.synopsys.com (mother.synopsys.com [146.225.100.171])
> by boden.synopsys.com (Postfix) with ESMTP
> id 3BDB5DE2B; Thu, 10 Jul 2003 10:42:44 -0700 (PDT)
>Received: from Synopsys.com (localhost [127.0.0.1])
> by mother.synopsys.com (8.9.1/8.9.1) with ESMTP id KAA15591;
> Thu, 10 Jul 2003 10:42:26 -0700 (PDT)
>Message-ID: <3F0DA593.3020005@Synopsys.com>
>Date: Thu, 10 Jul 2003 10:42:43 -0700
>From: Greg Jaxon <Greg.Jaxon@synopsys.com>
>Organization: //Synopsys/ICBU/HDL Compiler
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a)
>Gecko/20021212
>X-Accept-Language: en-us, en
>MIME-Version: 1.0
>To: mac@verisity.com
>Cc: Shalom Bresticker <Shalom.Bresticker@motorola.com>,
> Dave Rich <David.Rich@synopsys.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>
><3F0C5274.9010809@synopsys.com> <3F0D2B87.13B5E355@motorola.com>
><16141.40510.337835.72428@gargle.gargle.HOWL>
>In-Reply-To: <16141.40510.337835.72428@gargle.gargle.HOWL>
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit
>
>Michael McNamara wrote:
>
> > [T]his allows is an additional fairly powerfull
> > capability: Easy reference to a sibling.
> >
> > Let us say you have a module, implementing a Flip Flop:
> >
> > module ff (input D, CLK, output reg Q, Q_)
> > always @(CLK) Q = D;
> > assign Q_ = ~Q;
> > endmodule
> >
> > Then say you want to reuse this module to define the JTAG
> > version. Using upward relative references you could:
> >
> > module jtag_ff(input D, CLK, JTAG_D, JTAG_C, output Q, Q_)
> > ff flip_flop (D, CLK, Q, Q_);
> > add_jtag jt (JTAG_D, JTAG_C);
> > endmodule
> >
> > module add_jtag(input JTAG_D, JTAG_C);
> > always @(JTAG_C) ff.Q = JTAG_D;
> > endmodule
> >
> > The difference here is that the add_jtag doesn't need to know the
> > instance name of the ff it is mucking with: the rules of 12.4 require
> > the simulator to find the nearest neighbor up the hierarchy that
> > instanticate an 'ff' module. It does not affect every 'ff' module,
> > just the first one found using the upwards relative refernecing rules
> > defined in 12.4.1
> >
> > -mac
>
>I could not find the 12.4 "nearest neighbor" prescription - which document
>are you citing? In 1364-2001 section 12.5 says:
>
>"It shall only search in higher enclosing modules for the name, not
>instances."
>
>I understand the use of upward references to module_names to be analogous to
>C++ class references: i.e. something you'd use only to reach static data,
>typedefs,
>local functions, or other entities shared by all instances of the module.
>
>Greg
--------------------
Stefen Boyd Boyd Technology, Inc.
stefen@BoydTechInc.com (408)739-BOYD
www.BoydTechInc.com (408)739-1402 (fax)
This archive was generated by hypermail 2.1.4
: Thu Jul 10 2003 - 22:54:21 PDT
and
sponsored by Boyd Technology, Inc.