Re: [sv-bc] Errata in SV 3.1a LRM Section 18.4: inconsistent use of error and warning

In considering the proposal for erratum 226 (see also erratum 218 and

     http://www.eda.org/sv-bc/hm/1967.html
     http://www.eda.org/sv-bc/hm/1606.html
     http://www.eda.org/sv-bc/hm/att-1633/design_clarifications.htm )

it was discussed whether there was a definition of 'warning' and
'error' in the LRM and what the difference between them is in practice.

Some of the discussion was in the teleconference and some was on the
reflector --

     http://www.eda.org/sv-bc/hm/2052.html
     http://www.eda.org/sv-bc/hm/2051.html
     http://www.eda.org/sv-bc/hm/2050.html
     http://www.eda.org/sv-bc/hm/2049.html
     http://www.eda.org/sv-bc/hm/2048.html
     http://www.eda.org/sv-bc/hm/2047.html
     http://www.eda.org/sv-bc/hm/2044.html
     http://www.eda.org/sv-bc/hm/2043.html

The same usage appears in the V2K LRM --

     http://www.boyd.com/1364/1364-2005_D3.pdf

Just search for 'warning message' and 'error message'.
For example, look at the description of $sformat in
V2K section 17.2.3. The ACC routines especially make this
distinction. See, for example, V2K section 22.7 and
Tables 127-128.

I think it's outside the scope of this erratum to define
formally the difference between a 'warning' and an 'error'.
The main points of unique case and if are that they are
assertions by the user about what will happen at runtime
and that the simulator must use due diligence in trying
to detect whether this assertion actually holds. In my
opinion, as expressed in the proposal for

    http://www.eda.org/svdb/bug_view_page.php?bug_id=0000218

it is illegal for that assertion to be violated.

Adam says, however, in http://www.eda.org/sv-bc/hm/2047.html
that --

   "Requiring simulators to evaluate unique case branches and
    issue errors may cause false errors to be reported due to
    simulation evaluation artifacts and timed signal propagations."

Does this mean that it is actually legal to violate the
uniqueness assertion, or just that a simulator could get confused
about whether the assertion was violated? Adam continues --

   "We have shown in early sv-ac discussions that error checking
    synchronized to a clock is the safest way to avoid false failures.

   "Thus I think the change to warnings is prudent."

-- Brad

   
Received on Wed Nov 3 18:08:41 2004