Subject: Re: [sv-bc] 18.5.1-2, modports -- proposal
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Feb 28 2003 - 14:30:33 PST
At 07:39 PM 2/27/2003 -0800, Brad Pierce wrote:
>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."
Yes I agree with " the directions are those seen from the module".
What I am saying is that a module has to export the tasks/functions it defines
so that they can be used by other modules through the interface.
Just have the full prototype on the export rather than on the import.
>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.
Yes I agree. Just make the full prototype always required for export rather
than
saying it has to be for import but only if the task/functions are exported
from a
module which defined them.
>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.
I think that prototypes should be provided in the export declaration.
>-- 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 : Fri Feb 28 2003 - 14:31:55 PST