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

Hi Gord,

Please, see my comments below.

Dmitry

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Wednesday, February 20, 2008 11:17 PM
To: Thomas.Thatcher@Sun.COM
Cc: Korchemny, Dmitry; Mehdi Mohtashemi; sv-ec@eda-stds.org;
sv-ac@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,
> 
> Let me handle the easier problems first:   2089
> 
> The 2110 proposal:  "Checkers inside loops" states that when checkers 
> are instantiated inside a procedural loop, only the assertion
components 
>  are executed multiple times.  Procedures are not executed multiple 
> times, once for each set of loop index variables, but are executed 
> according to their timing control.
> 
> In addition, My understanding is that the default disable or inferred 
> enable are not used to control the execution of procedures.  Thus, an 
> always_check, or a final procedure will execute the same regardless of

> the place of instantiation of the checker. (Correct, Dmitry?)  Of 
> course, an always_check procedure could use a $inferred_clock, in its 
> timing control, but this does not apply to final procedures.
> 
> The final procedure should be very straightforward.  It is triggered
by 
> the end of simulation.  It will execute once, regardless of the
location 
> of the instance.

So a "final" inside a checker that is instantiated in a task/function
that is never used will still be run at the end of simulation.   In
addition it will only execute ONCE independent of the number or context
of the calls to the enclosing task/function.  I think that this needs
to explicitly stated since users might (reasonably) expect that a
sequentially unreachable checker instantiation would not have its
"final" run.

[Korchemny, Dmitry] Checkers may be instantiated only where concurrent
assertions may be instantiated, and the concurrent assertions cannot be
instantiated in functions or tasks.

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?

[Korchemny, Dmitry] Same comment.


> Now for 2088.  I assure you that this was not intended as a sneaky way

> to get type declarations into procedural contexts :-)   It was
developed 
> to enable coverage-driven methodology.  The idea was that a
verification 
> units could be developed that contained all the necessary assertions, 
> cover properties and covergroup instances all in one package
> 
> What assumptions are being made?  I guess I did assume that multiple 
> instances of a checker would NOT create multiple type definitions for 
> the covergroup.  Is this a fundamentally flawed assumption?  Is there 
> some clarification in the proposal that is needed on this?


Absolutely this needs to be clarified (at least).  There are
still lots of visibility issues here.  Since a covergroup has
class-static properties and calculations that depend on that
staticness, it is crucial to determine how many distinct types
there are and how such types (including class static properties)
can be manipulated.  If a covergroup is permitted, clearly to
have a "single" type, the covergroup can't refer to anything
that isn't static.  Normally this isn't an issue since a
covergroup's declaration context makes that impossible.  Now that
you've opened the door and have to explicitly add text that
makes such references illegal.


I need to go back yet again and look at the checker/assertion
assumptions.  I thought that the assumptions regarding the
rest of the checker constructs (assertions, etc) were that
those constructs *are* distinct for each loop iteration
and/or condition.  Does this mean that we now have some
things that are unique per iteration and some that are not?

[Korchemny, Dmitry] This issue is a subject of another proposal, 2110,
see details there. Its main idea is not to replicate any of checker's
internals in the loop, but make references to loop control variables
illegal in a checker. The only exceptions are concurrent assertions so
that their behavior is consistent to concurrent assertions in loops, as
described in 1995.

> 
> The intent was that, as much as possible, covergroups would work the 
> same within a checker definition as they do outside.  For example, 
> covergroup operation is not affected by default clocking, inferred 
> disables or inferred enables.  That is still the case within a
checker.
> Although a checker containing a covergroup instance may be
instantiated 
> in a loop, there is still only one instance of the covergroup.  Like 
> procedural blocks, they are not "replicated".  

So in what context can I refer to the covergroup's static properties?
Clearly I can't do "loop_name.checker.covergroup_type::..." since that
would be illegal.  I can't even do that within the loop.  So can
I only do that in a checker "new"?  16.18.5 seems to state that a
checker's
initial can't have any sequential assignments, so as far as I can tell,
there is no reasonable to modify a covergroup's static properties.

[Korchemny, Dmitry] See my previous comment.

 >  Likewise, if a checker
> containing a covergroup instance is instantiated in a unreachable 
> section of a case statement, the covergroup new() will be executed
once, 
> just as if the covergroup instance were outside the checker. 

[Korchemny, Dmitry] The execution of the checker code is not related
directly to the place it is instantiated.

E.g.,

always @(posedge clk) begin

mycheck c1(...);

end

is almost the same (the subtleties are immaterial here) as

always @(posedge clk) begin

end
 
mycheck c1(...);

????

Pardon?   A covergroup is NOT implicitly constructed in any context.
Even an embedded covergroup in a class requires a "new" to "activate"
the covergroup.  Are you assuming that a covergroup acts like
an embedded covergroup in the context of a checker?  If so, I have
lots of questions on that.

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.



> I can put 
> additional text in the proposal to clarify this.
> 
> The covergroup is allowed to observe checker variables (free or 
> otherwise).  There are some possible timing race conditions with this.
> In one case we did forbid an interaction (using a checker variable in 
> the clocking event of the covergroup).  We have also documented some
of 
> the other unexpected results that might occur because of the different

> timing of checker variables.  Do you see other problematic
interactions 
> other than timing?


I don't know yet.  The interactions between the assumed static nature
of the covergroup and the non-static instantiation context make much
of this very difficult to reason about since there are all sorts
of interactions that don't appear anywhere else in the language.  I
am really trying to figure out why this is so deeply compelling
as to require all this complexity and special case language.

What fails to work by defining a covergroup as a sibling declaration
to the checker and then just having the checker use that?  I
know that you lose the untyped aspects, but that is also exactly
where all the assumptions come in.

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.