Re: [sv-ac] Re: [sv-ec]e-mail ballot Closes Wednesday February 20 2008, 11:59pm PST

Korchemny, Dmitry wrote:
[...]
> [Korchemny, Dmitry] I believe it was some misunderstanding here. As far
> as I understand *all* references require binding at the declaration
> point, and I don't see reasons for exceptions from this rule.
> 
> If *all* references require binding at the declaration point,
> then this is likely not a problem since the context of the
> checker decl can't have automatics visible.
> 
> 
> The model that you have is not really one of "instantiation"
> in the module sense (in which case point of instantiation is
> important), but rather something closer to object construction
> in which case all resolution occurs at the point of the
> *type*.  So, in that sense, is it correct that name resolution
> within the context of the checker is like a "type" definition?
> 
> [Korchemny, Dmitry] I think that the checker is very close to a
> parameterized module. I am not sure I have completely understood your
> question. Could you clarify?


Certainly.  If I have "a.b.c.d" in a module, it does not necessarily
bind to either the internals of the module or the context of the
module (the $unit context) -- it can bind hierarchically in
an upwards manner based on the **instantiation context**.  I
hope/trust that such behavior is NOT the case for a checker.
If it is, I will likely have concerns.  If that is not the case,
then the behavior of a hierarchical (dotted) name must be clarified
such that dotted names must resolve either within checker
or within the context of the checker's declaration.


> By the way, I noticed that checkers can also be in interfaces.
> Is is possible, as with an interface type, to instantiate
> a checker from an interface by appealing to the interface port?
> 
> [Korchemny, Dmitry] Could you provide an example?

Normally, one can have:
    module m (some_interface i);
       typedef i.T my_local_type;
       my_local_type m = new;   // assuming i.T is a class
    endmodule

Would you expect one to be able to do something similar with
a checker?  Right now, I think the syntax would imply that
the answer is "no" since you would need to have:
       i.some_checker my_checker(...);
and "i.some_checker" isn't valid syntax.

So I think the answer is "no" but that does seem to imply
some limitations in one's ability to compose with interface
elements.  This is almost certainly a good thing, but I
want to make sure that you aren't thinking about this
differently.

> [Korchemny, Dmitry] The hierarchical reference into a checker has not
> been explicitly forbidden, and there is at least one reasonable
> application of it: if you need to enable/disable an assertion inside a
> checker using $asserton/off.

Umm, the implication here is still that you can't use the "::" form
since there is no context in which:
    name.name::name
is legal.  "::" can't be prefixed by a dotted name and it would
have to be in order to allow direct access to the static properties
of the covergroup.

So, one would have to use "check_name.covergroup_instance_name.static_prop"
in order to manipulate that static properties.  Of course that also
implies that the covergroup_instance_name is hierarchically
referencable via the checker name.  It also *requires* one to do
so in procedural code (on every evaluation) rather than in a more
natural "set it once" manner.

Is there any reason for a checker initial to not allow assignments
to checker statics?


Gord
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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