Standardized Functional Verification- P8 pot

3.5 Analyzing an 8-entry Queue 55 Three function points with DRAIN_PRIORITY == 0 are condensable and three function points with DRAIN_PRIORITY == 1 are condens- able. Condensation removes 4 hold arcs, 4 add arcs, and 4 remove arcs. Fig. 3.4 illustrates the condensed functional space of the queue after this addition of the high-water mark and the indirect condition that establishes drain priority. Fig. 3.1. Functional space of an 8-entry queue 56 Chapter 3 – Exploring Functional Space Fig. 3.2. Condensed functional space of an 8-entry queue 3.5 Analyzing an 8-entry Queue 57 Fig. 3.3. Reaching HWM at 6 sets the indirect condition for drain priority We can also add a low-water mark (at 2 for the purposes of our example) such that when the number of items in the queue reaches this value, the pri- ority reverts back to normal at the next clock cycle. This is illustrated 58 Chapter 3 – Exploring Functional Space Fig. 3.4. Condensed functional space of queue with high-water mark in Fig. 3.5. Note that none of the function points are condensable, be- cause no two adjacent points have congruent arrival and departure arcs. This simple example has function points represented as 4-tuples of the values of only 4 variables, each variable having only a few values within its respective range. Real systems will have hundreds or thousands of vari- ables with hundreds or thousands (or more) values in the range of each variable. Fortunately for us, the invention of the computer has made it fea- sible to handle such vast spaces, in particular sparsely populated spaces. 3.6 59 Fig. 3.5. Queue with low-water mark added at 2 Reset in the VTG Asynchronous external events have a propensity for occurring at any time, adding complexity to the target and adding arcs to the corresponding VTG. Variables of activation have effects that are usually pervasive 3.6 Reset in the VTG 60 Chapter 3 – Exploring Functional Space Letting the specification for the 8-entry queue require that the queue be treated as empty when hard reset is asserted, then the VTG in Fig. 3.6 depicts this requirement. Fig. 3.6. Explicit representation of reset for 8-entry queue throughout the functional space, adding departure arcs to perhaps every function point. Reset is one such culprit. 3.6 Reset in the VTG 61 The functional space can be condensed greatly for the purposes of de- picting the effects of asserting and de-asserting reset. Consider the exam- ple in Fig. 3.7. arcs from all other function points corresponding to the assertion of hard reset are shown as headed to the single arrival point R. The arrival point for hard reset is the origin of all functional trajectories through the function space. 3 All functional trajectories stem from the origin. 3 Mathematical graph theory regards such a point as similar to a source, a point in the graph joined only by one or more departure arcs. In our VTG when reset is excluded, no arc arrives at the origin from any other point in the VTG. Fig. 3.7. Hard reset In this example the tuples in each function point are the values of four variables of response VA, VB, VC, and VD. For clarity and simplicity, the variable of activation corresponding to hard reset is not shown. Function point P1 is a condensation of the entire activated functional space, includ- ing function point P3. Function point P2 is the arrival point for hard reset, the origin for the target. Because the specification for this target requires that the values of these four response variables have defined initial values VA(0), VB(0), VC(0), and VD(0), the function arc P1→ P2 can be verified by inspection. If there are P function points in the complete uncondensed function space, then there are also P function arcs corresponding to the assertion of hard reset, including the arc that departs from and arrives back at P2 (when hard reset remains asserted for more than one clock cycle). The function point depicted as the dark oval indicates the arrival point for hard reset. This function point is labeled R in the figure. The departure Fig. 3.8. Soft reset To avoid clutter in the VTG for a target similar to the one in the exam- ple (all variables have defined initial values), the function arcs correspond- ing to assertion of reset can be regarded as implied and need not be drawn explicitly. A soft reset can be represented as in Fig. 3.8. Soft reset is similar to hard reset in that every function point has a departure arc leading to function point P2, the arrival point for soft reset. It differs from a hard reset in that the values of certain variables must be retained at the value present when soft reset was asserted. In Fig. 3.8 variable VC has a requirement that its current value (when soft reset is asserted) be retained when the target is re-activated. Function point P2 is the arrival point for soft reset at cycle n, and the value of vari- able VC is retained at its most recent value VC(n-1). The values of the re- maining three variables are returned to their initial values VA(0), VB(0), and VD(0). The arrival point for soft reset is a soft origin of the function space. This verification by inspection is best performed by software, and syn- thesis software can identify any flip-flops that do not receive the required reset signal(s). Verifying this particular subset of arcs with CRV should be unnecessary. However, a check of the values in the tuple P2 is a prudent measure to guard against any change in these initial values. This verifica- tion by inspection of resetability of all flip-flips should be listed as a spe- cial case in the verification plan (see chapter 4). 62 Chapter 3 – Exploring Functional Space This point is also the origin for all functional trajectories within the func- tion space that stem from assertion of soft reset at that particular time (clock cycle). All subsequent functional trajectories stem from this soft origin. 3.7 Modeling Faulty Behavior A test fails when our verification software or an attentive engineer ob- serves something that appeared to be incorrect. Some value somewhere was different from what the monitoring software was designed to expect, breaking some rule. In other words, either a function point was observed that was not a member of the set of responses R or an arc was traversed that was not a member of the set of arcs A. Call this function point y. We recall that the set of responses is R = { p | p = f ( r (n),e(n),s(n),c(n),a(n),k(n))}, for some n ≥ 0. . (3.6) Faulty behavior comprises those function points y such that y (n) ∉ R ,o r (y(n −1), y(n)) ∉ A, or b oth. (3.9) If every variable is properly monitored, and this particular point y(n) was the first observation of faulty behavior, then y (n − 1) ∈ R an d y(n) ∉ R. (3.10) With this information we can theoretically determine what is needed for 100% functional coverage when testing whatever changes are made to eliminate the faulty behavior. We can list all functional trajectories that end at the function point y(n). Assume that there are k such trajectories. 3.7 Modeling Faulty Behavior 63 y k (n − 1) ∈ R an d y k (n) ∉ R. (3.11) Moreover, because these k trajectories each end at y(n), then y 1 (n) = y 2 (n) = = y k (n). (3.12) Testing the changes for the bug that led to the observed faulty behavior is accomplished with CRV focused such that these k trajectories are forced or observed with our monitors. If for all k y k (n − 1) ∈ R an d (y k (n −1), y k (n)) ∈ A, (3.13) then we can claim that the faulty behavior has been eliminated. Further CRV testing may be needed to ensure that no new bug was in- troduced with the changes, however. Additionally, we may choose to con- sider the coverage over trajectories within a condensed subspace to deter- mine if the risk (probability) of not eliminating the faulty behavior is acceptably low. Having determined that some bug is present in the RTL and that it has manifested itself in the observed faulty behavior, at least two questions remain to be answered. How can other faulty behavior caused by this bug be determined? And, how does one establish that all faulty behavior caused by the bug has been determined? It remains to be seen whether it is possible to answer the second question, but CRV techniques such as sweep testing exist to address the first question. Chapter 4 provides an overview of these techniques in the section Failure Analysis. 3.8 Back to those Special Cases We deferred discussion of special cases because we had not yet developed the concept of VTGs as a representation for the points and arcs in the func- tional space. We can now undertake to count the function points contrib- uted by this category. Then, 64 Chapter 3 – Exploring Functional Space . illustrates the condensed functional space of the queue after this addition of the high-water mark and the indirect condition that establishes drain priority. Fig. 3.1. Functional space of an. Fig. 3.1. Functional space of an 8-entry queue 56 Chapter 3 – Exploring Functional Space Fig. 3.2. Condensed functional space of an 8-entry queue 3.5 Analyzing an 8-entry Queue 57 . normal at the next clock cycle. This is illustrated 58 Chapter 3 – Exploring Functional Space Fig. 3.4. Condensed functional space of queue with high-water mark in Fig. 3.5. Note that none