How To Read SDF (Standard Delay Format) - Part4

In the last few articles (PART 1, PART 2 and PART 3), we have discussed the following things

• What is SDF and what information it contain?
• Construct of SDF (2 Section – Header and CELL)
• Header Section contain general information about the Tool which is used to create/generate the SDF and the Design related information (like Design name, Process, Voltage, Temperature of the design for which SDF is generated).
• Cell Section can be multiple in the SDF file. These CELL section can represent to a specific Primitive cell (standard Cell) or a region of the design (Blocks) or any instance in a hierarchy.
• Cell section has 3 different sub-section – CELLTYPE , INSTANCE, Timing specification section.
• Timing specification section contain 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.
• DELAY: Specify the delay related information for back-annotation.
• TIMINGCHECK: Specify Timing checks limit data for back-annotation
• TIMINGENV: Specify timing environment data and constraint data for forward-annotation.
• LABEL: Set the values of timing model variables upon that delays and timing constraint values depend

In this Article, we will discuss more details about the DELAY construct. This is the most important part of the SDF. It’s a Standard Delay format – so it’s important to have a separate Article only for Delay.

Delay values are defined in SDF in the form of list. This list can have 1,2,3,6 or 12 pairs. These pairs are corresponds to the transition of the signal at the output port. The sequence of those transition is fixed and described in the following table.

Note:

• If only 1 pair is present in the delay list then it’s same for all 12 transition.
• There are chances that in SDF, any pair has NULL value. It is consider as placeholder for that particular transition. Means the stage where SDF is created, the delay info corresponding to that transition is not available and later it can be filled.

Example 1: (IOPATH i3 o1 () () (2:4:5) (4:5:6) (2:4:5) (4:5:6))

In the above example, there is no delay value present for 0->1 and 1->0 transition.

Type of Delay:

There are 2 types of Delay based on how it will be annotated into the design.

Incremental Delay: If any delay value is defined under this category it means it will add SDF value into the Delay present in the design (at the time you are trying to annotate SDF delay).

Absolute Delay: If any delay value is defined under this category it means it will replace the Delay present in the design (at the time you are trying to annotate SDF delay).

Category of Delay in SDF:

Delay in the SDF can be any of the following category.

1) Input-output path Delay:

• Represent the delays on a legal path from an input/bidirectional port to an output/bidirectional port of a device. Each delay value shall be associated with a unique input_port - output_port pair.
• Input or a bidirectional port can have an edge identifier.
• No edge Identifier can be present in case of output or a bidirectional port.
• Representation of Delay values are in the same fashion as explained in above.
• Construct used in SDF : IOPATH

Note:

• For in1, positive edge identifier is specified.
• These Delay are absolute (ABSOLUTE) in nature. Means it’s going to replace any delay specified in Timing models for these paths under specified transitions.
• For in3, delay values are NULL for first 2 transition (0->1 and 1->0). It means for these transition, Delay values are unchanged (it will remain as-it-is as in the timing models).

2) Conditional path delays:

Now if you want to apply a particular condition before applying a particular path delay, we can use this method. The conditional path delay shall specify conditional (state-dependent) input-to-output path delays.
There are 2 ways to apply the conditions

• If a Particular Condition met, then apply the Delay value
• The annotator must locate in the timing model a path delay with conditions matching those specified in the SDF file. Other path delays between the same ports but with different conditions shall not receive the data.
• The expression shall evaluate to a logical signal, rather than a boolean. The analysis tool shall treat a logical zero as FALSE and any other logical value (1, X, or Z) as TRUE. A particular conditional path delay in the timing model shall be used only if the condition is TRUE.
• Use the SDF Construct : COND
• If a Particular Condition doesn’t met, then apply the Delay value
• The delay values specified in SDF shall be used if none of the conditions specified for the path in the model are TRUE but a signal must still be propagated over the path.
• Use the SDF construct: CONDELSE

3) Port Delay:

• Port delay specify the interconnect delay (actual or estimated) that are modelled as delay at input port.
• Use the SDF Construct: PORT

Note: Above delay is applied same for net between “y” and “c.r1.a” and “c.r2.a”.

4) Interconnect Delay

• The interconnect delay shall specify the propagation delay across a net connecting a driving module port (the source) to a driven module port (the load).
• Either or both ports can be bidirectional. Both source and load ports for the delay path shall be specified.
• Use the SDF Construct: INTERCONNECT

5) Net Delay:

• The net delays shall specify the propagation delays from all sources to all loads of a net.
• Neither start nor end points for the delay path are specified, and the delays from all the source ports to all the destination ports will have the same value.
• Use the SDF Construct: NETDELAY

There are other SDF construct also but I am not discussing them here. The reason being – it will increase the length of the Article & looks to me that’s not required right now.;) For the detail info, you can refer the “IEEE standard for Standard Delay format for electronic design format”. Most of my content also have same reference.

Apart of this – Most important thing is SDF constructs are originally targeted for annotation to tools using the Verilog language, so many SDF constructs are analogous to those in Verilog specify blocks. Those already familiar with the Verilog specify block will find many of the SDF constructs familiar. So it’s very easy for those who are champ in Verilog. 

In the Next Article, we will take a circuit and respective SDF, to give you an idea - how to read SDF with respect to a circuit.