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

Yes, this is correct. The let proposal says that let may be used in
other let only and in assertions. The checkers proposal adds that "The
right-hand side of a checker variable assignment or initialization may
contain let expressions". In all other constructs let is forbidden.

Unfortunately, I am not an expert in covergroups, so I won't be able to
address all your concerns, and I hope that Tom will do it much better
than I. I will try to contribute to this discussion as it develops where
I can help.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Gordon Vreugdenhil
Sent: Monday, February 18, 2008 4:58 PM
To: Korchemny, Dmitry
Cc: Mehdi Mohtashemi; sv-ec@server.eda-stds.org; sv-ac@server.eda.org
Subject: [sv-ac] Re: [sv-ec]e-mail ballot Closes Wednesday February 20
2008, 11:59pm PST

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

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