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

Hi Gord,

Please, see my comments below. I haven't followed the consequent
discussion, so if some of my comments may be outdated, then just ignore
them.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Gordon Vreugdenhil
Sent: Thursday, February 21, 2008 8:12 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] The checkers may appear where concurrent
assertions
> may appear, but according to 2091, concurrent assertions cannot appear
> in fork..join[any,none] blocks.

I think you are relying on an indirect argument.  Unless a checker
is *required* to contain an assertion, there is no rule or implication
saying that a checker instantiation cannot be in a fork...join.
In either case, it would be much more obvious to state the
restriction clearly rather than listing places where a checker
may be instantiated.  Why not just say explicitly -- a checker
may be instantiated in places where a concurrent assertion may
appear (see 16.4).  If there are any differences, list those.
That would be much more clear and would eliminate reliance on
a questionable indirect reason for legality.

[Korchemny, Dmitry] I added this note explicitly to the proposal.

>> I agree that all variable references in the final block should be
> static.
>> The Mantis 1900 proposal says (sec 16.18.6)
>>     "All checker variables in a checker body shall have a static
>>     lifetime"
> 
> But that is immaterial to my question.  If you have an auto
declaration
> in the enclosing scope, can a checker instance refer to that?  No
> one has (yet) made any restrictions regarding the resolution rules,
> so I am assuming that the answer is yes.
> 
> [Korchemny, Dmitry] Could you suggest a scenario when this can happen?
> The names in checkers are resolved according to the checker
declaration
> context, and not according to its instantiation. E.g.,
> 
> always begin
> 	automatic logic a;
> 	...
> 	mycheck c1(...);
> 	...
> end
> 
> How can mycheck reference a? As far as I know it is illegal to
reference
> automatic variables from outside.


But this was at the core of my earlier questions to which Tom
replied that covergroup references do NOT bind outside the checker
declaration.

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

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?

>> Can you explain what a class-static property is?   I think I have an 
>> idea what it means, but I need to really understand it.
> 
> It is a property that is shared across all objects of that type (there
> is only one per type not per object).
> 
> For a covergroup, see 18.7 for things like the "goal" and the
> "strobe" options.  Actually the "strobe" might be interesting in and
> of itself in this context.  Is "strobe" even reasonable for a
> covergroup on checker vars?
> 
> [Korchemny, Dmitry] Yes, strobe may be reasonable, though it is not
the
> only option.

But how do you modify the statics?  You can't do so within the
"initial_check" since that doesn't allow assignment.  Assuming
that hierarchical reference into a checker instance name is
legal (is it???), I guess you could modify the static options
post-covergroup construction be going through the instance, but
that seems pretty artificial.

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

>>> I haven't yet thought through potential issues with having the
>>> covergroup be able to see the context of the checker declaration
>>> at the time of definition and the relationship of covergroup
>>> ref args for sampling semantics.  I don't know if there are
> referencing
>>> issues there.
>>>
>> Sorry if I misled you here.  The covergroup is not able to see the 
>> context of the checker declaration.
> 
> I don't understand this claim at all.  Where is that statement made
> in the proposals?
> 
> Clearly a checker can have names resolve to, say, the package
> context.  The 1900 proposal explicitly says:
> 
>     Variables used in a checker that are neither formal arguments to
the
>     checker nor internal variables of the checker are resolved
according
>     to the scoping rules from the scope in which the checker is
> declared.
> 
> Are you saying that the normal resolution scoping rules do NOT
> apply to a covergroup embedded within a checker declaration?
> 
> [Korchemny, Dmitry] It looks like there is some misunderstanding here.
I
> don't see any reason why the normal resolution scoping rules do not
> apply to a covergroup. Gord, could you restate the original problem?

I was simply observing that I have not yet had time to determine
whether there were different kinds of issues here.  I don't
know if there are yet; Tom's response indicated that he
didn't think such references were possible which led to my
confusion.

> [Korchemny, Dmitry] The basic checker proposal is 1900, and it should
be
> taken as a reference. All stated in 1900 is valid unless another
> proposal explicitly modifies its text. Each proposal contains
> information about the Mantis item on whose top it is written.

I see that in the latest version you've added:

[Korchemny, Dmitry] This note is not recent, though it is not essential
for our discussion.

    When the checker is instantiated its contents are conceptually
    inserted at its instantiation point: if a checker is instantiated in
a
    procedure, its contents are inserted after this procedure, otherwise
    they are inserted in place.  Note that the checker instantiation
    rewriting is only conceptual since the code allowed in a checker is
    not legal outside it. The variables referenced in a checker are
    resolved according to the checker declaration context.

The first two parts of this seem to contradict each other.
Did you intend to say that an instantiation in a non-procedural
context inserts at that point and in a procedural context it
follows?
[Korchemny, Dmitry] Yes, this was my intention.

  In the procedural case, is the "after" part true for
all the contents or just the non-assertion contents?  I thought
the the assertions components were just like having a concurrent
assertion at that point.

[Korchemny, Dmitry] No, it is true for all the contexts. Consider the
following example:

checker my_check(bit x, event clock = $inferred_clock);
	assert property (@clock x);
endchecker

...

always @(posedge clk) begin
	...
	if (en)
		my_check c1(a);
end

This code is equivalent (if we ignore the naming and the scoping issues)
to:

always @(posedge clk) begin
	...
end

assert property (@(posedge clk) a);

Note that the clocking context has been inherited here, because of the
default argument, but the enabling context has not.

Had you written your assertion directly in the always procedure:

always @(posedge clk) begin
	...
	if (en)
		assert property(a);
end

it would have been equivalent to:

always @(posedge clk) begin
	...
end

assert property (@(posedge clk) en |-> a);


In addition, I would likely want to claim not just that
"variables referenced in a checker are resolved according to
the checker declaration context" but that **all** names and
hierarchical references are resolved in that manner (assuming
that hierarchical names are valid).  That would reduce
potential confusion about talking about checker "instantiations"
where that is really quite different conceptually than any
kind of other module, program, or interface instantiation.

[Korchemny, Dmitry] This was my intention. Will add an explicit node to
the proposal.

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.

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