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

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Thu Feb 21 2008 - 10:11:42 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.

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

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?


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?

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

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

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


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.

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.
Received on Thu Feb 21 10:15:53 2008

This archive was generated by hypermail 2.1.8 : Thu Feb 21 2008 - 10:16:12 PST