DeepTrans - A Model-based Approach to Functional Verification of Address Translation Mechanisms Allon Adir Roy Emek Yoav Katz Anatoly Koyfman fadir,emek,katz,
[email protected] IBM Research Laboratory in Haifa Abstract This paper presents a new test case generation technology, specifically targeted at verifying systems that include address translation mechanisms. The ever-growing demand for performance makes these mechanisms more complex, thereby increasing the risk of bugs and increasing the need for such technology. DeepTrans is a package that provides model-based test generation capabilities to verify translation mechanisms based on a modeling language. The modeling language includes constructs for describing the address translation process, commonly used translation resources, and architecture rules related to translation. DeepTrans is currently used by two different IBM test generators.
1. Motivation Most modern architectures provide a virtual address space for their applications. The operating system maps these virtual addresses to actual hardware resources (such as memory, disk, or I/O ports) using address translation mechanisms. Supporting a separate virtual address space makes the memory organization oblivious to the application. This enables the application to ignore actual memory sizes as well as the way in which the operating system actually distributes the memory segments. Address translation also commonly plays a part in memory protection and caching mechanisms by maintaining related properties for basic translated memory units (e.g., pages or segments). The translation is mostly carried out using hardware mechanisms, such as translation tables and control registers. The operating system maintains these resources through software, but the translation itself is carried out by the hardware. In this paper, we describe DeepTrans, a new technology for test generation, specifically targeted at verifying address translation mechanisms. The ever-growing demand for performance is causing these mechanisms to become more complex, thereby increasing the risk of bugs. In a survey
we carried out to analyze the verification processes of various micro-processors developed in IBM, we found that a significant percentage of bugs stems, more or less directly, from the translation mechanisms. Moreover, the complexity of these mechanisms makes the bugs themselves more intricate and difficult to find. Traditionally, simulation-based techniques have played a major role in functional verification. These techniques, which continue to be the cornerstone of functional verification [4, 9], are implemented through the running of test cases. In the past, the relatively low design complexity enabled exclusive reliance on deterministic tests that were developed manually. Current practices foster the use of automatic random stimuli generators to add quantity and randomness into the process [7]. In order to better stress the verified design and to ensure good coverage, the generator needs to have knowledge of the properties of this design. The need for a test generation solution applicable to various architectures led to a model-based test generation scheme, where this knowledge is kept separate from the test generation engine. The generator is partitioned into a generic, architecture-independent engine and a model that describes the targeted design [2, 3]. The development and maintenance of test generators targeted at translation mechanisms proved to be difficult and expensive. The model-based approach, including a comprehensive and declarative specification of a design mechanism was, in fact, never applied to the realm of address translation. Instead, for every new design that the test generator is required to support, a developer must write code to handle the specific translation mechanism being verified.
2. Integration with Test Generators As part of the new test generation technology described in our paper, we developed a software package, called DeepTrans, which extends the model-based approach to the realm of address translation verification. DeepTrans provides modeling and generation services that extend existing test generators with address translation testing capabil-
ities. This approach enables the developer of the test generator to concentrate on its specific problem domain and rely on DeepTrans for any required capabilities that have to do with translation. Figure 1 illustrates the typical integration scheme of DeepTrans into a test generator. For any verified design, the test generator developer can construct a declarative model of the translation mechanisms that will be integrated into the model of its own problem domain. The integrated model is converted into a constraint satisfaction problem (CSP) [5, 8], solved by a CSP engine, and finally, converted into a test case.
3. Modeling Address Translation DeepTrans provides a modeling language specifically designed for modeling address translation mechanisms. The language includes a set of powerful building blocks that can be used to describe a large variety of existing translation mechanisms. These building blocks include the translated address, the various transformations that are carried out as part of the translation process, typically used resources (e.g., translation tables), and consistency rules. An example of a consistency rule is the prohibition imposed by some architectures of accessing the same memory location via pages of different sizes. The focus of the model is a description of the translation process. This is done in the form of a directed acyclic graph (DAG), where the nodes represent possible intermediate stages, and the edges represent the possible transformations that occur between the stages. A stage may have several possible outgoing edges, each associated with a different traversal condition. Each node and edge has a list of attributes, where the transformations and the traversal conditions relate to these attributes. A simplified example is shown in Figure 2. The initial stage has a Virtual-Address attribute providing the address to be translated into a physical address, an Access-Type attribute indicating the type of access (e.g., data or fetch) and a Control-Register attribute providing the value of a register that controls the translation process. From this stage, the translation may proceed through one of three possible edges, depending on the value of the Control-Register. The transformation associated with the corresponding edge links together the attributes of the succeeding stage with the attributes of the preceding one. Translation tables are widely used in various translation mechanisms. The modeling language of DeepTrans provides constructs for modeling translation tables. A model of a translation table includes a set of specific properties, such as its size and entry fields. It also provides a match condition, which defines whether a table entry translates a given address. In addition, it specifies the transformations between the attributes of the DAG stages connected by the
translation table and various additional constraints between table attributes. The modeling example in Figure 2 includes a model of a Page Translation table. As the figure shows, there are different transformations and succeeding stages, depending on whether a matching entry was found in the table (i.e., the match condition was satisfied) or not.
4. Testing Knowledge A test generator targeted at the verification of the address translation mechanism should be able to generate events with a high verification value in that area. A pseudo random test generator should thus employ some kind of Testing Knowledge (TK) designed to increase the coverage of desired verification events that are not likely to be generated randomly. Address translation TK may include:
Scenarios that trigger various translation mechanisms. For example, various types of translation-related exceptions can be triggered when a translation entry is not found in the table or when access protection rules are violated. Scenarios that involve several translations. For example, aliasing scenarios that translate different virtual addresses to the same physical address. Scenarios that trigger events related to translation tables. For example, successive accesses to adjacent locations in a translation table. A large amount of the testing knowledge is generic in the sense that it is appropriate for translation mechanisms of many designs. DeepTrans can generate much of the generic TK from the declarative model of the translation mechanism. This testing knowledge is automatically made available for any modeled design and requires no coding effort by the application that uses DeepTrans. At most, the modeling person would need to select some testing knowledge so that it is made available to the particular test generator that uses DeepTrans. Typically, the end user can activate or customize the generator’s use of such generic testing knowledge through directives given to the test generator. This “write once, use many times” approach allows for high coverage of translation mechanisms and sharing of verification knowledge between different designs – a process that cannot be ensured by ad-hoc solutions. The modeling person can still add non-generic testing knowledge required by the specific design verification plan. However, a significant portion of the testing knowledge, including the examples given above, is provided with the DeepTrans package. DeepTrans implements several mechanisms that enable it to automatically construct generic testing knowledge from the model. These include the following:
Figure 1. Integration Scheme
Value partitioning. The domain of each modeled attribute value may be partitioned into several sub-domains. For example, the value of an effective address may be partitioned into small addresses ([0x00000000,0x0000FFFF), regular addresses ([0x00010000,0x0FFFFFFF]), and large addresses ([0x100000000,0xFFFFFFFF]). Such partitioning can be described as a part of a model. For enumerated value domains (e.g, type of exception), every possible attribute value is considered to be a separate partition, unless modeled otherwise. For a partitioned attribute, DeepTrans automatically produces testing knowledge that generates values from each partition with a probability specified by the end user. This mechanism can generate testing knowledge for generating all possible translation-related exceptions. Used attribute value. DeepTrans can remember the values of modeled attributes that were generated for earlier translations of the test. For selected attributes, DeepTrans can then automatically create testing knowledge that will bias the generator to choose attribute values that are identical to or related to historic values of, the attribute. This mechanism can generate testing knowledge for various aliasing events (such as translating to the same physical or intermediate address in different translations) or testing knowledge for the generation of contiguous accesses to adjacent locations in a page table.
Translation path control. DeepTrans analyzes the DAG model of the translation process to determine all the possible paths that a translation can take. Automatically generated testing knowledge enables the end user to control the paths actually taken in the test case, for example, by giving relative weights to certain paths, intermediate stages, or transformation edges. Translation table close match. DeepTrans automatically creates testing knowledge for generating tablerelated events in the test case. For example, in the “close match” event, the table contains entries that are not actually supposed to be used for the translation, but are similar to the entry to be used.
5. Usage DeepTrans is currently being used by two test program generators in IBM: GPro and X-Gen. GPro[1] is currently the main test generation tool used for the functional verification of most IBM processors. GPro uses DeepTrans to generate address translations between the virtual and real address spaces of the processor. X-Gen [6] is IBM’s leading test generation tool for system verification. X-Gen uses DeepTrans to generate the various types of address translations that occur in a system. Examples include translations between I/O address spaces and the main system address space, as well as virtual-to-real processor address translations. Another possibility we are considering is incorporating DeepTrans into a special purpose test generator that will focus on the verification of address translation mechanisms.
Figure 2. Translation Modeling Example
References [1] A. Adir and G. Shurek. Generating concurrent test-programs with collisions for multi-processor verification. In IEEE International High Level Design Validation and Test Workshop, pages 77–82, Cannes, France, October 2002. [2] A. Aharon, D. Goodman, M. Levinger, Y. Lichtenstein, Y. Malka, C. Metzger, M. Molcho, and G. Shurek. Test program generation for functional verification of PowerPC processors in IBM. In the 32nd Design Automation Conference, pages 279–285, 1995. [3] A. Aharon, Y. Lichtenstein, and Y. Malka. Model-based test generator for processor design verification. In Innovative Applications of Artifical Intellegence (IAAI), 1994. [4] B. Bentley. Validating the Intel Pentium4 microprocessor. In Proceedings of the 38th Design Automation Conference, pages 244–248, June 2001. [5] E. Bin, R. Emek, G. Shurek, and A. Ziv. Using constraint satisfaction formulations and solution techniques for random test program generation. IBM Systems Journal, 41(3):386–402, August 2002. [6] R. Emek, I. Jaeger, Y. Naveh, G. Bergman, G. Aloni, Y. Katz, M. Farkash, I. Dozoretz, and A. Goldin. X-Gen: A random test-case generator for systems and SoCs. In IEEE International High Level Design Validation and Test Workshop, pages 145–150, Cannes, France, October 2002. [7] L. Fournier, Y. Arbetman, and M. Levinger. Functional verification methodology for microprocessors using the Genesys
test program generator - application to the x86 microprocessors family. In Desigh Automation and Test in Europe, pages 434–441, 1999. [8] V. Kumar. Algorithms for constraint-satisfaction problems: A survey. A.I. Magazine, 13(1):32–44, Spring 1992. [9] S. Taylor, M. Quinn, D. Brown, N. Dohm, S. H. an d J. Huggins, and C. Ramey. Functional verification of a multipleissue, out-of-order, superscalar Alpha processor - the DEC Alpha 21264 microprocessor. In Proceedings of the 35th Design Automation Conference, pages 638–643, June 1998.
