Skip to Content

How to Read SPEF File

  • strict warning: Non-static method view::load() should not be called statically in /var/www/drupal_module/views/views.module on line 906.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /var/www/drupal_module/views/handlers/views_handler_filter.inc on line 0.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /var/www/drupal_module/views/handlers/views_handler_filter.inc on line 0.
  • strict warning: Declaration of views_handler_filter_node_status::operator_form() should be compatible with views_handler_filter::operator_form(&$form, &$form_state) in /var/www/drupal_module/views/modules/node/views_handler_filter_node_status.inc on line 0.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /var/www/drupal_module/views/plugins/views_plugin_row.inc on line 0.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /var/www/drupal_module/views/plugins/views_plugin_row.inc on line 0.
  • strict warning: Non-static method view::load() should not be called statically in /var/www/drupal_module/views/views.module on line 906.
  • strict warning: Non-static method view::load() should not be called statically in /var/www/drupal_module/views/views.module on line 906.
  • strict warning: Non-static method view::load() should not be called statically in /var/www/drupal_module/views/views.module on line 906.
  • strict warning: Declaration of views_handler_field_comment::init() should be compatible with views_handler_field::init(&$view, $options) in /var/www/drupal_module/views/modules/comment/views_handler_field_comment.inc on line 0.
  • strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /var/www/drupal_module/views/handlers/views_handler_filter_boolean_operator.inc on line 0.

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 few important one.

General Syntax

A typical SPEF file will have 4 main sections

  1. – a header section,
  2. – a name map section,
  3. – a top level port section and
  4. – the main parasitic description section.

Generally, SPEF keywords are preceded with a *. 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

  1. – the design name,
  2. – the parasitic extraction tool,
  3. – naming styles
  4. – 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 kOhm while SPEF from Star-RCXT will be in fF and Ohm.

Name Map Section

To reduce file size, SPEF allows long names to be mapped to shorter numbers preceded by a *. 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. You can write a script will 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 a *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 for input, output or bidirect.

– 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 then 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

– e.g

o 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

– E.g

o 2 regcontrol_top/GRC/U9409:A regcontrol_top/GRC/U10716:Z 0.622675

If netA is coupled to netB, 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 *RES section contain 4 fields,

– an identifying integer,

– two node names and

– the resistance between these two nodes.

– E.g

o 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 due how the extraction tool cuts nets into tiny pieces for extraction and then mathematically stitches 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.

Reference:

-- EOF-TRUEVUE --