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

-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Thomas Thatcher
Sent: Wednesday, February 20, 2008 3:29 AM
To: Gordon Vreugdenhil
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

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

[Korchemny, Dmitry] Yes, this is my understanding, too.

  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.



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?

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

Let me know if you have other questions.

Thanks,

Tom


Gordon Vreugdenhil wrote:
> Are you saying that let can't be used *at all*?  What about
> in bins declarations, etc?  I don't see that kind of restriction.
> 
> My concerns other than "let" are still open.
> 
> Gord.
> 
> Korchemny, Dmitry wrote:
>> Hi Gord,
>>
>> I don't think that let is an issue here since the let construct
cannot
>> be used to define covergroup elements even in checkers, so from this
>> point of view the situation should not be different from covergroups
in
>> modules.
>>
>> Regards,
>> Dmitry
>>
>> -----Original Message-----
>> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
>> Behalf Of Gordon Vreugdenhil
>> Sent: Friday, February 15, 2008 1:30 AM
>> To: Mehdi Mohtashemi
>> Cc: sv-ec@server.eda-stds.org
>> Subject: Re: [sv-ec]e-mail ballot Closes Wednesday February 20 2008,
>> 11:59pm PST
>>
>>
>>
>> Mehdi Mohtashemi wrote:
>>>  We are conducting an email based on request from SV-AC on the
>> following
>>> mantis items:  2088 and 2089.
>>>
>>> the latest documents associated with the mantis items are:
>>>  2088_covergroups_20080211.pdf
>>>  2089_finalInChecker_20080129.pdf
>> ...
>>>  Please mark your vote below by an x. If No, then specify a reason. 
>>>  Send it to the reflector.
>>>
>>>  2088  ___ Yes   _X_ No  http://www.eda-twiki.org/svdb/view.php?id=2088

>>
>>
>> No for a couple of reasons.  First, I need more time to be
>> able to adequately review this.  Second, the interactions
>> between the type space (the covergroup type) and the checker
>> "instantiations" are not obvious to me.  Is a checker
>> now a sneaky way of introducing type declarations (covergroups)
>> into a procedural (even conditional) block?   What
>> assumptions are being made about whether new covergroup
>> types are introduced with such checker "instantiations"?
>> Remember -- covergroups have class-static properties so
>> type uniqueness is important to have absolutely clear.
>> Are unreachable (sequentially dead) covergroup types
>> still alive?  When are they created (via the "new") in
>> such scenarios?  Can a covergroup look at a free var from
>> the checker?
>>
>> I am also concerned that there might be lurking assumptions
>> about essentially having "macro like" expansions involving
>> "let" and other untyped aspects.  All of this is related
>> to my early serious objections to "let" and checkers as
>> a whole and how they interact with the rest of the language.
>> "let" was tied down to only be used in assertions
>> constructs but now AC needs to inject a non-assertions
>> construct back into an assertions context.  Many of
>> my earlier concerns are likely going to reappear in
>> this context as well.
>>
>> In short, there are all sorts of interactions here that are
>> not at all obvious to me and could pose major issues unless
>> the instantiation points of checkers with covergroups are
>> restricted to contexts in which a covergroup type itself
>> is a legal declaration.
>>
>>
>>>  2089  ___ Yes   _X_ No  http://www.eda-twiki.org/svdb/view.php?id=2089   
>>
>> Similarly here, there are unanswered questions.  If checker
>> is "instantiated" in a loop or conditional sequential
>> construct, in what state is its "final" block?  What if
>> the checker is not sequentially reachable?  The final
>> is allowed to read from checker vars -- does that include
>> free vars?
>>
>>
>> Gord
> 

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