You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>Sometimes an in-progress property should be terminated early — either because an abort condition renders the check irrelevant, or because its occurrence should itself be flagged as a failure. SVA provides two operators for this:</p>
2
+
<ul>
3
+
<li><code>reject_on(cond) prop</code> — if <code>cond</code> becomes true while <code>prop</code> is being evaluated, <strong>fail</strong> immediately.</li>
4
+
<li><code>accept_on(cond) prop</code> — if <code>cond</code> becomes true, <strong>pass</strong> immediately (abort without failure).</li>
5
+
</ul>
6
+
<p>Both have synchronous variants — <code>sync_reject_on</code> and <code>sync_accept_on</code> — that only sample <code>cond</code> at the property's clock edge instead of asynchronously.</p>
7
+
<p>Example: a burst transfer should normally complete with <code>ack</code> within 4 cycles, but if an error fires mid-burst the property should immediately fail:</p>
8
+
<pre>start |=> reject_on(err) (##[1:4] ack)</pre>
9
+
<p>Open <code>abort_check.sv</code> and complete the property body using <code>reject_on</code>.</p>
10
+
<blockquote><p><code>reject_on(cond) seq</code> is equivalent to <code>(!cond) throughout seq</code> — both fail when <code>cond</code> goes true during the sequence window. <code>reject_on</code> is more expressive because it also applies to composite properties, not just sequences.</p></blockquote>
<p>SVA provides two operators for reasoning about entire future traces rather than bounded windows:</p>
2
+
<ul>
3
+
<li><code>s_eventually prop</code> — <strong>strong eventually</strong>: <code>prop</code> must become true at some future clock tick. Fails if the trace ends without it occurring.</li>
4
+
<li><code>always prop</code> — <code>prop</code> must hold at <em>every</em> clock tick from now on.</li>
5
+
</ul>
6
+
<p>The <em>strong</em> vs <em>weak</em> distinction matters for formal tools: a weak property (<code>eventually</code>) is satisfied vacuously by a finite trace that never reaches the condition, while a strong property (<code>s_eventually</code>) demands the condition eventually occurs:</p>
7
+
<pre>// After POR, the lock signal must eventually assert
<p>Open <code>liveness.sv</code> and fill in both property bodies.</p>
17
+
<blockquote><p><code>s_eventually</code> and <code>always</code> used as property operators are <strong>IEEE 1800-2012</strong> features. They express Linear Temporal Logic (LTL) properties and require a formal tool that supports unbounded reasoning. Bounded model checking can only falsify them within its bound, not fully prove them.</p></blockquote>
<p><code>$changed(sig)</code> returns true when a signal's sampled value differs from its value at the previous clock edge — a concise way to write <code>sig !== $past(sig)</code>:</p>
2
+
<pre>update |=> $changed(data)</pre>
3
+
<p>The companion function <code>$sampled(expr)</code> returns the value of an expression as sampled in the preponed region (the settled value at the clock edge). It is most useful inside action blocks to print what the checker actually saw:</p>
<p>Open <code>toggle_check.sv</code> and complete the property body: while <code>update</code> is high, <code>data</code> must change every cycle.</p>
6
+
<blockquote><p><code>$changed</code> uses four-state inequality (<code>!==</code>) so it is also true when a signal transitions to or from X. To ignore X transitions use <code>data != $past(data)</code> (two-state inequality) instead.</p></blockquote>
0 commit comments