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

Thanks Gord for sending in your input and vote on 
the two mantis items, 2088, 2089. Even though the
vote is no, I still would like to urge the members
who are eligible to vote to review the two documents
and send their inputs as well. We will have a chance
to review the inputs at our next sv-ec meeting in 
beginning of March. In the meantime the inputs/reviews
will be shared with sv-ac folks.
thanks,
- Mehdi

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Thursday, February 14, 2008 3:30 PM
To: Mehdi Mohtashemi
Cc: sv-ec@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.