D Related Standards

VHDL, as a hardware description language, is a fundamental tool for designing electronic circuits and systems. However, it does not stand alone. It must be part of a collection of methodologies, tools and utilities that form a complete electronic design automation (EDA) environment. The IEEE Design Automation Standards Committee (DASC) and other groups are actively developing standards that specify these other components of the EDA suite. In this appendix, we briefly introduce those standards that have been completed or are in progress and discuss future evolution of existing standards.

The IEEE practice is to designate authorized standards development projects that are in progress with the letter ‘P’ followed by the standard number. Several of the projects are in this state at the time of writing. When their development work is complete and the standard is passed, the ‘P’ will be dropped to form the official standard number.

The reader should bear in mind that the information here is a snapshot of standards at the time of writing. In the field of EDA, things move quickly. A good starting point for up-to-date information is the EDA Industry Working Groups Web page at umiw.eda.org. For each of the standards described in this appendix, we list the Web address of the group responsible for maintaining the standard.

VHDL is officially defined in IEEE Standard 1076–2001, IEEE Standard VHDL Language Reference Manual. This document is maintained by a subcommittee of the DASC called the VHDL Analysis and Standardization Group (VASG). At the time of writing, the VASG is preparing for the next revision of the language, scheduled for completion around 2006. The initial stages of preparation involve collecting requirements for changes and enhancements from VHDL users and other stakeholders. The group’s Web pages currently include a “Bugs and Enhancements” form for users to provide input to this process.

The DASC VHDL PLI Task Force is developing a specification for a programming language interface to VHDL design databases and simulators. The PLI defines a collection of C functions for accessing static information about an elaborated VHDL model, for controlling activity in a VHDL simulator, for accessing and modifying the values of VHDL objects during simulation, and for interfacing non-VHDL models with a VHDL simulation. These functions can be used for design processing tools, such as translators, delay calculators, debuggers, code profilers and coverage analyzers, and specialized behavioral models. At the time of writing, it is unclear whether the PLI will be published as an annex to the VHDL standard document, or as a separate standard document.

While many electronic systems are entirely digital, there are many that include at least a small part that are analog in nature. Indeed, any system that interfaces to the “real world” must contain some analog components, such as transducers and analog/digital converters. Unfortunately, the mechanisms for describing and simulating analog circuits are quite different from those used in the digital domain. Analog modeling typically uses simultaneous differential and algebraic equations to model analog behavior, requiring iterative numerical techniques for solution. This contrasts with the programming language form of description used in VHDL to model digital behavior and the discrete event paradigm used to simulate digital systems.

IEEE Standard 1076.1-1999, IEEE Standard VHDL Analog and Mixed-Signal Extensions, defines extensions to VHDL for modeling systems composed of analog and digital components. The extended language is informally known as VHDL-AMS. The approach taken is to allow the designer to define natures, which have across and through properties. A nature is used to model a particular analog domain. For example, we can define an electrical nature that has voltage as its across property and current as its through property. Other natures might include thermal nature, with temperature drop and heat flow as properties, and rotational nature, with torque and angular velocity as properties. The analog behavior of a system is specified in terms of interconnected nodes, at which Kirchoff conservation laws apply, and equational relations between analog quantities, namely, values of a given nature. The system is simulated by solving the user-specified equations subject to the conservation laws. The language extensions also specify mechanisms for interfacing between the analog and digital domains. These include predefined functions and attributes for allowing analog threshold crossings to cause digital events and for converting digital values to analog quantities.

The interested reader should see The Designer’s Guide to VHDL-AMS, by Ash-enden, Peterson and Teegarden, forthcoming from Morgan Kaufmann Publishers.

In Chapter 8 we described the packages math_real and math_complex. These packages are defined in IEEE Standard 1076.2-1996, IEEE Standard VHDL Mathematical Packages. At the time of writing, the IEEE 1076.2 Working Group has not been active. However, the standard needs to be reviewed soon, so there is an opportunity for considering enhancements when the Working Group reconvenes.

In Chapter 8 we also described the packages numeric_bit and numeric_std. These packages are defined in IEEE Standard 1076.3-1997, IEEE Standard VHDL Synthesis Packages. The standard also specifies the interpretation by synthesis tools of the standard logic types defined in std_logic_1164. At the time of writing, the IEEE 1076.3 Working Group also has not been active. However, the 1076.3 standard also needs to be reviewed soon, providing an opportunity for considering enhancements.

One of the most difficult aspects of designing a digital system is the timing. This is one reason why features to deal with timing are such a major part of VHDL. However, as a language, VHDL just provides basic mechanisms. It does not provide a complete methodology for specifying or testing the detailed timing behavior of a circuit. In response to this lack, a consortium of interested parties, including ASIC vendors and designers, formed an organization called the VHDL Initiative Towards ASIC Libraries (VITAL). They developed a standard practice for including detailed timing information in VHDL models of ASIC cells and a standard interface for back-annotation of timing data from layout tools. They also developed a library of primitive components (gates, flipflops, registers, etc.) that conform to the methodology. The goal was to allow a designer to perform “sign-off” simulation of a design, namely, a sufficiently detailed simulation to satisfy both designer and ASIC foundry that the fabricated ASIC will function as simulated. The VITAL Committee subsequently transferred the specifications to an IEEE Working Group, resulting in development of IEEE Standard 1076.4-1995, IEEE Standard VITAL Application-Specific Integrated Circuit (ASIC) Modeling Specification.

The VITAL standard specifies a package, vital_timing in library ieee, containing types for specifying detailed pin-to-pin propagation delays and timing constraints, including maximum, minimum and nominal values. The package also provides procedures for performing timing checks. The VITAL standard methodology involves the designer including generic constants for timing data in entity declarations. The names and types for the generic constants are specified by the standard, as is the way in which they should be used within architecture bodies to implement correct timing behavior and to verify timing constraints. Instead of using configuration declarations to include actual back-annotated timing data, the standard allows simulators to read the data from files in Standard Delay Format (SDF). The reasons for this approach are that SDF is widely used already and that reading the data in this format is faster than analyzing a VHDL version and reconfiguring the model. The VITAL standard also specifies a package, vital_primitives, that provides subprograms to assist in expressing the behavior of ASIC cell models. The subprograms include operations to model basic logic primitives, such as gates, multiplexers and decoders, as well as operations to model combinatorial truth tables and sequential state tables.

At the time of writing, the IEEE 1076.4 Working Group has prepared a revision of the standard, to be published in 2001. The revision addresses several usability issues that were raised with the 1995 standard. However, the most significant enhancement is inclusion of a new package, vital_memory, that defines data types and subprograms to support development of memory models.

Most organizations that use VHDL find it necessary or desirable to develop a library of packages of generally useful operations. This follows the good software engineering practice of code reuse. Since VHDL’s widespread adoption, many organizations have made their utility packages freely available. However, designers often find the urge to “do it better” irresistible.

The P1076.5 Working Group was formed to develop a utility library to add to the collection of IEEE standard packages. However, very little interest was shown in the work, and the project has since lapsed. We mention it here so that the curious reader will know why the number 1076.5 is missing from the sequence of 1076 “dot” standards.

In Appendix A we described the Synthesis Interoperability standard, formally known as IEEE Standard 1076.6-1999, IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis. The subset of VHDL described in the standard is referred to by the IEEE 1076.6 Working Group as the Level 1 subset. It is deliberately very restrictive, in order to allow models to be accepted by as many synthesis tools as possible. At the time of writing, the Working Group is specifying a Level 2 subset, in which many of the restrictions are relaxed.

The PI577 Object-Oriented VHDL (OOVHDL) Working Group is developing extensions to VHDL to support object-oriented modeling of data and designs. The intention is to improve designer productivity by raising the level of abstraction in models and by supporting the styles of reuse afforded by object-oriented techniques. These techniques have gained wide acceptance in the software engineering community.

In an object-oriented version of VHDL, we can describe the data manipulated by a model in terms of class hierarchies. A class encapsulates the types of data elements and the operations that we apply to the data. Particular data objects in the model are instances of classes. We achieve reuse by deriving subclasses from parent classes. A subclass inherits data elements and operations from the parent and can add further data elements and operations and override inherited operations with new versions appropriate to the added data. The combination of encapsulation and inheritance make it easier for us to manage the complexity of data and operations in a large model, such as a behavioral model on a system-wide scale, or a test-bench suite for a large system. This is important, given the increasing complexity of modern “system on a chip” designs.

The OOVHDL Working Group is also investigating application of object-oriented techniques to design entities. In this case, we treat entity declarations as class definitions, and architecture bodies as the corresponding class implementations. We can derive a new entity from a parent, inheriting the generic constants and ports, and adding further generic constants and ports. For the derived entity, we can define a derived architecture body that inherits the concurrent statements from a parent architecture body and adds further concurrent statements to implement additional behavior. In this way, we can incrementally build a design, adding new functionality at each step.

The Working Group is also investigating extension of the notion of generics by allowing generic types. The idea is that we can specify a formal generic type for use in a design entity or class. Then, when we instantiate the design entity or class, we specify an actual type to be used for that instance. As an example, we might describe a generic multiplexer, with a generic type T, that has two inputs of type T and an output of type T. The statements to select between the inputs to assign to the output do not depend on the specific type T. We could instantiate the multiplexer with the actual type bit and connect the inputs and outputs to signals of type bit. We could also instantiate the same multiplexer with the actual type integer and in this case connect the inputs and outputs to signals of type integer. By this means, we have achieved significant reuse of design effort, thus increasing our design productivity.

The OOVHDL Working Group is developing a specification for a Trial Use standard. This is a formal mechanism within the IEEE standards process for getting user feedback on a standard in development. Once published, the Trial Use standard will have a lifetime of two years. After that, it may be revised and published as a full standard. In the case of OOVHDL, it is not clear yet whether the language extensions will remain as a full standard separate from the base VHDL standard or be included in a later revision of the base standard.

The IEEE P1551 Working Group is developing a Standard for VHDL Electronic Digital System and Interface Design, based on the VHDL+ extensions to VHDL developed by ICL. The ideas behind the extensions are to raise the level of abstraction of design and to allow a designer to express the interfaces and communications protocols between modules independently of the module implementations.

In VHDL+, we describe an interface as a separate design unit. Within it, we specify the message types that can be sent between entities that implement the interface. Messages are specified hierarchically. At the top level, we describe a message as consisting of one or more data elements. At lower levels, we specify compositions of the message using sequences of more primitive data types. For example, at the top level we might describe a message as a set of integers, and at lower levels we might specify how the bits of the integers are sent in sequence. VHDL+ also allows us to describe a transaction on an interface as consisting of a sequence of messages of different types.

Within an architecture body in VHDL+, we can describe the behavior of the module in terms of concurrent activities. The activities are an abstraction of hardware resources, so invocation of an activity involves implicit arbitration for the resource it represents. An activity can send and receive messages through the interface implemented by the design entity.

A novel feature of VHDL+ is the way in which we can specify inexact timing. When describing times at which events occur, or durations for activities, we can specify intervals of time or ranges of clock cycles. This allows us to avoid specifying precise timing early in the design process. Compare this with standard VHDL, in which we must specify exact times and durations.

In this book we have made extensive use of the package std_logic_1164. The package is defined in IEEE Standard 1164–1993, IEEE Standard Multivalue Logic System for VHDL Model Interoperability (Std_logic_1164). At the time of writing, the Working Group responsible for the standard has not been active. However, the standard is overdue for review, and there has been call for inclusion of some minor enhancements.

IEEE Standard 1029.1-1998, IEEE Standard for VHDL Waveform and Vector Exchange to Support Design and Test Verification (WAVES) Language Reference Manual, specifies use of VHDL to exchange stimulus/response test vector information between simulation and test environments. Because it relies purely on VHDL, it is a nonproprietary format.

A WAVES test set is a collection of VHDL packages, including a waveform generator procedure that produces a stream of stimulus or expected response values (a waveform) for a unit under test. The procedure draws upon the resources of a number of predefined WAVES packages to specify the values in the waveform and the timing relationships between waveform elements. The VHDL packages in a WAVES data set may be augmented with external files containing data in a non-VHDL format. The waveform generator procedure may read data from these files to construct the waveform.

One of the difficulties with WAVES is that it simply defines a format for describing a waveform generator. It does not indicate how a generator is to be incorporated into a VHDL test bench to test operation of a simulation model. To address this problem, a group at Rome Laboratories of the United States Air Force has developed a WAVES-VHDL Tool Set. It includes a tool to generate a WAVES test set and a VHDL test bench from a VHDL entity declaration and a tool to generate automatic test equipment (ATE) files from a WAVES test set. The tool set is available from the WAVES Working Group Web page.

While VHDL is a major tool for design of digital systems, there are other standardized tools that complement it to form a complete EDA environment. Some of these are standardized by the IEEE, whereas others are specified by other organizations. In this section, we list several major EDA standards and projects that are not specifically VHDL-based.

Verilog is “the other” hardware description language. While it is widely used in North America and Asia, it is much less popular in Europe. It originated as a proprietary simulation language and was subsequently handed over to the IEEE and published as IEEE Standard 1364–1995, IEEE Standard Description Language Based on the Verilog Hardware Description Language. The Working Group responsible for maintaining the standard operates under the auspices of Open Verilog International (OVI). At the time of writing, a revised version of the standard is being prepared for publication in 2001.

Verilog addresses many of the same requirements of a hardware description language as VHDL. However, it lacks the emphasis on strong software-engineering discipline and support. In particular, it does not have the rich type system of VHDL. Instead, data is represented and manipulated at the bit and bit-vector level. Furthermore, Verilog does not provide support for managing complex structural design hierarchy. However, the language does offer better support than VHDL for modeling at low levels of abstraction, in particular, gate level and switch level. For these reasons, many designers choose VHDL for their models at the behavioral and register-transfer levels and use synthesis tools to generate Verilog models at the gate level. They then rely on Verilog simulation tools to perform final timing verification of the design.

The Verilog-2001 revision of the standard addresses some of the shortcomings of Verilog for behavioral-level modeling and for design configuration. For further information, see the Working Group’s Web page.

The IEEE P1364.1 Working Group is developing a specification of a synthesizable subset of Verilog, analogous to the subset of VHDL defined in IEEE Standard 1076.6.

The Verilog-AMS Technical Subcommittee of OVI is developing extensions to Verilog for modeling analog and mixed-signal systems. Verilog-AMS uses much of the same underlying theory for describing analog behavior as VHDL-AMS. It allows description in terms of differential and algebraic equations relating values of potential and flow quantities at nodes in the analog circuit and provides transition generators and threshold-crossing detectors for interfacing between analog and digital parts of a model. Information about the extensions and example models can be found in the Verilog-AMS Subcommittee’s Web pages.

In this book we have described the use of VHDL for expressing models of hardware designs. We have also mentioned Verilog as an alternative hardware description language. However, in some cases, model vendors choose to express models using a programming language, such as C or C++. There are various reasons for doing so. One is that the code generated by programming language compilers is generally much more efficient, and hence higher in performance, than that generated by a VHDL or Verilog compiler. Another is the protection of intellectual property (IP) afforded by supplying compiled programming language object files instead of VHDL or Verilog source code. Furthermore, use of programming languages allows interfacing with hardware modelers and emulators to accelerate simulation.

For models written using programming languages to be portable across host platforms and different simulators, there needs to be a specification for the interface between models and simulators. Such a specification was developed by the Open Model Forum (OMF), a consortium of simulator and model vendors. The specification was subsequently standardized as IEEE Standard 1499–1998, IEEE Standard Interface for Hardware Description Models of Electronics Components. It specifies a set of functions to be implemented by a simulator and a model that allow the model to drive values on signals and to respond to events generated by the simulator.

The System Level Design Language (SLDL) Initiative was formed under the auspices of the EDA Industry Council and subsequently migrated to VHDL International. Its charter is to develop languages to support high-level specification and design of microelectronic systems. This also encompasses specification and design of the environment in which the systems operate, including software, mixed-signal, optical and micro-electronic/mechanical characteristics. At the time of writing, the SLDL Committee has two Working Groups. The Mechanisms of Computation Working Group is defining the forms of computation and process interaction required in different domains of description (for example, discrete event and discrete time systems, state-based systems, and continuous systems described using differential equations). The Language Working Group is defining the Rosetta description language, in which system-level specifications and constraints will be expressed.

The OVI Design Constraints Working Group is developing a standard for a Design Constraints Description Language (DCDL). We can use a hardware description language to describe the functionality of a design, but it is difficult to express the constraints under which that design must operate. Examples of constraints include timing, power and area constraints. The Timing Constraints Working Group is initially focusing on timing constraints, since they are relatively well understood. The DCDL allows the designer to express such constraints as setup and hold times and path-specific propagation delays and to supply ranges of permissible values. The Working Group is collaborating with the SLDL Initiative (see above), which is also addressing the issue of describing constraints, but in a broader context.

The Virtual Socket Interface Alliance (VSIA) is a member-based organization addressing the needs of “system on a chip” design. Their approach is centered around use of predesigned blocks of intellectual property, or virtual components (VCs) in VSIA terminology. VSIA is assembling a collection of specifications for virtual sockets, that is, interfaces to VCs, describing VC functionality and physical and electrical properties. VSIA adopts and endorses standards developed by other organizations, but where no standard exists for a particular requirement, VSIA is developing its own specifications. The organization has a number of Development Working Groups (DWGs) addressing development of standards: Analog Mixed-Signal, Implementation/Verification, IP Protection, Manufacturing Related Test, On-Chip Buses, System-Level Design, Virtual Component Transfer, and Verification. Information about the specifications developed by these DWGs is available in the VSIA Web pages.

Standard Delay Format (SDF) is a file format for expressing detailed timing information about a design. The data in an SDF file is a tool-independent representation of path delays, timing constraint values, interconnect delays and high-level technology parameters. The SDF specification was originally developed as a proprietary format and subsequently standardized by OVI. It has gained widespread acceptance by EDA tool vendors. Recently, the specification was handed over to an IEEE Working Group. At the time of writing, the draft standard has been approved and should be published in 2001.

The Advanced Library Format (ALF) Technical Committee of OVI has developed a specification for a format to describe ASIC library cells for use by synthesis tools, timing and power analysis tools, and other physical design tools. The description of a library cell includes specification of its function; its timing and electrical characteristics; and other data needed for synthesis, layout and test. The format also allows for specification of library information, such as interconnect models and technology physical data.

The Delay and Power Calculation System (DPCS) and Delay Calculation Language (DCL) were originally developed under the auspices of the Silicon Integration Initiative (SI²) and OVI. The specifications were subsequently standardized as IEEE Standard 1481–1999, IEEE Standard for Delay and Power Calculation. DCL is a language for use by an ASIC cell provider to specify how delays should be calculated for cells in a given technology library. A DCL description is compiled into a Delay Calculation Module (DCM) that is incorporated into the library. The standard specifies a procedural interface for use by EDA tools to invoke the delay calculation rules in the DCM. The DPCS also makes use of information represented in two subsidiary formats: the Physical Data Exchange Format (PDEF), for floor plan information, and the Standard Parasitic Extended File (SPEF) format, for interconnect parasitic information resulting from the detailed layout of the ASIC design. Among other applications, the DPCS can be used in timing analysis tools that generate SDF timing information for detailed timing simulation of a design.

The Open Library Architecture (OLA) is a development by the SI², based on a merger of ALF, DCL and the DCL procedural interface, described above. The OLA specification includes a procedural interface for EDA tools to access all of the functional, timing and physical design data for library cells. The information in the library is generated by ASIC library vendors from source information conforming to the ALF, DCL and related standards. At the time of writing, the OLA Task Force plans to form an IEEE Working Group to develop an IEEE standard.

The Chip Hierarchical Design System Technical Data Standard (CHDStd) program, jointly sponsored by SI² and SEMATECH, defines an integrated data model and procedural interface for accessing design data. It is based on technology developed at IBM. The model integrates data from a design library, a semiconductor process library and an ASIC technology library and also deals with engineering change orders expressed in an ECO language. The CHDStd specification draws on other standards, including the OLA mentioned above for dealing with the technology library. The motivation behind the program is to provide EDA tools with a single procedural interface to deal with all of the data required for design processing, rather than having to deal with a number of different file formats and database access procedures.

EDIF is a standard for exchanging electronic design information between EDA tools and for transferring the information to manufacturers. The standard originated with the Electronic Industries Alliance (EIA) and has subsequently been adopted as an international standard by the International Electrotechnical Commission (IEC). EDIF Version 3 0 0 is IEC Standard 61690–1, and EDIF Version 4 0 0 is IEC Standard 61690–2. Version 3 0 0 provides for description of schematics connectivity, design hierarchy, libraries and configuration, while Version 4 0 0 adds support for describing printed circuit boards and multichip modules.

The EIA has developed the VHDL Hardware Component Modeling and Interface Standard to provide guidelines for component models. The standard addresses issues similar to those addressed by P1076.4, but with an emphasis on modeling existing hardware components rather than ASICs under development. The EIA-567-A standard specifies the form and content of an electronic data sheet for a hardware component, analogous to the paper data sheets provided by component manufacturers. The electronic data sheet includes an electrical view, a timing view and a physical view, all of which are written as VHDL packages. The data sheet also includes a VHDL simulation model that implements the component behavior, a test bench and stimulus/response test vectors, VHDL configuration declarations required to build a simulation and documentation for the model user. The electrical view specifies the signal voltage and current characteristics for each electrical connection of the component. The physical view specifies all of the pins of the physical package of the component, including power supply and electrically unconnected pins. The timing view specifies the values of timing parameters, such as setup and hold times, pulse widths and propagation delays for minimum, nominal and maximum operating points. The standard also describes the generic constants to be included in an entity interface to specify wire delays at inputs and load delays at outputs.

The Library of Parameterized Modules (LPM) standard allows mapping of digital designs into different implementation technologies such as programmable logic devices, gate arrays and standard cells. The standard specifies a collection of generic technology-independent logic functions that can be used by designers or synthesis tools to implement a design. Each function has a number of parameters that are used to specialize the module for a particular application. For example, the counter module has parameters that specify the width, whether the counter counts up or down, whether it loads synchronously or asynchronously, and so on. Each technology vendor supplies their own implementation of the library modules for use with their place and route tools. Versions of the LPM descriptions exist in EDIF, VHDL and Verilog formats.