Surya Pratik Saha wrote:
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?"
I think my proposal suggests the obvious answer here. The modport
specification is orthogonal to the other properties, so it
will be expected from
every element of an interface actual
array; it would be an error to connect an array if one of its elements
lacks the needed modport.
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.
Where is that written? In any case, my proposal is to make this legal
(as indeed some vendors have done).
On the other
side "U1[1].x" is illegal as actual expression, because formal port is
another array.
This
is illegal, but only because the array shapes must match.
That requirement was not explicit before either.
As syntax this is a legal (maybe even the preferred) form to refer to a
(scalar) interface modport x, since
U1[1] was traditionally regarded as a "name" for the interface
instance. In my proposal U1.x[1] would be
an equivalent way of naming the same interface instance modport,
although that form flirts with getting an
error if one of the elements of U1 lacks a modport named "x". I hint
that that's probably an error, but leave
it to practice and user pressure to settle the issue in some future
standard.
You have tried to answer this thing, but it is not there
in LRM yet.
I have offered proposed text to put it there. I agree that the LRM
text describing interfaces is formally one of its weakest spots.
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
My gut feeling is that you probably should be able to do this, but
should not be required to supply the second ".x" above.
But, disclaimer: virtual interfaces are outside my area of direct
knowledge.
As a language designer, the one aspect of my proposal which I find
bizarre is the way it allows the modport selection to be added either
before or after any of the unpacked dimension selectors. I rationalize
this by noting that any selection sequence could happen as an interface
array is handed down the design hierarchy and decomposed along the way;
the modport restriction might enter the picture at any instantiation
step. Once you accept that fact, flattening the syntax is perfectly
natural, and having many ways to achieve the same result is not so
bizarre. Since the modport identifier never becomes part of a design
element name (e.g., a cell or pin), there is little need for a
canonical form that includes it.
We could probably describe a formally tighter theory of strong typing
to explain all this, but chapter 25 hasn't laid much foundation for
that. I stuck with the hand-waving approach and hope that good
implementations will converge.
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?
Here's my proposal again - two minor touch-ups for readability:
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 matching criteria in addition to the interface named type needed to
establish 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 instance whose type 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 permitted.
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 or interface array type with no modport
specification,
the formal modport identifier must exist within the actual interface
instances 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.
Until it is fixed, this type of usage should be
stopped.
You probably don't really mean this the way it sounds.
Until the science of aerodynamics was worked out in the 30s, Curtiss
and Wright were still able to build and fly airplanes.
Their insurance rates were just a bit higher.
Greg Jaxon
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:
Shalom
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 Wed May 27 01:22:54 2009