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

Hi Gord,

Please, see my comments below.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Gordon Vreugdenhil
Sent: Thursday, February 21, 2008 5:13 PM
To: Thomas.Thatcher@sun.com
Cc: Korchemny, Dmitry; 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



Thomas Thatcher wrote:
> Hi Gord,
> 
[...]
>> I assume that is also true for fork..join_none or similar contexts.
>> What is the expected state of visible variable in such contexts?
>> I assume that the final is not permitted to reference and visible
>> non-static variables.  Is that a correct assumption?  Is that
>> stated anywhere?
>>
>>
> I don't think a checker is allowed in a fork-join.  Would the list
above 
> admit that possibility?

Sure - it is allowed in an initial or always as a statement.  An
initial or always allows a fork..join[any,none] *statement* which
in turn admits other statements.

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

[...]

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

[...]

>> 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 would really like someone to describe the full model that
they have in their head for how this is all supposed to
fit together.  It seems that there are still a large number
of assumptions, ties to other in-progress proposals, and
special case rules all over the place that make me extremely
concerned about how this all fits together.

[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 will be glad to provide any clarifications I can.

As I've said before, and will continue to say, name resolution
and overall elaboration modeling is very complex in Verilog.
Inconsistencies, special cases, and introduction of new
relationships cannot be done lightly and takes a very
substantial amount of time to really make sure is sound.

[Korchemny, Dmitry] As far as I can tell, the name resolution in
checkers is consistent with other SV design blocks. What kind of
inconsistency do you have in mind?


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.