How To Read SDF (Standard Delay Format) - Part3

Part1

Part2

Part3

Part4

In the Part2, we have discussed following things.

• What are SDF Constructs?
• Syntax of SDF file
• Sample SDF file.
• Header Section and details of various Constructs present in that.

As we come to know that SDF file has 2 different section. Header section ( which we have discussed in Part2 ) and Cell Section. He we will discuss about the Cell section.

Cell Section:

Cell Section has all the important information require for timing calculation like delay, timing constraints, timing environment and etc for a particular cell or part of the design.
In the SDF, its necessary that at least "1" (one) cell section should be present. There is no limit on higher side. Sequence of Cell section is also important in the SDF file. Lets suppose that there are 2 cell sections defining the timing properties/specification for same part of the design, then the information in one section can override (Replace the existing information- this will happen when the ABSOLUTE keyword is present in the cell section) Or may be cumulative with other information ( added to previous information- if INCREMENTAL keyword is present in the cell section). EDA tools read the file from top to bottom ( or say beginning to end) and apply the different constraint or information in the similar sequence.

So there are 2 files and both has overlap information then designer should take care of the sequence before sourcing those file in the EDA tool. 

Syntax of Cell section:      (CELL  <cell_type>  <cell_instance>  <timing_spec> )

Below are the different SDF file Constructs and their details which are the parts of Cell Section.

Fields/Entities of Cell Section		SDF File Constructs	Remark
Cell type		CELLTYPE	Name of a particular cell or a region of the design.
Cell instance		INSTANCE	Specify the path of cell instance
Timing Specification	Delay	DELAY	Specify the delay related information for back-annotation
	Timing Check	TIMINGCHECK	Specify Timing checks limit data   for back-annotation
	Timing environment	TIMINGENV	Specify timing environment data and constraint data for forward-annotation
	Label	LABEL	Set the values of timing model variables upon that delays and timing constraint values depend

A snapshot of sample SDF file present in the part2 to understand most of the things.

(CELL                                                                             // Cell 2

(CELLTYPE "AND2")

(INSTANCE top/b/d)

(DELAY

(ABSOLUTE

(IOPATH a y (1.5:2.5:3.4) (2.5:3.6:4.7))

(IOPATH b y (1.4:2.3:3.2) (2.3:3.4:4.3))

)

)

)

(CELL                                                                              // Cell 3

(CELLTYPE "DFF")

(INSTANCE top/b/c)

(DELAY

(ABSOLUTE

(IOPATH (posedge clk) q (2:3:4) (5:6:7))

(PORT clr (2:3:4) (5:6:7))

)

   )

(TIMINGCHECK

(SETUPHOLD d (posedge clk) (3:4:5) (-1:-1:-1))

(WIDTH clk (4.4:7.5:11.3))

)

)

You can see that there are multiple definition of the Cell section. In each cell section, CELLTYPE and INSTANCE (cell_instance)  and at least one of the timing specification entity (DELAY, TIMINGCHECK, TIMINGENV, LABEL) is defined. There may be Zero "0" entity of timing specification in a particular SDF, but then there is no meaning of define that cell section.

Few more detail about above parameters...

CELLTYPE

It represent the Name of the Cell in the design. That may be either the cell name mentioned with in the Library (e.g standard cell library) OR name of a particular region with in the design ( e.g Name of a Block).

E.g- In my sample SDF file in part2, there are 3 types of CELLTYPE.

• (CELLTYPE "MYDESIGN")  >> Name of My design.
• (CELLTYPE "AND")  >> Name of a cell present in standard cell library.
• (CELLTYPE "DFF")   >> Name of a block present in my design at some hierarchy.

INSTANCE

It identify the region with in the design for which timing information is present in the cell section. If you want to apply the timing constraints for a particular instance of a cell, then you have to mention of the complete path of that particular instance. Else if you want to use associated timing data with all occurrences of the specified cell type, then in the INSTANCE mention wild character ( * ).

Path of the instance should start from the same level of design from where EDA tool (or say annotator) is instructed to apply the SDF file.

For example-

• From the top level the path of AND gate is "Top/block1/block2/block3/AND" but you have instructed to annotator to apply a SDF from block2 level, then the path in the INSTANCE should be "block3/AND".
• Similarly if you will mention (INSTANCE *) in the above case, then the timing information only link to the AND gate present in the same level or in below levels, not at a level of block1.

This entry should be in consistance with the CELLTYPE. It should not be the case that Cell name is AND and the instance path is with respect to the NAND gate.

Timing Specification:

Each cell in the SDF file shall include zero or more timing specifications that contain the actual timing data associated with that cell. There are four types of timing specifications that are identified by the DELAY, TIMINGCHECK, TIMINGENV, and LABEL keywords. Out of these DELAY and TIMNGCHECK data used for back-annotation and TIMINGENV used for forward-annotation. We will discuss about the back forward annotation in other blog.

Lets discuss these timing specification one by one.

DELAY:

There are 4 ways to implement the delay value on the design defined in the SDF file.

Types of Delay	SDF File Constructs	Remark
Path-pulse delay	PATHPULSE	Both Constructs specify how pulses shall propagate across paths in corresponding cell
Path-pulse percent delay	PATHPULSEPERCENT
Absolute delay	ABSOLUTE	Containing delay values to be applied to the region identified by the cell
Increment delay	INCREMENT

Path-Pulse Delay and Path-Pulse Percent Delay:

As such both are same and only difference in terms of representation of value. In Path pulse Percent Delay every thing is in terms of percentage only.

These parameter usually apply a limit on a PULSE and determine whether a pulse of certain width can travel through a device or not and appear in which form to output.

Syntax is (PATHPULSE <input port> <output_port> <pulse_rejection_limit> <X-limit>)

Note:

• If input_port and output_port is not defined then these limits applied to all paths present in the instance defined by cell entry.
• pulse_rejection_limit means if the width of Pulse is less then this value, nothing will appear at the output.
• X-limit means if width is less then this but greater then pulse_rejection_limit, output will be unknown (means X stage).
• If any one value is provided in place of these 2 limits, then both limits are set to that value.
• These Limits must not be in negative.

ABSOLUTE and INCREMENT:

ABSOLUTE - introduce delay data to replace existing delay values in the design during annotation.

INCREMENT -introduce delay data that is added to existing delay values in the design during annotation.

Both of these can be specified with the help of same type of SDF constructs. These are based on the type of Delay in a design.

Delay type	SDF Construct	Description
Input output path delay	IOPATH	Represent delays from an input/bidirectional port to an output/bidirectional port of a device.
Conditional Delay	COND	Specify conditional (state-dependent) input-to-output path delays
	CONDELSE	Specify default delays (if none of the conditions specified for the path in the model is TRUE but a signal must still be propagated over the path) for conditional paths.
Port Delay	PORT	Specify interconnect delays (actual or estimated). Start point of the delay path is not specified.
Propagation/ Interconnect/ Net Delay	INTERCONNECT	Specify the propagation delay across a net connecting a driving module port (the source) to a driven module port (the load).
	NETDELAY	Specify the propagation delays from all sources to all loads of a net. Neither start nor end points are specified, so have same value from all source ports to destination ports.
Device Delay	DEVICE	Represent the delay of all paths through a cell to the specified output port
Output Retain Delay	RETAIN	Represent the time required to retain the previous logic even after a change in input port.

TIMINGCHECK:

Timing checks specify different types of limits for signal/signals the way they can change (in terms of values). Different types of limits are SETUP, HOLD, SETUPHOLD, RECOVERY, REMOVAL, SKEW, WIDTH and PERIOD. These are well known terminology in the timing, so not discussing in this blog.

Different EDA analysis tools use this information in different ways:

• Simulation tools issue warnings about signal transitions that violate timing checks.
• Timing analysis tools identify delay paths that might cause timing check violations and shall determine the constraints for those paths.
• Synthesis tools use timing check values to determine if their results meet timing requirements.

TIMINGCHECK:

Specify constraint values with critical paths in the design (PATHCONSTRAINT, PERIODCONSTRAINT, or SKEWCONSTRAINT) and provide information about the timing environment (ARRIVAL, DEPARTURE, SLACK, or WAVEFORM) in which the circuit shall operate. Constructs in this sub-clause are used in forward-annotation and not back-annotation.

Again, above constraint and environment are well know terminology in the Timing, so not discuessing in this blog.

Please see the Next Blog for few example, application of SDF constructs in different situations/circuit and how delay values are specified in a SDF and how can you interpret those values.