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

From: Greg Jaxon <Greg.Jaxon_at_.....>
Date: Thu May 28 2009 - 18:24:08 PDT
Anand Gurusamy wrote:

Hi Greg,

 

Thanks for your inputs.

 

So, if we assume that both U1.x[0] and U1[0].x are legal, then can we select different modports for different instances of interface arrays, possibly do a  concatenation from the top level {U1[]0].x[0], U1[1].y}

 

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[0].x, U1[1].y}),.in(in), out(out));

endmodule

Concatentation require a much more comprehensive proposal than I've offered.
Since interface array dimensions are always unpacked, I think you'd want to use assignment pattern '{}
notation to do this anyway - establishing a bitstream order for interface arrays is probably
impractical.

If the simulator supports virtual interface arrays, I suppose the same result could be achieved
by assignments into one of those.  Within the synthesis subset I am familiar with, there are no
heterogeneous interface arrays (i.e. having distinct element types), but nothing about the proposal
is meant to impose a limit like that - I just wanted to put "modport selection" in its own
category as a kind of type-restriction operator that looks like subfield selection and works
itemwise on any interface or interface array type object.

I thought this was a current ballot issue, but it turns out not to be part of the forthcoming 2009
edition (as of now).   Since it won't be developed hastily, you're welcome to embellish it
as you see fit.

 

Also, if we use the modport name in the instance itself (like below), would referencing the interface array from top level is legal?  //like sub  inst_sub  (.U1({U1[0].x),.in(in), out(out));

 

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[0].x),.in(in), out(out));

endmodule

 

Yes, the proposal says that redundant modport selections are permitted and clashing modport selections are errors.
You might wish to have both sides of the connection contract specify the modport identifier as an added check.
I believe this is consistent with the current standard, and is not an extension.

Greg

Regards,

-Anand


From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
Sent: Tuesday, May 26, 2009 11:17 PM
To: Bresticker, Shalom
Cc: Anand Gurusamy; sv-bc@server.eda.org; Arun Maity; Girish Ravunnikutty; Kapil Kaushik
Subject: Re: [sv-bc] 9058: Specifying modport on array of interfaces; a Proposal

 

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. Received on Thu May 28 18:26:57 2009

This archive was generated by hypermail 2.1.8 : Thu May 28 2009 - 18:28:44 PDT