Shalom,
Steve's and Mark's answers seem like partial justifications to
me.
They're right that this is a possible circularity; it must be
broken by a prohibition on some step of the cycle.
But there are several candidates here; the one that's poking me in
the eye is this:
module top;
test t(top.t.block.if1_inst);
endmodule
It galls me because the parser rules for "point of declaration"
for names in IEEE-1800 is such a mixture of C, C++, and things
never C'n before. The instance name "t" is accessible in its own
port list!? Was the prefix "
top." even necessary?
I think a more basic explanation for this prohibition has to do
with "generate unrolling" being a late elaboration "pass" coupled
with actual types of interface ports being specializing parameters
of their down design.
For starters 27.3 says "all expressions in generate schemes shall
be constant expressions, deterministic at elaboration time."
The definitive explanation for that seems to be 23.10.4.1 (which
disambiguates generate vs defparam).
Then 23.10.4.2 "Early resolution of hierarchical names" gives a
brain-twisting example that involves an ambiguous reference
m.n.p.
It is ambiguous because there is an apparent top module named
m,
and also a conditional generate block named
m. The
latter only obtains its definition is the "late" (generate
unrolling) stage of elaboration. In this case the standard saw fit
to impute the "earlier" meaning.
Now look again at your example, where I have cast a Shade of Grey
over the names that are "late" arrivals:
interface if1 ();
endinterface
module module1 (if1 if1_inst);
endmodule
module test();
generate
for (genvar i=0; i<2; i++) begin : if_gen
if1 if1_inst();
end
endgenerate
module1 module1_inst
(
.if1_inst(if_gen[0].if1_inst)
);
endmodule
I claim that pursuant to 23.10.4.1,
if_gen[0].if1_inst
is an undefined name.
It's absence makes it impossible to finish ("as much as possible
without elaborating generate constructs")
the hierarchy expansion of
test.
In step (c) of the elaboration order, we're told that "Each
generate construct encountered in step b) is revisited".
We are not told that any other hierarchical points must also be
revisited. Was that an oversight?
This leaves the question of whether hiding
module1_inst
inside a generate block would relieve the problem.
I think it could - your example isn't circular, after all.
And that raises the next question - about limits on circularity:
is generate even a necessary ingredient?
interface if1#(p = 1) ();
endinterface
module test(if1
if1_port);
localparam p =
if1_port.p;
if1#(p)
if1_inst();
endmodule
module top;
test
t(top.t.if1_inst);
endmodule
If instance's ports can refer into the hierarchy under the
instance, then circularity can run rampant.
If an adequate rule can be framed to require the actual instances
at interface ports be resolved
during 23.10.4.1(a), I think you'd break these cycles.
Shalom would then be able to make some (just not all )
hierarchical references to generated interfaces.
Greg
On 2/23/2015 12:52 PM, Steven Sharp wrote:
I don’t think
that it is actually legal to access a parameter value from
an interface port, though various tools may allow it. There
is a legal way you can get the same effect, so there is not
much point in disallowing it. You can definitely access a
type from an interface port, using an “interface based
typedef”. See clause 6.18. That mechanism combined with
$bits would allow you to smuggle a parameter value out
through an interface port.
The basic
reason is that modules can access parameters and types from
the interface connected to an interface port. When the high
conn of an interface port is a hierarchical reference, then
accessing the parameters from it is similar to a defparam.
Since the static hierarchy must be elaborated first and all
parameters evaluated before generate block unrolling starts,
a hierarchical reference through generate blocks can create
a situation where not all parameters can be evaluated.
Consider this
example:
interface
if1#(p = 1) ();
endinterface
module test(if1
if1_port);
localparam p
= if1_port.p;
if (p == 2)
begin : block
if1#(4)
if1_inst();
end
else begin :
block
if1#(2)
if1_inst();
end
endmodule
module top;
test
t(top.t.block.if1_inst);
endmodule
The
LRM says in 25.3,
“If
the actual of an interface port connection is a hierarchical
reference to an interface …, the hierarchical reference
shall refer to an interface instance and shall not resolve
through … a generate block.”
What
is the reason for this restriction ?
Example:
/////////////////////
Beginning of code ///////////////////////
interface if1 ();
endinterface
module module1 (if1 if1_inst);
endmodule
module test();
generate
for (genvar i=0; i<2; i++) begin : if_gen
if1 if1_inst();
end
endgenerate
module1 module1_inst
(
.if1_inst(if_gen[0].if1_inst)
);
endmodule
////////////////////////
End of code /////////////////////////
I
saw 2 major compilers reject this code due to the above
restriction.
Thanks,
Shalom
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential
material for
the sole use of the intended recipient(s). Any review or
distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
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.