[sv-bc] RE: Connecting generated interface instances

This is one of many things about interfaces that the LRM leaves ambiguous.  The LRM does not say it is legal, but it does not say it is illegal either.  As you say, the LRM clearly does allow one to get the same information in other ways.  The chapter on interfaces tends to use examples to explain things.  It does not say anyplace what kinds of objects you can access through an interface port. There are examples of variables, nets, tasks, functions, clocking blocks and named typedefs. Other than those, it is very unclear. Sequences, properties, generate blocks, and parameters are all unclear.

I think we gave up trying to insist it was illegal some years ago because you already can legally access the same information other ways.

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Steven Sharp
Sent: Monday, February 23, 2015 10:53 AM
To: Mark Hartoog; Bresticker, Shalom; sv-bc@eda.org
Subject: [sv-bc] RE: Connecting generated interface instances

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 ///////////////////////

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<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

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