The SystemVerilog Assertion (SVA) language offers a very powerful way todescribe design properties and temporal behaviors;...
First, let’s start our discussion by having a look at asynchronous behaviors and thechallenges that they present.         ...
Asynchronous behaviors typically come in two forms: (1) asynchronous controlsignals, and (2) asynchronous communication. M...
Let’s have a look at the first type of behavior—asynchronous control signals. Tounderstand the difficulties, we’ll start b...
If we were to write assertions for this counter, they might look something like this.These assertions are rather straightf...
A common mistake would be to add Reset into our assertion precondition as shownhere. While this looks like it would work, ...
What we really need is some way to not only stop the evaluation of an assertionwhen Reset occurs, but also kill any thread...
Disable iff handles terminating our assertions, but what about checking that theRTL does the correct thing when the asynch...
To understand why, we need to understand how the SystemVerilog simulationscheduler evaluates assertions, which we will loo...
A Verilog or SystemVerilog simulator has different scheduling regions where eventsare scheduled and subsequently evaluated...
Now that we understand the scheduling semantics, let’s take a look at why theasynchronous reset assertion failed. On the l...
Let’s have a look at some simple methods we could use to delay the sampling of ourassertion inputs.                       ...
The most common way of handling asynchronous checking is to simply check thesignal synchronously. Either the clock or a fa...
Alternatively, immediate assertions can be used to check the asynchronous behaviorimmediately at the appropriate time. Imm...
The first method to delay input sampling is to use a program block. Program blockssample their inputs in the Observed regi...
Sequence events are another way to delay assertion input sampling. TheSystemVerilog standard states that sequence events s...
The expect statement is another useful SystemVerilog construct for delaying inputsampling. The SystemVerilog standard stat...
Since the RTL updates using non-blocking assignments, trying to delay sampling tothe NBA region could pose a possible race...
Clocking blocks can also be used for delaying immediate assertion input sampling.When an “input #0” is specified in a cloc...
Immediate assertions generally do not allow us to use the SVA temporal syntax thatwe get with concurrent assertions. Concu...
The first way to make a concurrent assertion work is to delay the sampling event. Asimple concurrent assignment with a #1 ...
Another way to delay input sampling is by calling a task or function in a concurrentassertion. The SystemVerilog standard ...
Delaying the input sampling for assertions works great for RTL simulation, but whathappens when timing delays are inserted...
The best solution to this problem is probably a compromise using a multi-clockedsequence with Reset and the Clock. The ass...
So in summary….                  25
Here are some guidelines to follow when handing asynchronous behaviors withSVA …                                          ...
For more information on writing asynchronous assertions, please see the followingpaper:       Doug Smith. “Asynchronous Be...
Upcoming SlideShare
Loading in …5
×

How to Handle Asynchronous Behaviors Using SVA

3,610 views

Published on

Published in: Technology, Design
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,610
On SlideShare
0
From Embeds
0
Number of Embeds
39
Actions
Shares
0
Downloads
143
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

How to Handle Asynchronous Behaviors Using SVA

  1. 1. The SystemVerilog Assertion (SVA) language offers a very powerful way todescribe design properties and temporal behaviors; however, they are innatelysynchronous due to how they are defined by the SystemVerilog standard.Unfortunately, this makes them especially hard to use for checking asynchronousevents and behaviors. Notwithstanding, armed with the proper techniques, SVA canbe used to effectively describe and check both synchronous and asynchronousassertions. 1
  2. 2. First, let’s start our discussion by having a look at asynchronous behaviors and thechallenges that they present. 2
  3. 3. Asynchronous behaviors typically come in two forms: (1) asynchronous controlsignals, and (2) asynchronous communication. Most designs have some kind ofasynchronous event like an asynchronous reset, enable, non-maskable interrupt, etc.Even if these events are synchronized within to a clock, they may occur at any time,preempting the current operation of the design, and should immediately trigger anassertion to check that the design properly responds to the event.The second form of asynchronous behavior is asynchronous communication. This isseen with communication across clock domains or on interfaces that use some kindof asynchronous handshaking. See the following paper for details on handling thesebehaviors: Doug Smith. “Asynchronous Behaviors Meet Their Match with SVA,” DVCon Proceedings, San Jose, February 2010.This paper is also available from www.doulos.com. 3
  4. 4. Let’s have a look at the first type of behavior—asynchronous control signals. Tounderstand the difficulties, we’ll start by having a look at a simple up-down counter.The table here shows the proper behavior of this counter. The asynchronous controlis the reset that causes the design to immediately change to 0. 4
  5. 5. If we were to write assertions for this counter, they might look something like this.These assertions are rather straightforward since checking always happens on therising edge of the clock. But what about the asynchronous reset? How do weincorporate that into our assertions? 5
  6. 6. A common mistake would be to add Reset into our assertion precondition as shownhere. While this looks like it would work, we might actually encounter false failuresfrom this. As you can see, when reset occurs, the value of Q immediate resets to 0.On the next clock cycle when the precondition is evaluated, the asserted Reset willstop the precondition from spawning a thread and the check from occurring just aswe intended.The problem lies with the cycle before Reset occurs. The cycle before, theprecondition is met, an assertion thread is spawned, and the checker waits to checkthe condition on the next clock edge. Before the check is evaluated, the Reset signalasserts, changing the actual value of Q from the expected and the assertion throws afalse failure. 6
  7. 7. What we really need is some way to not only stop the evaluation of an assertionwhen Reset occurs, but also kill any threads waiting to check when the reset asserts.The “disable iff” abort terminator allows us to do just that. As soon as the Resetsignal occurs, the level-sensitive abort terminator stops both the evaluation of theassertion and kills any processing threads. As a general rule of thumb, all assertionsensitive to an asynchronous signal should use a “disable iff” qualifying expression. 7
  8. 8. Disable iff handles terminating our assertions, but what about checking that theRTL does the correct thing when the asynchronous reset occurs? To write such anassertion, we might write something as shown here---when the Reset goes high, thencheck that Q goes to 0.At first glance, this looks like it would do what we expect, but unfortunately it doesnot. In fact, the assertion never even evaluates!! 8
  9. 9. To understand why, we need to understand how the SystemVerilog simulationscheduler evaluates assertions, which we will look at in the next section. 9
  10. 10. A Verilog or SystemVerilog simulator has different scheduling regions where eventsare scheduled and subsequently evaluated. All event evaluations occur in thescheduler’s Active region. Events are scheduled in the Inactive region by using a #0delay, and the Non-Blocking Assignment (NBA) region by using a non-blockingassign. Once all the events in the Active region are exhausted, the Inactive regionevents are promoted to the Active region and evaluated. Likewise, once those eventsare evaluated, the non-blocking events are promoted to the Active region andevaluated. As simulation progresses, events are scheduled and evaluated until allevents for a particular time step are evaluated and simulation can move forward.The traditional Verilog scheduling semantics have been extended from including anActive, Inactive, and NBA regions to also include some special regions just forassertions. The Preponed region has been added in SystemVerilog in order tosample all of a concurrent assertion’s inputs, and the Observed region is used fortheir evaluation. Events such as clock or asynchronous signals are generated usingblocking or non-blocking assignments from initial or always blocks, which meansthat they occur in the Active or subsequent regions. Since concurrent assertioninputs are sampled in the Preponed region before any clock or reset events aregenerated, assertions ALWAYS sample their input values before the sampling eventoccurs. This is why when we write synchronous assertions we always need to go 1clock cycle into future and then look into the past with $past() in order to see whathappened on the last clock edge.In addition to the Preponed and Observed regions, SystemVerilog also includes aReactive region where program blocks can schedule their events after the design hasfinished evaluating in the Active/Inactive/NBA regions. The idea for this is to avoidrace conditions between the testbench and the design. 10
  11. 11. Now that we understand the scheduling semantics, let’s take a look at why theasynchronous reset assertion failed. On the left-hand side, you can see what thevalues of Reset and Q are in their respective regions. In the top assertion, when theposedge of Reset occurs, the precondition evaluates whether Reset is true (non-zero). As you can see, in the Preponed region, Reset == 0 so this assertion’sprecondition ALWAYS evaluates to false and the assertion never performs anychecking (this is hard to detect in simulation because it looks like the assertion isalways working and evaluating to true!)In the bottom assertion, we set the precondition to always evaluate true (i.e., non-zero) so that the assertion check occurs, but the value sampled for Q in the Preponedregion is 3, not 0. So this assertion always fails except for the case when Q wasalready 0 before reset.Where we need to check the value of Q is sometime after the design has updated Qin the NBA region. To do so, we need to move the sampling of the assertion inputsto either the Observed, Reactive, or later regions. 11
  12. 12. Let’s have a look at some simple methods we could use to delay the sampling of ourassertion inputs. 12
  13. 13. The most common way of handling asynchronous checking is to simply check thesignal synchronously. Either the clock or a fast clock usually suffices to give thedesign enough time to update so when the assertion evaluates it samples the correctinput values. For most people this is adequate and it handles any timing delays inthe design, but it also leaves you wondering if the design really did immediatelyreact to the asynchronous control signal since the actual checking is delayed. 13
  14. 14. Alternatively, immediate assertions can be used to check the asynchronous behaviorimmediately at the appropriate time. Immediate (or procedural) assertions areplaced inside of procedural blocks of code (initial, always) and sample their inputsat the time they are evaluated, which is based on their context. By placing theimmediate assertions in the right context, the sampling of their inputs can be delayedto check the asynchronous behavior.There are several simple methods that can be used to delay the input sampling,which will be discuss in the following slides. 14
  15. 15. The first method to delay input sampling is to use a program block. Program blockssample their inputs in the Observed region and schedule their events in the Reactiveregion. By placing the assertion in a program block, the value of Q can be sampledAFTER the non-blocking assignment is made to it by the RTL when Reset occurs.Now, when Reset occurs, its results can be immediately observed and checked.One drawback to using a program block is that not all simulators support nestedprograms inside of modules, which means that hierarchical references would beneeded to access the RTL signals. To work around this, a program could be bound(using bind) into the design unit. 15
  16. 16. Sequence events are another way to delay assertion input sampling. TheSystemVerilog standard states that sequence events set their end-point (i.e., whenthey are matched) in the Observed region, and that a process resumes it executionfollowing the Observed region in which the end-point is detected (see IEEE1800-2005, Section 10.10.1, p. 142).A sequence event is created by defining a named sequence and then waiting on it asshown above. The assertion is placed after the sequence event so that its inputs aresampled after the Observed region. The latest versions of most simulators havegood support for sequence events. 16
  17. 17. The expect statement is another useful SystemVerilog construct for delaying inputsampling. The SystemVerilog standard states, “The statement following the expectis scheduled to execute after processing the Observe region in which the propertycompletes its evaluation” (IEEE 1800-2005, Section 17.6, p. 299). The advantage ofusing expect over just assert is that expect can evaluate temporal expressions andproperties; whereas, assert cannot. Unfortunately, not all simulators delay theevaluation of expect so a program block can be used as seen before. 17
  18. 18. Since the RTL updates using non-blocking assignments, trying to delay sampling tothe NBA region could pose a possible race condition. However, if done correctly, animmediate assertion can be also be delayed to right after the RTL has finished itsupdating. This can be accomplished by using a combination of a non-blockingevent, such as the non-blocking trigger shown above, and the use of a #0 delay.The non-blocking trigger above will delay the assertion evaluation until at least theNBA region; however, System/Verilog does not guarantee the order that the alwaysblocks will evaluate and schedule their events. In order to further delay the assertionevaluation until after the RTL schedules its update to Q, a #0 delay can be used todelay the assertion further to the Inactive region as illustrated in this slide. Usingthe #0 delay, the order that the non-blocking events no longer matters and theassertion can be guaranteed to always sample its inputs and evaluate at the correctmoment in simulation time.For older simulators that do not implement the non-blocking trigger construct, thefollowing could also be used:always @(posedge Reset)
 myReset <= Reset;"always @(posedge myReset)
 #0 assert( Q == 0 );" 18
  19. 19. Clocking blocks can also be used for delaying immediate assertion input sampling.When an “input #0” is specified in a clocking block, the inputs are sampled in theObserved region. Using the clocking block then means that the inputs are alwayssampled after the design has finished updating.Unfortunately, clocking blocks do not give the same results in all simulators the firsttime Reset occurs. Since System/Verilog indeterminately executes processes, a racecondition may exist between when the assertion reads the clocking block variableand when it gets updated, resulting in an X for Q the first time Reset occurs. Tosolve this, it is usually adequate to wait on the clocking block. 19
  20. 20. Immediate assertions generally do not allow us to use the SVA temporal syntax thatwe get with concurrent assertions. Concurrent assertions are limited by the standardon when they can sample their inputs---inputs must be sampled in the Preponedregion. However, there are 2 workarounds that we can consider. 20
  21. 21. The first way to make a concurrent assertion work is to delay the sampling event. Asimple concurrent assignment with a #1 delay is adequate enough to delay the inputsampling long enough for the asynchronous assertion to evaluate correctly. Ofcourse, some might object that this is not much different than sampling with a clockbecause there is a possibility of glitches between the asynchronous event and theactual check. However, a #1 delay should be small enough to not worry too muchabout this. While not exactly standard, some simulators support using #1step in anassignment, which essentially delays the assertion evaluation to the Postponedregion and removes the possibility of missing any glitches. One major simulator(Modelsim/Questasim) supports #step instead. 21
  22. 22. Another way to delay input sampling is by calling a task or function in a concurrentassertion. The SystemVerilog standard states that subroutines called in a sequenceare to be evaluated in the Reactive region. By using a ref on a task argument, thecurrent value is sampled in the Reactive region. Unfortunately, not all simulatorstreat functions the same as tasks so a workaround is to not pass the thing to besampled as a function argument but to simply sample it within its declarative scopeinside the function. Since the signal is not an argument, it is not an assertion inputand not sampled in the Preponed region but in the Reactive region---the region of itsevaluating context. 22
  23. 23. Delaying the input sampling for assertions works great for RTL simulation, but whathappens when timing delays are inserted in a gate-level simulation? Now of theseassertions would work because the RTL does not change on the same time step asthe asynchronous event.Instead, our assertions need to wait for the asynchronous event and then watch forthe design to change before checking. We could use a multi-clocked sequence asshown above to wait for the design to update.However, what if Q was already 0 so @Q never evaluates because there was novalue change? It could be qualified using a conditional statement, but there stillexists 2 problems: (1) there is the same sampling issue of Q when @Q occurs sincethe input is sampled in the Preponed region, and (2) how can it guaranteed that Qchanged because of Reset event that triggered it? What if Q did not change fromReset but when the counter started counting again? Even if it is qualified with Resetbeing high, Q might not change until a future Reset event and not the current one. 23
  24. 24. The best solution to this problem is probably a compromise using a multi-clockedsequence with Reset and the Clock. The assertion will trigger asynchronously whenthe Reset event occurs, but then Q is sampled using the Clock to ensure that iteventually updates while under Reset given a window of time specified by sometimeout constant. This makes it easy to change the assertion to compensate for gate-delays with the gate-level netlist, to ensure that Q changes within an acceptablewindow of time, and that Q actually responses to the corresponding Reset event. 24
  25. 25. So in summary…. 25
  26. 26. Here are some guidelines to follow when handing asynchronous behaviors withSVA … 26
  27. 27. For more information on writing asynchronous assertions, please see the followingpaper: Doug Smith. “Asynchronous Behaviors Meet Their Match with SVA,” DVCon Proceedings, February 2010.This paper describes in detailed what is presented here, plus discusses how to handleasynchronous communication using multi-clocked sequences. The full paper can bedownloaded from the Doulos website (www.doulos.com). 27

×