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

Here are some additional comments on section 8.4 Selection statements

1. Which tools are being referred to

   In the paragraphs that discuss 'if' statements there are references to
   "software tool". In the paragraph that discusses 'case' statements it
   refers to "the simulator".

2. How often are the checks performed

   These checks would need to be performed only once for each time slot
   where the statement is executed. No check would be required for time slots
   where the statement is not executed.

   As was mentioned by others already, in practice these checks tend to only
   be required at clock edges. Since there is no clock edge associated with
   this construct the check needs to be performed for each time slot that the
   statement is executed. Dave Rich has shown an example for getting this
   affect. I assume that his example is based on the semantic mentioned in
   my previous paragraph.

3. During which event region should the check take place

   Brad has suggested the postponed region. I would expect the observe region
   to be more appropriate since that is where assertions are evaluated.
   Deferring the check to either of these regions would eliminate 0-time
   glitches that could occur if the checks were made for every statement
   evaluation within the same time slot.

4. Severity of the check

   A simulation should not terminate based on these checks. The simulation
   log would be post-processed to determine the correct course of action.
   A warning is appropriate.

Section 8.4 isn't very clear about these points (except for item 4.).

The benefits of this construct could end up getting outweighed by the
drawback of slower simulations. If it becomes expensive to perform this type
of check when compared to using an equivalent assertion, this check could end
up being rarely used.

Neil

Shalom.Bresticker@freescale.com wrote:
> Brad,
>
> This is not correct.
>
> In typical one-hot logic, we don't care if there is a small glitch when
> going from one value to another, since the output value is only sampled
> on the clock edge, and the glitch is so short that we don't care.
> But the glitch can indeed exist.
>
> If I write
>
> casez(a[1:0]) //synthesis parallel_case
> 2'b1?: out = b;
> 2'b?1: out = c;
> endcase
>
> I indeed tell the synthesizer to assume that the cases are
> mutually exclusive, but I don't assume that the 2'b11 cannot occur as a
> transient.
>
> Shalom
>
>
> On Tue, 9 Nov 2004, Brad Pierce wrote:
>
>
>>The user is asking for hardware that takes advantage of his/her assertion.
>>So 'unique' should be a promise that the implicit selector signals
>>will be one-hot by the end of each simulation time step.
>
>

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Member of Technical Staff                         Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------