CHAPTER 1 Introduction

The Advanced Intermediate Representation with Extensibility (AIRE) specifications address the HDL user's need for efficient mechanisms for sharing of design information between tool components. The AIRE specifications includes coordinated internal intermediate representation (IIR) and file intermediate representation (FIR) specifications. This document specifies the IIR; a companion document specifies FIR.

Existing tools, by their very nature, are already tied to proprietary representations and generally have little ongoing development resource available with which to change the underlying design representation. For practical reasons, such tools are unlikely candidates for use of a new intermediate representation, such as AIRE.

AIRE targets tools beginning early in the development cycle or at a major system redesign. AIRE's designers have concentrated on providing powerful new capabilities intended to facilitate system design well into the next century rather than operating within the tight constraints of backward compatibility. AIRE delivers on key user requirements including performance, capacity, portability, extensibility, security, availability and reusability; keys to advanced system design.

This chapter introduces AIRE's file intermediate representation through a discussion of this document's purpose, and an overview of the specification's remaining chapters and an introduction to the specification change process. Hypertext renderings of this document provide linkages, beginning with this chapter, into the remainder of the document.

As an extensible representation, your version of this document may include non-core extensions. For example, extensions may support VHDL language extensions, other languages or implementation-specific information. Additions to the core AIRE representation are the result of a careful coordination process open to all those using the intermediate representations. All such extensions are denoted by underlined text, as in extension.

1.1 Purpose

Through compliance with this specification, a development group should be able to design and develop inter-operable implementations of the file representation (foundation) or component tools which work with information present in the file representation (applications).

This FIR specification is designed to allow transport of the representation between machines of differing architectures. The FIR data will be written according the writer's architecture. There will be information in the FIR that specifies the architectural assumptions, so the data can be transformed on reading. The extraction of an IIR (Internal Intermediate Representation) from the FIR can use mechanisms described in this document.

The FIR like the IIR is useful following source code analysis, integration of separately analysed units, elaboration, in-line expansion, machine-independent optimization, backend code generation/synthesis and execution (simulation). The FIR is the likely mode of integration of component tools from different development groups.

AIRE's purpose is to meet the evolving needs of advanced tool developers. Therefore, the specification is still evolving. Some changes to the core specification are still being made as a result of experience with early implementations. Implementation-specific extensions are being added to the core specification. For the latest information on AIRE, please join the AIRE mail reflector by sending a request to:

aire-request@vhdl.org

and tracking on-line copies of the AIRE specifications via the following WWW sites:

http://www.vhdl.org/~aire/

http://www.ftlsys.com/aire/

http://www.ece.uc.edu/~paw/aire/

http://www.mtl.com/projects/savant

...

1.2 Related Efforts

Intermediate representations have been moderately successful in facilitating Ada compiler implementations. DIANA[] serves as the basis for Ada compilers from the Ada Group Ltd.[]., Bell Labs[], Burroughs[], The University of California[], Berkeley[], Intermetrics[], The University of Karlsruhe[], Rational[], Rolm[], SoftTech Microsystems[], Stanford[], and Verdix[].

IVAN[] was initially conceived, in 1985, as the corresponding interface description language IR for VHDL. Unfortunately IVAN was not nearly as successful as DIANA. It never saw wide-spread use in the development of VHDL compilers beyond the initial Intermetrics VHDL implementation Relatively few implementations of IVAN are believed to remain in use and no new development efforts are believed under way using IVAN

In the late 1980s, CAD Language Systems (CLSI) developed an IR and associated VHDL analyser. This analyser achieved substantial commercial success and is still in use by some VHDL compilers. CLSI's intermediate representation is proprietary and limited to representation of IEEE Std. 1076-87. Experience with CLSI's intermediate identified several intrinsic design decisions which were later recognized to limit an implementation's performance.

For several years, ending in 1991, an IEEE Design Automation Standards Committee (DASC) Working Group attempted to develop VIFASG []. This effort is generally believed to be closely patterned after CLSI intermediate. Despite substantial effort by the working group, a standard failed to materialize and the IEEE has withdrawn the associated PAR. The group's inability to reach a standard is generally attributed to competing commercial concerns and sub-optimal technical characteristics.

The unsuccessful VIFASG effort was picked up by Leda SA, updated to represent IEEE Std. 1076-93, and is currently the basis for an analyser product by Leda []. While this interface has seen some commercial success, it has less than optimal compaction, leads to relatively slow tools, does not benefit from IDL advances over the last five to ten years and does not address the complete design life-cycle of VHDL and Verilog designs. Leda's interface is supported by an expensive, single-source implementation. Until at least recently, Leda's interface has also been proprietary.

By the middle of 1995, HDL "power" users and advanced tool developers recognized that a fundamentally new intermediate representation was needed. Today, AIRE offers a widely-available, high-capacity, high-performance intermediate which takes maximal advantage of contemporary, object-oriented software techniques. Multiple IIR implementations are available, including a free non-commercial implementation and at least one low-cost commercial implementation. Over a dozen advanced applications using AIRE's IIR foundation are in development.

1.3 AIRE Approach

The FIR follows the IIR class hierarchy (See the AIRE Internal Intermediate Representation). The record names will begin with FIR instead of IIR. A base record class, called FIR, is located at the top of the class hierarchy. Each record class will be composed of the root (FIR) data first, followed by the data for each derived class as the hierarchy is descended. The IR class hierarchy is shown abstractly in Figure 1 on page 11. Records of a specific record class are differentiable by an enumerated value denoting the records's IR_Kind.

At the start of an FIR will be a header that has information on the FIR. It will contain information on the version of FIR, on the source architecture of the IR for transformation of the data to the reading architecture and on other data about the FIR.

An FIR is one logical file. It may consist of many physical files that are partitioned by a writer and concatenated into one logical file by a reader.

In this document FIR records and functions will be described in a pseudo-C format. This does not imply that C must be used to create or read an FIR. Any I/O system should be usable to read or write an FIR.

Extension classes, shown in darker shading in Figure 1 on page 11, may be interposed within the IR inheritance hierarchy in order to add application-specific methods and data elements. All extension data is added at the end of standard data defined in this document. The type of extension information is application dependent and outside the scope of this document. (See the IIR document for more information on Extensions)

FIGURE 1. Structure of IR

1.4 Document Structure

Chapter 2 details design requirements which shape AIRE's FIR. All of the subsequent design decisions are based on the explicit design objectives set forth in this chapter. The interested reader will see a close linkage between these design requirements and the decisions which follow.

Chapter 3 describes the basic file layout and the basic data types used to specify the record structure within specific classes. These basic data types include integers, characters, and floating point values with specific ranges.

Chapter 4 presents the complete predefined FIR class hierarchy. Tables in this chapter allow the reader to trace inheritance relationships from the IR base class through to derived classes from which instances may be created. This chapter also describes general properties of all FIR classes.

Details of the FIR base class and IR_Kind enumeration are found in Chapter 5. The IR_Kind enumerated type distinguishes between the classes in the file.

Chapter 6 through Chapter 16 describe the IR_Kind, and data layout for the various classes descended from the FIR base class. Each chapter begins with a table illustrating the class derivation hierarchy described by the following chapter. Then distinct sections describe each intermediate and terminal derived class.

Finally, Chapter 18 records changes made to this document from one version to the next. This log begins with the trial implementation draft (Version 2.3).

On-line copies of this specification provide hypertext linkages, generally highlighted by a viewer or browser. These linkages allow the reader to rapidly navigate from use of a particular identifier back to its definition. In a like fashion the reader may directly step from a table of contents or index entry to the corresponding point in the document's body. Since these linkages greatly facilitate usage of the specification, access to an on-line version of this specification is strongly recommended.

1.5 Change Review Process

In order to accelerate the update process, accommodate world-wide involvement, and reduce costs, the AIRE change review process is based on effective use of internet mail reflectors and WWW sites, not on face-to-face meetings.

The applicable language reference manual and language disambiguation authority, such as ISAC, represent the reference point defining language semantics.

The process for making a change to this document involves:

1. Change request sent to aire@vhdl.org (a more specific mail reflector may be needed for the review board). This request need not follow any specific form, but should state as specifically as possible what change is needed and ideally why.

2. Comment period sufficiently long for all interested parties to identify critical pros and cons of the proposed change. Conversely, keeping the comment period open too long delays the update process. The minimum period for comment should be fixed, perhaps at 2 weeks. A moderator is essential to keep this process on track and establish a closure point.

3. Precise statement of the document change proposed, circulated to the CRB reflector.

4. Consensus-based decision which respects all implementations involved, if needed at the cost of increased specification and tool implementation complexity. This is the price of inter-operability.

5. Specification editor will update the applicable text, maintaining change bars in the margin for at least 6 months. FTL Systems, Inc. is committed to provide specification documentation and editing services for AIRE through 1999. All editorial changes to the document are the result of following the above steps.

6. Update of FTP and WWW sites maintaining the specification.

The IIR specification will be placed under change review control following completion of the first two trial implementations (expected in June, 1996).

The change review process is intended to satisfy ISO 9000 compliance requirements. Changes will be made to the above process as needed to comply with ISO 9000.