[sv-ac] 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.


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