As mentioned earlier in this chapter, there are special cases correspond- ing to scenarios and there are special cases corresponding to properties, such as performance. It should be apparent by now that every scenario described in prose text can be described more precisely as one or more VTGs, and these scenarios don’t define additional points in the functional space. They are simply natural-language descriptions of specific function points or trajectories. That doesn’t mean that we simply disregard them, however. It means they are of interest for one reason or another and merit observation. These scenarios have raised some specific doubts on the part of one or more engineers or managers, and confidence is sought that there is no bug associated with the behavior. Perhaps a special case represents some ex- treme of power consumption, or some new compiler idioms for a super- scalar processor still under development, or perhaps an area of functional- ity that has been notoriously buggy in other projects. If a special case does lead us to defining a new variable not already rep- resented in P, then it means that our initial interpretation overlooked some information in the specification, or that the specification document itself was incomplete or unclear on the subject. The higher-level special cases define properties of the target and do not contribute to the functional space as modeled by vectors of values of vari- ables. These special cases remain in the written record (the verification plan, that is – see chapter 4), because they must also undergo testing to verify the properties described. In both sub-categories (scenarios and properties), our list of special cases does not add function points to the space, so P y = 0. So, we now have a slightly more refined estimate (compared to Eq. 3.3) P ≤ P k ⋅ P a ⋅ P c ⋅ P s ⋅ P r . (3.14) 3.9 A L ittle Graph Theory Earlier in this chapter we observed that for each clock domain in each in- stance in each context there exists a separate VTG containing all possible functional trajectories of that clock domain. In mathematical graph theory a graph consists of points (or vertices) and edges. VTGs are graphs in this same sense. of the upper bound on the number of function points as 3.9 A Little Graph Theory 65 The following definitions apply to graphs: • An edge with direction is called an arc. A graph with arcs between points is called a directed graph or digraph. A graph that includes loops (an arc departing from and arriving at the same point) is called a pseu- dograph. A VTG is a pseudograph. • The vertex set V(G) of the graph G contains all of the points in the graph. • The edge set E(G) of the graph G contains all of the edges or arcs in the graph. • A walk is an alternating sequence of points and arcs. A trail is a walk through a graph in which all arcs are distinct, but possibly with repeated points. A path is a trail but in which all points are distinct as well. A given functional trajectory through a VTG is a walk through the graph. • The complement G of a graph G contains the same vertex set V(G) as G, but contains all of the edges or arcs not in the graph. In other words, for every edge (x,y) where x ∈ V(G) and y ∈ V( G ), if ( x ,y) ∉ E (G), then (x,y) ∈ E(G) . • The order |V(G)| of the graph is the number of vertices in the graph. • The size |E(G)| of the graph is the number of edges in the graph. Algebraic analysis of VTGs can help us find bugs in the specification documents or in our definitions of variables, their ranges, and their rules. For a directed graph of n points (vertices), there is an n x n matrix M = [m ij ] with entries defined by m ij = 1, if p i → p j 0, otherwise. (3.15) Such a matrix is called a vertex matrix. Consider the directed graph of 5 points shown in Fig. 3.9. 66 Chapter 3 – Exploring Functional Space Fig. 3.9. A directed graph with 5 points (vertices) The vertex matrix M corresponding to this graph is given by M = 01001 00110 10000 10000 00010 ⎡ ⎣ ⎤ ⎦ . (3.16) Linear algebraic techniques can reveal much about a graph. For exam- ple, to determine the number of 2-arc walks between points i and j, one simply computes the matrix product M 2 : M 2 = 00120 20000 01001 01001 10000 ⎡ ⎣ ⎤ ⎦ . (3.17) 3.9 A Little Graph Theory 67 ⎢ ⎢ ⎢ ⎢ This result tells us, for example, that there is only one 2-arc walk from P1 to P3 (P1 → P2 → P3) but that there are two 2-arc walks from P1 to P4 (P1 → P2 → P4 and P1 → P5 → P4). The reader can confirm the other en- tries in M 2 by inspecting the graph in Fig. 3.9. Similarly, the number of 3- arc walks is given by M 3 . In general, the number of n-arc walks is given by M n . A knot in a graph constitutes deadlock or livelock. If a VTG contains a knot, then there is a bug (error) somewhere: either in the VTG we have de- rived, or in our interpretation of some document, or in one of the specifica- tion documents itself. If some observed faulty behavior consists of an arc between existing function points, this arc is part of the complement G of the value transition graph G. We now have the mathematical tools needed to compute the actual size of the functional space for a given clock domain of a given instance in a given context. For a given VTG G the number P of function points is P = V(G), (3.18) and the size S of the functional space is given by S = E(G). (3.19) 3.10 Reaching Functional Closure We have seen that the overall size of the functional space is typically very large. As RTL is simulated, it can be said to pass from function point to function point as time advances and values of variables change. There are usually many arcs leading to a given function point and until each and every arc has been traversed, true functional closure has not been achieved. Referring to mathematical graph theory we see that the size of the func- tional space is equal to the size of the VTG, and this size is defined as the number of arcs in the graph. Returning to our example of an 8-entry queue will help understand what it means to reach functional closure. The reader can confirm by reviewing the VTGs in Appendix 1 and counting up the arcs between values, that the given by 68 Chapter 3 – Exploring Functional Space 8-entry queue with programmable high- and low-water marks has a total of 756 arcs. There are no more and there are no fewer. 4 After traversing each of these arcs between one set of defined values and another, there are no other arcs to traverse and continued simulations are redundant and unnec- essary. Every possible transition of defined values has been demonstrated at least once. All possible transitions of defined stimuli have been applied to the target and it has been confirmed to produce the correct value transi- tion every time, as have all defined responses, under constant observation by our watchful monitors. Genuine functional closure, in the same sense that we say we reach tim- ing closure, means that each and every arc to each and every function point has been traversed. In other words, just as timing closure means that every timing path has been verified (via simulation) to propagate its sig- nals in the required time, so then functional closure means that every func- tion arc has been verified (via simulation) to lead to its required successor value. In the example of an 8-entry queue, functional closure requires travers- ing 100% of the 756 function arcs, resulting in visiting 100% of the 266 function points. For practical purposes, it is usually more useful to refer to closure over distinct morphs of a given target. Those who dare to undertake functional verification are faced with a co- lossal state machine with a stupendous number of arcs connecting the states, presenting the noble engineer with extraordinary complexity to be verified. Claiming functional closure after checking off every item on a list of things to do is, at best, misleading, if not outright false. Such lists, while useful, lack sufficient structure and analytical rigor to form a basis for comparing the universe of conceivable ICs from the standpoint of risk. Functional closure is not yet commercially practical, however, and as we shall see, it is also not commercially necessary provided that we are willing to accept some risk at tape-out and at other critical junctures in bringing product to market. Exhaustive functional coverage is theoretically possible, but commer- cially impractical. Fortunately, as we will see in chapter 7, exhaustive cov- erage is not necessary to achieve the risk goals established for a project. 4 To keep the example sufficiently small, no variable associated with activation of the queue has been included. 3.10 Reaching Functional Closure 69 3.11 Summary With standard variables it is now possible to determine the size of the functional space in terms of its points and arcs and, therefore, determine what is required to achieve functional closure, that is, exhaustive func- tional coverage. By analyzing a simple queue in detail we have learned that the function is in the action, that is, in the arcs that carry the target forward through the correct and complete functional space. Functional clo- sure means traversing every arc in the functional space and, thereby, visit- ing every point. Now that we have a technique to analyze a given functional space, we can apply this same technique to standards compliance tests, such as for USB or PCI-Express, to determine their functional coverage exactly. The outcome of such analysis may be surprising. We have also seen how condensation of inter-boundary values in this vast functional space enables us to focus our efforts on corner cases. Ex- haustive functional coverage of a condensed space is much more feasible than coverage of the entire functional space. Nevertheless, even the con- densed functional space can be prohibitively large for commercial applica- tions. We will revisit this issue in our discussion of risk assessment in chapter 7. The alert reader might wonder at this point how we have come this far without any discussion of such familiar verification elements as bus func- tional models or checkers or scoreboards. These constitute models for digi- tal components whose many behaviors are determined precisely by the standard variables and their ranges. The existence of these elements and their capabilities are implicit in the definitions of the variables. In fact, these elements will each use subsets of these variables in their implementa- tion. For example, a BFM (bus functional model) will use variables of stimulus to determine what transactions to generate, what each will con- tain, and when to generate it, possibly as a result of some response from the target (acknowledge one transaction, generate another). Chapter 4 will explore the relationships between these standard vari- ables and the verification software that relies upon them. 70 Chapter 3 – Exploring Functional Space Chapter 4 – Planning and Execution The previous chapter discussed exalted and lofty notions of functional spaces of function points connected by directed arcs over which functional closure can be computed. This chapter will bring us back down to earth with discussion of how useful results can be produced within the standard framework. The discussions in this chapter will be of use to all managers and project leaders. The manager tackling a verification project for the first time will benefit from the basics described in this section. The seasoned verification manager will recognize familiar concepts and principles and perhaps dis- cover some new ones. This chapter will also define a sparse but sturdy skeleton for structuring a verification project by defining rational milestones that pertain to all verification projects. 4.1 Managing Verification Projects Planning and executing a verification project is not merely a theoretical exercise, flexing intellectual muscles with weighty concepts. With rare academic exceptions the goal is to produce some useful device in some limited time and on some limited budget and with limited resources. The manager must make judicious and productive use of these limited re- sources. This chapter provides guidance for planning and executing successful projects. Much of the discussion relates to the standard framework, but other unrelated (but helpful) topics will be discussed as well. It’s important to realize that verification – and CRV in particular – does not take place in a vacuum. The RTL is not some remote black box whose functionality must be verified at a distance. Design reviews and code in- spections are essential ingredients of good verification strategy. They should not be regarded as optional. An important assumption underlying the CRV strategy relates to the dis- tribution of bugs in the target. Experience tells us that bugs exist despite 72 Chapter 4 – Planning and Execution our most earnest efforts to create perfect RTL. Each generation of digital devices brings greater and greater complexity to the engineering team, and specifications change during the design process. The unrelenting schedule pressure will encourage engineers to take shortcuts that might otherwise not be worth taking. Haste makes waste. We naturally expect bugs to be distributed among corner cases and new clever functionality. CRV is a powerful technique for exposing these bugs. So, what is the assumption underlying this powerful technique? It is as- sumed that bugs are due to human errors of commission or omission and not due to deliberate intent (vandalism or sabotage). If it were possible for such a bug to escape the diligence of code inspections, it would be neces- sary to achieve 100% functional coverage to ensure that no bug had been deliberately added to the RTL. 4.2 The Goal As discussed in chapter 1 the regression suite with the mechanisms to ap- ply it is the tangible product of verification. This regression suite must: • provide evidence of thoroughness of exercise of the target (a.k.a. func- tional coverage). • provide protection against the introduction of bugs with future en- hancements or other changes (e.g. to eliminate a bug). In effect the verification software constitutes a reference machine that produces independently the results expected from the target for compari- son. If the results agree, they are both presumed to be correct. If they dis- agree, one or the other or both has produced an incorrect result. The verification plan details the work needed to produce this regression suite. Business imperatives will determine the acceptable level of risk for un- exposed bugs at the various stages of development, from tape-out for first prototypes to ramping manufacturing for quantity shipments. No integrated circuit development, with the possible exception of those undertaken for academic purposes, is performed in the absence of competitive market pressures. But, even academic undertakings cost real money, not to men- tion the costs to academic reputation. 4.3 Executing the Plan to Obtain Results 73 Fig. 4.1. Planning the Verification Project 4.3 Executing the Plan to Obtain Results Verification projects may differ widely in the way they are organized and the way they make progress towards tape-out. Nevertheless, there are simi- larities among these many various projects that can provide useful check- points or milestones against which to gauge progress. Fig. 4.2 provides a conceptual skeleton – sparse but sturdy – for verifi- cation projects. Most dependencies, both those with the coding project and those within the verification project, can be tied to some key milestone be- tween major project phases in the skeleton. 74 Chapter 4 – Planning and Execution Fig. 4.2. Project Execution We can regard any verification project as having three distinct phases: preparation, construction, and revision. Phases are defined from the point of view of the RTL so as to focus our attention on the overall objective: a profitable IC or system. 4.3.1 Preparation Ideally interpretation of the specifications will precede project planning (and coding, for that matter), but in practice these types of work will over- lap to some extent, with iteration on specification documents and other project plans before the final go-ahead is given by upper management and the project is officially started. 4.3.2 Code Construction During the Initial Coding phase of the project functionality is added, both to the RTL and to the verification environment, and both are guaranteed to have bugs of omission (unfinished modeling of functionality). Nonethe- less, as modeling within both the RTL coding team and the verification team adds brick upon brick in the testbench, each contribution is simulated with the other in order to debug the verification environment. At some point in time sufficient coding has been completed such that it becomes possible for the target RTL and the testbench to perform basic functions in co-operation with each other. This is usually an exciting time for the project because it is the very first time that the team’s created off- spring shows signs of life. The target can be activated by the testbench and . complete functional space. Functional clo- sure means traversing every arc in the functional space and, thereby, visit- ing every point. Now that we have a technique to analyze a given functional. corner cases. Ex- haustive functional coverage of a condensed space is much more feasible than coverage of the entire functional space. Nevertheless, even the con- densed functional space can be. Functional Space Chapter 4 – Planning and Execution The previous chapter discussed exalted and lofty notions of functional spaces of function points connected by directed arcs over which functional