Subject: Re: Fwd: Re: [sv-bc] Outstanding Proposals List
From: Francoise Martinolle (fm@cadence.com)
Date: Mon Mar 17 2003 - 08:53:14 PST
My votes for the proposals are the following:
>>Karen Pieper wrote:
>>
>>>Hi, all,
>>>
>>>Here is the current set of outstanding proposals. If you have issues
>>>with any of these, it would
>>>be helpful if the issues could be raised so new proposals can be made
>>>before Friday.
>>>
>>>The current proposals are:
>>>SV-BC30:
>>>http://www.eda.org/sv-bc/hm/att-0284/06-Peter-action-items.txt
Approved
>>>SV-BC70: http://www.eda.org/sv-bc/hm/0477.html
Approved
>>>SV-BC72: http://www.eda.org/sv-bc/hm/0500.html
Approved, that would be good clarification to say the unique or priority
applies to all the branches of the same if.
Note that we should still be able to mix priority and unique, if we have
embedded if-then-else in another if.
Example:
unique if((a==0) || (a==1)) $display("0 or 1");
else if (a == 2)
priority if (x == 0) $display("x0");
else if (x == 1) $display("x1");
else if (a == 4) $display("4"); // values 3,5,6,7 will cause a warning
The priority applies to the inner if
the unique applies to the outer if.
>>>SV-BC73: http://www.eda.org/sv-bc/hm/0508.html
Disagreed. I proposed some changes by email.
>>>SV-BC74: http://www.eda.org/sv-bc/hm/0511.html
Approved. just like VHDL!
>>>SV-BC39: http://www.eda.org/sv-bc/hm/0514.html
Minor modifications
>>>SV-BC81: http://www.eda.org/sv-bc/hm/0518.html
I agree with Dan that the square brackets on :
name_of_udp_instance ::= udp_instance_identifier [ range ]
should NOT be in bold. The range should be optional.
>>>SV-BC78: http://www.eda.org/sv-bc/hm/0530.html
I still think that logically the full prototype should be on the export.
>>>SV-BC80: http://www.eda.org/sv-bc/hm/0534.html
Approved
>>>SV-BC81-1: http://www.eda.org/sv-bc/hm/0535.html
Approved
>>>SV-BC82: http://www.eda.org/sv-bc/hm/0538.html
looks complicated
It may have been simpler to declare a port declaration like:
port_declaration ::= {attribute_instance} [mode] [data_type]
list_of_port_identifiers
| interface_port_declaration
mode ::= output | input| inout
>>>SV-BC83: http://www.eda.org/sv-bc/hm/0539.html
Approved. I pointed out the same problem earlier.
>>>SV-BC59: http://www.eda.org/sv-bc/hm/0556.html
Approved
>>>SV-BC84: http://www.eda.org/sv-bc/hm/0557.html
better Approved
>>>SV-BC84-1: http://www.eda.org/sv-bc/hm/0558.html
Approved
>>>SV-BC79: http://www.eda.org/sv-bc/hm/0564.html
Approved
>>>SV-BC42-16: http://www.eda.org/sv-bc/hm/0565.html
Approved
>>>SV-BC42-23: http://www.eda.org/sv-bc/hm/0566.html
clarification needed from dave Rich
Dave,
When replacing all the rules page 59 and 60 of SV 3.0 for implicit .name
with:
A *.name* port connection is semantically equivalent to a *.name(name)*
port connection with the following exceptions:
— The identifier referenced by *.name* shall not create an implicit wire
declaration.
— It shall be an error if a *.name* port connection would create an
implicit cast. This includes truncation or padding.
"
Are we suppressing all the rules that implicit .name port connections
cannot be used
in the same instantiation with with .*, and with positional port
connections and may be used with named port connections.
(the last 4 to 7 th rules page 60 and 61)?
or are these rules also included in the named port connections semantic rules?
or there is no such restrictions at all?
>>>SV-BC42-24: http://www.eda.org/sv-bc/hm/0567.html
Dave,
with your proposed replacement, I am assuming then it is LEGAL to use .*
with positional
port connections. Correct? but the .* should be last
I think such a rule should be added.
WITH
An implicit .* port connection is semantically equivalent to a default *.name*
port connection for every port declared in the instantiated module. A named
port
connection may be mixed with a .* connection to override the port
connection to
a different expression or to leave the port unconnected.
When the implicit .* port connection is mixed in the same instantiation with
named port connections, the implicit .* port connection token can be placed
anywhere in the port list. The .* token may only appear at most once in the
port
list.
"
>>>SV-BC42-33: http://www.eda.org/sv-bc/hm/0568.html
Approved
>>>SV-BC75: http://www.eda.org/sv-bc/hm/0569.html
Disagree with the wording
:
WITH
"Note that in SystemVerilog, data can be declared in unnamed blocks as
well as in named blocks. This data is visible to the unnamed block and
any nested blocks below it. Hierarchical references cannot be used to
access this data by name. Some tools may automatically generate scope
names for data in these unnamed blocks, however, these generated scope
names shall not be visible to the scopes below it."
>>>SV-BC26-2: http://www.eda.org/sv-bc/hm/0576.html
>>>SV-BC42-11: http://www.eda.org/sv-bc/hm/0579.html
I looked at the IEEE table and there are some operators which we have
deleted inthe SV table
~& (reduction) removed
~| removed
The second row of the SV table contains more than the IEEE table
The IEEE table only has:
+ - ! ~ (unary)
Why are these discrepancies?
>>>SV-BC21-1: http://www.eda.org/sv-bc/hm/0580.html
Some disagreement and comments to Gordon.
>>>Thanks,
>>>
>>>Karen
>>
>>--
>>--
>>Dave Rich
>>Principal Engineer, CAE, VTG
>>Tel: 650-584-4026
>>Cell: 510-589-2625
>>DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Mon Mar 17 2003 - 08:54:02 PST