SV-SC Assertions meeting Procedural Concurrent Assertions

1. SV-SC Assertions meetingProcedural Concurrent Assertions 5/14/2008Gord VreugdenhilMentor Graphics Gord Vreugdenhil, Mentor Graphics

2. Overview • Approach is intended to reduce problems in understanding the difference between “immediate” consideration of values (the normal procedural flow) and sampling. • Eliminates reliance on “loop unrolling” descriptions and restrictions on structure of the code • Aims to be more easily extensible to functions • Based on the approach used for deferred assertions Gord Vreugdenhil, Mentor Graphics

3. Existing Approach for (i=0; i<=1; i++) begin : b2 bus[i] = (my_ints[i] == 123); a1: assume property (p(bus[i])); The current restrictions (Mantis 1995) don’t allow various other forms due to rules regarding the form of the loop and identification of the loop control variables. for (i=0; i<=1; i++) begin : b2 j = i + 1; bus[j] = (my_ints[i] == 123); a1: assume property (p(bus[j])); From a user perspective these should be equivalent; the current rules would in fact not grant equivalence and would produce very surprising results since j would follow sampling behavior. Gord Vreugdenhil, Mentor Graphics

4. Proposed Approach The deferred approach would be to separate the initial “arming” of the assertion and the set of committed assertions. Example (using explicit syntax to differentiate): always @(posedge some_clock) for (i=0; i<=1; i++) begin : b2 bus[i] = (my_ints[i] == 123); a1: assume property (p(bus[const’(i)])); The deferred approach would be to “arm” two assertions at the clock edge – p(bus[0]) and p(bus[1]). Then in the observed region the assertions are committed as normal assertion attempts. Gord Vreugdenhil, Mentor Graphics

5. Example (with a data glitch): Assume that en changes from 0 – 1 – 0 – 1 via the active region at times 6, 7, and 8 and the clock arrives at time 10. always @(posedge some_clock, data, en) for (i=0; i<=1; i++) begin : b2 if (en) a1: assume property (p(data[const’(i)])); At time 6, we evaluate the loop and “arm” assertions for p(data[0]) and p(data[1]). This are candidates that can’t be committed until time 10 (the next clock). At time 7, the process is re-entered. The candidates are dismissed (flushed) and a new set is computed; since en is 0, the set is empty. At time 8, we evaluate again and the set p(data[0]) and p(data[1])is found. At time 10, in the observed region the assertions are committed and become normal assertion attempts. Gord Vreugdenhil, Mentor Graphics

6. Example (multi-clocked): Assume that property p is explicitly clocked with slow_clock. always @(posedge fast_clock) for (i=0; i<=1; i++) begin : b2 if (en) a1: assume property (p(data[const’(i)])); Each fast_clock posedge will cause another candidate set to be determined but only the most recent set when the slow_clock actually occurs will become a committed attempt. Gord Vreugdenhil, Mentor Graphics

7. Clock/enable races Assume that en and clk change simultaneously at time 10 and that en becomes 1 before the clock event. always @(posedge clk) for (i=0; i<=1; i++) begin : b2 if (en) a1: assume property (p(data[const’(i)])); The evaluation will use the new value of en rather than the sampled value under the original semantics. Thus a new set of assertions attempts will occur at this clock edge. The user could avoid this race by having: if ($sampled(en))This yields behavior that is identical to the current descriptions and is clear as to the procedural/assertion relationship. Gord Vreugdenhil, Mentor Graphics

8. Requirement for this approach: The main requirement for this to work is that there must be a mechanism for distinguishing what is “sampled” and what follows “immediate” or “constant” semantics. Currently that mechanism is the loop unrolling requirement with the attendant restrictions regarding the form of the loop. Some options: • A syntactic qualification – “const” cast or similar as used in the examples • A requirement to indicate “const” attributes on the formals of the construct • A mix of explicit forms and rules for to treat “common” cases as implicit equivalents. • Others? Gord Vreugdenhil, Mentor Graphics