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

My votes below.

 

            Arturo

 

 

  885  _X_ Yes   ___ No    CLOSE 885, covered by 339

 

 1384  ___ Yes   _X_ No     

 

I will change my vote to "yes" if the proposal adopts Neil's
suggestions.

In particular, I object to the change form "superclass" to "parent's
class". The former is unambiguous, the latter may be.

 

 1609  _X_ Yes   ___ No  

 

 1715  ___ Yes   _X_ No  

 

I support addition of the "triggered" method to the clocking-block - the
original issue - and I'll change my vote to yes if the proposal is
limited to that enhancement.

A major problem I have with this proposal is that it makes
clocking-block names assignment compatible with event variables while
imposing additional semantic restrictions (i.e., triggering the event)
that require run-time checks to ascertain if a particular event (such as
a task's event argument) refers to a native event or a clocking block.
These errors cannot be issued at compile time.

IMHO, the more general enhancement adds much complexity to the type
system for little value-add. 

 

 1723  _X_ Yes   ___ No  

 

 1851  _X_ Yes   ___ No

 

I'd like the proposal to incorporate Dev Rich's suggestion as a friendly
amendment - use localparam instead of "local parameter" to avoid
confusion with a local class property/parameter.

 

 2021  _X_ Yes   ___ No  

 

 2055  ___ Yes   _X_ No  

 

It is unclear how the new distribution is any better. As I wrote
earlier, "the rule needs to be unambiguous, but it must also be simple
enough for users to figure out what happened." Coverage reports must be
actionable, that is, users need to be able to easily determine how to
cover certain bins, and this proposal complicates that determination.

I believe that simplicity trounces the need for uniformity. As proof of
how complex the new rules are, I submit the email exchange between
Steven Sharp and Shalom - it took these two experts several iterations
to arrive at a correct formula. Are we seriously suggesting users must
do this computation in their heads? The current rule is simplistic but
predictable.

 

 2113  ___ Yes   _X_ No  

 

I'd like to discuss the merits of the added sentence:

    For queues, any change in size due to randomization results in
elements being added or removed from the end of the queue.

Why is this a requirement for queues only? How would this be observable
in a randomized queue?

 

Other than that, I do favor the replacement of associative array with
queues.

 

 2137  _X_ Yes   ___ No  

 

This proposal is in need of some wordsmith.

 


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