The functional design of a microprocessor core requires a large number of tools, including various types of models (cycle-accurate simulators and instruction-set simulators), an assembler, a disassembler, a compiler, a debugger, and a test bench in order to validate its performance and correctness and to use for software development. These tools have a high degree of overlap in terms of the information that they require: For example, they need to know about the registers in the design, instructions, memory hierarchy, address translation, and any other architected resources. Traditionally, however, these tools have been created by hand by disparate groups, often from a hand-written specification. This increases the probability for errors to be introduced. It also greatly increases the turnaround time required to add and experiment with new architectural concepts.

Figure 1 Generated IP

A solution to this problem is to write a high-level description of the architecture and microarchitecture. If all of the resources of a microprocessor can be described at a high enough level of abstraction, then all of the collateral can be generated from this description automatically. Assuming that the generators work correctly, then only the description needs to be verified for correctness, rather than each and every hand-written tool. The evolution of this description is shown in Figure 1. At first, the description may only approximate the behavior of the proposed design, but it is perfectly suitable for early tradeoff analysis. The model can then be used and refined during functional verification, acting as the golden reference specification for the project. Toward the end of the project, it can then be used to generate customer models with a high degree of confidence in their accuracy and without the need to conduct a complete validation process.

The concept of generating models and tools from a description is not a new one. While such systems exist, few can handle the needs of a company with a diverse portfolio of microprocessor cores. This subject has received a lot of attention from academia. While most of these academic tools tend to have interesting features, they are not ready for industrial use. Commercial offerings tend to concentrate on the application-specific processor market and thus emphasize ease of use for relatively simple architectures and microarchitectures. They frequently do not handle features found in high-end microprocessors such as memory management units (MMUs), hardware multithreading, and speculative execution.

Most of the commercial tools also have a significant limitation in that they couple architecture and microarchitecture. For this discussion, architecture is considered the programmers' view of a core, such as the instructions and registers, without a concept of time. The microarchitecture defines the underlying pipeline and deals with temporal aspects. These are orthogonal concepts, and as shown in Figure 2, the same architecture might be implemented as an in-order, single-issue pipeline or a multi-issue out-of-order processor with speculative execution.

Figure 2: Architecture versus Microarchitecture

Freescale Semiconductor has a broad spectrum of host processors containing PowerPC®¹ cores, ranging from simple, in-order, single-issue embedded cores to advanced superscalar parts. All of the processors implement a common set of instructions, but various parts contain additional architectural extensions such as Altivec for multimedia applications. For the reasons mentioned above, we were unable to find an existing language capable of satisfying all of our modeling needs. Thus, we decided to develop our own language, known as the ADL project.

Our language allows users to easily specify architectural blocks consisting of resources found within microprocessors. These architectures may be incomplete when viewed in isolation, but when instantiated into a core, completeness is required. For example, a multimedia block might reference a register file but not declare them itself. When a core is instantiated with this block, however, that register file is required to have been declared by some other architecture block.

We also maintain a clear separation between architecture and microarchitecture: ADL describes architected resources only, with no references to time. Another project, known as microADL, describes the pipeline. The two languages work together when cycle accuracy is required. This is accomplished by creating a transactional instruction-set simulator (ISS) model from an ADL description. The pipeline model requests instructions from the ISS, which creates instruction packets. These flow through the pipeline model and store all of their own operand and result information. The architected state of the model is only updated when the packet is finally committed back to the ISS.

The concept is not simply that of a trace-driven pipeline model coupled to an ISS: This system produces a true execution-driven model that will generate wrong answers if, for example, a forwarding path is omitted. This allows the cycle-accurate model to be verified for correctness using the usual techniques of random test-case generation. In addition, there is very little redundancy in the specification: All instruction semantics are extracted from the ADL model. Finally, this technique allows for the modeling of a wide range of microarchitectures, including superscalar systems.

Currently, we are modeling approximately 80 percent of PowerPC's user-mode integer instructions, along with a three-level memory hierarchy, an MMU, and hardware multithreading. Although the project is still in its early stages, an architecture enablement group for a new high-performance core is using this for multithreaded workload development. Our next steps will be to configure an architectural test-case generator to be able to use an ADL description for functional verification.

Using architectural description languages is a promising approach for decreasing the total cost of processor development. By automating the creation of necessary tools and models from a common description used throughout the life cycle of the project, the validation costs of the generated tool chain is greatly reduced. Currently, such languages are primarily used for smaller projects such as for simple embedded cores. At Freescale, we are pioneering the use of description languages for complex, high-performance parts in order to allow the technology to be used across our complete line of cores with a high degree of reuse between projects.