[sv-bc] FW: E-mail Ballot Due Dec 17 8AM PST

>-----Original Message-----
>From: Steven Sharp [mailto:sharp@cadence.com] 
>Sent: Friday, December 14, 2007 6:20 PM
>Subject: Re: E-mail Ballot Due Dec 17 8AM PST
>
>
>>SVDB 1397 _X_Yes   ___No
>>http://www.eda.org/svdb/view.php?id=1397
>>
>>SVDB 1809 ___Yes   ___No
>>http://www.eda.org/svdb/view.php?id=1809
>
>Both proposals are complex or can cause unexpected behavior.  I think
>we would be better off not allowing forward references to 
>tasks/functions
>in $unit.  The fact is that forward references to tasks/functions were
>never allowed in Verilog, even if users thought they were.  
>But since it
>seems clear that will not be approved, I will abstain.
>
>>SVDB 2037 ___Yes   _X_No
>>http://www.eda.org/svdb/view.php?id=2037
>
>I have not taken the time to understand the implications of this
>fully, so I will not raise a strong objection.  However, I have
>some concerns, and a number of grammar corrections.
>
>I am concerned that a hierarchical identifier is allowed in an 
>override.
>There are reasons why hierarchical identifiers are not allowed 
>in overrides
>(whether on an instance or a defparam) in the Verilog source: 
>it can lead
>to circularities.  It appears to me that the same issue arises here.
>
>Note that only allowing constant system functions does not 
>make the config
>independent of the design.  If the design links in 
>user-defined PLI system
>functions, those could override the built-in ones, so they 
>would no longer
>be constant system functions.  Or at least that is the case 
>when the system
>functions appear in the Verilog code, which is the closest 
>precedent.  If
>a different rule is intended here, it would need to be spelled out.
>
>In the first paragraph, "override parameters values" should either be
>"override parameter values" or "override parameters' values".
>
>In the list of restrictions, I think the "i.e. a.b.c + 7 is 
>invalid" should
>be "e.g. a.b.c + 7 is invalid".  This is an example of the rule, not an
>alternate restating of it.
>
>In the sentence "All parameters can be reset to their default values,
>meaning their initial values, prior to any parameter overrides",
>setting the central phrase off with commas makes it a parenthetical
>clause.  If we drop out the parenthetical clause, we get "All 
>parameters
>can be reset to their default values prior to any parameter 
>overrides." 
>This suggests that they are reset and then parameter overrides 
>are applied.
>I assume that the intended meaning was to say that the initial 
>values are
>the ones before any overrides.  In that case, the second comma 
>should be
>dropped, making the sentence "All parameters can be reset to 
>their default
>values, meaning their initial values prior to any parameter overrides."
>
>In the sentence "Only parameter W is configured to use it's default
>value", the apostrophe should be dropped.  "It's" is a contraction of
>"it is", while "its" is used for the possessive.
>
>
>>SVDB 2106 _X_Yes   ___No
>>http://www.eda-stds.org/sv-bc/hm/7701.html
>>http://www.eda.org/svdb/view.php?id=2106
>>
>>SVDB 1602 _X_Yes   ___No
>>http://www.eda.org/svdb/view.php?id=1602
>
>Still not convinced this is the most desirable behavior, but at least
>it is defined and consistent.
>
>>SVDB 2097 _X_Yes   ___No
>>http://www.eda.org/svdb/view.php?id=2097
>
>
>
>Steven Sharp
>sharp@cadence.com
>
>

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