Standard Parasitic Exchange Format

SPEF (Standard Parasitic Exchange Format) is documented in chapter 9 of IEEE 1481-1999. Several methods of describing parasitics are documented, but we are discussing only a few important ones. General Syntax A typical SPEF file will have 4 main sections: • a header section, • a name map section, • a top level port section, and • the main parasitic description section. Generally, SPEF keywords are preceded with an asterisk, for example: *R_UNIT, *NAME_MAP and *D_NET. Comments start anywhere on a line with // and run to the end of the line. Each line in a block of comments must start with //. Header Information The header section is 14 lines containing information about: • the design name, • the parasitic extraction tool, • naming styles, and • units. When reading SPEF, it is important to check the header for units as they vary across tools. By default, SPEF from Astro will be in pF and kΩ while SPEF from Star-RCXT and Quantus QRC will be in fF and Ω. Name Map Section To reduce file size, SPEF allows long names to be mapped to shorter numbers preceded by an asterisk. This mapping is defined in the name map section. For example: • NAME_MAP • 509 F_C_EP2 • 510 F_C_EP3 • 511 F_C_EP4 • 512 F_C_EP5 • 513 TOP/BUF_ZCLK_2_pin_Z_1 • 514 TOP/BUF_ZCLK_3_pin_Z_1 • 515 TOP/BUF_ZCLK_4_pin_Z_1 Later in the file, F_C_EP2 can be referred to by its name or by *509. Name mapping in SPEF is not required. Also, mapped and non-mapped names can appear in the same file. Typically, short names such as a pin named A will not be mapped as mapping would not reduce file size. One can write a script to map the numbers back into names. This will make SPEF easier to read, but greatly increase file size. Port Section The port section is simply a list of the top level ports in a design. They are also annotated as input, output or bidirect with an I, O or B. For example: • PORTS • 1 I • 2 I • 3 O • 4 O • 5 O • 6 O • 7 O • 8 B • 9 B Parasitics Each extracted net will have a *D_NET section. This will usually consist of a *D_NET line, a *CONN section, a *CAP section, *RES section, and an *END line. Single pin nets will not have a *RES section. Nets connected by abutting pins will not have a *CAP section. • D_NET regcontrol_top/GRC/n13345 1.94482 • CONN • I regcontrol_top/GRC/U9743:E I *C 537.855 9150.11 *L 3.70000 • I regcontrol_top/GRC/U9409:A I *C 540.735 9146.02 *L 5.40000 • I regcontrol_top/GRC/U9407:Z O *C 549.370 9149.88 *D OR2M1P • CAP 1 regcontrol_top/GRC/U9743:E 0.936057 2 regcontrol_top/GRC/U9409:A regcontrol_top/GRC/U10716:Z 0.622675 3 regcontrol_top/GRC/U9407:Z 0.386093 • RES 1 regcontrol_top/GRC/U9743:E regcontrol_top/GRC/U9407:Z 10.7916 2 regcontrol_top/GRC/U9743:E regcontrol_top/GRC/U9409:A 8.07710 3 regcontrol_top/GRC/U9409:A regcontrol_top/GRC/U9407:Z 11.9156 • END The *D_NET line tells the net name and the net's total capacitance. This capacitance will be the sum of all the capacitances in the *CAP section. *CONN Section The *CONN section lists the pins connected to the net. A connection to a cell instance starts with a *I. A connection to a top level port starts with a *P. The syntax of the *CONN entries is: *I <pin name> <direction> *C <xy coordinate> <loading or driving information> Where: • The pin name is the name of the pin. • The direction will be I, O, or B, corresponding to input, output, or bidirectional signals, respectively. • The xy coordinate will be the location of the pin in the layout. • For an input, the loading information will be *L and the pin's capacitance. • For an output, the driving information will be *D and the driving cell's type. • Coordinates for *P port entries may not be accurate because some extraction tools look for the physical location of the logical port (which does not exist) rather than the location of the corresponding pin. *CAP Section The *CAP section provides detailed capacitance information for the net. Entries in the *CAP section come in two forms, one for a capacitor lumped to ground and one for a coupled capacitor. A capacitor lumped to ground has three fields: • an identifying integer, • a node name, and • the capacitance value of this node. Example 1 regcontrol_top/GRC/U9743:E 0.936057 A coupling capacitor has four fields: • an identifying integer, • two node names, and • the values of the coupling capacitor between these two nodes. Example 2 regcontrol_top/GRC/U9409:A regcontrol_top/GRC/U10716:Z 0.622675 If net A is coupled to net B, the coupling capacitor will be listed in each net's *CAP section. *RES Section The *RES section provides the resistance network for the net. Entries in the *RES section contain 4 fields: • an identifying integer, • two node names, and • the resistance between these two nodes. Example 1 regcontrol_top/GRC/U9743:E regcontrol_top/GRC/U9407:Z 10.7916 The resistance network for a net can be very complex. SPEF can contain resistor loops or seemingly ridiculously huge resistors even if the layout is a simple point to point route. This is caused by the extraction tool cutting nets into tiny pieces for extraction and then mathematically stitching them back together when writing SPEF. Parasitic Values The above examples show a single parasitic value for each capacitor or resistor. It is up to the parasitic extraction and delay calculation flow to decide which corner this value represents. SPEF also allows for min:typ:max values to be reported: 1 regcontrol_top/GRC/U9743:E 0.936057:1.02342:1.31343 The IEEE standard requires either 1 or 3 values to be reported; however, some tools will report min:max pairs and it is expected that tools may report many corners (corner1:corner2:corner3:corner4) in the future. == The Difference Between Parasitic Data Formats ==

SPEF is not the same as SPF (including DSPF and RSPF). Detailed Standard Parasitic Format is a very different format, meant to be useful in a SPICE simulation. For example, *NET sections do not have endings, and comments should start with two asterisks. A brief syntax of the DSPF format is as shown below. • DSPF 1.0 • DIVIDER / • DELIMITER : • BUS_DELIMITER [ ] • |GROUND_NET NetName .SUBCKT • NET NetName NetCap • |I(InstancePinName InstanceName PinName PinType PinCap X Y) • |P(PinName PinType PinCap X Y) • |S(SubNodeName X Y) .ENDs .END The acronyms stand for: • SPF — Standard Parasitic Format • DSPF — Detailed Standard Parasitic Format • RSPF — Reduced Standard Parasitic Format • SPEF — Standard Parasitic Exchange Format • SBPF — Synopsys Binary Parasitic Format SPF is a Cadence Design Systems standard for defining netlist parasitics. DSPF and RSPF are the two forms of SPF; the term SPF itself is sometimes used (or misused) to represent parasitics in general. DSPF and RSPF both represent parasitic information as an RC network. RSPF represents each net as an RC "pi" model, which consists of an equivalent "near" capacitance at the driver of the net, an equivalent "far" capacitance for the net, and an equivalent resistance connecting these two capacitances. Each net has a single "pi" network for the network, regardless of how many pins are on the net. In addition to the pi network, RSPF causes the PrimeTime tool to calculate an Elmore delay for every pin-to-pin interconnects delay. In contrast, DSPF models a detailed network of RC parasitics for every net. DSPF is therefore more accurate than RSPF, but DSPF files can be an order of magnitude larger than RSPF files for the same design. In addition, there is no specification for coupling caps in DSPF. DSPF is more similar to a SPICE netlist than the other formats. SPEF is an Open Verilog Initiative (OVI) — and now IEEE — format for defining netlist parasitics. SPEF is not identical to the SPF format, although it is used in a similar manner. Like the SPF format, SPEF includes resistance and capacitance parasitics. Also like the SPF format, SPEF can represent parasitics in detailed or reduced (pi-model) forms, with the reduced form probably being more commonly used. SPEF also has a syntax that allows the modeling of capacitance between different nets, so it is used by the PrimeTime SI (crosstalk) analysis tool. SPEF is smaller than SPF and DSPF because the names are mapped to integers to reduce file size. SBPF is a Synopsys binary format supported by PrimeTime. Parasitic data converted to this format occupies less disk space and can be read much faster than the same data stored in SPEF format. You can convert parasitics to SBPF, by reading them in and then writing them out with the write_parasitics -format sbpf command. ==References==