Re: [sv-bc] 18.5.1-2, modports -- proposal


Subject: Re: [sv-bc] 18.5.1-2, modports -- proposal
From: Brad Pierce (Brad.Pierce@synopsys.com)
Date: Thu Feb 27 2003 - 19:39:38 PST


Francoise,

I think that the tasks/functions that are exported via a
modport are those that are declared with the 'import' keyword,
because the viewpoint of the modport declarations is that of
the consumer of the interface. In the words of 18.1,

 "To provide direction information for module ports and to
  control the use of tasks and functions within particular
  modules, the 'modport' construct is provided. As the name
  indicates, the directions are those seen from the module."

For example, in 18.5.4, the Read and Write tasks are services
of the slaves that are made available through a master modport,
either from the interface itself or, as in this testbench example,
from another module. If a consumer wants those services, it must
use the master modport. So the prototypes are declared there using
the 'import' keyword.

The prototype is not required even for 'import' except when the
services are being provided by another module (as in this testbench
example) instead of by the interface, because otherwise the services
are already declared in the interface. The modport task declarations
in the example of 18.5.2 are redundant.

The 'export' keyword indicates services that must be provided
by anyone using that modport. It is a constraint on a provider,
rather than a promise to a consumer.

At the Jan. 21, 2003 meeting, I suggested that prototypes in
modports be disallowed except in the one case where they are required
(imports of tasks/functions not defined in the interface), but
found no support for that.

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of
Francoise Martinolle
Sent: Thursday, February 27, 2003 9:09 AM
To: Brad.Pierce@synopsys.COM; sv-bc@eda.org
Subject: Re: [sv-bc] 18.5.1-2, modports -- proposal

Brad,

then if my understanding is correct, I question why we would need to put
the full prototype
on the import declaration. It seems illogical to me. I think it is more
logical to say that
the full prototype is required on the export declaration if a module has to
export the tasks/functions declarations defined within it through the
interface so that another module can import and use the tasks.

Currently the proposal is the other way around.

Francoise
        '
At 02:15 PM 2/26/2003 -0800, Brad Pierce wrote:
>Francoise,
>
>I agree with each of your points and so would like to add
>the following to my initial proposal:
>
>-----------------------------------------
>
>In the example of 18.5.1, REPLACE --
>
> memMod mem(sb_intf.slave); // only has access to the slaveRead task
> cpuMod cpu(sb_intf.master); // only has access to the masterRead task
>
>WITH --
>
> memMod mem(sb_intf);
> cpuMod cpu(sb_intf);
>
>---
>
>In the example of 18.5.2, REPLACE --
>
> memMod mem(sb_intf.slave); // only has access to the slaveRead task
> cpuMod cpu(sb_intf.master); // only has access to the masterRead task
>
>WITH --
>
> memMod mem(sb_intf.slave); // only has access to the slave tasks
> cpuMod cpu(sb_intf.master); // only has access to the master tasks
>
>-----------------------------------------



This archive was generated by hypermail 2b28 : Thu Feb 27 2003 - 19:40:06 PST