Languages for Design and Implementation of Hardware:System-Level Design Flow

As the size and complexity of digital systems increase, more computer-aided design (CAD) tools are introduced into the hardware design process. Early simulation and primitive hardware generation tools have given way to sophisticated design entry, validation, high-level synthesis, formal verification, automatic hardware and layout generation, automatic test pattern generation, and various design and test utilities. Growth of design automation tools is largely due to languages for description and modeling hardware and design methodologies that are based on these languages. Languages in hardware design are used for description of hardware at various levels of abstraction as well as description of hardware for interfacing various design tools and equipment.

The category of hardware-related languages that are used for describing hardware are called hardware description languages (HDLs). On the basis of HDLs, new digital system CAD tools have been developed and are now widely utilized by hardware designers. At the same time new languages and formats for porting a hardware description from one tool to another and from tools to test and manufacturing equipment are designed. Work on languages for higher level design and easier and better verification and test of designs continues. In today’s fast changing VLSI technology, the knowledge of hardware languages for VLSI designers is a necessity.

This chapter presents an overview of a modern hardware design process and based on this, discusses the languages needed for each stage of the design process. We discuss steps involved in taking a high-level hardware–software description from a system description to its implementation in hardware. Processes and terminologies are illustrated here.

System-Level Design Flow

For the design of a digital system, the design flow begins with specification of the system at a high level of abstraction and ends with files representing test data, layouts, and the final hardware in the form of a chip or a board. In this process, languages are used for data representation, design entry, or tool control. Figure 85.1 shows a high-level design flow and languages that are used in each step of the design.

System-Level Languages

At the highest level of abstraction, a design is entered as an interaction of processes and tasks. A designer at this level does not have to worry about what processes are done in hardware and what is done in software, rather, a designer studies his or her system from the point of view of tasks that have to be performed by the complete design and how these tasks interact with each other. Languages used for this purpose are UML, C, and C++. Chapter 86 of this handbook covers these languages. Since C and C++ are software languages that are too extensive to be covered as part of a chapter, our presentation in Chapter 86 will merely focus of terminologies needed for understanding other hardware languages that are derived from C and C++.

After the complete high-level analysis of a design, a designer’s attention goes to partitioning the system description into hardware and software parts and defining communications between them. Communications describe how data are exchanged between various system components regardless of them being hardware or software components. Languages used for description of software parts of a system include C and C++. Although many other languages can effectively be used for this purpose, the strong link between C++ and its hardware-oriented derivates make this language a very popular language in hardware/ software codesign environments.

After system partitioning and when lines are drawn between parts that are to be implemented in hardware and those that are to be implemented in software, hardware parts are described in transaction level modeling (TLM), in C++ for the behavioral components, or in standard register transfer level (RTL) hardware languages. SystemC is a library of functions based on C++. Because this language has strong ties with C++ it is often used for description of hardware in C++. TLM is a library that is written on top of SystemC and is used for description of systems that involve complex mechanisms for data communications. Chapter 86 discusses SystemC and TLM.

RTL Languages

Realization of a hardware described at the high level translates to extracting its RTL description from its high-level description. This process can be done manually, or with new electronic system level (ESL) tools it can be done semiautomatically. After completing this phase of design, translated hardware parts become available in VHDL, Verilog, RTL SystemC, and System Verilog. These languages are discussed in Chapters 87–90 of this handbook.

Like System Verilog, SystemC is considered both as a system-level design language and a powerful RTL language. SystemC covered in Chapter 86 looks at this language from a system point of view, while the presentation of Chapter 89 of SystemC merely focuses on its RTL features.

Description of Analog Parts

Often, a complete system involves several analog parts, and these components must participate in the simulation of the complete system if the simulation is to give a realistic prediction of what happens between analog and digital parts. The same way that SystemC is popular because it has links with its higher-level C++ language, a good analog description language must have links with hardware description languages that are used for the digital parts of a hardware description.

VHDL-AMS is based on VHDL, and analog extensions of VHDL follow the same flow of the VHDL language. This language has features that make it useful for describing analog circuits at various levels of abstraction. In a mixed-simulation environment, analog, digital and software parts of a system are simulated together. Presently, several VHDL-AMS simulators are available that use the same simulation engine to simulate an entire hardware consisting of analog and digital parts. The interfacing between analog signals and digital events is a critical issue that such mixed simulators have to properly deal with. VHDL-AMS is discussed in Chapter 91. It is recommended that this chapter is read after the reader is familiar with the material of Chapter 87 on VHDL.

Verification Languages

Simulators have long been used for design validation. However, because of the complexity of today’s design, other alternatives or complementary verification methods are introduced in the hardware design process. Two such methods are assertion verification and formal verification. Assertion verification uses assertion monitors to monitor design behavior, while formal or static verification uses properties to check against a design.

Instead of having to inspect simulation results manually or by developing sophisticated testbenches, assertion monitors can be used to continuously check for design properties while the design is being simulated. Assertion monitors are put in the design being simulated by the designer. The designer decides that if the design functions correctly, certain conditions have to be met. These conditions are regarded as design properties, and assertion monitors are developed by the designer to assert that these properties are not violated. The standard property specification language (PSL) is a language for description of assertions and design properties. This language is discussed in Chapter 92.

Formal verification is the process of checking a design against certain properties. When a design is completed, the designer develops a set of properties reflecting correct behavior of his or her design. A formal verification tool examines the design to make sure that the described properties hold under all conditions. If a situation is found that the property will not hold, the property is said to have been violated. As mentioned above, PSL is a language that can be used for property specification. In addition, computational temporal logic (CTL) is a property language that has a mathematical orientation. This language is also discussed in Chapter 92.

Primitive and Cell Description Languages

After satisfactory results are obtained from a simulation or verification of a design, the design is synthe- sized to take it one step closer to the actual hardware. At the RT level, the input of a synthesis tool is a hardware described in any of the RTL hardware description languages.

The output of a synthesis tool contains information about the cells used for the implementation of hardware and their interconnections. These cells may be from an ASIC library, or primitive cells of a custom IC. The format this level of hardware is described in must be such that it can be used by hardware generation tools and tools for automatic routing and placement. Although structural VHDL and Verilog can be used for this purpose, other standards, such as electronic design interchange format (EDIF) and VHDL initiative toward ASIC libraries (VITAL), are more commonly used. The VITAL standard is based on VHDL and it contains timing as well as interconnection information. These standards are described in Chapter 93 of this handbook.

EDIF and VITAL, which are primarily used for description of netlists, do not provide placement and geometrical specification of cells used in a hardware implementation. The standard notation, or language, used for layout specification is the GDS2 language. This format that contains complete geometrical and physical information is obtained after layout and placement passes are completed. GDS2 is also described in Chapter 93.

Test-Related Languages

Netlists generated by synthesis tools represent gate level details of hardware being designed. This level of abstraction contains proper information for test generation and fault simulation programs. An automatic

test pattern generation (ATPG) program uses gate level information to generate data for testing the hardware after it is built. A fault simulation program uses test patterns generated by an ATPG to simulate the hardware for possible physical faults. In contrast, data generated by a postsynthesis simulation run can also be used for modeling the correct behavior of a manufactured circuit.

Waveform and vector exchange specification (WAVES) and standard test interface language (STIL) are used for test data representation. These languages that are described in Chapter 94 provide mechanisms for specification of stimuli and timing of data as well as data and timing of expected outputs. Automatic test equipment (ATE) machines use these formats to apply data to a circuit that is being tested and to analyze its responses. In addition, the value change dump (VCD) format (part of Chapter 95) that will be mentioned next is also used as an input format for ATE.

Timing Specification Languages

In addition to netlists, synthesis tools also generate formats that can be used for postsynthesis simulators and timing analyzers. Such formats describe timing of cells and interconnections used in netlists generated by a synthesis tool. One such format is the standard delay format (SDF) that is primarily used for representation of timing of cells used in a netlist. An HDL simulator uses an SDF file for reading timing of the cells used in the hardware structure being simulated. SDF is used by both VHDL and Verilog simulation engines. This format is described in Chapter 95.

Another form of timing representation is used in VCD. VCD that is discussed in Chapter 95 is generated by HDL simulators and is the textual form of waveforms. This makes it a standard way of representing input and output waveforms that are used for graphical waveform displays or for ATE, as discussed in the previous section.