Envisia HDL Modeling Reference

1

HDL Synthesis Overview

The Ambit® BuildGates® synthesis software accepts VHDL, Verilog, and EDIF HDL

(Hardware Description Language) design modules. This chapter introduces the basic steps involved in HDL synthesis, including: the process of reading in design data described in Verilog, VHDL, and EDIF and generating the corresponding hardware implementation in the form of a generic netlist (i.e. technology independent) netlist. The resulting generic netlist is then optimized and mapped to the target technology.

HDL Synthesis Flow

Figure 1-1 shows the typical steps involved in HDL synthesis. Each step is described in the following sections.

Envisia HDL Modeling Reference

HDL Synthesis Overview

Figure 1-1 Typical HDL Synthesis Flow

Chip Planning

Read Libraries

read_alf

Read Design Data

read_adb read_edif read_vhdl read_verilog

Build Generic Design

do_build_generic

Generate

Generic Netlist

write_adb write_edif write_vhdl write_verilog

Read Technology Libraries

In general, HDL synthesis produces generic hardware implementations for the HDLdesigns being synthesized. Such generic implementations are comprised of ATL (Ambit Technology

Library) and XATL (Extended Ambit Technology Library) cells. However, for some arithmetic

Envisia HDL Modeling Reference

HDL Synthesis Overview

components such as multiplexers, adders, and multipliers, it is often advantageous to base architectural decisions on the type of cells available in the target technology library. For example, if the target technology has booth encoder cells, then it is possible to generate a booth-encoded multiplier during HDL synthesis. If the technology library contains multiplexor cells, then the option exists to implement a multiplexor as a tree of those multiplexor cells rather than using AND/OR gates.

For this reason, the first step in HDL synthesis involves reading the target technology library file into BuildGates synthesis using the read_alf command. For example:

ac_shell> read_alf lca300k.alf

Read Design Data

The next step in HDL synthesis is to read in the design data in the form HDLs such as VHDL (read_vhdl) and Verilog (read_verilog). For example:

ac_shell> read_verilog controller.v dma.v

In BuildGates synthesis, there are no restrictions on the order in which designs are read in; you can read the designs either in a bottom-up or top-down fashion. In VHDL however, for any one design, its entity must be read in prior to its architecture, and all packages must be read in prior to reading in entities and architectures that refer to them.

When reading in RTL modules, the following constraints apply:

■VHDL is case-insensitive and Verilog is case-sensitive; care must be taken when using the tool to synthesize mixed VHDL and Verilog designs in the same session.

■VHDL modules that have similar names are treated as identical modules. For example, if VHDL modules FOO and foo are read in sequentially, foo will replace FOO in the synthesis module pool.

■If there are both VHDL and Verilog modules with similar names in different cases, they are considered identical modules. For example, if Verilog module FOO and VHDL module foo are read in sequentially, the last module read into the tool will take precedence. In this case, VHDL module foo will replace Verilog module FOO in the synthesis module pool.

If design data was saved in a previous BuildGates synthesis session as a binary .adb file (Ambit Binary Database), the file can be read in using the read_adb command. The advantages of using .adb files to exchange design information from one session to another is the speed in which such files are written and read, compared to ASCII text HDL files.

Envisia HDL Modeling Reference

HDL Synthesis Overview

Build Generic Design

After reading in the design data, the next step in HDL synthesis is to generate the hardware implementation of the design using the command do_build_generic:

ac_shell> do_build_generic

The do_build_generic command performs the following functions:

■Generates a control/data flow graph to analyze the read-in designs

■Determines the number and type of registers (latches and flip-flops) needed to store any data values in the design.

■Determines the types and sizes of arithmetic components (adders, multipliers, etc.) required to implement the operations in the designs.

■Generates the appropriate control and interconnection logic.

After the build, the design is represented internally as a generic netlist.

In the case of EDIF designs, there is no need to perform do_build_generic; the read_edif command directly generates the generic netlist from the EDIF description.

It is worth noting that in the presence of design data spread across several files, there is no difference between reading in all the HDL files then performing a single do_build_generic, or reading in modules one at a time and performing a do_build_generic on each one individually.

Save Generic Netlist

Once the generic netlist is generated, various logic and timing optimizations can be performed on the design. Alternatively, a generic netlist can be written out in a variety of formats such as Verilog (write_verilog), VHDL (write_vhdl), EDIF (write_edif), or as a binary database (write_adb). One potential use of writing out generic netlists in VHDL or Verilog is to verify the functionality of the generic netlist produced by do_build_generic against the original design using techniques such as simulation or formal verification.

Use the write_adb command to save the generic netlist for optimization in another session, reading in the file with the read_adb command. Using a binary netlist database to exchange database information preserves optimization-related attributes that are stored on netlist objects; these attributes would be lost if the netlist was saved in a VHDL or Verilog format.

In addition, the write_vhdl and write_verilog commands have an -equation option that writes out the cells instantiated in the design in the form of equations instead of