RE: [sv-cc] vpiParent and ref objs

 
Tapati,

this is consistent with my interpretation of ref obj. The parent
relationship allows
walking of the ref obj expression up to its base ref obj.

In the second example you give below I would however have expected that the
parent
of task a.read is the generic interface a which vpiActual returns the
modport int1.slave.

Francoise
    '


-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Tapati
Basu
Sent: Thursday, April 14, 2005 3:24 PM
To: vellenga; fm; michael.rohleder@freescale.com
Cc: sv-cc@eda.org
Subject: Re: [sv-cc] vpiParent and ref objs

Hi,

Please ignore my last mail and consider this. Here I am trying to explain
the ides behind creating the vpiParent realtion but I thin we need to
revisit this together with other issues with vpiRefObj.

- Thanks,
tapati 

>
>>-- In 32.12, the vpiParent of a ref obj is another ref obj?  What does 
>>this mean?  Does this have to do with hierarchical instantiation?
>>
>
>Let's consider this scenario : 

module mod()

int1 i1();

child c1 (i1.modport1)


Here, the highconn of the port of c1 is i1.modport1 which is a RefObj of
type vpiModportRefObj and it's parent is i1, which is again a Refobj of type
vpiInterfaceRefObj.

This was the idea behind the vpiParent relation when we first started
thinking about RefObjs.

>-- In 32.26, what does it mean for a ref obj to be a vpiParent of a 
>task or function declaration?
>

This was added to handle the case of export tasks inside interface.

interface simple_bus()
modport slave ......
	export task read()....
	
	
	
module mymod(interface a)

 task a.read ()
 
 }
 
 the instantiation of mymod will be
 mymod m1(int1.slave) // where int1 is an instance of interface simple_bus
 
 so, if we take the task a.read, it's parent is a RefObj which is
int1.slave.