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

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

 

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

 

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 <http://www.mailscanner.info/>
, 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 <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.