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

Hi Gord,

Please, see my notes below. We cannot change anything in the proposal
right now, since the proposal may be changed only to address the
champions' feedback or a feedback of any committee. So you will need to
provide your feedback officially to allow addressing it by SV-AC.

Thanks,
Dmitry

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Thursday, February 28, 2008 11:35 PM
To: Korchemny, Dmitry
Cc: Thomas.Thatcher@Sun.com; Mehdi Mohtashemi;
sv-ec@server.eda-stds.org; sv-ac@server.eda.org
Subject: 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.

[Korchemny, Dmitry] This is not explicitly written in the proposal, but
can be added to it. Also it has to be added that the actual arguments of
a checker cannot be hierarchical names of objects defined in checkers.
Otherwise there will be type inference problems.

> 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] I don't see why this feature should not be allowed,
but I would postpone it introduction until the next release unless there
are compelling reasons to do it right now.

> [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?

[Korchemny, Dmitry] Unless we are talking about covergroups, the only
static variables in checkers are checker variables. The checker
variables should comply a single assignment rule (SAR) that implies that
at every time step each checker variable may be assigned only once (this
is not the exact language of the proposal, but illustrates its idea).

Suppose that the checker variables are allowed to be assigned in initial
procedures. If the checker variable is continuous, we immediately get
the SAR violation:

assign a = x;
initial a = y;

If the checker variable is sequential, we also get a SAR violation if it
is both initialized and assigned:

bit a = x;
initial a = y;

If the initial procedure is clocked, we'll get SAR violation with a
non-blocking assignment:

initial @clk1 a = x;
always @clk2 a <= y;

But except for checker variables there is no specific reason to not
allow assignments in checker initial.

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

---------------------------------------------------------------------
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.