Re: [sv-bc] 9058: Specifying modport on array of interfaces; a Proposal

From: Surya Pratik Saha <spsaha_at_.....>
Date: Tue May 26 2009 - 21:25:52 PDT

Hi Greg,
I was the mailer of 9058 mail. The main question in that mail was - how an interface port array with a modport selection can be used as actual connection without interface port array selection. I don't think I got a proper answer then. The last sentence of Brad in his reply mail was very interesting -

"is there any reason to think that if one element had a modport "slave", then they all would?"

In general, to select some item of an array, [] operator to be used. But in the example <1>, "U1.x" is directly used, instead of "U1[1].x". Now "U1.x" is illegal because "U1" is an array. On the other side "U1[1].x" is illegal as actual expression, because formal port is another array.

You have tried to answer this thing, but it is not there in LRM yet. Also can we use same thing to assign virtual interface array.
For e.g
Can we write following snippet inside module "top" in the e.g. <1>?

virtual inf.x vim [2];
initial begin
    vim = U1.x;
end

The standard simulators giving different behaviors. I think there should be a mantis to fix it in LRM to avoid any confusion in future, or is there already? Until it is fixed, this type of usage should be stopped.

Regards
Surya

-------- Original Message  --------
Subject: Re:[sv-bc]  9058: Specifying modport on array of interfaces; a Proposal
From: Greg Jaxon <Greg.Jaxon@synopsys.com>
To: Bresticker, Shalom <shalom.bresticker@intel.com>
Cc: Anand Gurusamy <gurusamy@magma-da.com>, "sv-bc@server.eda.org" <sv-bc@eda.org>, Arun Maity <amaity@magma-da.com>, Girish Ravunnikutty <girishr@magma-da.com>, Kapil Kaushik <kkapil@magma-da.com>
Date: Tuesday, May 26, 2009 11:17:07 PM

Yes, I believe this is the same issue.
Both of Anand's example cases conform to BNFs that already exist in Annes A and elsewhere.
Either will work.  Furthermore, per section 25.5,

If a port connection specifies a modport list name in both the module instance and module header declara-
tion, then the two modport list names shall be identical. [emphasis added]

... so the two can be combined.   [One defect I notice in this section's prose is the unwarranted bias that
the "down design" to which the interface's modport connects is a "module", when it might also be another
interface.]

In 9058 and in the present case, some doubt exists because the prose never refers to the unpacked
dimension syntax; nor does it explain how the dimensions of an interface instance interact with
the modport access restrictions.  We've never formally introduced the concept of an "array of interface
modports", though the BNF suggests these exist.

The existing prose in section 25.5 was written in the spirit of examples being more definitive than the text,
but for the text to be entirely accurate in everything, it would become even more unreadable than it is already.
I'd recommend leaving it in its current "gentle tutorial" form and adding the array of modport concept in a
new subsection devoted to resolving the question that wasn't asked in either 9058 or this thread.

Add:

25.5.n  Modport and interface array expressions for use in port connections

The ports in a list_of_interface_identifiers have (possibly empty) sets of unpacked_dimensions; the corresponding  actual port expressions must have a matching set of unpacked_dimensions (or a matching lack thereof).  Both the modport specification and the unpacked dimensions are additional matching criteria to the interface named type used on this port connection.  The three properties (named type, modport, and dimensions) are completely orthogonal.  In an interface port actual expression, the optional .modport_identifier clause may appear as a subfield selection anywhere in the static prefix of the actual interface (see section 11.5.3).  It is an error for a modport selection to be applied to an interface type which does not declare that modport identifier, or to an interface type which already has a different modport identifier specified; redundantly specifying the same modport is not prohibited. 

Also add to Section 23.3.3.4 the following paragraphs:

If a port declaration with either a generic or a named interface type has a modport specification, it serves to either select or confirm the modports being connected.  If the actual port expression delivers an interface type without a particular modport specification, the formal modport identifier must exist within the actual interface type being connected, and only the connections it specifies shall be made between corresponding elements of the actual and formal ports.   If the actual port expression adds a modport specification, or refers to an interface type for which a modport has already been specified, it must match the declaration's modport, and again only the modport connections are made.
A modport specification may be given as a subfield selection anywhere within the static prefix of an interface port expression.

Greg Jaxon


Bresticker, Shalom wrote:

At first glance, I think this is the same issue from http://www.eda-stds.org/sv-bc/hm/9058.html ?

 

Shalom

---

From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Anand Gurusamy
Sent: Monday, May 25, 2009 3:04 PM
To: sv-bc@server.eda.org
Cc: Arun Maity; Girish Ravunnikutty; Kapil Kaushik
Subject: [sv-bc] Specifying modport on array of interfaces..

Hi there,

 

Here we are trying to use array of interfaces and specify modport.

In case-1, we instantiate array of interfaces in the submodule and specify the modport list name in the top level module

And in case-2, we instantiate the array of interface along with modport specified.

 

So, could you please clarify which one would be the correct way?  

 

Thanks and Regards,

-Anand

 

***********************************************

* CASE 1:

***********************************************

interface inf ();

 logic   din;

 logic   dout;

 

 modport x(output dout, input din);

 modport y(inout dout, inout din);

endinterface: inf

 

module sub(in, U1, out);

 input [1:0] in;

 output [1:0] out;

  

 inf U1 [2];

endmodule

 

module top(in, out);

 input      [1:0] in;

 output    [1:0] out;

 

 inf U1 [2] ();

 sub  inst_sub  (.U1(U1.x),.in(in), out(out));

endmodule

 

***********************************************

* CASE 2:

***********************************************

interface inf ();

 logic   din;

 logic   dout;

 

 modport x(output dout, input din);

 modport y(inout dout, inout din);

endinterface: inf

 

module sub(in, U1, out);

 input [1:0] in;

 output [1:0] out;

  

 inf.x U1[2];

endmodule

 

module top(in, out);

 input      [1:0] in;

 output    [1:0] out;

 

 inf U1 [2] ();

 sub  inst_sub  (.U1(U1), .in(in), out(out));

endmodule

 

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

---------------------------------------------------------------------
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. Received on Tue May 26 21:27:19 2009