[sv-bc] Updates for Mantis 2008

From: Alsop, Thomas R <thomas.r.alsop_at_.....>
Date: Wed Jan 30 2008 - 13:17:46 PST
I have updated the proposal.  The following issues noted by Shalomhave
been addressed. I also covered all the issues noted by Doug from the
last SV-BC meeting. Thanks Doug for the jump start. Please see Rev6 of
this proposal.  Thanks, -Tom

 

Issues from Shalom:

Comments on 0002008 <http://www.eda.org/svdb/view.php?id=2008> : 
1. First, a comment on 0002131
<http://www.eda.org/svdb/view.php?id=2131> , which is referenced by
2008: 
If the proposal renames the title of 12.4.2 from
"12.4.2 unique-if and priority-if"
to
"12.4.2 unique-if, unique0-if and priority-if",

then it should also rename the title of 12.5.3 from
"12.5.3 unique-case and priority-case"
to
"12.5.3 unique-case, unique0-case and priority-case" 

Alsop, Thomas - I have removed references to unique0 on these titles
since they are covered in other mantis items.


2. A note to the editor says, 
"Changes to 0002131 <http://www.eda.org/svdb/view.php?id=2131>  are only
taken into account in the new wording, not anywhere else." 
The note should refer to 0001345
<http://www.eda.org/svdb/view.php?id=1345>  as well. 
Alsop, Thomas - Done


3. In 12.4.2.1 and 12.5.3.1, after the first reference in each to the
"active region set", add "(see 4.4.1)". 
Alsop, Thomas - Done


4. In the unique-if example in 12.4.2.1, 
always_comb begin : a1 
unique if (a) begin : i1 
z = a || b; 
else if (not_a) begin 
z = a || c; 
end 
end 
there is an "end" missing after "begin :i1". Simpler would be 
always_comb begin : a1 
unique if (a) 
z = a || b; 
else if (not_a) 
z = a || c; 
end 
Alsop, Thomas - Cleaned this up for all the code examples that are now
in the proposal.  Please double check for any syntax issues.  I double
and triple checked but it's easy to miss things.


5. 12.4.2.1 and 12.5.3.1 say in the examples, "the implied assertion
will fail". But nowhere is it stated that unique/priority if/case create
implied assertions. If the LRM is to require that they be treated as
assertions, that needs to be stated explicitly. The implications of that
need to be considered. For example, does $assertoff affect them?

Alsop, Thomas -Removed all references to "implied assertion".  Used
"violation check for uniqueness" instead.  Credit to Doug on that
wording.

6. Similarly, 12.4.2.1 and 12.5.3.1 do not specify how the immunity to
false errors is to be implemented, with what mechanism. The examples
talk about "flushing the original error", etc., but that is not a
normative specification of a requirement

Alsop, Thomas - this is completely reworked.  Hopefully current
descriptions and examples will suffice.  Most of them are converted from
Mantis 2005.

 

 

 

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Jan 30 13:28:21 2008

This archive was generated by hypermail 2.1.8 : Wed Jan 30 2008 - 13:28:50 PST