Re: [sv-bc] e-mail ballot: respond by Dec 3, 8am PST

Matt, I added 2217 at the end in this response.

I have several no votes -- 329, 1571, 1957, and 2184.
See reasons below.

I voted yes on 1338 and 1619 but suggested a minor change
in each.  My yes votes on those stand with or without the
suggested changes.

I think my "no" vote concerns can be addressed quickly and
if so, I would be willing to re-cast my votes on those
rather than spend meeting time.


Maidment, Matthew R wrote:
> -You have until 8am PST, Monday, December 3, 2007 to respond
> -An issue passes if there are zero NO votes and half of the eligible
>  voters respond with a YES vote.
> -If you vote NO on any issue, your vote must be accompanied by a reason.
>  The issue will then be up for discussion during a future conference
> call.
> -Note: For some issues, the proposed action is captured in the bug note
>        (resolve as duplicate, already addressed, etc.). 
> 
> As of the November 12, 2007 meeting, the eligible voters are:
> 
> Brad Pierce        
> Shalom Bresticker  
> Cliff Cummings      
> Mark Hartoog        
> Francoise Martinolle
> Karen Pieper       
> Dave Rich          
> Steven Sharp       
> Gordon Vreugdenhil 
> Stu Sutherland 
> Alex Gran
> Don Mills
> Heath Chambers
> Tom Alsop
> Doug Warmke
> Mike Burns
> 
> SVDB  329 ___Yes   _X__No  
> http://www.eda.org/svdb/view.php?id=329


The BNF in 329 is not quite right.  Instead of:

    [ package_import_declaration ] [ parameter_port_list ] list_of_ports ;

it should be:

    { package_import_declaration } [ parameter_port_list ] list_of_ports ;
   ^^^                          ^^^
in each of the productions.  The package_import_declaration production
is a single "import ...;" declaration and we want to allow a list
of them (as in fact the examples use).

With that change my vote would become "yes".


> SVDB 1338 _X_Yes   ___No  
> http://www.eda.org/svdb/view.php?id=1338

Yes on 1338 (the V5 proposal) but I would suggest a friendly amendment.

The sentence:
    A string literal embedded inside a macro will not replace macro arguments
    or embedded macros within that string.
seems a bit awkward.  How about:
    Macros and macro arguments within a string literal shall
    not be replaced when the string literal occurs within macro text.

In any case the "will not" should become "shall not".

My "yes" stands even without the change, but I think a bit of
word-smithing would help here.


> SVDB 1339 _X_Yes   ___No
> http://www.eda.org/svdb/view.php?id=1339

> SVDB 1548 _X_Yes   ___No
> http://www.eda.org/svdb/view.php?id=1548
> 
> SVDB 1571 ___Yes   _X_No  
> http://www.eda.org/svdb/view.php?id=1571

See comments below on 1957 -- I think there is an
incorrect interaction between 1571 and 1957 that
needs to be corrected on one of the two sides.

> SVDB 1619 _X_Yes   ___No
> http://www.eda.org/svdb/view.php?id=1619

Suggested friendly amendment -- please change:
   parameter logic [7:0] My_DataIn =  8’hFF;
to:
   localparam logic [7:0] My_DataIn =  8’hFF;
when used in the $unit scope.

"parameter" is legal and equivalent to "localparam"
but I really don't like seeing "parameter" used everywhere
like that.

> SVDB 1957 ___Yes   _X_No  
> http://www.eda.org/svdb/view.php?id=1957

The 1571 proposal has the following:
   `define MACRO2(a=5, b, c="C") $display(a,,b,,c);
   `MACRO2 (1, , 3)    // ILLEGAL: b omitted, no default
But my reading of 1957 is that "b" should just be empty
here and not illegal.

What is the intent of 1957 and 1571?  Do different rules
apply for macros in which any formal has a default?  If so
the example above is Ok but the rule needs to be much more
clearly stated.

I think that 1571 might intend to say that if an argument
for a formal with a default is omitted, the default is used
and then ALL subsequent omitted arguments must have defaults.
If that is the intent then 1957 and 1571 are Ok together
except for the above example which would be legal.


Sorry for the late "no" on this -- I had focussed on the
"blue" text in 1571 previously and it wasn't until I looked
at 1957 separately that I became a bit confused on this point.


> SVDB 2102 _X_Yes   ___No  
> http://www.eda.org/svdb/view.php?id=2102
> 
> SVDB 2106 _X_Yes   ___No  
> http://www.eda.org/svdb/view.php?id=2106
> 
> SVDB 2152 _X_Yes   ___No  
> http://www.eda.org/svdb/view.php?id=2152

(Yes here is to close as covered by 2097)

> SVDB 2163 _X_Yes   ___No  
> http://www.eda.org/svdb/view.php?id=2163
> 
> SVDB 2169 _X_Yes   ___No  
> http://www.eda.org/svdb/view.php?id=2169
> 
> SVDB 2170 _X_Yes   ___No  
> http://www.eda.org/svdb/view.php?id=2170
> 
> SVDB 2178 _X_Yes   ___No  
> http://www.eda.org/svdb/view.php?id=2178

> SVDB 2184 ___Yes   _X_No  
> http://www.eda.org/svdb/view.php?id=2184

2184 is bit misleading.  The paragraph being changed
starts with:
    Constant system function calls are calls to certain
    built-in system functions where the arguments are
    constant expressions.

The data/array query routines ($bits, etc) are then
added to the list of routines.  But those routines
can be constant even when their arguments are not.

I'd prefer these routines to be broken out with a
statement similar to the following:
    Enables of the data query system functions described in 19.6 and the
    array query system functions described in 19.7 are normally
    constant expressions even when their arguments are not constant.
    See those sections for the conditions under which such enables
    are considered to be constant expressions.


 > SVDB 2217 _X_Yes   ___No
 > http://www.eda.org/svdb/view.php?id=2217


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.