Re: [sv-bc] RE: Connecting generated interface instances

In the last PAR, I suggested having some discussion about
a different approach to talking about the intent of the
elaboration restrictions.  There was no interest in doing
so at the time.  Such a change would be very substantial
and would likely impact vendor flows in manners that
would cause difficulties in reaching consensus.  So
there would need to be agreement on the importance
of doing this and a very serious push to get the vendors
together and work out what the rules would need to be.
Even then, it isn't clear that we'd reach consensus and
end up with substantially compatible implementations.

Gord

On 2/24/15 5:37 AM, Bresticker, Shalom wrote:
>
> Greg wrote:
>
> 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.
>
> Actually, what I told the person who asked me the question is that he 
> could rewrite the code like this (his test case was a little more 
> complex than what I sent ):
>
> module test();
>
> generate
>
> for (genvar i=0; i<2; i++) begin : if_gen
>
> if1 #(.PARAM(i)) if1_inst ();
>
> if1_wrapper if1_wrapper_inst ( if1_inst);
>
>  if (i==0) module1 module1_inst1 ( .if1_wrapper_inst(if1_wrapper_inst));
>
> end
>
> endgenerate
>
> endmodule
>
> The “if (i==0)” works, but is ugly and rapidly becomes awkward for 
> more complex cases.
>
> More generally, one CAN make a problematic case, but there should not 
> be such a wide restriction that prevents the normal, useful cases due 
> to the possibility of writing a problematic corner case. There is 
> nothing inherently problematic in referencing an interface instance 
> through a generate block.
>
> Shalom
>
> *From:*Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
> *Sent:* Monday, February 23, 2015 23:51
> *To:* Steven Sharp; Mark Hartoog; Bresticker, Shalom; sv-bc@eda.org
> *Subject:* Re: [sv-bc] RE: Connecting generated interface instances
>
> 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:
>
> interfaceif1();
>
> endinterface
>
> modulemodule1(if1 if1_inst);
>
> endmodule
>
> moduletest();
>
> generate
>
> for(genvari=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.
>
>     *From:* owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org>
>     [mailto:owner-sv-bc@eda.org] *On Behalf Of *Mark Hartoog
>     *Sent:* Sunday, February 22, 2015 10:04 PM
>     *To:* Bresticker, Shalom; sv-bc@eda.org <mailto:sv-bc@eda.org>
>     *Subject:* [sv-bc] RE: Connecting generated interface instances
>
>     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
>
>     *From:*owner-sv-bc@eda.org
>     <mailto:owner-sv-bc@eda.org>[mailto:owner-sv-bc@eda.org] *On
>     Behalf Of *Bresticker, Shalom
>     *Sent:* Saturday, February 21, 2015 11:53 PM
>     *To:* sv-bc@eda.org <mailto:sv-bc@eda.org>
>     *Subject:* [sv-bc] RE: Connecting generated interface instances
>
>     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 ///////////////////////
>
>     interfaceif1();
>
>     endinterface
>
>     modulemodule1(if1 if1_inst);
>
>     endmodule
>
>     moduletest();
>
>     generate
>
>     for(genvari=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* <http://www.mailscanner.info/>, and is
> believed to be clean. 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Verification Technologies, Mentor Graphics        gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.