Re: [sv-ec]E-mail Vote: Closes 12am PST October 26th 2007

Here's my votes. 1715 is my only 'no' vote; all the rest are 'yes'.

--Mike

Mehdi Mohtashemi wrote:

>  885  _x__ Yes   ___ No    CLOSE 885, covered by 339
>  http://www.eda.org/svdb/bug_view_page.php?bug_id=000885        
> 
>  1384  _x__ Yes   ___ No     
>  http://www.eda.org/svdb/bug_view_page.php?bug_id=0001384        
> 
>  1609  _x__ Yes   ___ No  
>  http://www.eda.org/svdb/bug_view_page.php?bug_id=0001609        
>  
>  1715  ___ Yes   _x__ No  
>  http://www.eda.org/svdb/bug_view_page.php?bug_id=0001715        

Objections along the same lines as Arturo et. al. - I like adding .triggered, 
but other additions are problematic. For example, the proposal says the clocking 
block event is read-only, yet allows assigning it to an event handle:

    clocking cb @(posedge clk);
    ...
    endclocking

    event ev;
    ...
    ev = cb;

Is ev now subject to the same read-only restrictions as the clocking block 
event? I don't think we want to say yes since that would be hard to implement 
and confusing to users, and we don't want to say no because we don't want to 
enable explicit triggering of the underlying event regardless of how it's 
referred to. I think we should disallow clocking block events on the RHS of 
event assignments and as actual arguments. Clocking block events should not be 
treated as event variables; rather, they should be treated as event expressions, 
legal only where event expressions are legal.

Perhaps the notion of a "const event" variable would be useful? Such variables 
would support all the "read-only" functionality of event variables without 
breaking the connection of the underlying event to happenings in the design. You 
could then do things like this:

   const event ev = (posedge clk);

Of course, I think "const event" already means something else (namely, an event 
variable that cannot be asigned to); perhaps "event const"?

If there's support for this idea, we should do it before adding .triggered to 
clocking blocks; then we would just say that the clocking block can be treated 
as an "event const" and be done with it.

>  1723  _x__ Yes   ___ No  
>  http://www.eda.org/svdb/bug_view_page.php?bug_id=0001723        
>  
>  1851  _x__ Yes   ___ No  
>  http://www.eda.org/svdb/bug_view_page.php?bug_id=0001851        
>   
>  2021  _x__ Yes   ___ No  
>  http://www.eda.org/svdb/bug_view_page.php?bug_id=0002021        
>  
>  2055  _x__ Yes   ___ No  
>  http://www.eda.org/svdb/bug_view_page.php?bug_id=0002055        
>  
>  2113  _x__ Yes   ___ No  
>  http://www.eda.org/svdb/bug_view_page.php?bug_id=0002113        
> 
>  2137  _x__ Yes   ___ No  
>  http://www.eda.org/svdb/bug_view_page.php?bug_id=0002137        
>  
>  
>   885  syntax typo in descriptions 
>  1384  bit stream cast and pack/unpack for protected./local members 
>  1609  import statements should not be allowed in class scopes
>  1715  Triggered property of a clocking block 
>  1723  Size method for associative arrays 
>  1851  all params declared inside class body are local 
>  2021  Relax excessively severe restriction on what can connect to a
> clocking inout 
>  2055  coverage bin distribution is not even 
>  2113  Inconsistency in constraining assoc array size 
>  2137  Some assertion contexts should be procedural 
> 
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.