Subject: Re: [sv-bc] Re: implicit instantiation of top-level modules?
From: Michael McNamara (mac@verisity.com)
Date: Thu Jul 10 2003 - 10:11:26 PDT
Shalom Bresticker writes:
> Dave,
>
> You must be tired!
>
> You are taking the text and turning it on its head!
...
> On the contrary, 1364 goes out of its way to talk about the "module
> name OR the instance name". If instance names were sufficient,
> there would be no need to mention instance names as well.
>
> Note again that upwards name referencing allows you to reference
> the module name even though it is explicitly instanciated with
> different names. That reference to the module name is not
> referencing an additional, implicit instance with the same name as
> the module. On the contrary, it simultaneously references all the
> instances of that module together. That same mechanism allows
> referencing top-level modules with requiring an implicit instance
> with the same name as the module.
Actually, what this 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
This archive was generated by hypermail 2b28 : Thu Jul 10 2003 - 10:21:52 PDT