[sv-ac] RE: binding checkers

Resolving the name of the thing to be instantiated in the target scope seems spooky to me.

I'd feel better if some name resolution experts had a look and gave opinions.

J.H.

-----Original Message-----
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Monday, September 23, 2013 1:56 AM
To: Kulshrestha, Manisha; John Havlicek
Cc: sv-ac@eda-stds.org
Subject: RE: binding checkers

Agreed.

I see two points here:

1. While checkers can be bound like modules and interfaces, they are not in the global name space like modules and interfaces.
2. Bind instantiation statements have target scope visibility of declarations in the target scope and of declarations imported into the target scope, but not from $unit.

It might be possible to relax one or both of those restrictions.

Shalom

> -----Original Message-----
> From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
> Sent: Monday, September 23, 2013 09:36
> To: Bresticker, Shalom; John Havlicek
> Cc: sv-ac@eda-stds.org
> Subject: RE: binding checkers
> 
> Hi Shalom,
> 
> I agree with you that as per this statement in LRM, the checker name
> should be resolved as per target scope. But the reason I raised this
> question was that this behavior does not look very user friendly for
> checkers. Especially for the checkers in packages as it will require
> the targets to be modified to import checker packages.
> 
> Dimitry, do you want to give your input on this?
> 
> Thanks.
> Manisha
> 
> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Sunday, September 22, 2013 7:46 PM
> To: John Havlicek; Kulshrestha, Manisha
> Cc: sv-ac@eda-stds.org
> Subject: RE: binding checkers
> 
> I disagree.
> 
> The LRM says,
> 
> "When an instance is bound into a target scope, the effect will be as
> if the instance was present at the very end of the target scope."
> 
> So I think the checker name is resolved in the context of the target,
> not the bind statement.
> 
> In the first example, I would say that ch1 binds to A.ch1.
> In the second example, I would say that it is an error as no ch1 is
> visible in A.
> 
> Regards,
> Shalom
> 
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> > John Havlicek
> > Sent: Friday, September 20, 2013 17:46
> > To: Kulshrestha, Manisha
> > Cc: sv-ac@eda-stds.org
> > Subject: [sv-ac] RE: binding checkers
> >
> > Hi Manisha:
> >
> > My quick, intuitive reactions are the following.
> >
> > For the bind instantiation of a checker whose declaration is nested
> > within a module, I would try to follow the rules for instantiating
> > other things, like modules, whose declarations can be nested within a
> > module.  Potentially, configurations may come into play in the
> > resolution of the name ch1.  I would say that the name of the checker
> > must be resolved in the context of the bind statement, not in the
> > target context.
> >
> > For the example of checker declared in a package, I think the import
> > should be required only insofar as it is needed to resolve the name
> ch1
> > of the checker (if it is needed at all).  I do not think the import
> > affects the meaning of global references, say, in the declaration of
> > ch1 to items in the package.  In any event, I would follow the rules
> of
> > packages for other items, like tasks and functions, that can be
> > declared in a package and have global references there.
> >
> > Best regards,
> >
> > John H.
> >
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> > Kulshrestha, Manisha
> > Sent: Friday, September 20, 2013 12:20 AM
> > To: sv-ac@eda-stds.org
> > Subject: [sv-ac] binding checkers
> >
> > Hi All,
> >
> > LRM allows instantiating checkers in another module using bind
> > construct. But it is not clear how it would be decided which checker
> to
> > pickup.
> >
> > Here is an example:
> >
> > module A;
> >
> > checker ch1;
> > ....
> > endchecker
> >
> > ....
> > endmodule
> >
> > module B;
> >
> > checker ch1;
> > ....
> > endchecker
> >
> > bind A ch1 U1(); <===
> > endmodule
> >
> > It is not clear which ch1 it should pick up? One in A or B?
> >
> > As per bind section, all the symbols in the port list are resolved in
> > the target scope. What about the name of the checker?
> >
> > Here is another example which is more interesting:
> >
> > package p1;
> > checker ch1;
> > ...
> > endchecker
> > endpackage
> >
> > module A;
> > ....
> > endmodule
> >
> > module B;
> > import p1::*; <<== should this be needed for the bind to work
> > bind A ch1 U1(); <===
> > endmodule
> >
> > Here is some text from the LRM:
> > "When an instance is bound into a target scope, the effect will be as
> > if the instance was present at the very end
> > of the target scope. In other words, all declarations present in the
> > target scope or imported into the target
> > scope are visible to the bound instance. Wildcard import candidates
> > that have been imported into the scope
> > are visible, but a bind statement cannot cause the import of a
> wildcard
> > candidate. Declarations present or
> > imported into $unit are not visible in the bind statement."
> >
> > So, the bind statement should be effectively as if 'ch1 U1()' is
> > written at the end of module A. But, A does not import anything from
> > package p1 so effectively ch1 is not visible in A. Does that mean it
> is
> > an error or tools should take care of this scenario?
> >
> > I would like to know what others think about these usages.
> >
> > Thanks.
> > Manisha
> 
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.