• To translate theoretical knowledge on adder structures as presented in the book and lectures into practical design of these structures.
• To perform a characterization of adder structures, i.e. to generate hardware for different word lengths and different synthesis constraints and then collect and analyze performance data (area, time) for the different results.

• .synopsys_dc.setup: configuration settings for the Synopsys Design Compiler.
• .synopsys_fm.setup: configuration settings for the Synopsys tool Formality.

Hardware Descriptions in VHDL

The file adder_behav_arch.vhd declares an architecture for the adder that contains a behavioral description of addition. The operator '+' is simply used. This means that one leaves it up to Synopsys to decide on the adder structure: the tighter the timing constraints, the faster the structure that Synopsys will choose for initially (at the expense of more area). This initial choice (e.g. "carry-lookahead" when the constraints are tight, and "carry-ripple" when the critical path is not constrained) strongly determines the quality of the final design.

The file adder_ripple_arch.vhd, on the other hand, contains a structural description of an adder, viz. a ripple adder. It makes use of the full-adder entity and architecture as given in the file full_adder.vhd. The full-adders are instantiated using a for ... generate loop. This is a construct that is not (yet) explained in the document VHDL for Simulation and Synthesis. However, the example given in the file should be sufficient to understand the mechanism. Note that conditional generation is possible by means of an if statement. Such an if does not have an else clause.

The file reg_gen.vhd contains a description of a register with a generic word length. The file contains both the entity and architecture declarations as only one architecture for registers will be used in the whole project. The file all_hardware_gen.vhd instantiates the adder and three registers. Two registers are connected to the adder's inputs, one register is connected to the adder's output. In this way, we do not need to bother about combinatorial paths between the adder hardware and primary inputs or outputs. The critical path of the design will always start at a register and finish in a register going through the adder hardware.

The entire hardware contains a generic word length. A concrete value has to be assigned to this generic both for simulation and synthesis. For simulation, this is done by means of a configuration that also involves the testbench (see the testbench section below). The Synopsys Design Compiler tool does not support configurations; there the generic is given a value in the script that calls Design Compiler in batch mode (see the characterization section below). Also Formality requires a specical measure to assign a value to the generic before verification can take place.

Testbench and Simulation

• testvectors: this entity reads inputs from a file data_in.txt and terminates the simulation when the end of this file is reached; it also generates the clock and reset signals.
• testbench_gen: this entity combines the testvectors and the hardware into one model without any I/O; the entity has a generic word length.
• testbench: this is the top-level entity; its only purpose is to be able to assign a value to the word length; this is not done in the entity or architecture, but in configurations of this entity.

• config_ripple_16.vhd: this configuration uses the presynthesis description of the ripple adder for word length 16; study this file and note that a configuration can cover multiple levels of a structural hierarchy.
• config_8_5_behav.vhd: this configuration uses the post-synthesis description of the behavioral adder synthesized for word length 8 and a clock period of 5 ns.

Exercise ADD-1: Presynthesis Simulation

Verify the correctness of the computation by means of simulation.

Now verify the correctness of the carry-ripple architecture by using Formality to prove that it is equivalent to the behavioral architecture. You can operate directly on the adder leaving out the registers around it. You can proceed as explained in SYN except that you cannot use the GUI to select the top-level reference and implementations due to the presences of generics in the implementation. After having loaded the VHDL files for the reference design stored in "container" r, you go to the command-line at the bottom of the window and type there:

set_top r:/WORK/adder -param 16

This tells Formality to assign value 16 to the only top-level generic word_length of the design adder (the syntax for designs with multiple generics is somewhat more complex). WORK is the default library in which Formality "compiles" designs. For the implementation design stored in container i, you need to give the command:

set_top i:/WORK/adder -param 16

From then on, you can carry ahead with matching and verification in the usual way.

Characterization Setup

In the inner loop, a unique instance name composed of word length, clock period and adder structure is used. It is stored in the shell variable INSTANCE. The instance name is used in many places:

• The name of the log file in which the result of each call to dc_shell-t is stored. You have to look into this to collect the information on time and area.
• The entity name of the synthesized design.
• The file names of the synthesized designs. Four versions of the synthesized design are stored in files. First, hierarchical versions in DB and VHDL format, called all_hw_${INSTANCE}_hier.db, respectively all_hw_${INSTANCE}_hier.vhd. The DB format is an internal Synopsys format that can be read by design_vision; make use of this possibility to get a feeling of the result obtained. The other two files are flattened versions of the design in DB and VHDL format (the file names end in _flat rather than in _hier). The VHDL versions can be compiled and configured into the testbench for post-synthesis verification.
• The file name of the SDF file associated to the flattened VHDL description.

Exercise ADD-2: Synthesis and Simulation of New Adder Structure

Write synthesizable VHDL architectures for alternative adder structures, e.g. carry-lookahead adder, carry-select adder, etc. (see the book and slides). Your description should be independent of the word-length value (if you want to keep it simple, you may assume that the word length is an integer multiple of 8). Remember that the entity for the adder is in a separate file and does not need to be modified. Your files should only contain architecture declarations.

You should elaborate on as many alternative structures as you have members in your team (1 adder for students working alone, 2 adders for teams of 2). Verify your description with presynthesis simulation, synthesize your design for a few settings of the parameters and verify the result of synthesis with post-synthesis simulation. Use formal verfication for checking both your pre-synthesis and post-synthesis designs against the behavioral reference design. You just need to modify the generate-all script for performing synthesis.

Exercise ADD-3: Time-Area Plots

The requirements are:

• The architectures that you synthesize should include your own designs as well as the ripple and behavioral architectures.
• The word-lengths of 16, 32 and 64 bits should be investigated.
• The clock periods should be chosen to be meaningful for the particular word length.

Use MS-Excel (or any alternative of your choice) to create separate time-area plots for each of the word lengths considered. Which of the solutions are Pareto optimal?

Deliverables

• An explanation of the adder structure(s) designed by yourself.
• The VHDL source code for your own adder(s).
• Evidence (e.g. waveforms) of simulations with your designs.
• Evidence (taken from the file formality.log) that your design has successfully passed formal verification.
• The time-area plots, as well as the time-area data in tabular form.
• Your comments on the results obtained.