Subject: [sv-ec] RE: Clarification of 19.4 modports
From: Slater Rob-R53680 (R.Slater@motorola.com)
Date: Sat Feb 28 2004 - 22:20:01 PST
Hi,
I would argue that the current modport behavior is contrary to what one would expect.
When I define a list of signals in a modport, I would expect only those signals
to be visible in the instantiating module. If I intentionally left a signal out of a modport
list, I think that would imply that I do not what this particular module to have any
access to the missing signal.
I would suggest the following behavior:
interface inf;
logic a;
logic b;
logic c;
modport one(input a, // Only a & b are available in the directions specified
output b); // c cannot be accessed
modport two(); // No signals are available
modport three(*); // All signals available as inouts
endinterface inf;
Rob Slater
Motorola Semiconductor Israel, Ltd. (MSIL)
r.slater@motorola.com
> -----Original Message-----
> From: Michael Burns [mailto:Michael.Burns@motorola.com]
> Sent: Friday, February 27, 2004 7:43 PM
> To: sv-ec@eda.org
> Cc: R.Slater@motorola.com
> Subject: Clarification of 19.4 modports
>
>
>
> Hi folks (especially Arturo - I think this section may be from you),
>
> Is the intent of the last paragraph in 19.4 (reproduced below) this:
>
> all the nets and variables in the interface are accessible with
> direction inout or ref if *either* 1) no modport is specified in the
> module header, *or* 2) no modport is specified in the port
> connection.
>
> Or is it this:
>
> all the nets and variables in the interface are accessible with
> direction inout or ref if *both* 1) no modport is specified in the
> module header, *and* 2) no modport is specified in the port
> connection.
>
> The spec seems to say the first (barely), but the second
> seems to be more what one would expect.
>
> Mike
>
> ------- Start of forwarded message -------
> Date: Fri, 27 Feb 2004 11:35:18 -0600 (CST)
> To: R.Slater@motorola.com
> CC: Michael.Burns@motorola.com
> Subject: Re: SystemVerlog 3.1a D 4 Spec Bug
> From: Michael Burns <Michael.Burns@motorola.com>
> Reply-to: Michael.Burns@motorola.com
>
>
> Hi Rob,
>
> Sorry for the delay - I've been locked up in meetings for days...
>
> At the very end of the section there's a paragraph that says,
>
> "Note that if no modport is specified in the module header or in the
> port connection, then all the nets and variables in the interface
> are accessible with direction inout or ref, as in the examples
> above."
>
> To be particularly pedantic: if we logically decompose the
> above spec, it would appear to say that all interface signals
> are available if
> *either* 1) no modport is specified in the module header,
> *or* 2) no modport is specified in the port connection. Your
> example specified a modport in the port connection, but not
> in the module header, so all interface signals should be visible.
>
> However, I'm not convinced this was the intent of the
> committee - it rests too heavily on the word "or", which
> could have been chosen without much though. I'll ask.
>
> Mike
>
> >Mike,
> >
> >I noticed that in Section 19.4 of the SystemVerlog 3.1a Draft 4,
> >discussion on modports, it does not explicitly say that if a port is
> >not specified in the modport declaration then it is not exported to
> >instantiated modules.
> >
> >In other words, given:
> >interface rw_if
> > logic a;
> > logic b;
> > logic c;
> >
> > modport clown (input a,
> > output b);
> >
> >endinterface: rw_if
> >
> >rw_if rw;
> >
> >module dodo(rw_if rw);
> > initial
> > rw.c <= 0; // Should fail because c doesn't exist in this view
> >endmodule // dodo
> >
> >module top;
> > dodo bozo(rw.clown);
> >endmodule // top
> >
> >
> >I know this sounds picky, but I've already written an example in VCS
> >where it treats undeclared ports as inout rather than
> non-existent as
> >one would expect.
> >
> >Can you follow up on this?
> >
> >
> >Thanks,
> >
> >Rob
> >
> >------_=_NextPart_001_01C3FC69.52F1FE64
> >Content-Type: text/plain; charset=us-ascii
> >X-Former-Content-Type: text/html
> >Content-Transfer-Encoding: 7bit
> >X-Former-Content-Transfer-Encoding: base64
> >
> >[file:/home/burns/INCOMING/FILE_0008.html]
> >
> >------_=_NextPart_001_01C3FC69.52F1FE64--
> ------- End of forwarded message -------
This archive was generated by hypermail 2b28 : Sat Feb 28 2004 - 22:28:21 PST