Standardized Functional Verification- P8 pot

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.. Ex

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 inspecverifica-tion 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 asserfunc-tion 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))},

Faulty behavior comprises those function points y such that

y(n) ∉ R, or (y(n −1),y(n)) ∉ A, or

both.

(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 and

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

yk(n −1) ∈ R and

Moreover, because these k trajectories each end at y(n), then

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

yk(n −1) ∈ R and

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