Class and method names are chosen so as to correspond as closely as feasible with the corresponding language standard without violating the original standard's copyright. As one ramification of this design decision, the class and method names tend to be longer than would otherwise be chosen.
VHDL serves as the semantic basis for all extensions currently under development. This breadth facilitates practical design environments using an integrated mixture of VHDL, Verilog and C++ (co-design). By sharing a common IIR, designs represented in one or more of the languages may be more tightly, efficiently and rapidly compiled together.
The IIR is also intended to be portable to a variety of processor and operating system architectures. Processor instruction set architectures may vary in the precision and layout of intrinsic data types as well as address space organizations. Portability requires that the IIR specification can be effectively matched to any of today's mainstream processor architectures and anticipate characteristics of those likely to be in common use within the next 5 to 10 years.
Although C++ is intended as the primary tool development language, it is imperative that IIR be accessible from a variety of mainstream programming languages including C, Ada and Pascal. Many useful tools have and will be developed using languages other than C++.
Distribution of system design tools takes many forms. Many university-developed tools are distributed in source form. Commercially developed tools tend to be distributed in executable (binary). A critical design requirement for this work was the need to support both foundation (IIR implementation) as well as application tools distributed in either source or executable forms.
In order for such an extensible IIR to also remain portable, the format needs to have a well-defined, stable, and common core functionality; it must also have extensibility mechanisms allowing a core-compliant tool to ignore non-core information with minimal impact.
In order to maintain and evolve a core which meets the needs of a broad user community, it is important that there be an open but controlled process for changes to the core IIR. Control by an independent AIRE Change Review Board (CRB), comprised of those actively using the specification in substantial tool development or with substantial motivation for AIRE's success, is critical to the AIRE's long term success.
Objects within the IIR must be rapidly mapped into and out of the corresponding file intermediate representation (FIR) []. Whereas a direct map between IIR and FIR, such as a memory-mapped file, provides high performance, such a technique does not satisfy our portability or integration requirements.
Space and often time requirements dictate use of canonical elements wherever possible. For example, there is only one representation of the identifier "foo" in a given memory image. All uses of "foo" refer back to the common, canonical representation of the identifier.
In order to accommodate rapidly developing standard and locally standard packages, the IIR must avoid "hard-wiring" standard definitions, yet facilitate merging of separately "pre-compiled" designs referring to a common set of standard or utility libraries.
Today, there are no openly available mechanisms by which intellectual property owners may implement discretionary export of their design information. The Open Modeling Forum (OMF) is working to specify a means of distributing fully compiled component models. The OMF does not provide for representation of partially compiled design information; tools are unable to optimize across the caller/callee boundary of a model and are unable to retarget a model; the model is pre-compiled for simulation on a specific target architecture.
Without some means of providing discretionary security within the IIR, intellectual property owners are unwilling to export their design information. Since compiled forms of intellectual property have a well-defined standing in the legal community, it is important that the IIR be considered as a compiled form of the design and not a wrapper around the design's source code.
IIR must be capable of representing as little or as much of the designer's original source code as the designer intends without structural or semantic changes to the underlying IIR definition. A highly obscure representation will remove all meaning from identifiers, elaborate, expand and obfuscate the design. Component tools operating on the IIR must still function on the obscured form of the design. Conversely, some designers require that the IIR contain a loss-less representation of the original design, including comments and source layout. For example, such a complete representation facilitates short-term symbolic debug and long-term documentation of design intent. AIRE's designers intend that the IIR embrace this full usage range.
In order to facilitate AIRE's use, a snap-shot of this specification is available in HTML on the world-wide web and Postscript via anonymous FTP. Such network-based publishing increases availability of the specification while discouraging local modification of the core document. Users are welcome and encouraged to provide hypertext links into their own, clearly distinguished extensions. AIRE's portability disappears if evolution of the core specification is not globally synchronized by a change-control board.
Even more important than formal standardization is the availability of multiple, high-quality, affordable implementations of IIR foundations and applications are critical to AIRE's success. Already, two implementations of the foundation are underway and nearly a dozen applications. At least one university implementation is free for non-commercial use and available for license with commercial support. A second, commercial implementation is geared toward high capacity, parallel tool implementation. Concurrent development of multiple implementations helps to insure that AIRE is sufficiently specified without becoming design documentation for any one implementation [].