Subject: Re: [sv-ec] RE: Clarification of 19.4 modports
From: Dave Rich (David.Rich@synopsys.com)
Date: Sun Feb 29 2004 - 21:55:30 PST
Hi Rob,
Apparently, you missed my reply to this question. See
http://www.eda.org/sv-ec/hm/1753.html
The third style you mention is the "no modport" option.(i.e. when you
use an interface with no modport)
Dave
Slater Rob-R53680 wrote:
>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 -------
>>
>>
>
>
>
>
-- -- David.Rich@Synopsys.com Technical Marketing Consultant and/or Principal Product Engineer http://www.SystemVerilog.org tele: 650-584-4026 cell: 510-589-2625
This archive was generated by hypermail 2b28 : Sun Feb 29 2004 - 22:03:55 PST