Standardized Functional Verification- P4 pps

2.6 Rules and Guidelines 15 objectives, it is preferable that a READ request be serviced within 8 or fewer cycles.” From this brief paragraph we recognize both a rule and a guideline that govern a standard response variable (standard variables for stimulus and response will be discussed later in this chapter) called read_cycles. Both the rule and the guideline can be expressed formally in the e language as follows 1 : Check for rule and guideline of section x.y: <’ extend sys { setup() is also { // Halt simulation when a rule is violated. set_check(“FAIL ”, ERROR_AUTOMATIC); // Continue simulation when a guideline is // violated. set_check(“WARN ”, WARNING); } } struct bus_example { event bus_clk is change (‘top.sysclk’) @sim; event read is rise (‘top.read’) @bus_clk; event data_ready is rise (‘top.ready’) @bus_clk; event read_cycles; // Rule: On a read, must return data // within 16 cycles. expect read_cycles is @read => {[1 16]; @data_ready} @bus_clk; else dut_error (“FAIL data not ready in time”); // Guideline: On a read, return data // within 8 cycles. expect read_cycles is @read => {[1 8]; @data_ready} @bus_clk; else dut_error (“WARN data not ready quickly”); } ‘> 1 The examples in this chapter are intended to illustrate how the formal standard variables may be found in existing code or expressed in new code. They are not intended to endorse any particular language or promote any particular coding style. 16 Chapter 2 – Analytical Foundation In the example, the relevant section of the specifications document is in- cluded in the comment preceding the code. This is helpful in relating the code to the natural-language specification on which the code is based. Both the rule and the guideline have been coded in this example. Violat- ing the rule causes the dut_error method to be invoked, printing a mes- sage and halting simulation according to the manner in which set_check has been programmed. Violating the guideline causes the dut_error method to be invoked, printing a message and then continuing the simulation. Rules and guidelines govern values of variables and we have four cate- gories of variables. We shall consider each category of variable in turn, starting with variables of connectivity. 2.7 Variables of Connectivity The network of gates and memory elements that constitute the target represents a specific connectivity 2 . Many designs are intended to be re- used and, consequently, will be structured so that different designs can be generated from a single RTL database. This is especially true for vendor- supplied IP (intellectual property) intended to be used in a variety of dif- ferent connectivity. Many targets will operate differently depending on the presence or ab- sence of elements in its surroundings. That is, variables for both the inter- nal connectivity and the external connectivity must be suitably defined. For example, the stimuli applied to a bus-resident target will vary depending on the presence or absence of other devices attached to the same bus, com- peting for access. The distinction between external and internal depends on where the boundary is defined for the target. Many specifications for industry- standard protocols provide for optional functionality that can be included in or excluded from an IC. The determination of whether a variable associ- ated with such functionality is internal or external might be postponed until the definition of the target has been made final. Most variables of connectivity are static (constant valued) with respect to time. However, an important class of targets designed to provide 2 Bailey uses the term “structure” to refer to a network of interconnected logical and memory elements. However, in the course of a verification project both a behavioral model and a structural model may undergo regression testing with the same suite of tests. To avoid this ambiguity in the use of the term “struc- ture”, the term connectivity is used instead. 2.7 Variables of Connectivity 17 “hot-plugging” functionality experience changes to connectivity during op- eration. Connecting a USB cable between a device and host or plugging in a PCM-CIA card each causes a change in value to a variable of connectivity. A particular set of values chosen from the ranges of the variables of in- ternal connectivity determines an instance of the target. A particular set of values chosen from the ranges of the variables of ex- ternal connectivity determines the context of the instance. 2.7.1 Example – External Connectivity As an example of how to interpret a specification and define standard vari- ables for external connectivity, consider the following sentences from a specification for the number of agents on a shared bus: “The bus is limited to a total of 16 agents in total. The number of proc- essors is limited to 8 and there may be up to 4 memory controllers. Re- maining slots may be occupied by I/O controllers.” Fig. 2.2. External connectivity This paragraph defines three standard variables of external connectivy and also defines their ranges. This can be expressed in e as follows: External connectivity as described on page N: <’ unit processor { // Code not shown for purposes of this example. } unit mem_ctrl { 18 Chapter 2 – Analytical Foundation // Code not shown. } unit io_ctrl { // Code not shown. } unit arbiter { // Code not shown. } unit bus_connectivity { num_proc: int; // This is a standard variable, keep num_proc in [1 8]; // and its range. num_mem_ctrl: int; // A second standard variable, keep num_mem_ctrl in [1 4]; // and its range. num_io_ctrl: int; // And a third with its range. keep num_io_ctrl in [1 (16 - num_proc - num_mem_ctrl)]; proc_agents: list of processor is instance; keep proc_agents.size() == num_proc; mem_agents: list of mem_ctrl is instance; keep mem_agents.size() == num_mem_ctrl; io_agents: list of io_ctrl is instance; keep io_agents.size() == num_io_ctrl; arb_agents: list of arbiter; keep arb_agents.size() == 1; // NOT a variable! } ‘> Four different types of bus agent are defined, namely processors, mem- ory controllers, I/O controllers, and arbiters. For the purposes of this ex- ample, all I/O controllers are considered equivalent. Real systems are not so simple. The number of arbiters is always one so there is no variable of external connectivity associated with arbiters. There is always one arbiter. The remaining three types of bus agent can appear in varying numbers, so there are standard variables of external connectivity defined for each. Note that ranges of two of the variables ( num_proc and num_mem_ctrl) are independent and that the range of the third ( num_io_ctrl) is depend- ent on the values chosen (generated) for the first two variables. In this simple example (and in the ones that will follow) we have merely illustrated how the concept of a standard variable of external con- nectivity is used in verification code. An actual implementation of a test environment would benefit from having all standard variables organized into some central location (such as include files) for inclusion in code modules developed by members of the engineering team. For the purposes 2.7 Variables of Connectivity 19 of illustrating the concepts, however, we will not attempt to create a working test environment. 2.7.2 Example – Internal Connectivity Prior to the availability of commercial IP, verification targets had little or no variables of internal connectivity. That is, the target was RTL that would be synthesized into only one single IC device. The internal connec- tivity was fixed and no provisions were made to vary one or more parame- ters of the design. However, with increasing use of commercial IP, RTL with varying internal connectivity is becoming commonplace. Variables of internal connectivity might be used in a make file to gen- erate specific instances of multi-instance RTL. Similarly, commercial IP is often packaged with some tools to guide the user in selecting values for in- ternal connectivity. Users eventually obtain RTL for simulation and synthesis that is gener- ated from a single body of Verilog or VHDL. Generation produces RTL based upon values assigned to the variables of internal connectivity corre- sponding to the user’s requirements. In our previous example, consider the processor as the verification tar- get. It is being designed for licensing as IP and has variable cache sizes as well as options for memory management and floating-point. These options for customizing this processor core for use in an application constitute standard variables of internal connectivity. Consider Fig. 2.3 below. 20 Chapter 2 – Analytical Foundation Fig. 2.3. Internal connectivity We could define fields in e corresponding to the standard variables of internal connectivity explicitly as follows: Standard variables of internal connectivity for processor: <’ unit processor is also { // Standard variables of internal connectivity. cache_size: [8K, 16K, 32K, 64K]; FPU: [ABSENT, PRESENT]; memory_mgt: [ABSENT, MPU, MMU, DMA]; // Etc. } ‘> To ensure that the RTL for a database that is intended to generate multi- ple instances is thoroughly exercised, a carefully chosen subset (or perhaps all) of the possible instances must be sufficiently exercised with suitably 2.8 Variables of Activation 21 chosen combinations of conditions and stimuli (defined later in this chap- ter). This is especially true for IP (intellectual property) that is intended to serve a wide variety of applications by enabling the generation of many different instances from a single base of source code. Most manufactured devices will have no variables of internal connec- tivity. All wires and transistors are present and connected at all times dur- ing its lifetime. However, a certain class of ICs containing fusible links may be regarded as having multiple variables of internal connectivity. For example, each individual link might be mapped to a standard variable with a binary range: Standard variables of internal connectivity for IC containing fusible links: <’ unit fusible_links { cache_enabled: [OFF, ON]; fpu_enabled: [OFF, ON]; // Etc. } ‘> 2.8 Variables of Activation Choosing the values of variables associated with power, clocking, and re- set determines the activation of the instance in its context. After a logic circuit is activated with the application of power, and then of clocking, and then with the release of reset, it can then be excited with stimuli to obtain responses. The variables for power determine when power is applied or removed from subsets of the target’s logic. Similarly, the variables for reset define when reset is deasserted for each clock domain or subsets of each domain relative to assertion/deassertion of reset in other domains. There may be other relationships between power, clocking, and reset, and variables of ac- tivation must be defined to describe these as well. Some targets will behave differently depending on the clock frequency at which they are operated. In this case a variable whose range of values contains each of the supported clock frequencies could be defined. A target constituting multiple clock domains would require one or more variables defining the possible combinations of clock frequencies supported by the target. From the standpoint of coverage analysis, it is more useful to consider each clock domain and its associated synchronization logic as 22 Chapter 2 – Analytical Foundation a single target. See chapter 7 for further discussion of coverage analysis of such targets. 2.8.1 Example – Activation Consider the processor core of the previous examples (see Fig. 2.4 below). Let’s expand its functional specifications to incorporate power-saving cir- cuitry, variable clock-speeds, and a built-in self-test unit. The optional floating-point unit (FPU) has an associated power-control block so that this power-hungry unit can be turned off when not in use. A control register called pwr_reg has bits that determine whether various subsets of logic in the processor should be powered or not. The processor has been designed to operate at a higher frequency than the system bus to which it is connected, and the bus interface block han- dles the synchronization of signals between the bus and the rest of the processor. For this example, we will assume that the bus is defined to op- erate at any of three different frequencies, 33 MHz, 66 MHz, and 132 MHz, and that the processor is defined to operate at 500 MHz, 800 MHz, and 1 GHz. Then, there are three different ways to bring the processor out of reset. One is by deassertion of the external cpu_reset signal. The second way is by writing to an internal control register (not shown in figure) to cause a soft reset. And, the third way is by way of the built-in self test (BIST) block which is able to cause reset of the processor autonomously. 2.8 Variables of Activation 23 Fig. 2.4. Activation These capabilities add variability that must be verified and this vari- ability might be expressed in terms of standard variables of activation as follows. <’ struct activation_vars { power_on: [EXTERNAL_PWR_APPLIED, PWR_REG]; bus_clk: int; keep bus_clk in [33, 66, 132]; cpu_clk; int; keep cpu_clk in [500, 800, 1000]; reset_deassert: [cpu_reset, BIST, SOFT_RESET]; } ‘> There are numerous familiar examples of variables associated with acti- vation. A “magic packet” defined within the Ethernet protocol will cause a controller to wake up and power itself. A USB host controller can shut down power to logic for ports that are not connected to any device or hub. 24 Chapter 2 – Analytical Foundation Firewire devices can also wake up and power themselves when a cable connect event is detected. After power and clocks to a target have become stable, the target is en- ergized but not yet activated. Assertion of reset de-activates an energized target, and de-assertion of reset activates an energized target. A target must be fully energized before it can be activated. An active target is able to per- form its computations. An energized target merely drains the battery. 2.9 Variables of Condition Values which govern the operation of the target and which are generally constant during its operation are classified as conditions 3 . Most, if not all, conditions receive a default value as a consequence of reset. Many condi- tions are established by software or firmware during system initialization by setting or clearing various bits. Some conditions may even be estab- lished in hardware by strapping or jumpering a value (tying it to logical 1 or 0), or perhaps by means of a fusible link (but such a variable might in- stead be classified as one of connectivity if this is convenient). Conditions are often single-bit values that enable or disable some func- tion. For example, enabling prefetching of instructions or data in a proces- sor or enabling big- or little-endianness of a bus will govern the operation of the target. These conditions usually persist unchanged (but not necessar- ily) while the target is in operation. More complex conditions might estab- lish the value for some threshold in a queue (such as a high- or low-water mark). For example, the result of training a PCI-Express link width consti- tutes a persistent condition that affects the subsequent behavior of the tar- get. These conditions are called direct conditions because their values are written directly by software or by hardware (such as by strapping a bit to a logical 1 or 0). Some conditions are established indirectly in response to application of a certain sequence of stimuli. These conditions are called indirect condi- tions. Such conditions are usually transient, in contrast to direct conditions, which are persistent. For example, a state machine that controls the operation of a queuing mechanism might be caused to operate differently when the data reach or 3 Note that another use of the term “condition” in the context of verification is in a particular measure of code coverage, called condition coverage. See chapter 5 for a discussion of code coverage. . industry- standard protocols provide for optional functionality that can be included in or excluded from an IC. The determination of whether a variable associ- ated with such functionality is internal or external. “struc- ture”, the term connectivity is used instead. 2.7 Variables of Connectivity 17 “hot-plugging” functionality experience changes to connectivity during op- eration. Connecting a USB cable between. Activation Consider the processor core of the previous examples (see Fig. 2.4 below). Let’s expand its functional specifications to incorporate power-saving cir- cuitry, variable clock-speeds, and a