Tabular Design Formats:The SDF Format.

The SDF Format

Objective of the SDF Format

SDF is an abbreviation for Standard Delay Format published by the non-commercial interest group, Accellera, a unification of Open Verilog International and VHDL International [8.4]. SDF is no language and no program but it describes how delay data should be formatted in a design process. The goal is to make that kind of data independent from the CAD programs of different suppliers.

The present version is 3.0. The format is kept relatively stable and only improvements are added so that data sets from older versions are still compatible. For that reason and because version 2.1 is widely used, the following descriptions deal mainly with this version 2.1.

There are SDF formats for single devices (ASICs, such as FPGAs, gate arrays, and cell based standard products) and also for multiple system modules, as shown in fig. 8.1.

The SDF format must be independent of programs and still represent data of different types:

• Delay Times which could be associated with the following information:

– module path;

– device;

– interconnect;

– port.

• Clock Constraints:

– setup and hold times;

– recovery after asynchronous reset;

– skew;

– width;

– period.

• Path and Skew Constraints;

• Incremental and Absolute Delays;

• Conditional Delays and Constraint Checks;

• Design Specific or Library Specific Data;

• Production Tolerances and Operational Limits:

– data triple [best, nom and worst case];

– temperature;

– supply voltage.

SDF may be a standardized format, but the libraries, programs, and design flows which are involved have to be coordinated. In that sense, SDF eases a consistent implementation, but does not guarantee it.

SDF Files in a Design Flow

There are typically two types of timing specifica- tions in design flows:

Forward Annotation; and Back Annotation

Forward Annotation

Forward annotation describes the transfer of timing constraints generated during the specification process to the subsequent logic synthesis and layout generation steps. In the later steps the programs have to try and meet the constraints within their frame of optimization.

For example, a synthesis program is supposed to  generate a structural design for a given maximum of operational clock frequency. Thereby the area is to be minimized without significantly exceeding the frequency.

Back Annotation

Back annotation means the feed-back of delay information after successful synthesis or layout.

After a Place&Route run, the wire lengths and loads can be extracted and re-calculated in form of an SDF delay format for cells and interconnect. Finally, the data may be fed back into a timing analyzer or a digital simulator. In the case of back annotation, the SDF files always exist next to the netlist files, because the analysis tools need both data sets. Figure 8.2 demonstrates the principle of both types of annotation.

In the case of forward annotation into the synthesis program constraint data based on the target specification have to be transferred. The delay data after the synthesis run (Back Annotation Pre- Layout) are usually generated by formulas, taking into account the complete netlist. Depending on the estimated physical dimension, additional delay data are calculated for each instance of a cell. That type of calculation is often carried out within the simulator.

The timing constraints for the layout steps may consist of a few ‘critical paths’ based on the pre- layout digital simulations. A much more exact  calculation can be done after the layout generation (Back Annotation Post-Layout). The extraction program for generating the post-layout data has to be able to identify the actual ‘critical paths’ in order to check the original target of maximum clock frequency.

Structure and Elements of SDF

SDF is a nested format of expressions in parentheses with specific SDF key words. The following values may be of type text string, value triple, or further parenthetical expressions. The exact definition of key words can be found in [8.5].

A Header Section at the beginning is always followed by Cell Entries.

VOLTAGE, PROCESS and TEMPERATURE are followed be three values (triple) best:nom:worst. They de- scribe the conditions for the following timing analysis. The header information has the character of documentation because only the values following the delay entries are used.

The value of TIMESCALE sets the unit for interpret For describing the cell and its instance name the following three key words can be used which cor- respond directly with the netlist:

 

One of the most common elements of delay times is IOPATH, which describes the name of the input and output pins of the timing path. The format for an inverter could look like this:

An SDF Example

This example has been created on an ALTERA system. It serves the purpose of demonstrating SDF in a mixed design flow:

• The design has been created on a front-end design system with a high level language, such as

VHDL or Verilog. It could have been a behavioral or RTL (Register Transfer Language) level design, which may have been verified by a high level simulation run before synthesis;

• After the synthesis run for an ALTERA target library the netlist has been transferred to the ALTERA system via EDIF;

• During the subsequent compilation the physical CPLD placement file and the timing data have been created;

• By using EDIF for the netlist and SDF for the set of timing data a final timing simulation can be done on the front-end design system;

• This final verification step has to ensure the conformity to the original timing constraints.

An automatic comparison of the simulation runs of the behavioral (pre-placement) and the structural (post-placement) can also be conducted.

In this example the timing triple contains three times the same value, which prevents a true best- case/worst-case analysis. The conditions, which are valid for all three values, are explained in the header section:

Some functional cells, such as AND2, have values of 0.0 only. The ALTERA system has re-structured some logic to the specific CPLD. Some functions may exist in the netlist and the SDF file, but not in the optimized physical implementation, for example DELAY_24.