Liberty User Guide Volume 1

Version R-2020.09, September 2020

confidential and proprietary information that is the property of Synopsys, Inc. The software and documentation are

furnished under a license agreement and may be used or copied only in accordance with the terms of the license

agreement. No part of the software and documentation may be reproduced, transmitted, or translated, in any form or

by any means, electronic, mechanical, manual, optical, or otherwise, without prior written permission of Synopsys,

Inc., or as expressly provided by the license agreement.

Right to Copy Documentation

The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.

Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee

must assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:

This document is duplicated with the permission of Synopsys, Inc., for the use of Open Source Liberty users.

Destination Control Statement

All technical data contained in this publication is subject to the export control laws of the United States of America.

Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to

determine the applicable regulations and to comply with them.

Disclaimer

SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,

WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF

MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Trademarks

Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at

https://www.synopsys.com/company/legal/trademarks-brands.html.

All other product or company names may be trademarks of their respective owners.

Third-Party Links

Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse

and is not responsible for such websites and their practices, including privacy practices, availability, and content.

Synopsys, Inc.

690 E. Middlefield Road

Mountain View, CA 94043

www.synopsys.com

Liberty User Guide Volume 1

R-2020.09

Contents

1. Sample Library Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

General Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Group Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

Attribute Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Simple Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Complex Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Define Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Reducing Library File Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2. Building a Logic Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Creating Library Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

library Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Using General Library Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

technology Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

delay_model Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

bus_naming_style Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Delay and Slew Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

input_threshold_pct_fall Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

input_threshold_pct_rise Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

output_threshold_pct_fall Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

output_threshold_pct_rise Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

slew_derate_from_library Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

slew_lower_threshold_pct_fall Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . 40

slew_lower_threshold_pct_rise Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . 40

slew_upper_threshold_pct_fall Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . .41

slew_upper_threshold_pct_rise Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . 41

Defining Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

time_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

voltage_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

current_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

Contents

pulling_resistance_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

capacitive_load_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

leakage_power_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Setting Minimum Cell Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

3. Building Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Library-Level Default Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

Setting Default Cell Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

default_cell_leakage_power Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . 46

Setting Default Pin Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Setting Wire Load Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

default_wire_load Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

default_wire_load_capacitance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

default_wire_load_resistance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

default_wire_load_area Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Setting Other Environment Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

default_operating_conditions Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

default_connection_class Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

Examples of Library-Level Default Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Defining Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

operating_conditions Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Defining Power Supply Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

power_supply group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Defining Wire Load Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

wire_load Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

wire_load_table Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Specifying Delay Scaling Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Pin and Wire Capacitance Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Scaling Factors Associated With the Nonlinear Delay Model . . . . . . . . . . . . . . 57

4. Defining Core Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Defining cell Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

cell Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

area Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

cell_footprint Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

clock_gating_integrated_cell Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Contents

Setting Pin Attributes for an Integrated Cell . . . . . . . . . . . . . . . . . . . . . . . . 63

Setting Timing for an Integrated Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

contention_condition Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

is_macro_cell Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

pad_cell Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

physical_variant_cells Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

pin_equal Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

pin_opposite Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

type Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

cell Group Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

mode_definition Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Group Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

mode_value Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

Defining pin Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

pin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

General pin Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

capacitance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

clock_gate_clock_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

clock_gate_enable_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

clock_gate_obs_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

clock_gate_out_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

clock_gate_test_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

complementary_pin Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

connection_class Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

direction Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

driver_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

fall_capacitance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

fault_model Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

inverted_output Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

is_analog Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

pin_func_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84

steady_state_resistance Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84

test_output_only Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Describing Design Rule Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

fanout_load Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

max_fanout Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

min_fanout Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

max_transition Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

max_trans Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

min_transition Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90

max_capacitance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

max_cap Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Contents

min_capacitance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

cell_degradation Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Describing Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

clock Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

min_period Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

min_pulse_width_high and min_pulse_width_low Attributes . . . . . . . . . . . . 95

Describing Clock Pin Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

internal_node Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Defining Bused Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

type Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

bus Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

bus_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Pin Attributes and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Example Bus Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Defining Signal Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

bundle Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

members Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107

pin Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Defining Layout-Related Multibit Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Defining Multiplexers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Library Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Defining Decoupling Capacitor Cells, Filler Cells, and Tap Cells . . . . . . . . . . . . . . 112

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Cell-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

is_decap_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

is_filler_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

is_tap_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113

Fault Tolerant Cell Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Library-Level Attributes and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

altitude_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

soft_error_rate_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

default_soft_error_rate Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

soft_error_rate_confidence Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Cell-Level Attributes and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

soft_error_rate Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Fault Tolerant Library Modeling Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

5. Defining Sequential Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Contents

Using Sequential Cell Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Describing a Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Using the ff Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

clocked_on and clocked_on_also Attributes . . . . . . . . . . . . . . . . . . . . . . . 119

next_state Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

nextstate_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

clear Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

preset Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

clear_preset_var1 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

clear_preset_var2 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

power_down_function Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

ff Group Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Describing a Single-Stage Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

Describing a Master-Slave Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Using the function Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125

Describing a Multibit Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126

Describing a Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

latch Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

enable and data_in Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

data_in_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

clear Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

preset Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

clear_preset_var1 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

clear_preset_var2 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Determining a Latch Cell’s Internal State . . . . . . . . . . . . . . . . . . . . . . . . . 133

Describing a Multibit Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

latch_bank Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Describing Sequential Cells With the Statetable Format . . . . . . . . . . . . . . . . . . . . 138

statetable Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Using Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Partitioning the Cell Into a Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Defining an Output pin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

state_function Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146

internal_node Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

input_map Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

inverted_output Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Internal Pin Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148

Determining a Complex Sequential Cell’s Internal State . . . . . . . . . . . . . . . . . 149

Flip-Flop and Latch Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Contents

Cell Description Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

6. Defining Test Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Describing a Scan Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

test_cell Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Pins in the test_cell Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158

test_output_only Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Describing a Multibit Scan Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162

Multibit Scan Cell With Parallel Scan Chain . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Multibit Scan Cell With Internal Scan Chain . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Scan Cell Modeling Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Simple Multiplexed D Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175

D Flip-Flop With Gated Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177

Multibit Cells With Multiplexed D Flip-Flop and Enable . . . . . . . . . . . . . . . . . . 178

LSSD Scan Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Scan-Enabled LSSD Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Functional Model of the Scan-Enabled LSSD Cell . . . . . . . . . . . . . . . . . . 187

Timing Model of the Scan-Enabled LSSD Cell . . . . . . . . . . . . . . . . . . . . . 188

Scan-Enabled LSSD Cell Model Example . . . . . . . . . . . . . . . . . . . . . . . . . 190

Scan-Enabled LSSD Cell With Asynchronous Inputs . . . . . . . . . . . . . . . . 192

Multibit Scan-Enabled LSSD Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Clocked-Scan Test Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Scan D Flip-Flop With Auxiliary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

7. Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Understanding Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202

Combinational Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Sequential Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203

Modeling Method Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204

Defining the timing Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Naming Timing Arcs Using the timing Group . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Timing Arc Between a Single Pin and a Single Related Pin . . . . . . . . . . . 206

Timing Arcs Between a Pin and Multiple Related Pins . . . . . . . . . . . . . . . 206

Timing Arcs Between a Bundle and a Single Related Pin . . . . . . . . . . . . . 207

Timing Arcs Between a Bundle and Multiple Related Pins . . . . . . . . . . . . 208

Contents

Timing Arcs Between a Bus and a Single Related Pin . . . . . . . . . . . . . . . 209

Timing Arcs Between a Bus and Multiple Related Pins . . . . . . . . . . . . . . . 210

Timing Arcs Between a Bus and a Related Bus Equivalent . . . . . . . . . . . 212

Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

delay_model Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214

Defining the NLDM Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Creating Lookup Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Defining the Scalable Polynomial Delay Model Template . . . . . . . . . . . . . 218

timing Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220

related_pin Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

related_bus_pins Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

timing_sense Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

timing_type Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

mode Complex Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227

Describing Three-State Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Describing Three-State-Disable Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Describing Three-State-Enable Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Describing Edge-Sensitive Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Describing Clock Insertion Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Describing Intrinsic Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

In the CMOS Piecewise Linear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . 236

In the Scalable Polynomial Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Describing Transition Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Defining Delay Arcs With Lookup Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Modeling Transition Time Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241

Modeling Load Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

In the CMOS Scalable Polynomial Delay Model . . . . . . . . . . . . . . . . . . . . . . . 246

Describing Slope Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Describing State-Dependent Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

when Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248

sdf_cond Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250

Setting Setup and Hold Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

rise_constraint and fall_constraint Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

In the Scalable Polynomial Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Identifying Interdependent Setup and Hold Constraints . . . . . . . . . . . . . . . . . . 256

Setting Nonsequential Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Setting Recovery and Removal Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . 258

Contents

Recovery Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Removal Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Setting No-Change Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262

Setting Skew Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Setting Conditional Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

when and sdf_cond Simple Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

when_start Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

sdf_cond_start Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

when_end Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268

sdf_cond_end Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268

sdf_edges Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268

min_pulse_width Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

min_pulse_width Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

constraint_high and constraint_low Simple Attributes . . . . . . . . . . . . . . . . 269

when and sdf_cond Simple Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

minimum_period Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

minimum_period Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

constraint Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

when and sdf_cond Simple Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

min_pulse_width and minimum_period Example . . . . . . . . . . . . . . . . . . . . . . . 270

Using Conditional Attributes With No-Change Constraints . . . . . . . . . . . . . . . 272

Impossible Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273

Examples of NLDM Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

CMOS Piecewise Linear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Library With Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Library With Clock Insertion Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Describing a Transparent Latch Clock Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280

Driver Waveform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Library-Level Tables, Attributes, and Variables . . . . . . . . . . . . . . . . . . . . . . . . 283

normalized_voltage Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

normalized_driver_waveform Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

driver_waveform_name Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Cell-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

driver_waveform Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284

driver_waveform_rise and driver_waveform_fall Attributes . . . . . . . . . . . . 284

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285

driver_waveform Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285

driver_waveform_rise and driver_waveform_fall Attributes . . . . . . . . . . . . 285

Driver Waveform Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Contents

Sensitization Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287

sensitization Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

pin_names Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

vector Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Cell-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

sensitization_master Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

pin_name_map Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

timing Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289

sensitization_master Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

pin_name_map Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

wave_rise and wave_fall Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

wave_rise_sampling_index and wave_fall_sampling_index Attributes . . . 291

wave_rise_time_interval and wave_fall_time_interval Attributes . . . . . . . . 291

timing Group Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

NAND Cell Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Complex Macro Cell Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Phase-Locked Loop Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .296

Phase-Locked Loop Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Cell-Level Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

is_pll_cell Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297

is_pll_reference_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

is_pll_feedback_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

is_pll_output_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Phase-Locked Loop Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298

8. Modeling Power and Electromigration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Modeling Power Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Static Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Dynamic Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301

Internal Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Switching Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .302

Switching Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303

Modeling for Leakage Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Representing Leakage Power Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

cell_leakage_power Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Using the leakage_power Group for a Single Value . . . . . . . . . . . . . . . . . . . . 304

when Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

value Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

Contents

leakage_power_unit Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

default_cell_leakage_power Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . .307

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Threshold Voltage Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

Modeling for Internal and Switching Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

Modeling Internal Power Lookup Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Representing Internal Power Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

Specifying the Power Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315

Using Lookup Table Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

power_lut_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

Scalar power_lut_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Defining Internal Power Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Naming Power Relationships, Using the internal_power Group . . . . . . . . . . . .318

Power Relationship Between a Single Pin and a Single Related Pin . . . . .319

Power Relationships Between a Single Pin and Multiple Related Pins . . . 319

Power Relationships Between a Bundle and a Single Related Pin . . . . . . 320

Power Relationships Between a Bundle and Multiple Related Pins . . . . . .321

Power Relationships Between a Bus and a Single Related Pin . . . . . . . . .322

Power Relationships Between a Bus and Multiple Related Pins . . . . . . . . 323

Power Relationships Between a Bus and Related Bus Pins . . . . . . . . . . . 325

internal_power Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

equal_or_opposite_output Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . 326

falling_together_group Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

related_pin Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

rising_together_group Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

switching_interval Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329

switching_together_group Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . 329

when Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

fall_power Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

power Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332

rise_power Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332

Internal Power Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

One-Dimensional Power Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

Two-Dimensional Power Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Three-Dimensional Power Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . . 338

Modeling Libraries With Integrated Clock-Gating Cells . . . . . . . . . . . . . . . . . . . . . 340

What Clock Gating Does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Looking at a Gated Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341

Using an Integrated Clock-Gating Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Setting Pin Attributes for an Integrated Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

Contents

clock_gate_clock_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

clock_gate_enable_pin Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 344

clock_gate_test_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

clock_gate_obs_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

clock_gate_out_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Clock-Gating Timing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Timing Considerations for Integrated Cells . . . . . . . . . . . . . . . . . . . . . . . . 347

Integrated Clock-Gating Cell Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

Modeling Electromigration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

Controlling Electromigration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

em_lut_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

electromigration Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

related_pin Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

related_bus_pins Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

lifetime_profile Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

em_max_toggle_rate Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .355

em_temp_degradation_factor Simple Attribute . . . . . . . . . . . . . . . . . . . . . 357

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Cell Electromigration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

9. Advanced Low-Power Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

Power and Ground (PG) Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .361

Example Libraries With Multiple Power Supplies . . . . . . . . . . . . . . . . . . . . . . . 361

Partial PG Pin Cell Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

Special Partial PG Pin Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

Supported Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .366

Partial PG Pin Cell Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

PG Pin Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

Library-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

voltage_map Complex Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

default_operating_conditions Simple Attribute . . . . . . . . . . . . . . . . . . . . . . 369

Cell-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

pg_pin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

is_pad Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

voltage_name Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

pg_type Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

physical_connection Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . .371

related_bias_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .371

user_pg_type Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372

direction Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Contents

power_down_function Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

related_power_pin and related_ground_pin Attributes . . . . . . . . . . . . . . . .373

output_signal_level_low and output_signal_level_high Attributes . . . . . . . 373

input_signal_level_low and input_signal_level_high Attributes . . . . . . . . . 373

related_pg_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Timing-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

output_signal_level_low and output_signal_level_high Attributes . . . . . . . 374

Standard Cell With One Power and Ground Pin Example . . . . . . . . . . . . . . . . 375

Inverter With Substrate-Bias Pins Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Insulated Bias Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

Same PG Pin as Both Power Pin and Ground Pin . . . . . . . . . . . . . . . . . . . . . 383

PG Pin Power Mode Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

Library-Level Groups and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .387

voltage_state_range_list Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

voltage_state_range Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .387

Cell-Level Groups and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

pg_setting_definition Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

pg_setting_value Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

default_pg_setting Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

pg_setting_transition Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

illegal_transition_if_undefined Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

Specifying Power States in Timing, Power, and Noise Models . . . . . . . . . . . . 392

pg_setting Attribute in mode_value Group . . . . . . . . . . . . . . . . . . . . . . . . .393

mode Attribute in minimum_period and min_pulse_width Groups . . . . . . . 393

Defining PG Modes in Macro Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

PG Mode Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

Cell With Different Power States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

Power State Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

Macro Cell With PG Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

Retention Cell Leakage Power in Different Power Modes . . . . . . . . . . . . . 400

Feedthrough Signal Pin Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .406

Multipin Feedthroughs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

Single-Pin Feedthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Overdrive and Underdrive Voltage Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408

Internally Unconnected Pin Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Silicon-on-Insulator (SOI) Cell Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412

Library-Level Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .414

is_soi Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

Cell-Level Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

Contents

is_soi Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

Level-Shifter Cells in a Multivoltage Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

Operating Voltages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

Level Shifter Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .415

Basic Level-Shifter Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416

Cell-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416

is_level_shifter Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

level_shifter_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

input_voltage_range Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .417

output_voltage_range Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

ground_input_voltage_range Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

ground_output_voltage_range Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .418

std_cell_main_rail Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

level_shifter_data_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

level_shifter_enable_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

input_voltage_range and output_voltage_range Attributes . . . . . . . . . . . . 419

ground_input_voltage_range Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

ground_output_voltage_range Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

input_signal_level Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .420

power_down_function Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420

alive_during_power_up Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420

Enable Level-Shifter Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420

Differential Level-Shifter Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420

Clamping Enable Level-Shifter Cell Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . 423

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

Level Shifter Modeling Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Level-Shifter Cell Without Enable Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Simple Buffer Type Low-to-High Level Shifter . . . . . . . . . . . . . . . . . . . . . . 425

Simple Buffer Type High-to-Low Level Shifter . . . . . . . . . . . . . . . . . . . . . . 428

Power-and-Ground Level-Shifter Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430

Multibit Level-Shifter Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

Overdrive Level-Shifter Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

Level-Shifter Cell With Virtual Bias Pins . . . . . . . . . . . . . . . . . . . . . . . . . . 437

Simple Enable Level-Shifter Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

Enable Level-Shifter With Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

Clamping in Latch-Based Enable Level-Shifter Cell . . . . . . . . . . . . . . . . . 442

Differential Level-Shifter Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

Isolation Cell Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Cell-Level Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

is_isolation_cell Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .447

Contents

isolation_cell_data_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .447

isolation_cell_enable_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

power_down_function Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

permit_power_down Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .447

alive_during_partial_power_down Attribute . . . . . . . . . . . . . . . . . . . . . . . . 448

alive_during_power_up Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

Attribute Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

Isolation Cell Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

Simple NAND-Type Isolation Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

Simple NOR-Type Isolation Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

NOR-Type Isolation Cell With Inverted Input . . . . . . . . . . . . . . . . . . . . . . . 451

NOR-Type Isolation Cell With Inverted Output . . . . . . . . . . . . . . . . . . . . . 453

Isolation Cell Without Enable Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .454

Multibit Isolation Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455

Clock-Isolation Cell Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458

Cell-Level Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Clock Isolation Cell Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Clamping Isolation Cell Output Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .462

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

Example of Clamping in Isolation Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

Isolation Cells With Multiple Control Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . .464

Switch Cell Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .467

Coarse-Grain Switch Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

Coarse-Grain Switch Cell Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .468

Library-Level Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470

Cell-Level Attribute and Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .470

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

pg_pin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472

Fine-Grained Switch Support for Macro Cells . . . . . . . . . . . . . . . . . . . . . . . . . 472

Macro Cell With Fine-Grained Switch Syntax . . . . . . . . . . . . . . . . . . . . . . 472

Cell-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

pg_pin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

Switch-Cell Modeling Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

Simple Coarse-Grain Header Switch Cell . . . . . . . . . . . . . . . . . . . . . . . . . 474

Complex Coarse-Grain Header Switch Cell . . . . . . . . . . . . . . . . . . . . . . . .476

Complex Coarse-Grain Switch Cell With an Internal Switch Pin . . . . . . . . 478

Complex Coarse-Grain Switch Cell With Parallel Switches . . . . . . . . . . . . 480

Retention Cell Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

Retention Cell Modeling Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

Cell-Level Attributes, Groups, and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 488

Contents

retention_cell Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488

ff, latch, ff_bank, and latch_bank Groups . . . . . . . . . . . . . . . . . . . . . . . . . 488

retention_condition Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488

clock_condition Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

preset_condition and clear_condition Groups . . . . . . . . . . . . . . . . . . . . . . 489

reference_pin_names Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .490

variable1 and variable2 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

bits Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .491

retention_pin Complex Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .491

function Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .491

reference_input Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

save_action and restore_action Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 492

restore_edge_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

save_condition and restore_condition Attributes . . . . . . . . . . . . . . . . . . . . 493

Retention Cell Model Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

Retention Cell With Balloon Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

Retention Cell With Multiple latch Groups . . . . . . . . . . . . . . . . . . . . . . . . . 497

Retention Cell With Multiple latch_bank Groups . . . . . . . . . . . . . . . . . . . . 501

Retention Cell With Edge-Triggered Balloon Logic . . . . . . . . . . . . . . . . . . 504

MUX-Scan Retention Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

Always-On Cell Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

Always-On Cell Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

always_on Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513

Always-On Simple Buffer Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .513

Macro Cell Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514

Macro Cell Isolation Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

Modeling Macro Cells With Internal PG Pins . . . . . . . . . . . . . . . . . . . . . . . . . . 518

Macro Cell With Built-in Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Macro Cell With Fine-Grained Internal Power Switches . . . . . . . . . . . . . . . . . 524

Macro Cell With an Always-On Pin Example . . . . . . . . . . . . . . . . . . . . . . . . . . 525

Modeling Antenna Diodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527

Antenna-Diode Cell Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527

Cell-Level Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

Antenna-Diode Cell Modeling Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

Modeling Cells With Built-In Antenna-Diode Ports . . . . . . . . . . . . . . . . . . . . . . 530

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530

Antenna-Diode Pin Modeling Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

Contents

10. Composite Current Source Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

Modeling Cells With Composite Current Source Information . . . . . . . . . . . . . . . . . 532

Representing Composite Current Source Driver Information . . . . . . . . . . . . . . . . . 532

Composite Current Source Lookup Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . .533

Defining the output_current_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . 533

output_current_template Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533

Template Variables for CCS Driver Models . . . . . . . . . . . . . . . . . . . . . . . . 533

output_current_template Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533

Defining the Lookup Table Output Current Groups . . . . . . . . . . . . . . . . . . . . . 534

output_current_rise Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .534

vector Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

reference_time Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .534

Template Variables for CCS Driver Models . . . . . . . . . . . . . . . . . . . . . . . . 534

vector Group Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535

Representing Composite Current Source Receiver Information . . . . . . . . . . . . . . . 535

Comparison Between Two-Segment and Multisegment Receiver Models . . . . . . . 536

Two-Segment Receiver Capacitance Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537

Defining the receiver_capacitance Group at the Pin Level . . . . . . . . . . . . . . . 538

Defining the lu_table_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539

Conditional Data Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

Defining the Receiver Capacitance Groups at the Timing Level . . . . . . . . . . . 545

Conditional Data Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545

Defining the lu_table_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545

Timing-Level receiver_capacitance Example . . . . . . . . . . . . . . . . . . . . . . .546

Multisegment Receiver Capacitance Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547

Library-Level Groups and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .548

lu_table_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548

receiver_capacitance_rise_threshold_pct and

receiver_capacitance_fall_threshold_pct Attributes . . . . . . . . . . . . . . . . . . 548

Pin and Timing Level Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .549

receiver_capacitance Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .549

Conditional Data Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550

CCS Retain Arc Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552

CCS Retain Arc Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553

ccs_retain_rise and ccs_retain_fall Groups . . . . . . . . . . . . . . . . . . . . . . . . 554

vector Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .554

Contents

reference_time Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554

Compact CCS Retain Arc Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554

compact_ccs_retain_rise and compact_ccs_retain_fall Groups . . . . . . . . 555

base_curves_group Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555

index_1, index_2, and index_3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 556

values Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .556

Composite Current Source Driver and Receiver Model Example . . . . . . . . . . . . . .556

11. Advanced Composite Current Source Modeling . . . . . . . . . . . . . . . . . . . . . . . . 560

Modeling Cells With Advanced Composite Current Source Information . . . . . . . . .560

Compact CCS Timing Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560

Modeling With CCS Timing Base Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . .561

Compact CCS Timing Model Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563

base_curves Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564

compact_lut_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

compact_ccs_{rise|fall} Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566

Compact CCS Timing Library Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566

Variation-Aware Timing Modeling Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

Variation-Aware Compact CCS Timing Driver Model . . . . . . . . . . . . . . . . . . . . 568

timing_based_variation Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569

va_compact_ccs_rise and va_compact_ccs_fall Groups . . . . . . . . . . . . . .570

timing_based_variation and pin_based_variation Groups . . . . . . . . . . . . . 571

Variation-Aware CCS Timing Receiver Model . . . . . . . . . . . . . . . . . . . . . . . . . 572

timing_based_variation and pin_based_variation Groups . . . . . . . . . . . . . 574

va_parameters Complex Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

nominal_va_values Complex Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

va_receiver_capacitance1_rise, va_receiver_capacitance1_fall,

va_receiver_capacitance2_rise, and va_receiver_capacitance2_fall

Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

va_values Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575

Variation-Aware Timing Constraint Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . 575

timing_based_variation Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576

va_parameters Complex Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576

nominal_va_values Complex Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576

va_rise_constraint and va_fall_constraint Groups . . . . . . . . . . . . . . . . . . . 576

va_values Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577

Conditional Data Modeling for Variation-Aware Timing Receiver Models . . . . .577

when Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .578

mode Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578

Variation-Aware Compact CCS Retain Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . .583

Contents

va_compact_ccs_retain_rise and va_compact_ccs_retain_fall Groups . . .584

va_values Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584

values Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .585

Variation-Aware Syntax Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585

va_parameters in Advanced CCS Modeling Usage . . . . . . . . . . . . . . . . . .585

va_compact_ccs_rise and va_compact_ccs_fall Groups . . . . . . . . . . . . . .586

va_values With Three Variation Parameters . . . . . . . . . . . . . . . . . . . . . . . 587

peak_voltage in Values Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588

pin_based_variation Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589

Pin-based Model With nominal CCS receiver model and Variation-Aware

CCS Receiver Model Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .590

nominal_va_values in Advanced CCS Modeling Usage . . . . . . . . . . . . . . 591

Variational Values in Advanced CCS Modeling Usage . . . . . . . . . . . . . . . 591

Variation-Aware CCS Driver or Receiver with Timing Constraints . . . . . . . 592

12. Nonlinear Signal Integrity Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598

Modeling Noise Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598

Noise Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

Noise Immunity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

Noise Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

Modeling Cells for Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

I-V Characteristics and Drive Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .600

Noise Immunity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602

Using the Hyperbolic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605

Noise Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605

Representing Noise Calculation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .606

I-V Characteristics Lookup Table Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .607

iv_lut_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607

Defining the Lookup Table Steady-State Current Groups . . . . . . . . . . . . . . . . 608

I-V Characteristics Curve Polynomial Model . . . . . . . . . . . . . . . . . . . . . . . . . . 609

poly_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609

Defining Polynomial Steady-State Current Groups . . . . . . . . . . . . . . . . . . . . . 610

Using Steady-State Resistance Simple Attributes . . . . . . . . . . . . . . . . . . . . . . 611

Using I-V Curves and Steady-State Resistance for tied_off Cells . . . . . . . . . . 612

Defining tied_off Attribute Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

Representing Noise Immunity Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613

Noise Immunity Lookup Table Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613

noise_lut_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613

Defining the Noise Immunity Table Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 614

Contents

Noise Immunity Polynomial Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616

poly_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616

Defining the Noise Immunity Polynomial Groups . . . . . . . . . . . . . . . . . . . .617

Input Noise Width Ranges at the Pin Level . . . . . . . . . . . . . . . . . . . . . . . . . . . 618

Defining the input_noise_width Range Limits . . . . . . . . . . . . . . . . . . . . . . 618

Defining the Hyperbolic Noise Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620

Representing Propagated Noise Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621

Propagated Noise Lookup Table Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621

propagation_lut_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621

Defining the Propagated Noise Table Groups . . . . . . . . . . . . . . . . . . . . . . 623

Propagated Noise Polynomial Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624

poly_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .625

Defining Propagated Noise Groups for Polynomial Representation . . . . . 626

Examples of Modeling Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628

Scalable Polynomial Model Noise Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 628

Nonlinear Delay Model Library With Noise Information . . . . . . . . . . . . . . . . . . 634

13. Composite Current Source Signal Integrity Modeling . . . . . . . . . . . . . . . . . . . .639

CCS Signal Integrity Modeling Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639

CCS Signal Integrity Modeling Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639

Library-Level Groups and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .644

lu_table_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

variable_1, variable_2, variable_3, and variable_4 Attributes . . . . . . . . . . 644

Pin-Level Groups and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .645

ccsn_first_stage and ccsn_last_stage Groups . . . . . . . . . . . . . . . . . . . . . .645

is_needed Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .646

is_inverting Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646

stage_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646

miller_cap_rise and miller_cap_fall Attributes . . . . . . . . . . . . . . . . . . . . . . 646

output_signal_level and input_signal_level Attributes . . . . . . . . . . . . . . . . 646

related_ccb_node Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .647

dc_current Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

output_voltage_rise and output_voltage_fall Groups . . . . . . . . . . . . . . . . . 647

propagated_noise_high and propagated_noise_low Groups . . . . . . . . . . .647

when Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .648

CCS Noise Library Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648

Conditional Data Modeling in CCS Noise Models . . . . . . . . . . . . . . . . . . . . . . 652

when Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .653

mode Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653

Contents

CCS Noise Modeling for Unbuffered Cells With a Pass Gate . . . . . . . . . . . . . . . . 655

Syntax for Unbuffered Output Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656

Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .657

is_unbuffered Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657

has_pass_gate Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .657

ccsn_first_stage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .657

is_pass_gate Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658

CCS Noise Modeling for Multivoltage Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658

Referenced CCS Noise Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661

Modeling Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661

Cell-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663

driver_waveform Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .663

driver_waveform_rise and driver_waveform_fall Attributes . . . . . . . . . . . . 663

Pin-Level Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663

input_ccb and output_ccb Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663

Timing-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664

active_input_ccb Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665

active_output_ccb Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665

propagating_ccb Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .665

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .665

14. Composite Current Source Power Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 669

Composite Current Source Power Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .669

Cell Leakage Current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670

Gate Leakage Modeling in Leakage Current . . . . . . . . . . . . . . . . . . . . . . . . . . 671

gate_leakage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671

input_low_value Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672

input_high_value Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672

Intrinsic Parasitic Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672

Voltage-Dependent Intrinsic Parasitic Models . . . . . . . . . . . . . . . . . . . . . . 674

Library-Level Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

lu_table_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

Pin-Level Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

lut_values Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

Parasitics Modeling in Macro Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

total_capacitance Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .677

Parasitics Modeling Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678

Dynamic Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .678

Dynamic Power and Ground Current Table Syntax . . . . . . . . . . . . . . . . . . 679

Dynamic Power Modeling in Macro Cells . . . . . . . . . . . . . . . . . . . . . . . . . 679

Contents

Examples for CCS Dynamic Power for Macro Cells . . . . . . . . . . . . . . . . . 681

Conditional Data Modeling for Dynamic Current Example . . . . . . . . . . . . .682

Dynamic Current Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .684

Compact CCS Power Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685

Compact CCS Power Syntax and Requirements . . . . . . . . . . . . . . . . . . . . . . .687

Library-Level Groups and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .688

base_curves Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688

compact_lut_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689

Cell-Level Groups and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690

compact_ccs_power Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690

Composite Current Source Dynamic Power Examples . . . . . . . . . . . . . . . . . . . . . 691

Design Cell With a Single Output Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 691

Dense Table With Two Output Pins Example . . . . . . . . . . . . . . . . . . . . . . . . . .692

Cross Type With More Than One Output Pin Example . . . . . . . . . . . . . . . . . . 692

Diagonal Type With More Than One Output Pin Example . . . . . . . . . . . . . . . .693

15. On-Chip Variation (OCV) Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695

Advanced OCV Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695

Library-Level Groups and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .697

ocv_table_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

ocv_derate Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .697

default_ocv_derate_group Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

ocv_arc_depth Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

Cell-Level Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

ocv_derate_group Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

Advanced OCV Library Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

LVF Models For Cell Delay, Transition, and Constraint . . . . . . . . . . . . . . . . . . . . . 701

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701

Library-Level Groups and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .704

lu_table_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704

ocv_table_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706

ocv_derate Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .706

default_ocv_derate_distance_group Attribute . . . . . . . . . . . . . . . . . . . . . . 707

Cell-Level Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707

ocv_derate_distance_group Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . .707

Timing Arc Level Groups and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .707

ocv_sigma_cell_rise Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

ocv_sigma_cell_fall Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

ocv_sigma_rise_transition Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

Contents

ocv_sigma_fall_transition Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709

sigma_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .709

ocv_sigma_rise_constraint Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709

ocv_sigma_fall_constraint Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710

Parametric OCV Library Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710

LVF Retain Arc Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713

Library-Level Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

lu_table_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

Timing Arc Level Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

ocv_sigma_retaining_rise and ocv_sigma_retaining_fall Groups . . . . . . . 715

ocv_sigma_retain_rise_slew and ocv_sigma_retain_fall_slew Groups . . . 716

sigma_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .716

Library Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716

LVF Moment-Based Models For Ultra-Low Voltage Designs . . . . . . . . . . . . . . . . . 718

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720

Library-Level Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

lu_table_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

Timing Arc Level Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

ocv_std_dev_* Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

ocv_mean_shift_* Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725

ocv_skewness_* Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725

Library Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726

16. Defining I/O Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730

Special Characteristics of I/O Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730

Identifying Pad Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731

is_pad Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731

driver_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731

Defining Units for Pad Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734

Capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734

Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .735

Voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

Current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

Describing Input Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

hysteresis Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

Describing Output Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736

Contents

Drive Current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .736

Slew-Rate Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .736

Modeling Wire Load for Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738

Programmable Driver Type Support in I/O Pad Cell Models . . . . . . . . . . . . . . . . . 739

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739

Programmable Driver Type Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740

Pad Cell Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742

Input Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .743

Output Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746

Bidirectional Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747

Cell with contention_condition and x_function . . . . . . . . . . . . . . . . . . . . . . . . . 748

A. Library Characterization Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751

The char_config Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751

Library Characterization Configuration Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 751

Common Characterization Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754

driver_waveform Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757

driver_waveform_rise and driver_waveform_fall Attributes . . . . . . . . . . . . . . . 758

input_stimulus_transition Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758

input_stimulus_interval Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758

unrelated_output_net_capacitance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 758

default_value_selection_method Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759

default_value_selection_method_rise and default_value_selection_method_fall

Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759

merge_tolerance_abs and merge_tolerance_rel Attributes . . . . . . . . . . . . . . . 760

merge_selection Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760

NLPM Characterization Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .761

CCS Timing Characterization Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762

ccs_timing_segment_voltage_tolerance_rel Attribute . . . . . . . . . . . . . . . . . . . 763

ccs_timing_delay_tolerance_rel Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763

ccs_timing_voltage_margin_tolerance_rel Attribute . . . . . . . . . . . . . . . . . . . . . 763

CCS Receiver Capacitance Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763

Input-Capacitance Characterization Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764

capacitance_voltage_lower_threshold_pct_rise and

capacitance_voltage_lower_threshold_pct_fall Attributes . . . . . . . . . . . . . . . . 764

Contents

capacitance_voltage_upper_threshold_pct_rise and

capacitance_voltage_upper_threshold_pct_fall Attributes . . . . . . . . . . . . . . . . 764

Sample Library Description

This chapter familiarizes you with the basic format and syntax of a library description. The

chapter starts with an example that shows the general syntax of a library. The structure

of the library description is also discussed. These topics are covered in the following

sections:

This chapter includes the following sections:

•

General Syntax

•

Statements

• Reducing Library File Size

General Syntax

Example 1 shows the general syntax of a library description. The first statement names

the library. The statements that follow are library-level attributes that apply to the entire

library. These statements define library features such as the technology type, definitions,

and defaults. Every cell in the library has a separate cell description.

Example 1 General Syntax of the Library Description

library (name) {

technology (name) ; /* library-level attributes */

delay_model : generic_cmos | table_lookup | cmos2 |

piecewise_cmos | dcm | polynomial ;

bus_naming_style : string;

routing_layers (string) ;

time_unit : unit ;

voltage_unit : unit ;

current_unit : unit ;

pulling_resistance_unit : unit ;

capacitive_load_unit (value, unit) ;

leakage_power_unit : unit ;

piece_type : type ;

piece_define ("list") ;

define_cell_area (area_name, resource_type) ;

/* default values for environment definitions */

Liberty User Guide Volume 1

R-2020.09

Chapter 1: Sample Library Description

Statements

operating_conditions (name) {

/* operating conditions */

}

timing_range (name) {

/* timing information */

}

wire_load (name) {

/* wire load information */

}

wire_load_selection () {

/* area/group selections */

}

power_lut_template (name) {

/* power lookup table template information */

}

cell (name1) { /* cell definitions */

/* cell information */

}

cell (name2) {

/* cell information */

}

scaled_cell (name1) {

/* alternate scaled cell information */

}

...

type (name) {

/* bus type name

}

input_voltage (name) {

/* input voltage information */

}

output_voltage (name) {

/* output voltage information */

}

Statements

Statements are the building blocks of a library. All library information is described in one of

the following types of statements:

•

Group statements

•

Attribute statements

• Define statements

A statement can continue across multiple lines. A continued line ends with a backslash (\).

Liberty User Guide Volume 1

R-2020.09

Chapter 1: Sample Library Description

Statements

Group Statements

A group is a named collection of statements that defines a library, a cell, a pin, a timing

arc, and so forth. Braces ({}), which are used in pairs, enclose the contents of the group.

Syntax

group_name (name) {

... statements ...

}

name

A string that identifies the group. Check the individual group statement syntax

definition to verify if name is required, optional, or null.

You must type the group name and the { symbol on the same line.

Example 2 defines a pin group A.

Example 2 Group Statement Specification

pin(A) {

... pin group statements ...

}

Attribute Statements

An attribute statement defines characteristics of specific objects in the library. Attributes

applying to specific objects are assigned within a group statement defining the object,

such as a cell group or a pin group.

In this user guide, attribute refers to all attributes unless the manual specifically states

otherwise. For clarity, this manual distinguishes different types of attribute statements

according to syntax. All simple attributes use the same general syntax; complex attributes

have different syntactic requirements.

Simple Attributes

This is the syntax of a simple attribute:simple attributesimple attributesyntax

attribute_name : attribute_value ;

You must separate the attribute name from the attribute value with a space, followed by a

colon and another space. Place attribute statements on a single line.

Example 3 adds a direction attribute to pin group A shown in Example 2.

Liberty User Guide Volume 1

R-2020.09

Chapter 1: Sample Library Description

Statements

Example 3 Simple Attribute Specification

pin(A) {

direction : output ;

}

For some simple attributes, you must enclose the attribute value in quotation marks:

attribute_name : "attribute_value" ;

Example 4 adds the X + Y function to the pin example.

Example 4 Defining the Function of a Pin

pin (A) {

direction : output ;

function : "X + Y" ;

}

Complex Attributes

This is the syntax of a complex attribute statement. Include one or more parameters in

parentheses. complex attributecomplex attributesyntax of statement

attribute_name (parameter1, [parameter2, parameter3 ...] );

The following example uses the line complex attribute to define a line on a schematic

symbol. This line is drawn from coordinates (1,2) to coordinates (6,8):

line (1, 2, 6, 8);

Define Statements

You can create new simple attributes with the define statement.

Syntax

define (attribute_name, group_name, attribute_type) ;

attribute_name

The name of the new attribute you are creating.

group_name

The name of the group statement in which this attribute is specified.

attribute_type

The type of attribute you are creating: Boolean, string, integer, or floating point.

Liberty User Guide Volume 1

R-2020.09

Chapter 1: Sample Library Description

Statements

For example, to define a new string attribute called bork, which is valid in a pin group, use

define (bork, pin, string) ;

You give the new attribute a value using the simple attribute syntax:

bork : "nimo" ;

Reducing Library File Size

Large library files can compromise disk capacity and memory resources. To reduce file

size and improve file management, the syntax allows you to combine multiple source

files by referencing the files from within the source file containing the library group

description. During library compilation, the referenced information is retrieved, included at

the point of reference, and then the compilation continues.

Use the include_file attribute to reference information in another file for inclusion during

library compilation. Be sure the directory of the included file is defined in your search path

—the include_file attribute takes only the file name as its value; no path is allowed.

Syntax

include_file (file_name

) ;

Example

cell( ) {

area : 0.1 ;

...

include_file (memory_file) ;

...

}

where memory_file contains the memory group statements.

Limitations

The include_file attribute has these requirements:

• Recursive include_file statements are not allowed; that is, the source files that you

include cannot also contain include_file statements.

•

If the included file is not in the current directory, then the location of the included file

must be defined in your search path.

•

Multiple file names are not allowed in an include_file statement. However, there is

no limit to the number of include_file statements you can have in your main source

file.

Liberty User Guide Volume 1

R-2020.09

Chapter 1: Sample Library Description

Statements

• An included file cannot substitute for a group value statement. For example, the

following is not allowed:

cell ( ) {

area : 0.1 ;

...

pin_equal : include_file (source_file) ;

}

•

The include_file attribute cannot substitute or cross the group boundary. For

example, the following is not allowed:

cell ( A ) include (source_file)

where source_file is the following:

{

attribute : value ;

...

}

Liberty User Guide Volume 1

R-2020.09

Building a Logic Library

A library description identifies the characteristics of a logic library and the cells it contains.

The library group contains the entire library description. This chapter describes the

library group-level attributes of a CMOS logic library.

The following concepts and tasks are explained in this chapter:

• Creating Library Groups

• Using General Library Attributes

• Delay and Slew Attributes

• Defining Units

• Setting Minimum Cell Requirements

Creating Library Groups

The library group contains the entire library description. Each library source file must

have only one library group. Attributes that apply to the entire library are defined at the

library group level, at the beginning of the library description.

library Group

The library group statement defines the name of the library you want to describe. This

statement must be the first executable line in your library.

Example

library (my_library) {

...

}

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Using General Library Attributes

These attributes apply generally to the logic library:

• technology

•

delay_model

• bus_naming_style

technology Attribute

This attribute identifies the technology used in the library. Valid value is cmos. The

technology attribute must be the first attribute defined and is placed at the top of the

listing.

Syntax

technology (name) ;

Example

library (my_library) {

technology (cmos);

...

}

delay_model Attribute

This attribute indicates the delay model to use in delay calculations. Valid value is

table_lookup.

The delay_model attribute must follow the technology attribute; if the technology

attribute is not present, the delay_model attribute must be the first attribute in the library.

Syntax

delay_model : value ;

Example

library (my_library) {

delay_model : table_lookup;

...

}

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Delay and Slew Attributes

bus_naming_style Attribute

This attribute defines the naming convention for buses in the library.

Syntax

bus_naming_style : "string";

string

Contains alphanumeric characters, braces, underscores, dashes, or

parentheses. Must contain one %s symbol and one %d symbol. The %s and %d

symbols can appear in any order with at least one nonnumeric character in

between.

The colon character is not allowed in a bus_naming_style attribute value

because the colon is used to denote a range of bus members. You construct a

complete bused-pin name by using the name of the owning bus and the member

number. The owning bus name is substituted for the %s, and the member

number replaces the %d.

Delay and Slew Attributes

This section describes the attributes to set the values of the input and output pin threshold

points that are used to model delay and slew.

Delay is the time it takes for the output signal voltage, which is falling from 1 to 0, to fall

to the threshold point set with the output_threshold_pct_fall attribute after the input

signal voltage, which is falling from 1 to 0, has fallen to the threshold point set with the

input_threshold_pct_fall attribute (see Figure 1).

Delay is also the time it takes for the output signal, which is rising from 0 to 1, to rise to

the threshold point set with the output_threshold_pct_rise attribute after the input

signal, which is rising from 0 to 1, has risen from 0 to the threshold point set with the

input_threshold_pct_rise attribute.

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Delay and Slew Attributes

Figure 1 Delay Modeling for Falling Signal

Slew is the time it takes for the voltage value to fall or rise between two designated

threshold points on an input, an output, or a bidirectional port. The designated threshold

points must fall within a voltage falling from 1 to 0 or rising from 0 to 1.

Use the following attributes to enter the two designated threshold points to model the time

for voltage falling from 1 to 0:

•

slew_lower_threshold_pct_fall

• slew_upper_threshold_pct_fall

Use the following attributes to enter the two designated threshold points to model the time

for voltage rising from 0 to 1:

•

slew_lower_threshold_pct_rise

•

slew_upper_threshold_pct_rise

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Delay and Slew Attributes

Figure 2 Slew Modeling Example

Specifying Delay and Slew Attributes in Voltage Range

When partial voltage swing is defined in a pin or a timing group, the nonlinear

delay model (NLDM) data in that group is for the partial swing. You must apply the

following threshold and trip point attributes only in the voltage range specified using

the output_signal_level_low and the output_signal_level_high attributes. For

more information, see input_signal_level_low and input_signal_level_high Attributes on

page 373.”

input_threshold_pct_fall Simple Attribute

Note:

To model the delay of a signal going from an input pin to an output pin, you also

need to set the value of the output pin. See output_threshold_pct_fall Simple

Attribute on page 38 and output_threshold_pct_rise Simple Attribute on

page 39 for details.

Use the input_threshold_pct_fall attribute to set the value of the threshold point on

an input pin signal falling from 1 to 0. This value is used to model the delay of a signal

transmitting from an input pin to an output pin.

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Delay and Slew Attributes

Syntax

input_threshold_pct_fall : trip_point

value

;

trip_point

A floating-point number between 0.0 and 100.0 that specifies the threshold point

of an input pin signal falling from 1 to 0. The default is 50.0.

Example

input_threshold_pct_fall : 60.0 ;

input_threshold_pct_rise Simple Attribute

Use the input_threshold_pct_rise attribute to set the value of the threshold point on

an input pin signal rising from 0 to 1. This value is used to model the delay of a signal

transmitting from an input pin to an output pin.

Note:

To model the delay of a signal going from an input pin to an output pin, you also

need to set the value of the output pin. See “output_threshold_pct_fall Simple

Attribute” and output_threshold_pct_rise Simple Attribute on page 39 for

details.

Syntax

input_threshold_pct_rise : trip_point

value

;

trip_point

A floating-point number between 0.0 and 100.0 that specifies the threshold point

of an input pin signal rising from 0 to 1. The default is 50.0.

Example

input_threshold_pct_rise : 40.0 ;

output_threshold_pct_fall Simple Attribute

Use the output_threshold_pct_fall attribute to set the value of the threshold point on

an output pin signal falling from 1 to 0. This value is used to model the delay of a signal

transmitting from an input pin to an output pin.

Note:

To model the delay of a signal going from an input pin to an output pin, you also

need to set the value of the input pin. See “input_threshold_pct_rise Simple

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Delay and Slew Attributes

Attribute” and input_threshold_pct_fall Simple Attribute on page 37 for

details.

Syntax

output_threshold_pct_fall : trip_point

value

;

trip_point

A floating-point number between 0.0 and 100.0 that specifies the threshold point

of an output pin signal falling from 1 to 0. The default is 50.0.

Example

output_threshold_pct_fall : 40.0 ;

output_threshold_pct_rise Simple Attribute

Use the output_threshold_pct_rise attribute to set the value of the threshold point on

an output pin signal rising from 0 to 1. This value is used to model the delay of a signal

transmitting from an input pin to an output pin.

Note:

To model the delay of a signal going from an input pin to an output pin, you

also need to set the value of the input pin. See input_threshold_pct_rise Simple

Attribute on page 38 and input_threshold_pct_fall Simple Attribute on

page 37 for details.

Syntax

output_threshold_pct_rise : trip_point

value

;

trip_point

A floating-point number between 0.0 and 100.0 that specifies the threshold point

of an output pin signal rising from 0 to 1. The default is 50.0.

Example

output_threshold_pct_rise : 40.0 ;

slew_derate_from_library Simple Attribute

Use the slew_derate_from_library attribute to specify how the transition times found in

the library need to be derated to match the transition times between the characterization

trip points.

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Delay and Slew Attributes

Syntax

slew_derate_from_library : derate

value

;

derate

A floating-point number between 0.0 and 1.0. The default is 1.0.

Example

slew_derate_from_library : 0.5 ;

slew_lower_threshold_pct_fall Simple Attribute

Use the slew_lower_threshold_pct_fall attribute to set the value of the lower

threshold point that is used to model the delay of a pin falling from 1 to 0.

Note:

To model the delay of a pin falling from 1 to 0, you also need to set the value for

the upper threshold point. See “slew_lower_threshold_pct_rise Simple Attribute”

for details.

Syntax

slew_lower_threshold_pct_fall : trip_point_value ;

trip_point

A floating-point number between 0.0 and 100.0 that specifies the lower threshold

point that is used to model the delay of a pin falling from 1 to 0. The default is

20.0.

Example

slew_lower_threshold_pct_fall : 30.0 ;

slew_lower_threshold_pct_rise Simple Attribute

Use the slew_lower_threshold_pct_rise attribute to set the value of the lower

threshold point that is used to model the delay of a pin rising from 0 to 1.

Note:

To model the delay of a pin rising from 0 to 1, you also need to set the value for

the upper threshold point. See slew_upper_threshold_pct_fall Simple Attribute

on page 41 for details.

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Delay and Slew Attributes

Syntax

slew_lower_threshold_pct_rise : trip_point_value ;

trip_point

A floating-point number between 0.0 and 100.0 that specifies the lower threshold

point that is used to model the delay of a pin rising from 0 to 1. The default is

20.0.

Example

slew_lower_threshold_pct_rise : 30.0 ;

slew_upper_threshold_pct_fall Simple Attribute

Use the slew_upper_threshold_pct_fall attribute to set the value of the upper

threshold point that is used to model the delay of a pin falling from 1 to 0.

Note:

To model the delay of a pin falling from 1 to 0, you also need to set the value for

the lower threshold point. See slew_lower_threshold_pct_fall Simple Attribute

on page 40 for details.

Syntax

slew_upper_threshold_pct_fall : trip_point

value

;

trip_point

A floating-point number between 0.0 and 100.0 that specifies the upper

threshold point that is used to model the delay of a pin falling from 1 to 0. The

default is 80.0.

Example

slew_upper_threshold_pct_fall : 70.0 ;

slew_upper_threshold_pct_rise Simple Attribute

Use the slew_upper_threshold_pct_rise attribute to set the value of the upper

threshold point that is used to model the delay of a pin rising from 0 to 1.

Note:

To model the delay of a pin rising from 0 to 1, you also need to set the value for

the lower threshold point. See slew_lower_threshold_pct_rise Simple Attribute

on page 40 for details.

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Defining Units

Syntax

slew_upper_threshold_pct_rise : trip_point

value

;

trip_point

A floating-point number between 0.0 and 100.0 that specifies the upper

threshold point that is used to model the delay of a pin rising from 0 to 1. The

default is 80.0.

Example

slew_upper_threshold_pct_rise : 70.0 ;

Defining Units

Use these library-level attributes to define units:

• time_unit

•

voltage_unit

• current_unit

•

pulling_resistance_unit

•

capacitive_load_unit

• leakage_power_unit

The unit attributes identify the units of measure, such as nanoseconds or picofarads, used

in the library definitions.

time_unit Attribute

Use this attribute to identify the physical time unit used in the generated library.

Syntax

time_unit : unit ;

unit

Valid values are 1ps, 10ps, 100ps, and 1ns. The default is 1ns.

Example

time_unit : "10ps";

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Defining Units

voltage_unit Attribute

Use this attribute to scale the contents of the input_voltage and output_voltage

groups. Additionally, the voltage attribute in the operating_conditions group

represents values in the voltage units.

Syntax

voltage_unit : unit ;

unit

Valid values are 1mV, 10mV, 100mV, and 1V. The default is 1V.

Example

voltage_unit : "100mV";

current_unit Attribute

This attribute specifies the unit for the drive current that is generated by output pads. The

pulling_current attribute for a pull-up or pull-down transistor also represents its values

in this unit.

Syntax

current_unit : value

enum

;

value

The valid values are 1uA, 10uA, 100uA, 1mA, 10mA, 100mA, and 1A. No

default exists for the current_unit attribute if the attribute is omitted.

Example

current_unit : "1mA";

pulling_resistance_unit Attribute

The pulling_resistance_unit attribute defines pulling resistance unit values for pull-up

and pull-down devices.

Syntax

pulling_resistance_unit : "unit" ;

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Defining Units

unit

Valid unit values are 1ohm, 10ohm, 100ohm, and 1kohm. No default exists for

pulling_resistance_unit if the attribute is omitted.

Example

pulling_resistance_unit : "10ohm";

capacitive_load_unit Attribute

This attribute specifies the unit for all capacitance values within the logic library, including

default capacitances, max_fanout capacitances, pin capacitances, and wire capacitances.

Syntax

capacitive_load_unit (value

float

,unit

enum

) ;

value

A floating-point number.

unit

Valid values are ff and pf.

Example

capacitive_load_unit(1,pf);

leakage_power_unit Attribute

This attribute indicates the units of the power values in the library. If this attribute is

missing, the leakage-power values are expressed without units.

Syntax

leakage_power_unit : value

enum

;

value

Valid values are 1mW, 100mW, 10mW, 1mW, 100nW, 10nW, 1nW, 100pW,

10pW, and 1pW.

Example

leakage_power_unit : 100uW;

Liberty User Guide Volume 1

R-2020.09

Chapter 2: Building a Logic Library

Setting Minimum Cell Requirements

For the Design Compiler tool to perform technology mapping and optimization on design

descriptions, the logic library should contain a minimum set of cells.

This is a minimum set of cells for a CMOS logic library:

•

An inverter

•

A 2-input NAND gate

• A 2-input NOR gate

•

A three-state buffer

•

A D flip-flop with preset, clear, and complementary output values

• A D latch with preset, clear, and complementary output values

The Design Compiler tool writes out a warning message if the design contains a cell that is

not included in the library or libraries associated with the design.

Liberty User Guide Volume 1

R-2020.09

Building Environments

Variations in operating temperature, supply voltage, and manufacturing process cause

performance variations in electronic networks.

The environment attributes include various attributes and tasks, covered in the following

sections:

• Library-Level Default Attributes

• Defining Operating Conditions

• Defining Power Supply Cells

• Defining Wire Load Groups

• Specifying Delay Scaling Attributes

Library-Level Default Attributes

Global defaults are set at the library level. You can override many of these defaults.

Setting Default Cell Attributes

The following attributes are defaults that apply to all cells in a library.

default_cell_leakage_power Simple Attribute

Indicates the default leakage power for those cells that do not have the

cell_leakage_power attribute. This attribute must be a nonnegative floating-point

number. If it is not defined, this attribute defaults to 0.0.

Example

default_cell_leakage_power : 0.5;

Setting Default Pin Attributes

Default pin attributes apply to all pins in a library and deal with timing. How you define

default timing attributes in your library depends on the timing delay model you use.

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Library-Level Default Attributes

These are the defaults that apply to all pins in a library.

default_inout_pin_cap : value

float

;

Sets a default for capacitance for all I/O pins in the library.

default_input_pin_cap : value

float

;

Sets a default for capacitance for all input pins in the library.

default_output_pin_cap : value

float

;

Sets a default for capacitance for all output pins in the library.

default_max_fanout : value

float

;

Sets a default for max_fanout for all output pins in the library.

default_max_transition : value

float

;

Sets a default for max_transition for all output pins in the library.

default_fanout_load : value

float

;

Sets a default for fanout_load for all input pins in the library.

The following example shows the default pin attributes in a CMOS library:

Example 5 Default Pin Attributes for a CMOS Library

library (example) {

...

/* default pin attributes */

default_inout_pin_cap : 1.0 ;

default_input_pin_cap : 1.0 ;

default_output_pin_cap : 0.0 ;

default_fanout_load : 1.0 ;

default_max_fanout : 10.0 ;

default_max_transition : 15.0 ;

...

}

Setting Wire Load Defaults

Use the following library-level attributes to set wire load defaults.

default_wire_load Attribute

Assigns the defaults to the wire_load group, unless you assign a different value for

wire_load before compiling the design.

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Library-Level Default Attributes

Syntax

default_wire_load : wire_load_name;

Example

default_wire_load : WL1;

default_wire_load_capacitance Attribute

Specifies a value for the default wire load capacitance.

Syntax

default_wire_load_capacitance : value;

Example

default_wire_load_capacitance : .05;

default_wire_load_resistance Attribute

Specifies a value for the default wire load resistance.

Syntax

default_wire_load_resistance : value;

Example

default_wire_load_resistance : .067;

default_wire_load_area Attribute

Specifies a value for the default wire load area.

Syntax

default_wire_load_resistance : value;

Example

default_wire_load_area : 0.33;

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Library-Level Default Attributes

Setting Other Environment Defaults

Use the following library-level attributes to set other environment defaults.

default_operating_conditions Attribute

Assigns a default operating_conditions group name for the library. It must be specified

after all operating_conditions groups. If this attribute is not used, nominal operating

conditions apply. See Defining Operating Conditions on page 50.

Syntax

default_operating_conditions : operating_condition_name;

Example

default_operating_conditions : WCCOM1;

default_connection_class Attribute

Sets a default for connection_class for all pins in a library.

Example

default_connection_class : name1 [name2 name3 ...];

Examples of Library-Level Default Attributes

In Example 6, the wire_load and operating_conditions group statements illustrate the

requirement that group names that are referred to by the default attributes, such as WL1

and OP1, must be defined in the library.

Example 6 Setting Library-Level Default Attributes for a CMOS Library

library (example) {

...

/* default cell attributes */

default_cell_leakage_power : 0.2;

/* default pin attributes */

default_inout_pin_cap : 1.0;

default_input_pin_cap : 1.0;

default_output_pin_cap : 0.0;

default_fanout_load : 1.0;

default_max_fanout : 10.0;

wire_load (WL1) {

...

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Defining Operating Conditions

}

operating_conditions (OP1) {

...

}

default_wire_load : WL1;

default_operating_conditions : OP1;

default_wire_load_mode : enclosed;

...

}

Defining Operating Conditions

The following section explains how to define and determine various operating conditions

for a logic library.

operating_conditions Group

An operating_conditions group is defined in a library group.

Syntax

library ( lib_name ) {

operating_conditions ( name ) {

... operating

conditions description ...

}

name

Identifies the set of operating conditions. Names of all operating_conditions

groups and wire_load groups must be unique within a library.

The operating_conditions groups are useful for testing timing and other characteristics

of your design in predefined simulated environments. The following attributes are defined

in an operating_conditions group:

process : multiplier ;

The scaling factor accounts for variations in the outcome of the actual

semiconductor manufacturing steps, typically 1.0 for most technologies. The

multiplier is a floating-point number from 0 through 100.

process_label : "name" ;

The process name of the current process. The value is a string.

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Defining Power Supply Cells

temperature : value ;

The ambient temperature in which the design is to operate. The value is a

floating-point number.

voltage : value ;

The operating voltage of the design, typically 5 volts for a CMOS library. The

value is a floating-point number from 0 through 1,000, representing the absolute

value of the actual voltage.

Note:

Define voltage units consistently.

tree_type : model ;

The definition for the environment interconnect model.

The model is one of the following three models:

•

best_case_tree

Models the case in which the load pin is physically adjacent to the driver. In

the best case, all wire capacitance is incurred but none of the wire resistance

must be overcome.

•

balanced_tree

Models the case in which all load pins are on separate, equal branches of

the interconnect wire. In the balanced case, each load pin incurs an equal

portion of the total wire capacitance and wire resistance.

•

worst_case_tree

Models the case in which the load pin is at the extreme end of the wire. In

the worst case, each load pin incurs both the full wire capacitance and the

full wire resistance.

Defining Power Supply Cells

Use the power_supply group to model multiple power supply cells.

power_supply group

The power_supply group captures all nominal information about voltage variation.

It is defined before the operating_conditions group and before the cell groups.

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Defining Wire Load Groups

All the power supply names defined in the power_supply group exist in the

operating_conditions group. Define the power_supply group at the library level.

Syntax

power_supply () {

default_power_rail : string ;

power_rail (string, float) ;

...

}

Example

power_supply () {

default_power_rail : VDD0;

power_rail (VDD1, 5.0) ;

power_rail (VDD2, 3.3) ;

}

Defining Wire Load Groups

Use the wire_load group and the wire_load_selection group to specify values for the

capacitance factor, resistance factor, area factor, slope, and fanout_length you

want to apply to the wire delay model for different sizes of circuitry.

wire_load Group

The wire_load group has an extended fanout_length complex attribute. Define the

wire_load group at the library level.

Syntax

wire_load(name){

resistance : value ;

capacitance : value ;

area : value ;

slope : value ;

fanout_length(fanout

int

, length

float

average_capacitance

float

,standard_deviation

float

number_of_nets

int

);

}

In a wire_load group, you define the estimated wire length as a function of fanout. You

can also define scaling factors to derive wire resistance, capacitance, and area from a

given length of wire.

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Defining Wire Load Groups

You can define any number of wire_load groups in a logic library, but all wire_load

groups and operating_conditions groups must have unique names.

You can define the following simple attributes in a wire_load group:

resistance : value ;

Specifies a floating-point number representing wire resistance per unit length of

interconnect wire.

capacitance : value ;

Specifies a floating-point number representing capacitance per unit length of

interconnect wire.

area : value ;

Specifies a floating-point number representing the area per unit length of

interconnect wire.

slope : value ;

Specifies a floating-point number representing slope. This attribute characterizes

linear fanout length behavior beyond the scope of the longest length described

by the fanout_length attributes.

You can define the following complex attribute in a wire_load group:

fanout_length ( fanout

int

, length

float

, average_capacitance

float

standard_deviation

float

, number_of_nets

int

);

fanout_length is a complex attribute that defines values that represent fanout

and length. The fanout value is an integer; length is a floating-point number.

When you create a wire load manually, define only fanout and length.

You must define at least one pair of fanout and length points per wire load

model. You can define as many additional pairs as necessary to characterize the

fanout-length behavior you want.

interconnect_delay (template_name)

{values(float,...float,...float,...float,...) ; }

The interconnect_delay group specifies the lookup table template and the

wire delay values.

Specify the interconnect_delay values.

To overwrite the default index values, specify the new index values before the

interconnect_delay values, as shown here.

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Defining Wire Load Groups

Figure 3 illustrates the correlation between the number of pins on the net, excluding the

driver pin, and the estimated wire length of the metal between all the pins.

Figure 3 Wire Load Definition Graph

Example 7 gives the library description for the model in Figure 3.

Note:

In Example 7 and Example 8, the name 90x90 is enclosed in quotation marks

because it is a string that begins with a number.

Example 7 Wire Load Definition

library (example) {

...

wire_load ("90x90") {

resistance : 0;

capacitance : 1;

area : 0;

slope : 1.0;

fanout_length( 1, 1.2 );

fanout_length( 2, 2.0 );

fanout_length( 3, 3.3 );

}

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Defining Wire Load Groups

Example 8 Wire Delay Estimation Using 3-D Lookup Table

library (example) {

...

lu_table_template (wire_delay_table_template) {

variable_1 : fanout_number;

variable_2 : fanout_pin_capacitance;

variable_3 : driver_slew;

index_1( "0.12,3.4");

index_2( "0.12,4.24" );

index_3( "0.1,2.7,3.12" );

}

You can define one wire_load group per design. This is the syntax for the

set_wire_load command in dc_shell:

set_wire_load wire_load_name [-library][-mode]

The wire_load_name is the name of a wire_load group defined in the library. To use the

wire_load group defined in Example 7, enter

dc_shell> set_wire_load "90x90"

For more information, see the set_wire_load command in the Synopsys man pages.

If you don’t define a wire_load group, the default_wire_load_resistance and

default_wire_load_capacitance attribute values for wire resistance and wire

capacitance.

The report_lib command reports the information for

default_wire_load_capacitance, default_wire_load_resistance , and

default_wire_load_area.

Example 9 Report For a Wire Load Model Containing New fanout and length Information

Wire Loading Model:

Name : 05x05

Location : wl library_name

Resistance : 0

Capacitance: 1

Area : 0

Slope : 0.186

Fanout Length Points AverageCap StdDeviation

----------------------------------------------------------

1 0.39 50 1.30 0.02

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Specifying Delay Scaling Attributes

wire_load_table Group

You can use the wire_load_table group to estimate accurate connect delay. Compared

to the wire_load group, this group is more flexible, because wire capacitance and

resistance no longer have to be strictly proportional to each other. In some cases, this

results in more-accurate connect delay estimates.

Syntax

wire_load_table(name

string

) {

fanout_length(fanout

int

, length

float

);

fanout_capacitance(fanout

int

, capacitance

float

);

fanout_resistance(fanout

int

, resistance

float

);

fanout_area(fanout

int

, area

float

);

}

In the wire_load group, the fanout_capacitance , fanout_resistance , and

fanout_area values represent per-length coefficients. In the wire_load_table group the

values are exact.

The report_lib command reports the wire_load_table group.

Example 10 A library source file with the wire_load_table Group and the Table Report

library(wlut) {

wire_load_table("05x05") {

fanout_length(1, 0.2) ;

fanout_capacitance(1, 0.15);

fanout_resistance(1, 0.17) ;

fanout_area(1, 0.2) ;

fanout_length(2, 0.35) ;

fanout_capacitance(2, 0.39) ;

fanout_resistance(2, 0.25) ;

fanout_area(2, 0.41) ;

}

Name : 05x05

Location : wlut

Fanout Length Capacitance Resistance Area

----------------------------------------------------------

1 0.2 0.15 0.17 0.2

2 0.35 0.39 0.25 0.41

Specifying Delay Scaling Attributes

These k-factors (attributes that begin with k_) are multipliers that scale defined library

values, taking into consideration the effects of changes in process, temperature, and

voltage.

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Specifying Delay Scaling Attributes

To model the effects of process, temperature, and voltage variations on circuit timing, use

the following:

•

k-factors that apply to the entire library and are defined at the library level.

•

User-selected operating conditions that override the values in the library for an

individual cell.

Using these values, downstream tools uniformly scale timing numbers for timing analysis.

Pin and Wire Capacitance Factors

The pin and wire capacitance factors scale the capacitance of a pin or wire according

to process, temperature, and voltage variations. Each attribute gives the multiplier for a

certain portion of the capacitance of a pin or a wire. In the following syntax, multiplier is a

floating-point number:

k_process_pin_cap : multiplier ;

Scaling factor applied to pin capacitance to model process variation.

k_process_wire_cap : multiplier ;

Scaling factor applied to wire capacitance to model process variation.

k_temp_pin_cap : multiplier ;

Scaling factor applied to pin capacitance to model temperature variation.

k_temp_wire_cap : multiplier ;

Scaling factor applied to wire capacitance to model temperature variation.

k_volt_pin_cap : multiplier ;

Scaling factor applied to pin capacitance to model voltage variation.

k_volt_wire_cap : multiplier ;

Scaling factor applied to wire capacitance to model voltage variation.

Scaling Factors Associated With the Nonlinear Delay Model

The CMOS nonlinear delay model scaling factors scale the delay based on the variation

in process, temperature, and voltage. The following scaling factors apply to the CMOS

nonlinear delay model:

•

k_process_cell_rise

•

k_temp_cell_rise

Liberty User Guide Volume 1

R-2020.09

Chapter 3: Building Environments

Specifying Delay Scaling Attributes

• k_volt_cell_rise

• k_process_cell_fall

• k_temp_cell_fall

•

k_volt_cell_fall

•

k_process_rise_propagation

• k_temp_rise_propagation

•

k_volt_rise_propagation

•

k_process_fall_propagation

•

k_temp_fall_propagation

•

k_volt_fall_propagation

•

k_process_rise_transition

•

k_temp_rise_transition

•

k_volt_rise_transition

•

k_process_fall_transition

•

k_temp_fall_transition

•

k_volt_fall_transition

Liberty User Guide Volume 1

R-2020.09

Defining Core Cells

Cell descriptions are a major part of a logic library. They provide information about the

area, function, and timing of each component in an ASIC technology.

Defining core cells for CMOS logic libraries involves the following concepts and tasks

described in this chapter:

• Defining cell Groups

• Defining pin Groups

• Defining Bused Pins

• Defining Signal Bundles

• Defining Layout-Related Multibit Attributes

• Defining Multiplexers

• Defining Decoupling Capacitor Cells, Filler Cells, and Tap Cells

• Fault Tolerant Cell Modeling

Defining cell Groups

A cell group defines a single cell in the logic library.

This section discusses the attributes in a cell group.

For information about groups within a cell , see the following sections in this chapter:

•

Defining Bused Pins on page 100

•

Defining Signal Bundles on page 106

See Chapter 6, Defining Test Cells,” for a test cell with a test_cell group. See cell Group

Example for an example cell description.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining cell Groups

cell Group

The cell group statement gives the name of the cell being described. It appears at the

library group level, as shown here:

library (lib_name) {

...

cell( name ) {

... cell description ...

}

...

}

Use a name that corresponds to the name the ASIC vendor uses for the cell. When

naming cells, remember that names are case-sensitive. For example, the cell names,

AND2, and2, and And2 are all different. Cell names beginning with a number must be

enclosed in quotation marks.

To create the cell group for the AND2 cell, use this syntax:

cell( AND2 ) {

... cell description ...

}

To describe a CMOS cell group, you use the type group and these attributes:

•

area

•

bundle (See Defining Signal Bundles on page 106.)

•

bus (See Defining Bused Pins on page 100.)

•

cell_footprint

•

clock_gating_integrated_cell

• contention_condition

•

is_clock_gating_cell

•

map_only

•

pad_cell

•

pad_type

•

physical_variant_cells

•

pin_equal

•

pin_opposite

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining cell Groups

• preferred

area Attribute

This attribute specifies the cell area.

Example

area : 2.0;

For unknown or undefined (black box) cells, the area attribute is optional. Unless a cell

is a pad cell, it should have an area attribute. Pad cells should be given an area of 0.0,

because they are not used as internal gates.

cell_footprint Attribute

This attribute assigns a footprint class to a cell.

Example

cell_footprint : 5MIL ;

Characters in the string are case-sensitive.

Use this attribute to assign the same footprint class to all cells that have the same layout

boundary. Cells with the same footprint class are considered interchangeable and can be

swapped during in-place optimization.

clock_gating_integrated_cell Attribute

An integrated clock-gating cell is a cell that you or your library developer creates to use

especially for clock gating. The cell integrates the various combinational and sequential

elements of a clock gate into a single cell that is compiled into gates and located in the

logic library.

Consider using an integrated clock-gating cell if you are experiencing timing problems

caused by the introduction of randomly chosen logic on your clock line.

Use the clock_gating_integrated_cell attribute to specify a value that determines the

integrated cell functionality to be used by the clock-gating tools.

Syntax

clock_gating_integrated_cell : generic|value

;

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining cell Groups

generic

When you specify the value generic, the actual type of clock gating integrated

cell structure is determined by accessing the function specified on the library pin.

Note:

Statetables and state functions should not be used. Use latch groups

with function groups instead.

value

A concatenation of up to four strings that describe the cell’s functionality to the

clock-gating tools:

•

The first string specifies the type of sequential element you want. The

options are latch-gating logic and none.

•

The second string specifies whether the logic is appropriate for rising- or

falling-edge-triggered registers. The options are posedge and negedge.

•

The third (optional) string specifies whether you want test-control logic

located before or after the latch or not at all. The options for cells set to latch

are precontrol (before), postcontrol (after), or no entry. The options for

cells set to no gating logic are control and no entry.

•

The fourth (optional) string, which exists only if the third string does, specifies

whether you want observability logic or not. The options are obs and no

entry.

Example

clock_gating_integrated_cell : "latch_posedge_precontrol_obs" ;

Table 1 Values of the clock_gating_integrated_cell Attribute

When the value is The integrated cell must contain

latch_negedge Latch-based gating logic.Logic appropriate for

falling-edge-triggered registers.

latch_posedge_postcontrol Latch-based gating logic.Logic appropriate for

rising-edge-triggered registers.Test-control logic located

after the latch.

latch_negedge_precontrol Latch-based gating logic.Logic appropriate for

falling-edge-triggered registers.Test-control logic located

before the latch.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining cell Groups

When the value is The integrated cell must contain

none_posedge_control_obs Latch-free gating logic.Logic appropriate for

rising-edge-triggered registers.Test-control logic (no

latch).Observability logic.

Setting Pin Attributes for an Integrated Cell

The clock-gating tool requires that you set the pins of your integrated cells by using the

attributes listed in Table 2. Setting some of the pin attributes, such as those for test and

observability, is optional.

Table 2 Pin Attributes for Integrated Clock-Gating Cells

Integrated cell pin name Data direction Required attribute

clock in clock_gate_clock_pin

enable in clock_gate_enable_pin

test_mode or

scan_enable

in clock_gate_test_pin

observability out clock_gate_obs_pin

enable_clock out clock_gate_out_pin

For details about these pin attributes, see the following sections:

•

clock_gate_clock_pin Attribute on page 73

•

clock_gate_enable_pin Attribute on page 73

•

clock_gate_obs_pin Attribute on page 73

•

clock_gate_out_pin Attribute on page 74

•

clock_gate_test_pin Attribute on page 74

For more details about the clock_gating_integrated_cell attribute and the

corresponding pin attributes, see Chapter 8, Modeling Power and Electromigration,” and

the Power Compiler User Guide.

Setting Timing for an Integrated Cell

You set both the setup and hold arcs on the enable pin by setting the

clock_gate_enable_pin attribute for the integrated cell to true. The setup

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining cell Groups

and hold arcs for the cell are determined by the edge values you enter for the

clock_gating_integrated_cell attribute.

Table 3 Edge Values of the clock_gating_integrated_cell Attribute With Setup and

Hold Arcs

Value Setup arc Hold arc

latch_posedge rising rising

latch_negedge falling falling

none_posedge falling rising

none_negedge rising falling

For details about setting timing for an integrated cell, see Chapter 8, Modeling Power and

Electromigration”.

contention_condition Attribute

Contention is a clash of 0 and 1 signals. In certain cells, it can be a forbidden condition

and cause circuits to short.

Example

contention_condition : "!ap * an" ;

is_macro_cell Attribute

The is_macro_cell attribute identifies whether a cell is a macro cell. If the attribute is set

to true, the cell is a macro cell. If it is set to false, the cell is not a macro cell.

Example

is_macro_cell : true;

pad_cell Attribute

The pad_cell attribute in a cell group identifies the cell as a pad.

Example

pad_cell : true ;

If the pad_cell attribute is included in a cell definition, at least one pin in the cell must

have an is_pad attribute.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining cell Groups

If more than one pad cell is used to build a logical pad, put this attribute in the cell

definitions of all the component pad cells:

auxiliary_pad_cell : true ;

If you omit the pad_cell or auxiliary_pad_cell attribute, the cell is treated as an

internal core cell.

Note:

A cell with an auxiliary_pad_cell attribute can also be used within the core;

a pull-up or pull-down cell is an example of such a cell.

physical_variant_cells Attribute

The physical_variant_cells attribute specifies a list of physical variant cells of the cell

where it is defined.

Physical variant cells have different physical layouts but share the same logic Liberty

models. For example, a design can have multiple cells that are variants of a master cell

with only difference in the mask color of their pins. In smaller technology nodes, the timing

of these cells are close enough for you to use the same Liberty model for the master cell

and all its variants.

Syntax

library (library_name) {

cell (cell_name) {

physical_variant_cells : "names-list";

…

}

…

}

Specify the list of cell names by separating them with a blank space or comma. The listed

cell names are independent of order. For example, physical_variant_cells : "ABC_1

ABC_2"; is identical to physical_variant_cells : "ABC_2 ABC_1";.

Example

The following is a .lib snippet of the master cell, mycell, whose color variant cells are

mycell_1, mycell_2, and mycell_3. In the .lib file, all the four cells have the same

characterization data. The physical views of these four cells might be slightly different.

library(mylib) {

…

voltage_map(VDD, 1.0); /* Primary Power */

voltage_map(VSS, 0.0); /* Primary Ground */

…

cell (mycell) {

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining cell Groups

physical_variant_cells : "mycell_1 mycell_2 mycell_3";

/* other cell level attributes and groups */

…

/* pg_pin definitions */

…

/* Signal pin definitions */

…

} /* end cell group */

} /* end library group */

pin_equal Attribute

This attribute describes a group of logically equivalent input or output pins in the cell.

pin_opposite Attribute

This attribute describes functionally opposite (logically inverse) groups of pins in a cell.

The pin_opposite attribute also incorporates the functionality of pin_equal.

Example

pin_opposite("Q1 Q2 Q3", "QB1 QB2") ;

In this example, Q1, Q2, and Q3 are equal; QB1 and QB2 are equal; and the pins of the

first group are opposite to the pins of the second group.

The Design Compiler tool automatically determines the opposite pins for cells that have

function attributes. See function Attribute on page 96 for more information.

Note:

Use the pin_opposite attribute only in cells without function information or

when you want to define required inputs.

type Group

The type group, when defined within a cell, is a type definition local to the cell. It cannot

be used outside of the cell.

Example

type (bus4) {

base_type : array;

data_type : bit;

bit_width : 4;

bit_from : 0;

bit_to : 3;

}

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining cell Groups

cell Group Example

Example 11 shows cell definitions that include some of the CMOS cell attributes described

in this section.

Example 11 cell Group Example

library (cell_example){

date : "August 14, 2015";

revision : 2015.03;

cell (inout){

pad_cell : true;

dont_use : true;

dont_fault : sa0;

dont_touch : true;

area : 0; /* pads do not normally consume internal

core area */

cell_footprint : 5MIL;

pin (A) {

direction : input;

capacitance : 0;

}

pin (Z) {

direction : output;

function : "A";

timing () {

...

}

cell(inverter_med){

area : 3;

preferred : true;

pin (A) {

direction : input;

capacitance : 1.0;

}

pin (Z) {

direction : output;

function : "A’ ";

timing () {

...

}

cell(nand){

area : 4;

pin(A) {

direction : input;

capacitance : 1;

fanout_load : 1.0;

}

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining cell Groups

pin(B) {

direction : input;

capacitance : 1;

fanout_load : 1.0;

}

pin (Y) {

direction : output;

function : "(A * B)’ ";

timing() {

...

}

cell(buff1){

area : 3;

pin (A) {

direction : input;

capacitance : 1.0;

}

pin (Y) {

direction : output;

function : "A ";

timing () {

...

}

} /* End of Library */

mode_definition Group

A mode_definition group declares a mode group that contains several timing mode

values.

Syntax

cell(name

string

) {

mode_definition(name

string

) {

mode_value(name1) {

when : "Boolean expression" ;

sdf_cond : "sdf_expression

string

" ;

}

mode_value(name

string

) {

when : "Boolean expression" ;

sdf_cond :"Boolean expression" ;

}

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining cell Groups

Group Statement

mode_value (name

string

) { }

Specifies the condition that a timing arc depends on to activate a path.

mode_value Group

The mode_value group contains several mode values within a mode group. You can

optionally put a condition on a mode value. When the condition is true, the mode group

takes that value.

Syntax

mode_value (name

string

) { }

Simple Attributes

when :"Boolean expression" ;

sdf : "Boolean expression" ;

when Simple Attribute

The when attribute specifies the condition that a timing arc depends on to activate a path.

The valid value is a Boolean expression.

Syntax

when : "Boolean expression" ;

Example

when: !R;

sdf_cond Simple Attribute

The sdf_cond attribute supports Standard Delay Format (SDF) file generation and

condition matching during back-annotation.

Syntax

sdf_cond : "Boolean expression" ;

Example

sdf_cond: "R == 0";

Example 12 mode_definition Group Description

cell(example_cell) {

...

mode_definition(rw) {

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

mode_value(read) {

when : "R";

sdf_cond : "R == 1";

}

mode_value(write) {

when : "!R";

sdf_cond : "R == 0";

}

Defining pin Groups

For each pin in a cell, the cell group must contain a description of the pin characteristics.

You define pin characteristics in a pin group within the cell group.

A pin group often contains a timing group and an internal_power group.

For more information about timing groups, see Chapter 7, Timing Arcs”.

For more information about the internal_power group, see Chapter 8, Modeling Power

and Electromigration”.

pin Group

You can define a pin group within a cell, test_cell, model, or bus group.

library (lib_name) {

...

cell (cell_name) {

...

pin ( name | name_list ) {

... pin group description ...

}

cell (cell_name) {

...

bus (bus_name) {

... bus group description ...

}

bundle (bundle_name) {

... bundle group description ...

}

pin ( name | name_list ) {

... pin group description ...

}

See Defining Bused Pins on page 100 for descriptions of bus groups. See Defining

Signal Bundles on page 106 for descriptions of bundle groups.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

The pin groups are also valid within test_cell groups. They have different requirements

from pin groups in cell, bus, or bundle groups. See Pins in the test_cell Group on

page 158 for specific information and restrictions on describing test pins.

All pin names within a single cell, bus, or bundle group must be unique. Names are

case-sensitive: pins named A and a are different pins.

You can describe pins with common attributes in a single pin group. If a cell contains two

pins with different attributes, two separate pin groups are required. Grouping pins with

common technology attributes can significantly reduce the size of a cell description that

includes many pins.

In the following example, the AND cell has two pins: A and B.

cell (AND) {

area : 3 ;

pin (A) {

direction : input ;

capacitance : 1 ;

}

pin (B) {

direction : input ;

capacitance : 1 ;

}

Because pins A and B have the same attributes, the cell can also be described as

cell (AND) {

area : 3 ;

pin (A,B) {

direction : input ;

capacitance : 1 ;

}

General pin Group Attributes

To define a pin, use these general pin group attributes:

•

capacitance

•

clock_gate_clock_pin

• clock_gate_enable_pin

•

clock_gate_obs_pin

•

clock_gate_out_pin

• clock_gate_test_pin

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

• complementary_pin

• connection_class

• direction

•

dont_fault

•

driver_type

• fall_capacitance

•

fault_model

•

inverted_output

•

is_analog

•

pin_func_type

•

rise_capacitance

•

steady_state_resistance

•

test_output_only

For a complete list and descriptions for all the attributes and groups that you can specify in

a pin group, see Chapter 3, “pin Group Description and Syntax,” in the Synopsys Liberty

Reference Manual.

capacitance Attribute

The capacitance attribute defines the load of an input, output, inout, or internal pin. The

load is defined with a floating-point number, in units consistent with other capacitance

specifications throughout the library. Typical units of measure for capacitance include

picofarads and standardized loads.

Example

The following example defines the A and B pins in an AND cell, each with a capacitance of

one unit.

cell (AND) {

area : 3 ;

pin (A,B) {

direction : input ;

capacitance : 1 ;

}

If the timing groups in a cell include the output-pin capacitance effect in the intrinsic-delay

specification, do not specify capacitance values for the cell’s output pins.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

clock_gate_clock_pin Attribute

The clock_gate_clock_pin attribute identifies an input pin connected to a clock signal.

Valid values for this attribute are true and false.

Example

clock_gate_clock_pin : true;

See clock_gating_integrated_cell Attribute on page 61 for more information about

identifying pins on integrated clock-gating cells. For additional information about integrated

clock-gating, see the Power Compiler User Guide.

clock_gate_enable_pin Attribute

The Design Compiler tool uses the clock_gate_enable_pin attribute when it compiles a

design containing gated clocks that were introduced by the Power Compiler tool.

The clock_gate_enable_pin attribute identifies an input port connected to an enable

signal for nonintegrated clock-gating cells and integrated clock-gating cells.

Valid values for this attribute are true and false.

Example

clock_gate_enable_pin : true;

For nonintegrated clock-gating cells, you can set the clock_gate_enable_pin attribute

to true on only one input port of a 2-input AND, NAND, OR, or NOR gate. If you do so, the

other input port is the clock.

See clock_gating_integrated_cell Attribute on page 61 for more information about

identifying pins on integrated clock-gating cells. For additional information about integrated

clock gating, see the Power Compiler User Guide.

clock_gate_obs_pin Attribute

The clock_gate_obs_pin attribute identifies an output port connected to an observability

signal.

Valid values for this attribute are true and false.

Example

clock_gate_obs_pin : true;

See clock_gating_integrated_cell Attribute on page 61 for more information about

identifying pins on integrated clock-gating cells. For additional information about integrated

clock gating, see the Power Compiler User Guide.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

clock_gate_out_pin Attribute

The clock_gate_out_pin attribute identifies an output port connected to an

enable_clock signal..

Valid values for this attribute are true and false.

Example

clock_gate_out_pin : true;

See clock_gating_integrated_cell Attribute on page 61 for more information about

identifying pins on integrated clock-gating cells. For additional information about integrated

clock gating, see the Power Compiler User Guide.

clock_gate_test_pin Attribute

The clock_gate_test_pin attribute identifies an input port connected to a test_mode or

scan_enable signal.

Valid values for this attribute are true and false.

Example

clock_gate_test_pin : true;

See clock_gating_integrated_cell Attribute on page 61 for more information about

identifying pins on integrated clock-gating cells. For additional information about integrated

clock gating, see the Power Compiler User Guide.

complementary_pin Simple Attribute

The complementary_pin attribute supports differential I/O.

Differential I/O assumes the following:

•

When the noninverting pin equals 1 and the inverting pin equals 0, the signal gets logic

•

When the noninverting pin equals 0 and the inverting pin equals 1, the signal gets logic

The entry for this attribute identifies the differential input inverting pin with which the

noninverting pin is associated and from which it inherits timing information and associated

attributes.

Syntax

complementary_pin : "string" ;

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

string

Identifies the differential input data inverting pin whose timing information and

associated attributes the noninverting pin inherits. Only one input pin is modeled

at the cell level. The associated differential inverting pin is defined in the same

pin group.

For details on the fault_model attribute used to define the value when both

the complementary pin and the pin that it complements are driven to the same

value, see fault_model Simple Attribute on page 82.

Example

cell (diff_buffer) {

...

pin (A) { /* noninverting pin /

direction : input ;

complementary_pin : "DiffA" ;/* inverting pin /

}

connection_class Simple Attribute

The connection_class attribute lets you specify design rules for connections between

cells.

Example

connection_class : "internal";

Only pins with the same connection class can be legally connected. For example, you

can specify that clock input must be driven by clock buffer cells or that output pads can

be driven only by high-drive pad driver cells between the internal logic and the pad. To do

this, you assign the same connection class to the pins that must be connected. For the

pad example, you attach a given connection class to the pad driver output and the pad

input. This attachment makes it invalid to connect another type of cell to the pad.

•

In Example 13, the output_pad cell can be driven only by the pad_driver cell. The

pad driver’s input can be connected to internal core logic, because it has the internal

connection class.

In Example 14, the high_drive_buffer cell can drive internal core cells and pad cells,

whereas the low_drive_buffer cell can drive only internal cells.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

Example 13 Connection Class Example

default_connection_class : "default" ;

cell (output_pad) {

pin (IN) {

connection_class : "external_output" ;

...

}

cell (pad_driver) {

pin (OUT) {

connection_class : "external_output" ;

...

}

pin (IN) {

connection_class : "internal" ;

...

}

Example 14 Multiple Connection Classes for a Pin

cell (high_drive_buffer) {

pin (OUT) {

connection_class : "internal pad" ;

...

}

cell (low_drive_buffer) {

pin (OUT) {

connection_class : "internal" ;

...

}

cell (pad_cell) {

pin (IN) {

connection_class : "pad" ;

...

}

cell (internal_cell) {

pin (IN) {

connection_class : "internal" ;

...

}

direction Attribute

Use this attribute to specify whether the pin being described is an input, output, internal, or

bidirectional pin.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

Example

direction : output;

For a description of the effect of pin direction on path tracing and timing analysis, see the

Design Compiler Optimization Reference Manual.

driver_type Attribute

Use the optional driver_type attribute to modify the signal on a pin. This attribute

specifies a signal mapping mechanism that supports the signal transitions performed by

the circuit.

The driver_type attribute tells the application tool to use a special pin-driving

configuration for the pin during simulation. A pin without this attribute has normal driving

capability by default.

A driver type can be one or more of the following:

pull_up

The pin is connected to DC power through a resistor. If it is a three-state output

pin and it is in the Z state, its function is evaluated as a resistive 1 (H). If it is

an input or inout pin and the node to which it is connected is in the Z state, it is

considered an input pin at logic 1 (H). For a pull-up cell, the pin stays constantly

at logic 1 (H).

pull_down

The pin is connected to DC ground through a resistor. If it is a three-state output

pin and it is in the Z state, its function is evaluated as a resistive 0 (L). If it is

an input or inout pin and the node to which it is connected is in the Z state,

it is considered an input pin at logic 0 (L). For a pull-down cell, the pin stays

constantly at logic 0 (L).

bus_hold

The pin is a bidirectional pin on a bus holder cell. The pin holds the last logic

value present at that pin when no other active drivers are on the associated net.

Pins with this driver type cannot have function or three_state statements.

open_drain

The pin is an output pin without a pull-up transistor. Use this driver type only for

off-chip output or inout pins representing pads. The pin goes to high impedance

(Z) when its function is evaluated as logic 1.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

open_source

The pin is an output pin without a pull-down transistor. Use this driver type

only for off-chip output or inout pins representing pads. The pin goes to high

impedance (Z) when its function is evaluated as logic 0.

resistive

The pin is an output pin connected to a controlled pull-up or pull-down driver

with a control port (input). When the control port is disabled, the pull-up or pull-

down driver is turned off and has no effect on the pin. When the control port is

enabled, a functional value of 0 evaluated at the pin is turned into a weak 0 (L),

a functional value of 1 is turned into a weak 1 (H), but a functional value of Z is

not affected.

resistive_0

The pin is an output pin connected to DC power through a pull-up driver that

has a control port (input). When the control port is disabled, the pull-up driver

is turned off and has no effect on the pin. When the control port is enabled, a

functional value of 1 evaluated at the pin is turned into a weak 1 (H) but the

functional values of 0 and Z are not affected.

resistive_1

The pin is an output pin connected to DC ground through a pull-down driver that

has a control port (input). When the control port is disabled, the pull-down driver

is turned off and has no effect on the pin. When the control port is enabled,

a functional value of 0 evaluated at the pin is turned into a weak 0 (L) but the

functional values of 1 and Z are not affected.

Except for inout pins, each pin can have only one driver_type attribute.

Inout pins can have two driver types, one for input and one for output. The only valid

combinations are pull_up or pull_down for input and open_drain for output. If you specify

only one driver type and it is bus_hold, it is used for both input and output. If the single

driver type is not bus_hold, it is used for output. Specify multiple driver types in one entry

in this format:

driver_type : "driver_type1 driver_type2" ;

Example

This is an example of a pin connected to a controlled pull-up cell that results in a weak 1

when the control port is enabled.

function : 1;

driver_type : resistive;

three_state_enable : EN;

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

Interpretation of Driver Types

The driver type specifies one of the following signal modifications:

Resolve the value of Z

These driver types resolve the value of Z on an existing circuit node, implying a

constant 0 or 1 signal source. They do not perform a function. Resolution driver

types are pull_up, pull_down, and bus_hold.

Transform the signal

These driver types perform an actual function on an input signal, mapping the

transition from 0 or 1 to L, H, or Z. Transformation driver types are open_drain,

open_source, resistive, resistive_0, and resistive_1.

For output pins, the driver_type attribute is applied after the pin’s functional evaluation.

For input pins, this attribute is applied before the signal is used for functional evaluation.

Table 4 Signal Mapping and Pin Types for Different Driver Types

Driver type Description Signal mapping Applicable pin

types

pull_up Resolution 01Z -> 01H in, out

pull_down Resolution 01Z -> 01L in, out

bus_hold Resolution 01Z -> 01S inout

open_drain Transformation 01Z -> 0ZZ out

open_source Transformation 01Z -> Z1Z out

resistive Transformation 01Z -> LHZ out

resistive_0 Transformation 01Z -> 0HZ out

resistive_1 Transformation 01Z -> L1Z out

Signal Mapping:

0 and 1 represent strong logic 0 and logic 1 values

L represents a weak logic 0 value

H represents a weak logic 1 value

Z represents high impedance

S represents the previous state

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

Interpreting Bus Holder Driver Type

Figure 4 01Z to 01S Signal Mapping for bus_hold Driver Type

For bus_hold driver types, a three-state buffer output value of 0 changes the bus value to

0. Similarly, a three-state buffer output value of 1 changes the bus value to 1. However,

when the output of the three-state buffer is Z, the bus holds its previous value (S), which

can be 0, 1, or Z. In other words, the buffer output value of Z is resolved to the previous

value of the bus.

Modeling Pull-Up and Pull-Down Cells

Figure 5 Pull-Up Resistor of a Cell

Example 15 is the description of the pull-up resistor cell in Figure 5.

Example 15 Description of a Pull-Up Cell Transistor

cell(pull_up_cell) {

area : 0;

auxiliary_pad_cell : true;

pin(Y) {

direction : output;

multicell_pad_pin : true;

connection_class : "inpad_network";

driver_type : pull_up;

pulling_resistance : 10000;

}

Example 16 describes an output pin with a pull-up resistor and the bidirectional pin on a

bus holder cell.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

Example 16 Pin Driver Type Specifications

pin(Y) {

direction : output ;

driver_type : pull_up ;

pulling_resistance : 10000 ;

function : "IO" ;

three_state : "OE" ;

}

cell (bus_hold) {

pin(Y) {

direction : inout ;

driver_type : bus_hold ;

}

Bidirectional pads can often require one driver type for the output behavior and another

associated with the input. For this case, you can define multiple driver types in one

driver_type attribute:

driver_type : "open_drain pull_up" ;

Note:

An n-channel open-drain pad is flagged with open_drain, and a p-channel

open-drain pad is flagged with open_source.

fall_capacitance Attribute

Defines the load for an input and inout pin when its signal is falling.

Setting a value for the fall_capacitance attribute requires that a value for the

rise_capacitance also be set, and setting a value for the rise_capacitance requires

that a value for the fall_capacitance also be set.

Syntax

fall_capacitance : float ;

float

A floating-point number in units consistent with other capacitance specifications

throughout the library. Typical units of measure for fall_capacitance include

picofarads and standardized loads.

The following example defines the A and B pins in an AND cell, each with a

fall_capacitance of one unit, a rise_capacitance of two units, and a capacitance of

two units.

Example

cell (AND) {

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

area : 3 ;

vhdl_name : "AND2" ;

pin (A, B) {

direction : input ;

fall_capacitance : 1 ;

rise_capacitance : 2 ;

capacitance : 2 ;

}

fault_model Simple Attribute

The differential I/O feature enables an input noninverting pin to inherit the timing

information and all associated attributes of an input inverting pin in the same pin group

designated with the complementary_pin attribute.

If you enter a fault_model attribute, you must designate the inverted pin associated with

the noninverting pin, using the complementary_pin attribute.

For details on the complementary_pin attribute, see complementary_pin Simple Attribute

on page 74.

Syntax

fault_model : "two-value string" ;

two-value string

Two values that define the value of the differential signals when both inputs

are driven to the same value. The first value represents the value when both

input pins are at logic 0; the second value represents the value when both

input pins are at logic 1. Valid values for the two-value string are any two-value

combinations of 0, 1, and x.

If you do not enter a fault_model attribute value, the signal pin value goes to x

when both input pins are 0 or 1.

Example

cell (diff_buffer) {

...

pin (A) { /* noninverting pin /

direction : input ;

complementary_pin : ("DiffA")

fault_model : "1x" ;

}

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

Table 5 shows how testing interprets the complementary pin values for this example:

Table 5 Interpretation of Pin Values

Pin A (noninverting pin) DiffA (complementary_pin) Resulting signal pin value

1 0 1

0 1 0

0 0 1

1 1 x

inverted_output Attribute

The inverted_output attribute is a Boolean attribute that you can set for any output port.

It is a required attribute only for sequential cells.

Set this attribute to false for noninverting output, which is variable1 or IQ for flip-flop or

latch groups. Set this attribute to true for inverting output, which is variable2 or IQN for flip-

flop or latch groups.

Example

pin(Q) {

function : "IQ";

internal_node : "IQ";

inverted_output : false;

}

This attribute affects the internal interpretation of the state table format used to describe a

sequential cell.

is_analog Attribute

The is_analog attribute identifies an analog signal pin as analog so it can be recognized

by tools. The valid values for is_analog are true and false. Set the is_analog attribute

to true at the pin level to specify that the signal pin is analog.

Syntax

The syntax for the is_analog attribute is as follows:

cell (cell_name) {

...

pin (pin_name) {

is _analog: true | false ;

...

}

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

}

Example

The following example identifies the pin as an analog signal pin.

pin(Analog) {

direction : input;

capacitance : 1.0 ;

is_analog : true;

}

pin_func_type Attribute

This attribute describes the functions of a pin.

Example

pin_func_type : clock_enable;

With the pin_func_type attribute, you avoid the checking and modeling caused by

incomplete timing information about the enable pin. The information in this attribute

defines the clock as the clock-enabling mechanism (that is, the clock-enable pin). This

attribute also specifies whether the active level of the enable pin of latches is high or low

and whether the active edge of the flip-flop clock is rising or falling.

The report_lib command lists the pins of a cell if they have one of these

pin_func_type values: active falling, active high, active low, active rising, or clock enable.

steady_state_resistance Attributes

When there are multiple drivers connected to an interconnect network driven by library

cells and there is no direct current path between them, the driver resistances could take on

different values.

Use the following attributes for more-accurate modeling of steady state driver resistances

in library cells.

•

steady_state_resistance_above_high

•

steady_state_resistance_below_low

• steady_state_resistance_high

•

steady_state_resistance_low

Example

steady_state_resistance_above_high : 200 ;

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

test_output_only Attribute

This attribute is an optional Boolean attribute that you can set for any output port

described in statetable format.

In ff or latch format, if a port is to be used for both function and test, you provide the

functional description using the function attribute. If a port is to be used for test only, you

omit the function attribute.

Regardless of ff or latch statetable, the test_output_only attribute takes precedence

over the functionality.

In statetable format, however, a port always has a functional description. Therefore, if you

want to specify that a port is for test only, you set the test_output_only attribute to true.

Example

pin (my_out) {

direction : output ;

signal_type : test_scan_out ;

test_output_only : true ;

}

Describing Design Rule Checks

To define design rule checks, use the following pin group attributes and group:

•

fanout_load attribute

•

max_fanout attribute

• min_fanout attribute

•

max_transition attribute

•

max_trans group

• min_transition attribute

•

max_capacitance attribute

•

max_cap group

•

min_capacitance attribute

•

cell_degradation group

fanout_load Attribute

The fanout_load attribute gives the fanout load value for an input pin.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

Example

fanout_load : 1.0;

The sum of all fanout_load attribute values for input pins connected to a driving (output)

pin must not exceed the max_fanout value for that output pin.

Figure 6 Fanout Attributes of a Cell (max_fanout and fanout_load)

max_fanout Attribute

This attribute defines the maximum fanout load that an output pin can drive.

Example

pin(Q)

direction : output;

max_fanout : 10;

}

You can specify max_fanout at three levels: at the library level, at the pin level, and on the

command line in dc_shell.

The max_fanout attribute is an implied design rule constraint. The Design Compiler

tool attempts to resolve max_fanout violations, possibly at the expense of other design

constraints.

In the figure in fanout_load Attribute, the Design Compiler tool adds all the fanout_load

values of the input to equal 3.0. Then the Design Compiler tool compares the sum of

the fanout_load on all inputs with the max_fanout constraint of the driving output,

which is 10. In this case, no design rule violation occurs. If a design rule violation occurs,

the Design Compiler tool might replace the driving cell with a cell that has a higher

max_fanout value.

When you are selecting a max_fanout value, the Design Compiler tool follows these rules:

•

The value you assign for the pin always overrides the library default.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

• When you assign a max_fanout value at the command line, the Design Compiler tool

uses the smallest value. If the pin value is smaller, the Design Compiler tool ignores the

command-line value.

To specify a global maximum fanout for all gate outputs in the design, use max_fanout

on the command line of dc_shell. When defined on the command line, the value of

max_fanout is assigned to all gate outputs that do not have a specified max_fanout or

whose max_fanout value is greater than the one defined.

It differs from the capacitance pin attribute in the following ways:

•

The fanout values are used only for design rule checking.

• The capacitance values are used delay calculations.

Some designs have limitations on input load that an output pin can drive regardless of

any loading contributed by interconnect metal layers. To limit the number of inputs on the

same net driven by an output pin, define a max_fanout value for each output pin and a

fanout_load on each input pin in a cell. (See the figure in fanout_load Attribute.)

To determine max_fanout, find the smallest loading of any input to a cell in the library and

use that value as the standard load unit for the entire library. Usually the smallest buffer or

inverter has the lowest input pin loading value. Use some multiple of the standard value for

the fanout loads of the other cells.

Although you can use capacitance as the unit for your max_fanout and fanout_load

specifications, it should be used to constrain routability requirements.

min_fanout Attribute

This attribute defines the minimum fanout load that an output or inout pin can drive. The

sum of fanout cannot be less than the minimum fanout value.

Example

pin(Q) {

direction : output;

min_fanout : 2.0;

}

The min_fanout attribute is an implied design rule constraint. The Design Compiler tool

resolves min_fanout violations, possibly at the expense of other design constraints.

max_transition Attribute

This attribute defines a design rule constraint for the maximum acceptable transition time

of an input or output pin.

Example

pin(A) {

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

direction : input;

max_transition : 4.2;

}

You can specify max_transition at three levels: at the library level, at the pin level, and

on the command line.

With an output pin, max_transition is used only to drive a net for which the cell can

provide a transition time at least as fast as the defined limit.

With an input pin, max_transition indicates that the pin cannot be connected to a net

that has a transition time greater than the defined limit.

In the following example, the cell that contains pin Q cannot be used to drive a net for

which the cell cannot provide a transition time faster than 5.2:

pin(Q) {

direction : output ;

max_transition : 5.2 ;

}

The max_transition value you define is checked by the synthesis tool, the transition

delay that the Design Compiler tool calculates is the rise and fall resistance multiplied by

the sum of the pin and wire capacitances.

If the calculated delay is greater than the value you specify with the max_transition

attribute, a design rule violation is reported, and the Design Compiler tool tries to correct

the violation, possibly at the expense of other design constraints.

max_trans Group

The max_trans group specifies the maximum transition time of an input, output, or inout

pin as a function of operating frequency of the cell, input transition time, and output load.

Use the max_trans group instead of the max_transition attribute to include these effects

on the maximum transition time. When both the max_trans group and max_transition

attribute are present, the max_trans group overrides the max_transition attribute.

To model the effect of operating frequency, input transition time, and output load on the

maximum transition, define the lookup table template for the max_trans group at the

library level.

To define the lookup table template, use the maxtrans_lut_template group at

the library level. The maxtrans_lut_template group can have the variables,

variable_1, variable_2, and variable_3. The valid values of the variable_1,

variable_2, and variable_3 variables are frequency, input_transition_time, and

total_output_net_capacitance respectively.

The one-dimensional lookup table consists of the maximum transition values for different

values of frequency. Similarly, the two-dimensional lookup table consists of the maximum

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

transition values for different values of frequency and input_transition_time and so

on.

The following syntax shows the maximum transition model:

library (library_name) {

delay_model : table_lookup;

...

maxtrans_lut_template (template_name1) { /*1-D LUT template*/

variable_1 : frequency ;

index_1 ( "float, ... float" );

}

maxtrans_lut_template (template_name2) { /*2-D LUT template*/

variable_1 : frequency ;

variable_2 : input_transition_time ;

index_1 ( "float, ... float" );

index_2 ( "float, ... float" );

}

maxtrans_lut_template (template_name3) { /*3-D LUT template*/

variable_1 : frequency ;

variable_2 : input_transition_time ;

variable_3 : total_output_net_capacitance ;

index_1 ( "float, ... float" );

index_2 ( "float, ... float" );

index_3 ( "float, ... float" );

}

cell (cell_name) {

...

pin (pin_name) { /* input pin */

...

max_trans (template_name1) {

index_1 ("float, ... float");

values ("float, ... float");

}

...

} /* pin */

...

pin (pin_name) { /* input pin */

...

max_trans (template_name2) { /* output or inout pin */

index_1 ("float, ... float");

index_2 ("float, ... float");

values ("float, ... float");

}

...

pin (pin_name2) { /* input pin */

...

max_trans (template_name3) { /* output or inout pin */

index_1 ("float, ... float");

index_2 ("float, ... float");

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

index_3 ("float, ... float");

values ("float, ... float");

}

} /* pin */

}/* cell */

...

}/* library */

Maximum Transition Modeling Example

Example 17 Frequency-Dependent Maximum Transition Model With One-Dimensional Lookup

Table

library(my_lib) {

technology (cmos);

delay_model : table_lookup;

...

maxtrans_lut_template ( mt ) {

variable_1 : frequency;

index_1 ( "100.0000, 200.0000" );

}

...

cell ( test ) {

......

pin(Z) {

direction : output ;

function: "A";

...

max_trans(mt) {

index_1 ( "100.0000, 200.0000, 300.0000");

values ( "925.0000, 835.0000, 745.0000");

} /* end of max_trans */

timing () {

related_pin : "A" ;

...

} /* end of arc */

} /* end of pin Z */

pin(A) {

direction : input ;

max_transition : 5000.000000 ;

capacitance : 1.0 ;

} /* end of pin A */

} /* end of cell */

} /* end of library */

min_transition Attribute

This attribute defines a design rule constraint for the minimum acceptable transition time of

an input, output, or an inout pin.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

Example

pin(A) {

direction : input;

min_transition : 1.2;

}

max_capacitance Attribute

This attribute defines the maximum total capacitive load that an output pin can drive. This

attribute can be specified only for an output or inout pin.

Example

pin(Q) {

direction : output;

max_capacitance : 5.0;

}

You can specify max_capacitance at three levels: at the library level, at the pin level, and

on the command line.

The Design Compiler tool uses an output pin only when the pin has a max_capacitance

attribute value greater than or equal to the total wire and pin capacitive load it drives.

The total wire and pin capacitance is derated before it is checked by this tool. The tool

attempts to resolve max_capacitance design rule violations, possibly at the expense of

other design constraints.

max_cap Group

The max_cap group specifies the maximum capacitive load that an output or inout pin

can drive as a function of operating frequency of the cell or both operating frequency

and input transition time. Use the max_cap group instead of the max_capacitance

attribute to include these effects on the maximum capacitance. When both the max_cap

group and max_capacitance attribute are present, the max_cap group overrides the

max_capacitance attribute.

To model the effect of operating frequency and input transition time on the maximum

capacitance, define the lookup table template for the max_cap group at the library level.

To define the lookup table template, use the maxcap_lut_template group at the

library level. The maxcap_lut_template group can have the variables, variable_1

and variable_2. The valid values of the variable_1 and variable_2 variables are

frequency and input_transition_time, respectively.

The one-dimensional lookup table consists of the maximum capacitance values for

different values of frequency. The max_cap group takes the value of the maximum

capacitance from the lookup table by using the variable_1 variable.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

The two-dimensional lookup table consists of the maximum capacitance values for

different values of frequency and input_transition_time. The max_cap group takes

the value of the maximum capacitance from the lookup table by using the variable_1 and

variable_2 variables.

The following shows the maximum capacitance model syntax:

library (library_name) {

delay_model : table_lookup;

...

maxcap_lut_template (template_name1) { /*1-D lookup table template*/

variable_1 : frequency ;

index_1 ( "float, ... float" );

}

maxcap_lut_template (template_name2) {/*2-D LUT template */

variable_1 : frequency ;

variable_2 : input_transition_time ;

index_1 ( "float, ... float" );

index_2 ( "float, ... float" );

}

cell (cell_name) {

...

pin (pin_name) {

...

max_cap (template_name1) {

index_1 ("float, ... float");

values ("float, ... float");

}

...

} /* pin */

...

}/* cell */

...

}/* library */

Maximum Capacitance Modeling Example

Example 18 Frequency-Dependent Maximum Capacitance Model With One-Dimensional

Lookup Table

library(example_library) {

technology (cmos);

delay_model : table_lookup;

...

maxcap_lut_template ( mc ) {

variable_1 : frequency;

index_1 ( "100.0000, 200.0000" );

}

...

cell ( test ) {

......

pin(Z) {

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

direction : output ;

function: "A";

max_transition : 5000.000000 ;

min_transition : 0.000000 ;

min_capacitance : 0.000000 ;

max_cap(mc) {

index_1 ( "100.0000, 200.0000, 300.0000");

values ( "925.0000, 835.0000, 745.0000");

} /* end of max_cap */

timing () {

related_pin : "A" ;

...

} /* end of arc */

} /* end of pin Z */

pin(A) {

direction : input ;

max_transition : 5000.000000 ;

capacitance : 1.0 ;

} /* end of pin A */

} /* end of cell */

} /* end of library */

min_capacitance Attribute

This attribute defines the minimum total capacitive load that an output pin can drive. The

capacitance load cannot be less than the minimum capacitance value. This attribute can

be specified only for an output or inout pin.

Example

pin(Q) {

direction : output;

min_capacitance : 1.0;

}

The Design Compiler tool uses an output pin only when the pin has a min_capacitance

attribute value less than or equal to the total wire and pin capacitive load it drives. The

total wire and pin capacitance is derated before it is checked by the tool. The tool attempts

to resolve min_capacitance design rule violations, possibly at the expense of other

design constraints.

cell_degradation Group

Use the cell_degradation group to describe a cell performance degradation design

rule when compiling a design. A cell degradation design rule specifies the maximum

capacitive load a cell can drive without causing cell performance degradation during the

fall transition.

This description is restricted to functionally related input and output pairs. You can

determine the degradation value by switching some inputs while keeping other inputs

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

constant. This causes output discharge. The degradation value for a specified input

transition rate is the maximum output loading that does not cause cell degradation.

You can model cell degradation only in libraries using the CMOS nonlinear delay model.

Cell degradation modeling uses the same format of templates and lookup tables used to

model delay with the nonlinear delay model.

There are two ways to model cell degradation,

Create a one-dimensional lookup table template that is indexed by input transition time.

The following shows the syntax of the cell degradation template.

lu_table_template(template_name) {

variable_1 : input_net_transition;

index_1 ("float, ..., float");

}

The valid value for variable_1 is input_net_transition.

The index_1 values must be greater than or equal to 0.0 and follow the same rules

for the lookup table template index_1 attribute described in Defining pin Groups on

page 70. The number of floating-point numbers in index_1 determines the size of

the table dimension.

This is an example of a cell degradation template.

lu_table_template(deg_constraint) {

variable_1 : input_net_transition;

index_1 ("0.0, 1.0, 2.0");

}

Use the cell_degradation group and the cell degradation template to create a one-

dimensional lookup table for each timing arc in the cell. You receive warning messages

if you define a cell_degradation construct for some, but not all, timing arcs in the

cell.

The following example shows the cell_degradation group:

pin(output) {

timing() {

cell_degradation(deg_constraint) {

index_1 ("0.5, 1.5, 2.5");

values ("0.0, 2.0, 4.0");

}

You can describe cell degradation groups only in the following types of timing groups:

•

combinational

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

• three_state_enable

• rising_edge

• falling_edge

•

preset

•

clear

Describing Clocks

To define clocks and clocking, use these pin group attributes:

•

clock

•

min_period

• min_pulse_width_high

•

min_pulse_width_low

clock Attribute

This attribute indicates whether or not an input pin is a clock pin.

A true value labels a pin as a clock pin. A false value labels a pin as not a clock pin, even

though it might otherwise have such characteristics.

Example

clock : true ;

min_period Attribute

Place the min_period attribute on the clock pin of a flip-flop or a latch to specify the

minimum clock period required for the input pin. The minimum period is the sum of the

data arrival time and setup time. This time must be consistent with the max_transition

time.

Example

min_period : 26.0;

min_pulse_width_high and min_pulse_width_low Attributes

Use these optional attributes to specify the minimum length of time a pin must remain at

logic 1 (min_pulse_width_high) or logic 0 (min_pulse_width_low). These attributes can

be placed on a clock input pin or an asynchronous clear/preset pin of a flip-flop or latch.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

Note:

The Design Compiler tool does not support minimum pulse width as a

constraint during synthesis.

Example

The following example shows both attributes on a clock pin, indicating the minimum pulse

width for a clock pin.

pin(CLK) {

direction : input ;

capacitance : 1 ;

min_pulse_width_high : 3 ;

min_pulse_width_low : 3 ;

}

Describing Clock Pin Functions

To define the function of a clock pin, use these pin group attributes:

•

function

•

three_state

• x_function

•

state_function

•

internal_node

function Attribute

The function attribute defines the value of an output or inout pin in terms of the cell’s

input or inout pins.

Syntax

function : "Boolean expression" ;

The precedence of the operators is left to right, with inversion performed first, then XOR,

then AND, then OR.

The function attribute statement provides information for the Design Compiler and

DFT Compiler tools. The Design Compiler tool uses this information when choosing

components during synthesis. A cell without a function attribute is treated as a black box

and is not synthesized or optimized.

If you want to prevent a cell from being used or replaced during optimization, use the

dont_use attribute.

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

Note:

The DFT Compiler tool cannot test cells that do not include a function

attribute or cells that cannot have a function attribute, such as shift registers

and counters.

Table 6 Valid Boolean Operators in the function

Attribute Statement

Operator Description

’ Invert previous expression

! Invert following expression

^ Logical XOR

* Logical AND

& Logical AND

space Logical AND

+ Logical OR

| Logical OR

1 Signal tied to logic 1

0 Signal tied to logic 0

Grouped Pins in function Statements

Grouped pins can be used as variables in a function statement; see Defining Bused Pins

on page 100 and Defining Signal Bundles on page 106. In function statements that

use bus or bundle names, all the variables in the statements must be either a single pin or

buses or bundles of the same width.

Ranges of buses or bundles are valid if the range you define contains the same number of

members as the other buses or bundles in the same expression. You can reverse the bus

order by listing the member numbers in reverse (high: low) order. Two buses, bundles, or

bused-pin ranges with different widths should not appear in the same function statement.

When the function attribute of a cell with group input pins is a combinational-logic

function of grouped variables only, the logic function is expanded to apply to each set of

output grouped pins independently. For example, if A, B, and Z are defined as buses of the

same width and the function statement for output Z is

function : "(A & B)" ;

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

the function for Z[0] is interpreted as

function : "(A[0] & B[0])" ;

Likewise, the function for Z[1] is interpreted as

function : "(A[1] & B[1])" ;

If a bus and a single pin are in the same function attribute, the single pin is distributed

across all members of the bus. For example, if A and Z are buses of the same width, B is

a single pin, and the function statement for the Z output is

function : "(A & B)" ;

The function for Z[0] is interpreted as

function : "(A[0] & B)" ;

Likewise, the function for Z[1] is interpreted as

function : "(A[1] & B)" ;

three_state Attribute

Use this attribute to define a three-state output pin in a cell.

Only the high impedance to logic 0 and high impedance to logic 1 timing arcs are used

during three-state component synthesis and optimization.

In Example 19, output pin Z is a three-state output pin. When input pin E (enable) goes

low, pin Z goes to a high-impedance state. The value of the three_state attribute is,

therefore, E'.

Example 19 Three-State Cell Description

library(example){

technology (cmos) ;

date : "May 14, 2002" ;

revision : 2002.05;

...

cell(TRI_INV2) {

area : 3 ;

pin(A) {

direction : input ;

capacitance : 2 ;

}

pin(E) {

direction : input ;

capacitance : 2 ;

}

pin(Z) {

direction : output ;

function : "A’" ;

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining pin Groups

three_state : "E’" ;

timing() {

...

}

x_function Attribute

Use the x_function attribute to describe the X behavior of a pin, where X is a state other

than 0, 1, or Z.

Note:

Only the Formality tool uses the x_function attribute.

The three_state, function, and x_function attributes are defined for output and

inout pins and can have shared input. You can assign three_state, function, and

x_function to be the function of the same input pins. When these functions have shared

input, however, the cell must be inserted manually.

Also, when the values of more than one function equal 1, the three functions are evaluated

in this order:

x_function

2. three_state

function

Example

pin (y) {

direction: output;

function : "!ap * !an" ;

x_function : "!ap * an" ;

three_state : "ap * !an" ;

}

state_function Attribute

Use this attribute to define output logic. Ports in the state_function Boolean expression

must be either input, three-state inout, or ports with an internal_node attribute. If the

output logic is a function of only the inputs (IN), the output is purely combinational (for

example, feed-through output). A port in the state_function expression refers only to

the non-three-state functional behavior of that port. An inout port in the state_function

expression is treated only as an input port.

Example

state_function : Q*X;

Liberty User Guide Volume 1

R-2020.09

Chapter 4: Defining Core Cells

Defining Bused Pins

internal_node Attribute

Use this attribute to resolve node names to real port names. The internal_node attribute

describes the sequential behavior of an output pin. It provides the relationship between the

statetable group and a pin of a cell. Each output with the internal_node attribute might

also have the optional input_map attribute.

Example

internal_node : "Q";

Defining Bused Pins

To define bused pins, use these groups:

• type group

•

bus group

You can use a defined bus or bus member in Boolean expressions in the function

attribute. An output pin does not need to be defined in a cell before it is referenced.

type Group

If your library contains bused pins, you must define type groups and define the structural

constraints of each bus type in the library.

The type group is defined at the library group level, as follows:

library (lib_name) {

type ( name ) {

... type description ...

}

name

Identifies the bus type.

A type group can one of the following:

base_type

Only the array base type is supported.

data_type

Only the bit data type is supported.

Liberty User Guide Volume 1

R-2020.09

100

Chapter 4: Defining Core Cells

Defining Bused Pins

bit_width

An integer that designates the number of bus members. The default is 1.

bit_from

An integer indicating the member number assigned to the most significant bit

(MSB) of successive array members. The default is 0.

bit_to

An integer indicating the member number assigned to the least significant bit

(LSB) of successive array members. The default is 0.

downto

A value of true indicates that member number assignment is from high to low

instead of low to high. The default is false (low to high).

Example 20 type Group Statement

type ( BUS4 ) {

base_type : array ;

data_type : bit ;

bit_width : 4 ;

bit_from : 0 ;

bit_to : 3 ;

downto :false ;

}

It is not necessary to use all the type group attributes. For example, both the type group

statements in Example 21 are valid descriptions of BUS4 of Example 20.

Example 21 Alternative type Group Statements

type ( BUS4 ) {

base_type : array ;

data_type : bit ;

bit_width : 4 ;

bit_from : 0 ;

bit_to : 3 ;

}

type ( BUS4 ) {

base_type : array ;

data_type : bit ;

bit_width : 4 ;

bit_from : 3 ;

downto : true ;

}

After you define a type group, you can use the type group in a bus group to describe

bused pins.

Liberty User Guide Volume 1

R-2020.09

101

Chapter 4: Defining Core Cells

Defining Bused Pins

bus Group

A bus group describes the characteristics of a bus. You define it in a cell group, as

shown here:

library (lib_name) {

cell (cell_name) {

area : float ;

bus ( name ) {

... bus description ...

}

A bus group contains the following elements:

•

bus_type attribute

•

pin groups

In a bus group, use the number of bus members (pins) defined by the bit_width attribute

in the applicable type group. You must declare the bus_type attribute first in the bus

group.

bus_type Attribute

The bus_type attribute specifies the bus type. It is a required element of all bus groups.

Always declare the bus_type as the first attribute in a bus group.

Note:

The bus type name must exist in a type group.

Syntax

bus_type : name ;

Pin Attributes and Groups

Pin attributes in a bus or bundle group specify default attribute values for all pins in that

bus or bundle. Pin attributes can also appear in pin groups inside the bus or bundle group

to define attribute values for specific bus or bundle pins or groups of pins. Values used in

pin groups override the default attribute values defined for the bus or bundle.

All pin attributes are valid inside bus and pin groups. See General pin Group Attributes

on page 71 for a description of pin attributes. The direction attribute value of all bus

members must be the same.

Use the full name of a pin for the names of pins in a pin group contained in a bus group.

Liberty User Guide Volume 1

R-2020.09

102

Chapter 4: Defining Core Cells

Defining Bused Pins

The following example shows a bus group that defines bus A, with defaults for direction

and capacitance assigned:

bus (A) {

bus_type : bus1 ;

direction : input ;

capacitance : 3 ;

...

}

The following example illustrates a pin group that defines a new capacitance attribute

value for pin 0 in bus A:

pin (A[0]) {

capacitance : 4 ;

}

You can also define pin groups for a range of bus members. A range of bus members is

defined by a beginning value and an ending value, separated by a colon. No spaces can

appear between the colon and the member numbers.

The following example illustrates a pin group that defines a new capacitance attribute

value for bus members 0, 1, 2, and 3 in bus A:

pin (A[0:3]) {

capacitance : 4 ;

}

For nonbused pins, you can identify member numbers as single numbers or as a range of

numbers separated by a colon. Do not define member numbers in a list.

Table 7 Comparison of Bused and Single-Pin

Formats

Pin type Logic library

Bused Pin pin x[3:0]

Single Pin pin x

Example Bus Description

Example 22 includes type and bus groups. It also shows the use of bus variables in

function, related_pin, pin_opposite, and pin_equal attributes.

Example 22 A Complete Bus Description

library (ExamBus) {

date : "May 14, 2002";

Liberty User Guide Volume 1

R-2020.09

103

Chapter 4: Defining Core Cells

Defining Bused Pins

revision : 2002.05;

bus_naming_style :"%s[%d]";/* Optional; this is the

default */

type (bus4) {

base_type : array;/* Required */

data_type : bit;/* Required if base_type is array */

bit_width : 4;/* Optional; default is 1 */

bit_from : 0;/* Optional MSB; defaults to 0 */

bit_to : 3;/* Optional LSB; defaults to 0 */

downto : false;/* Optional; defaults to false */

}

cell (bused_cell) {

area : 10;

bus (A) {

bus_type : bus4;

direction : input;

capacitance : 3;

pin (A[0:2]) {

capacitance : 2;

}

pin (A[3]) {

capacitance : 2.5;

}

bus (B) {

bus_type : bus4;

direction : input;

capacitance : 2;

}

pin (E) {

direction : input ;

capacitance 2 ;

}

bus(X) {

bus_type : bus4;

direction : output;

capacitance : 1;

pin (X[0:3]) {

function : "A & B’";

timing() {

related_pin : "A B";

/* A[0] and B[0] are related to X[0],

A[1] and B[1] are related to X[1], etc. */

}

bus (Y) {

bus_type : bus4;

direction : output;

capacitance : 1;

pin (Y[0:3]) {

function : "B";

three_state : "!E";

Liberty User Guide Volume 1

R-2020.09

104

Chapter 4: Defining Core Cells

Defining Bused Pins

timing () {

related_pin : "A[0:3] B E";

}

internal_power() {

when: "E" ;

related_pin : B ;

power() {

...

}

internal_power() {

related_pin : B ;

power() {

...

}

bus (Z) {

bus_type : bus4;

direction : output;

pin (Z[0:1]) {

function : "!A[0:1]";

timing () {

related_pin : "A[0:1]";

}

internal_power() {

related_pin : "A[0:1]";

power() {

...

}

pin (Z[2]) {

function "A[2]";

timing () {

related_pin : "A[2]";

}

internal_power() {

related_pin : "A[0:1]";

power() {

...

}

pin (Z[3]) {

function : "!A[3]";

timing () {

related_pin : "A[3]";

}

internal_power() {

related_pin : "A[0:1]";

power() {

Liberty User Guide Volume 1

R-2020.09

105

Chapter 4: Defining Core Cells

Defining Signal Bundles

...

}

pin_opposite("Y[0:1]","Z[0:1]");

/* Y[0] is opposite to Z[0], etc. */

pin_equal("Y[2:3] Z[2:3]");

/* Y[2], Y[3], Z[2], and Z[3] are equal */

cell (bused_cell2) {

area : 20;

bus (A) {

bus_type : bus41;

direction : input;

capacitance : 1;

pin (A[0:3]) {

capacitance : 2;

}

pin (A[3]) {

capacitance : 2.5;

}

bus (B) {

bus_type : bus4;

direction : input;

capacitance : 2;

}

pin (E) {

direction : input ;

capacitance 2 ;

}

bus(X) {

bus_type : bus4;

direction : output;

capacitance : 1;

pin (X[0:3]) {

function : "A & B’";

timing() {

related_pin : "A B";

/* A[0] and B[0] are related to X[0],

A[1] and B[1] are related to X[1], etc. */

}

Defining Signal Bundles

You need certain attributes to define a bundle. A bundle groups several pins that have

similar timing or functionality. Bundles are used for multibit cells such as multibit latch,

multibit flip-flop, and multibit AND gate.

Liberty User Guide Volume 1

R-2020.09

106

Chapter 4: Defining Core Cells

Defining Signal Bundles

bundle Group

Define a bundle group in a cell group, as shown:

library (lib_name) {

cell (cell_name) {

area : float ;

bundle ( name ) {

... bundle description ...

}

A bundle group contains the following elements:

members attribute

The members attribute must be declared first in a bundle group.

pin attributes

These include direction, function, and three-state.

members Attribute

The members attribute is used in a bundle group to list the pin names of the signals in

a bundle. The members attribute must be included as the first attribute in the bundle

group. It provides the bundle element names and groups a set of pins that have similar

properties. The number of members defines the width of the bundle.

If a bundle has a function attribute defined for it, that function is copied to all bundle

members. For example,

pin (C) {

direction : input ;

...

}

bundle(A) {

members(A0, A1, A2, A3);

direction : output ;

function : "B’+ C";

...

}

bundle(B) {

members(B0, B1, B2, B3);

direction : input;

...

}

Liberty User Guide Volume 1

R-2020.09

107

Chapter 4: Defining Core Cells

Defining Signal Bundles

means that the members of the A bundle have these values:

A0 = B0’ + C;

A1 = B1’ + C;

A2 = B2’ + C;

A3 = B3’ + C;

Each bundle operand (B) must have the same width as the function parent bundle (A).

pin Attributes

For information about pin attributes, see General pin Group Attributes on page 71.

Example 23 Multibit Latch With Signal Bundles (bundle Group Syntax)

cell (latch4) {

area: 16;

pin (G) { /* active-high gate enable signal */

direction : input;

}

bundle (D) { /* data input with four member pins */

members(D1, D2, D3, D4); /*must be first attribute */

direction : input;

}

bundle (Q) {

members(Q1, Q2, Q3, Q4);

direction : output;

function : "IQ" ;

}

bundle (QN) {

members (Q1N, Q2N, Q3N, Q4N);

direction : output;

function : "IQN";

}

latch_bank(IQ, IQN, 4) {

enable : "G" ;

data_in : "D" ;

}

cell (latch5) {

area: 32;

pin (G) { /* active-high gate enable signal */

direction : input;

}

bundle (D) { /* data input with four member pins */

members(D1, D2, D3, D4); /*must be first attribute */

direction : input;

}

bundle (Q) {

members(Q1, Q2, Q3, Q4);

direction : output;

function : "IQ" ;

}

bundle (QN) {

Liberty User Guide Volume 1

R-2020.09

108

Chapter 4: Defining Core Cells

Defining Layout-Related Multibit Attributes

members (Q1N, Q2N, Q3N, Q4N);

direction : output;

function : "IQN";

}

latch_bank(IQ, IQN, 4) {

enable : "G" ;

data_in : "D" ;

}

Defining Layout-Related Multibit Attributes

The single_bit_degenerate attribute is a layout-related attribute for multibit cells. The

attribute also applies to sequential and combinational cells.

The single_bit_degenerate attribute is for use on multibit bundle or bus cells that are

black boxes. The value of this attribute is the name of a single-bit library cell.

Example 24 Multibit Cells With single_bit_degenerate Attribute

cell (FDX2) {

area : 18 ;

single_bit_degenerate : FDB ;

bundle (D) {

members (D0, D1) ;

direction : input ;

...

timing () {

...

}

cell (FDX4)

area : 18 ;

single_bit_degenerate : FDB ;

bus (D) {

bus_type : bus4 ;

direction : input ;

...

timing () {

...

}

The library description does not include information such as cell height; this must be

provided by the library developer.

Liberty User Guide Volume 1

R-2020.09

109

Chapter 4: Defining Core Cells

Defining Multiplexers

A one-hot MUX is a library cell that behaves functionally as a regular MUX logic gate.

However, in the case of a one-hot MUX, some inputs are considered dedicated control

inputs and others are considered dedicated data inputs. There are as many control inputs

as data inputs, and the function of the cell is the logic AND of the i

control input with the

data input. For example, a 4-to-1 one-hot MUX has the following function:

Z = (D_0 & C_0) | (D_1 & C_1) | (D_2 & C_2) | (D_3 & C_3)

One-hot MUXs are generally implemented using pass gates, which makes them very

fast and allows their speed to be largely independent of the number of data bits being

multiplexed. However, this implementation requires that exactly one control input be active

at a time. If no control inputs are active, the output is left floating. If more than one control

input is active, there could be an internal drive fight.

Library Requirements

One-hot MUX library cells must meet the following requirements:

•

A one-hot MUX cell in the target library should be a single-output cell.

•

Its inputs can be divided into two disjoint sets of the same size as follows:

C={C_1, C_2, ..., C_n} and D={D_1, D_2, ..., D_n}

where n is greater than 1 and is the size of the set. Actual names of the inputs can

vary.

• The contention_condition attribute must be set on the cell. The value of the

attribute is a combinational function, f{C}, of inputs in set C that defines prohibited

combinations of inputs as shown in the following examples (where size n of the set is

3):

FC = C_0' & C_1' & C_2' | C_0 & C_1 | C_0 & C_2 | C_1 & C_2

FC = (C_0 & C_1' & C_2' | C_0' & C_1 & C_2' | C_0' & C_1' & C_2)'

•

The cell must have a combinational function FO defined on the output with respect

to all its inputs. This function FO must logically define, together with the contention

condition, a base function F* that is a sum of n product terms, where the i

term

contains all the inputs in C, with C_i high and all others low and exclusively one input in

Liberty User Guide Volume 1

R-2020.09

110

Chapter 4: Defining Core Cells

Defining Multiplexers

Examples of the defined function are as follows (for n = 3):

F* = C_0 & C_1' & C_2' & D_0 | C_0' & C_1 & C_2' & D_1 | C_0' & C_1'

F* = C_0 & C_1' & C_2' & D_0' + C_0' & C_1 & C_2' & D_1' + C_0' &

C_1'

C_2 & D_2'

The function FO can take many forms, if it satisfies the following condition:

FO & FC' == F*

when FO is restricted by FC', it should be equivalent to F*. The term FO = F* is

acceptable; other examples are as follows (for n = 3):

FO = (D_0 & C_0) | (D_1 & C_1) | (D_2 & C_2)

FO = (D_0' & C_0) | (D_1' & C_1) | (D_2' & C_2)

Note:

When FO is restricted by FC, inverting all inputs in D is equivalent to

inverting the output. Inverting only a subset of D yields an incompatible

function. It is recommended that you use the simple form described earlier,

or F*.

The following example shows a cell that is properly specified.

Example

cell(one_hot_mux_example) {

... ...

contention_condition : "(C0 C1 + C0' C1')";

... ...

pin(D0) {

direction : input;

... ...

}

pin(D1) {

direction : input;

... ...

}

pin(C0) {

direction : input;

... ...

}

pin(C1) {

Liberty User Guide Volume 1

R-2020.09

111

Chapter 4: Defining Core Cells

Defining Decoupling Capacitor Cells, Filler Cells, and Tap Cells

direction : input;

... ...

}

pin(Z) {

direction : output;

function : "(C0 D0 + C1 D1)";

... ...

}

Defining Decoupling Capacitor Cells, Filler Cells, and Tap Cells

Decoupling capacitor cells, or decap cells, are cells that have a capacitor placed between

the power rail and the ground rail to overcome dynamic voltage drop; filler cells are used

to connect the gaps between the cells after placement; and tap cells are physical-only

cells that have power and ground pins and do not have signal pins. Cell-level attributes

that identify decoupling capacitor cells, filler cells, and tap cells in libraries are supported.

Syntax

The following syntax shows a cell with the is_decap_cell, is_filler_cell and

is_tap_cell attributes, which identify decoupling capacitor cells, filler cells, and tap cells,

respectively. However, only one attribute can be set to true in a given cell.

cell (cell_name) {

...

is_decap_cell : true | false;

is_filler_cell : true | false;

is_tap_cell : true | false;

...

} /* End cell group */

Cell-Level Attributes

The following attributes can be set at the cell level to identify decoupling capacitor cells,

filler cells, and tap cells.

is_decap_cell

The is_decap_cell attribute identifies a cell as a decoupling cell. Valid values are true

and false.

is_filler_cell

The is_filler_cell attribute identifies a cell as a filler cell. Valid values are true and

false.

Liberty User Guide Volume 1

R-2020.09

112

Chapter 4: Defining Core Cells

Fault Tolerant Cell Modeling

is_tap_cell

The is_tap_cell attribute identifies a cell as a tap cell. Tap cells are physical-only cells,

which means they have power and ground pins only and not signal pins. Tap cells are

well-tied cells that bias the silicon infrastructure of n-wells or p-wells. Valid values for the

is_tap_cell attribute are true and false.

Fault Tolerant Cell Modeling

Fault tolerance is a requirement of safe automotive systems. Fault-tolerant library cell

models ensure that fault-tolerant cell designs are honored by downstream tools.

In IC designs, registers contribute to most of the soft errors. Soft errors affect the data

state of sequential elements and are caused by random environmental radiation events.

Soft error rate (SER) is the rate at which a library cell is predicted to encounter soft errors.

SER is expressed as the number of failures-in-time (FIT) per million library cells, where

FIT is equivalent to one error per billion hours of device operation. SER is affected by

changes in process, voltage, temperature, altitude, frequency, and confidence.

Fault Tolerant Modeling Syntax

library (library_name) {

…

altitude_unit : enum_value ;

soft_error_rate_template (temp_name) {

variable_1 : [ altitude | frequency ] ;

variable_2 : [ altitude | frequency ] ;

index_1 ( … ) ;

index_2 ( … ) ;

}

default_soft_error_rate (temp_name) {

index_1 ( … ) ;

index_2 ( … ) ;

values ( … ) ;

}

soft_error_rate_confidence : float ;

cell (cell_name) {

soft_error_rate (temp_name) {

index_1 ( … ) ;

index_2 ( … ) ;

values ( … ) ;

}

…

} /* end cell group */

…

} /* end library group */

Liberty User Guide Volume 1

R-2020.09

113

Chapter 4: Defining Core Cells

Fault Tolerant Cell Modeling

Library-Level Attributes and Groups

Fault tolerant cell modeling contains the following library-level attributes and groups.

altitude_unit Attribute

The altitude_unit attribute specifies the unit of altitude in the library. Valid values are 1

m (default) or 1 km.

soft_error_rate_template Group

The soft_error_rate_template group defines the table template for the

default_soft_error_rate and the soft_error_rate group. The template has two

indexes, altitude and frequency. The template table can be one-dimensional or two-

dimensional.

The template definition includes two one-dimensional variables, variable_1 and

variable_2, with values, altitude and frequency, respectively.

The index_1 attribute specifies the altitude values at which the cell SER is sampled in

the library. The unit is defined by the library-level altitude_unit attribute.

The index_2 attribute specifies the frequency values at which the cell SER is sampled

in the library. The values must be greater than or equal to zero. The unit is defined by the

library-level time_attribute attribute, as the frequency unit is reciprocal of the time unit.

default_soft_error_rate Group

The default_soft_error_rate group is a lookup table that specifies the default cell SER

in the library. The table values must be greater than or equal to zero.

The default table applies to cells in libraries where the cell-level soft_error_rate table is

not defined. The table can be one-dimensional or two-dimensional. It is recommended to

specify the library-level default_soft_error_rate table even for libraries that contain a

cell-level soft_error_rate table.

soft_error_rate_confidence Attribute

The soft_error_rate_confidence attribute specifies the confidence level at which the

cell SER is sampled in the library. The value range is from 0.0 to 1.0.

Cell-Level Attributes and Groups

Fault tolerant modeling contains the following cell-level group.

Liberty User Guide Volume 1

R-2020.09

114

Chapter 4: Defining Core Cells

Fault Tolerant Cell Modeling

soft_error_rate Group

The soft_error_rate group is a lookup table that specifies the SER for the cell. The

table values must be greater than or equal to zero. You can specify this table for all cell

types. The cell-level values override the library-level default_soft_error_rate values.

The table can be one-dimensional or two-dimensional.

Fault Tolerant Library Modeling Example

library(mylib) {

...

time_unit : 1ns ;

altitude_unit : 1km ;

soft_error_rate_template ( ser_temp ) {

variable_1 : altitude ;

variable_2 : frequency ;

index_1 ( "1.6, 1.8" ) ; /* altitude 1.6 km, 1.8 km */

index_2 ( "0.1, 0.2" ) ; /* frequency 100 MHz, 200 MHz */

}

default_soft_error_rate ( ser_temp ) {

index_1 ( "1.6, 1.8" ) ; /* altitude 1.6 km, 1.8 km */

index_2 ( "0.1, 0.2" ) ; /* frequency 100 MHz, 200 MHz */

/* 3.5 soft errors per 1 billion hours of operation */

values ( "3.5, 3.6, 4.5, 4.6") ;

}

soft_error_rate_confidence : 0.5 ;/* confidence level 50% */

cell(mycell) {

...

soft_error_rate ( ser_temp ) {

index_1 ( "1.6, 1.8" ) ; /* altitude 1.6 km, 1.8 km */

index_2 ( "0.1, 0.2" ) ; /* frequency 100 MHz, 200 MHz */

/* 3.55 soft error per 1 billion hours of operation */

values ( "3.55, 3.65, 4.55, 4.65" ) ;

}

} /* end cell group */

} /* end library group */

Liberty User Guide Volume 1

R-2020.09

115

Defining Sequential Cells

This chapter describes the peculiarities of defining flip-flops and latches, building upon

the cell description syntax given in Chapter 4, Defining Core Cells.” It describes group

statements that apply only to sequential cells and also describes a variation of the

function attribute that makes use of state variables.

To design flip-flops and latches, you must understand the following concepts and tasks:

• Using Sequential Cell Syntax

• Describing a Flip-Flop

• Using the function Attribute

• Describing a Multibit Flip-Flop

• Describing a Latch

• Describing a Multibit Latch

• Describing Sequential Cells With the Statetable Format

• Flip-Flop and Latch Examples

• Cell Description Examples

Using Sequential Cell Syntax

You can describe sequential cells with the following cell definition formats:

• ff or latch format

Cells using the ff or latch format are identified by the ff group and latch group.

•

statetable format

Cells using the statetable format are identified by the statetable group. The

statetable format supports all the sequential cells supported by the ff or latch format. In

addition, the statetable format supports complex sequential cells, such as the following:

◦

Sequential cells with multiple clock ports, such as a cell with a system clock and a

test scan clock

Liberty User Guide Volume 1

R-2020.09

116

Chapter 5: Defining Sequential Cells

Describing a Flip-Flop

◦ internal state sequential cells, such as master-slave cells

◦ Multistate sequential cells, such as counters and shift registers

◦ Sequential cells with combinational outputs

◦

Sequential cells with complex clocking and complex asynchronous behavior

◦

Sequential cells with multiple simultaneous input transitions

◦ Sequential cells with illegal input conditions

The statetable format contains a complete, expanded set of table rules for which all L

and H permutations of table input are explicitly specified.

Some cells cannot be modeled with the statetable format. For example, you cannot use

the statetable format to model a cell whose function depends on differential clocks when

the inputs change.

The format you use depends on the tool for which you design the library.

•

Design synthesis, test synthesis, and fault simulation tools support only the ff or latch

format.

Note:

The Design Compiler tool supports the ff or latch format, and ASIC vendors

should continue to use ff or latch format for all sequential cells that are

already supported. However, the statetable syntax is more intuitive and

easier to use than the current sequential modeling format. Therefore, ASIC

vendors should add the statetable format to all their sequential cells, to

ensure automatic functional verification and compatibility.

•

DFT Compiler supports the statetable format design rule checking (DRC) but requires

ff or latch format for scan substitution. See Chapter 6, Defining Test Cells,” for

information about modeling cells for test.

Describing a Flip-Flop

To describe an edge-triggered storage device, include a ff group or a statetable group

in a cell definition. This section describes how to define a flip-flop by using the ff or latch

format. See Describing Sequential Cells With the Statetable Format on page 138 for the

way to define cells using the statetable group.

Liberty User Guide Volume 1

R-2020.09

117

Chapter 5: Defining Sequential Cells

Describing a Flip-Flop

Using the ff Group

A ff group describes either a single-stage or a master-slave flip-flop. The ff_bank group

represents multibit registers, such as a bank of flip-flops. See Describing a Multibit Flip-

Flop on page 126 for more information about the ff_bank group.

Syntax

library (lib_name) {

cell (cell_name) {

...

ff ( variable1, variable2 ) {

clocked_on : "Boolean_expression" ;

next_state : "Boolean_expression" ;

clear : "Boolean_expression" ;

preset : "Boolean_expression" ;

clear_preset_var1 : value ;

clear_preset_var2 : value ;

clocked_on_also : "Boolean_expression" ;

power_down_function : "Boolean_expression" ;

}

variable1

The state of the noninverting output of the flip-flop. It is considered the 1-bit

storage of the flip-flop.

variable2

The state of the inverting output

You can name variable1 and variable2 anything except the name of a pin in the cell being

described. Both variables are required, even if one of them is not connected to a primary

output pin.

The clocked_on and next_state attributes are required in the ff group; all other

attributes are optional.

Liberty User Guide Volume 1

R-2020.09

118

Chapter 5: Defining Sequential Cells

Describing a Flip-Flop

clocked_on and clocked_on_also Attributes

The clocked_on and clocked_on_also attributes identify the active edge of the clock

signals.

Single-state flip-flops use only the clocked_on attribute. When you describe flip-flops that

require both a master and a slave clock, use the clocked_on attribute for the master clock

and the clocked_on_also attribute for the slave clock.

Examples

A rising-edge-triggered device is:

clocked_on : "CP";

A falling-edge-triggered device is:

clocked_on : "CP’";

next_state Attribute

The next_state attribute is a logic equation written in terms of the cell’s input pins or the

first state variable, variable1. For single-stage storage elements, the next_state attribute

equation determines the value of variable1 at the next active transition of the clocked_on

attribute.

For devices such as a master-slave flip-flop, the next_state attribute equation

determines the value of the master stage’s output signals at the next active transition of

the clocked_on attribute.

Example

next_state : "D";

nextstate_type Attribute

The nextstate_type attribute is a pin group attribute that defines the type of

next_state attribute used in the ff or ff_bank group.

Any pin with the nextstate_type attribute must be included in the value of the

next_state attribute.

Note:

Specify a nextstate_type attribute to ensure that the sync set (or sync reset)

pin and the D pin of sequential cells are not swapped when instantiated.

Example

nextstate_type : data;

Liberty User Guide Volume 1

R-2020.09

119

Chapter 5: Defining Sequential Cells

Describing a Flip-Flop

The example in Using the function Attribute and Describing a Multibit Flip-Flop show the

use of the nextstate_type attribute.

clear Attribute

The clear attribute gives the active value for the clear input.

The example defines an active-low clear signal.

Example

clear : "CD’" ;

For more information about the clear attribute, see Describing a Single-Stage Flip-Flop

on page 122.

preset Attribute

The preset attribute gives the active value for the preset input.

The example defines an active-high preset signal.

Example

preset : "PD’" ;

For more information about the preset attribute, see Describing a Single-Stage Flip-Flop

on page 122.

clear_preset_var1 Attribute

The clear_preset_var1 attribute gives the value that variable1 has when clear and

preset are both active at the same time.

Example

clear_preset_var1 : L;

For more information about the clear_preset_var1 attribute, including its function and

values, see Describing a Single-Stage Flip-Flop on page 122.

clear_preset_var2 Attribute

The clear_preset_var2 attribute gives the value that variable2 has when clear and

preset are both active at the same time.

Example

clear_preset_var2 : L ;

For more information about the clear_preset_var2 attribute, including its function and

values, see Describing a Single-Stage Flip-Flop on page 122.

Liberty User Guide Volume 1

R-2020.09

120

Chapter 5: Defining Sequential Cells

Describing a Flip-Flop

power_down_function Attribute

The power_down_function attribute specifies the Boolean condition when the cell’s

output pin is switched off by the power and ground pins (when the cell is in off mode due to

the external power pin states).

You specify the power_down_function attribute for combinational and sequential

cells. For simple or complex sequential cells, the power_down_function attribute also

determines the condition of the cell’s internal state.

Syntax

library (name) {

cell (name) {

ff (variable1,variable2) {

//...flip-flop description...

clear : "Boolean expression" ;

clear_preset_var1 : L | H | N | T | X ;

clear_preset_var2 : L | H | N | T | X ;

clocked_on : "Boolean expression" ;

clocked_on_also : "Boolean expression" ;

next_state : "Boolean expression" ;

preset : "Boolean expression" ;

power_down_function : "Boolean expression" ;

}

…

}

…

}

Example

library ("low_power_cells") {

cell ("retention_dff") {

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

pin ("D") {

direction : "input";

}

pin ("CP") {

direction : "input";

}

ff(IQ,IQN) {

next_state : "D" ;

clocked_on : "CP" ;

power_down_function : "!VDD + VSS" ;

Liberty User Guide Volume 1

R-2020.09

121

Chapter 5: Defining Sequential Cells

Describing a Flip-Flop

}

pin ("Q") {

function : " IQ ";

direction : "output";

power_down_function : "!VDD + VSS";

}

…

}

…

}

ff Group Examples

The following is an example of the ff group for a single-stage D flip-flop.

ff(IQ, IQN) {

next_state : "D" ;

clocked_on : "CP" ;

}

The example defines two variables, IQ and IQN. The next_state attribute determines the

value of IQ after the next active transition of the clocked_on attribute. In the example, IQ

is assigned the value of the D input.

For some flip-flops, the next state depends on the current state. In this case, the first state

variable, variable1 (IQ in the example), is used in the next_state statement; and the

second state variable, IQN, is not used.

For the example, the ff attribute group for a JK flip-flop is,

ff(IQ,IQN) {

next_state : "(J K IQ’) + (J K’) + (J’ K’ IQ)";

clocked_on : "CP";

}

The next_state and clocked_on attributes define the synchronous behavior of the flip-

flop.

Describing a Single-Stage Flip-Flop

A single-stage flip-flop does not use the optional clocked_on_also attribute.

Table 8 Functions of the Attributes in the ff Group for a Single-Stage Flip-Flop

active_edge clear preset variable1 variable2

clocked_on inactive inactive next_state !next_state

-- active inactive 0 1

Liberty User Guide Volume 1

R-2020.09

122

Chapter 5: Defining Sequential Cells

Describing a Flip-Flop

active_edge clear preset variable1 variable2

-- inactive active 1 0

-- active active clear_preset_var1 clear_preset_var2

The clear attribute gives the active value for the clear input. The preset attribute gives

the active value for the preset input. For example, the following statement defines an

active-low clear signal.

clear : "CD’" ;

The clear_preset_var1 and clear_preset_var2 attributes specify the value for

variable1 and variable2 when clear and preset are both active at the same time.

Table 9 Valid Values for the clear_preset_var1 and clear_preset_var2

Attributes

Variable values Equivalence

L 0

H 1

N No change

T Toggle the current value from 1 to 0, 0

to 1, or X to X

X Unknown

If you use both clear and preset, you must use either clear_preset_var1,

clear_preset_var2, or both. Conversely, if you include clear_preset_var1,

clear_preset_var2, or both, you must use both clear and preset.

The flip-flop cell is activated whenever clear, preset, clocked_on, or clocked_on_also

change.

Example 25 is a ff group for a single-stage D flip-flop with a rising edge, negative clear

and preset, and the output pins set to 0 when both clear and preset are active (low).

Example 25 Single-Stage D Flip-Flop

ff(IQ, IQN) {

next_state : "D" ;

clocked_on : "CP" ;

clear : "CD’" ;

preset : "PD’" ;

Liberty User Guide Volume 1

R-2020.09

123

Chapter 5: Defining Sequential Cells

Describing a Flip-Flop

clear_preset_var1 : L ;

clear_preset_var2 : L ;

}

Example 26 is a ff group for a single-stage, rising edge-triggered JK flip-flop with scan

input, negative clear and preset, and the output pins set to 0 when clear and preset are

both active.

Example 26 Single-Stage JK Flip-Flop

ff(IQ, IQN) {

next_state :"(TE*TI)+(TE’*J*K’)+(TE’*J’*K’*IQ)+(TE’*J*K*IQ’)" ;

clocked_on : "CP" ;

clear : "CD’" ;

preset : "PD’" ;

clear_preset_var1 : L ;

clear_preset_var2 : L ;

}

Example 27 is a ff group for a D flip-flop with synchronous negative clear.

Example 27 D Flip-Flop With Synchronous Negative Clear

ff(IQ, IQN) {

next_state : "D * CLR" ;

clocked_on : "CP" ;

}

Describing a Master-Slave Flip-Flop

The specification for a master-slave flip-flop is the same as for a single-stage device,

except that it includes the clocked_on_also attribute.

Table 10 Functions of Attributes of ff Group for a Master-Slave Flip-Flop

active_edge clear preset internal1 internal2 variable1 variable2

clocked_on inactive inactive next_state !next_state

clocked_on_also inactive inactive internal1 internal2

active active clear_

preset_

var1

clear_

preset_

var2

clear_

preset_

var1

clear_

preset_

var2

active inactive 0 1 0 1

inactive active 1 0 1 0

Liberty User Guide Volume 1

R-2020.09

124

Chapter 5: Defining Sequential Cells

Using the function Attribute

The internal1 and internal2 variables represent the output values of the master stage,

and variable1 and variable2 represent the output values of the slave stage.

The internal1 and internal2 variables have the same value as variable1 and

variable2, respectively, when the clear and preset attributes are both active at the

same time.

Note:

You do not need to specify the internal1 and internal2 variables, which

represent internal stages in the flip-flop.

Example 28 shows the ff group for a master-slave D flip-flop with a rising-edge sampling,

falling-edge data transfer, negative clear and preset, and output values set to high when

the clear and preset attributes are both active.

Example 28 Master-Slave D Flip-Flop

ff(IQ, IQN) {

next_state : "D" ;

clocked_on : "CLK" ;

clocked_on_also : "CLKN’" ;

clear : "CDN’" ;

preset : "PDN’" ;

clear_preset_var1 : H ;

clear_preset_var2 : H ;

}

Using the function Attribute

Each storage device output pin needs a function attribute statement. Only the two state

variables, variable1 and variable2, can be used in the function attribute statement for

sequentially modeled elements.

Example 29 Complete Functional Description of a Rising-Edge-Triggered D Flip-Flop With

Active-Low Clear and Preset

cell (dff) {

area : 1 ;

pin (CLK) {

direction : input ;

capacitance : 0 ;

}

pin (D) {

nextstate_type : data;

direction : input ;

capacitance : 0 ;

}

pin (CLR) {

direction : input ;

Liberty User Guide Volume 1

R-2020.09

125

Chapter 5: Defining Sequential Cells

Describing a Multibit Flip-Flop

capacitance : 0 ;

}

pin (PRE) {

direction : input ;

capacitance : 0 ;

}

ff (IQ, IQN) {

next_state : "D" ;

clocked_on : "CLK" ;

clear : "CLR’" ;

preset : "PRE’" ;

clear_preset_var1 : L ;

clear_preset_var2 : L ;

}

pin (Q) {

direction : output ;

function : "IQ" ;

}

pin (QN) {

direction : output ;

function : "IQN" ;

}

} /* end of cell dff */

Flip-flops that have the function attribute statements can be

•

Inferred from a state machine description or a VHDL or Verilog description

•

Translated to flip-flops in a different logic library

•

Sized during timing optimization

•

Changed to flip-flops of a different type, such as D to JK, or D with preset to D with

clear

•

Converted to scan cells by DFT Compiler with the insert_dft command

Describing a Multibit Flip-Flop

The ff_bank group describes a cell that is a collection of parallel, single-bit sequential

parts. Each part shares control signals with the other parts and performs an identical

function. The ff_bank group is typically used to represent multibit registers. It can be used

in cell and test_cell groups.

The syntax is similar to that of the ff group; see Describing a Flip-Flop on page 117.

Syntax

library (lib_name)

{

cell (cell_name) {

Liberty User Guide Volume 1

R-2020.09

126

Chapter 5: Defining Sequential Cells

Describing a Multibit Flip-Flop

...

pin (pin_name) {

...

}

bundle (bundle_name) {

...

}

ff_bank ( variable1, variable2, bits ) {

clocked_on : "Boolean_expression" ;

next_state : "Boolean_expression" ;

clear : "Boolean_expression" ;

preset : "Boolean_expression" ;

clear_preset_var1 : value ;

clear_preset_var2 : value ;

clocked_on_also : "Boolean_expression" ;

}

An input that is described in a pin group, such as the clk input, is fanned out to each flip-

flop in the bank. Each primary output must be described in a bus or bundle group, and its

function statement must include either variable1 or variable2.

Three-state output pins are allowed; you can add a three_state attribute to an output

bus or bundle to specify this function.

The bits value in the ff_bank definition is the number of bits in this multibit cell.

Liberty User Guide Volume 1

R-2020.09

127

Chapter 5: Defining Sequential Cells

Describing a Multibit Flip-Flop

Figure 7 4-Bit Register With Rising-Edge-Triggered D Flip-Flops Having Clear and Preset

Example 30 is the description of the multibit register shown in Figure 7.

Example 30 4-Bit Register Modeled Using ff_bank Group for Rising-Edge-Triggered D Flip-

Flops

cell (dff4) {

area : 1 ;

pin (CLK) {

direction : input ;

capacitance : 0 ;

min_pulse_width_low : 3 ;

min_pulse_width_high : 3 ;

}

Liberty User Guide Volume 1

R-2020.09

128

Chapter 5: Defining Sequential Cells

Describing a Multibit Flip-Flop

bundle (D) {

members(D1, D2, D3, D4);

nextstate_type : data;

direction : input ;

capacitance : 0 ;

timing() {

related_pin : "CLK" ;

timing_type : setup_rising ;

}

timing() {

related_pin : "CLK" ;

timing_type : hold_rising ;

}

pin (CLR) {

direction : input ;

capacitance : 0 ;

timing() {

related_pin : "CLK" ;

timing_type : recovery_rising ;

}

pin (PRE) {

direction : input ;

capacitance : 0 ;

timing() {

related_pin : "CLK" ;

timing_type : recovery_rising ;

}

ff_bank (IQ, IQN, 4) {

next_state : "D" ;

clocked_on : "CLK" ;

clear : "CLR’" ;

preset : "PRE’" ;

clear_preset_var1 : L ;

clear_preset_var2 : L ;

}

bundle (Q) {

members(Q1, Q2, Q3, Q4);

direction : output ;

function : "(IQ)" ;

timing() {

related_pin : "CLK" ;

timing_type : rising_edge ;

}

timing() {

related_pin : "PRE" ;

timing_type : preset ;

timing_sense : negative_unate ;

}

timing() {

related_pin : "CLR" ;

Liberty User Guide Volume 1

R-2020.09

129

Chapter 5: Defining Sequential Cells

Describing a Latch

timing_type : clear ;

timing_sense : positive_unate ;

}

bundle (QN) {

members(Q1N, Q2N, Q3N, Q4N);

direction : output ;

function : "IQN" ;

timing() {

related_pin : "CLK" ;

timing_type : rising_edge ;

}

timing() {

related_pin : "PRE" ;

timing_type : clear ;

timing_sense : positive_unate ;

}

timing() {

related_pin : "CLR" ;

timing_type : preset ;

timing_sense : negative_unate ;

}

} /* end of cell dff4 */

Describing a Latch

To describe a level-sensitive storage device, you include a latch group or statetable

group in the cell definition. This section describes how to define a latch by using the ff or

latch format. See Describing Sequential Cells With the Statetable Format on page 138

for information about defining cells using the statetable group.

latch Group

This section describes a level-sensitive storage device found within a cell group.

Syntax

library (lib_name) {

cell (cell_name) {

...

latch (variable1, variable2) {

enable : "Boolean_expression" ;

data_in : "Boolean_expression" ;

clear : "Boolean_expression" ;

preset : "Boolean_expression" ;

clear_preset_var1 : value ;

clear_preset_var2 : value ;

}

pin (pin_name) {

Liberty User Guide Volume 1

R-2020.09

130

Chapter 5: Defining Sequential Cells

Describing a Latch

...

data_in_type : data | preset | clear | load ;

}

variable1

The state of the noninverting output of the latch. It is considered the 1-bit

storage of the latch.

variable2

The state of the inverting output.

You can name variable1 and variable2 anything except the name of a pin in the cell being

described. Both variables are required, even if one of them is not connected to a primary

output pin.

If you include both clear and preset, you must use either clear_preset_var1,

clear_preset_var2, or both. Conversely, if you include clear_preset_var1,

clear_preset_var2, or both, you must use both clear and preset.

enable and data_in Attributes

The enable and data_in attributes are optional, but if you use one of them, you must

include the other. The enable attribute gives the state of the enable input, and the

data_in attribute gives the state of the data input.

Example

enable : "G" ;

data_in : "D";

data_in_type Attribute

In a pin group, the data_in_type attribute specifies the type of input data defined by the

data_in attribute. The valid values are data, preset, clear, or load. The default is data.

Note:

The Boolean expression of the data_in attribute must include the pin with the

data_in_type attribute.

Example

data_in_type : data ;

clear Attribute

The clear attribute gives the active value for the clear input.

Liberty User Guide Volume 1

R-2020.09

131

Chapter 5: Defining Sequential Cells

Describing a Latch

Example

This example defines an active-low clear signal.

clear : "CD’" ;

preset Attribute

The preset attribute gives the active value for the preset input.

Example

This example defines an active-low preset signal.

preset : "R’" ;

clear_preset_var1 Attribute

The clear_preset_var1 attribute gives the value that variable1 has when clear and

preset are both active at the same time. Valid values are shown in Table 11.

Example

clear_preset_var1 : L;

Table 11 Valid Values for the clear_preset_var1 and clear_preset_var2 Attributes

Variable values Equivalence

L 0

H 1

N No change

T Toggle the current value from 1 to 0, 0 to 1, or X to X

X Unknown

clear_preset_var2 Attribute

The clear_present_var2 attribute gives the value that variable2 has when clear and

preset are both active at the same time. Valid values are shown in Table 11.

Example

clear_preset_var2 : L ;

Liberty User Guide Volume 1

R-2020.09

132

Chapter 5: Defining Sequential Cells

Describing a Latch

Table 12 Functions of the Attributes in the latch Group

enable clear preset variable1 variable2

active inactive inactive data_in !data_in

-- active inactive 0 1

-- inactive active 1 0

-- active active clear_preset_var1 clear_preset_var2

The latch cell is activated whenever clear, preset, enable, or data_in changes.

Example 31 D Latch With Active-High enable and Negative clear

latch(IQ, IQN) {

enable : "G" ;

data_in : "D" ;

clear : "CD’" ;

}

The enable and data_in attributes are not required to model an SR latch, as shown in

Example 32.

Example 32 SR Latch

latch(IQ, IQN) {

clear : "S’" ;

preset : "R’" ;

clear_preset_var1 : L ;

clear_preset_var2 : L ;

}

Determining a Latch Cell’s Internal State

You can use the power_down_function attribute to specify the Boolean condition under

which the cell’s output pin is switched off by the state of the power and ground pins

(when the cell is in off mode due to the external power pin states). The attribute should

be set under the latch group. The power_down_function attribute also determines the

condition of the cell’s internal state.

For more information about power_down_function, see power_down_function Attribute

on page 121.

power_down_function Syntax For Latch Cells

library (name) {

cell (name) {

latch (variable1,variable2) {

Liberty User Guide Volume 1

R-2020.09

133

Chapter 5: Defining Sequential Cells

Describing a Multibit Latch

//...latch description...

clear : "Boolean expression" ;

clear_preset_var1 : L | H | N | T | X ;

clear_preset_var2 : L | H | N | T | X ;

data_in : "Boolean expression" ;

enable : "Boolean expression" ;

preset : "Boolean expression" ;

power_down_function : "Boolean expression" ;

}

…

}

…

}

Describing a Multibit Latch

The latch_bank group describes a cell that is a collection of parallel, single-bit sequential

parts. Each part shares control signals with the other parts and performs an identical

function. The latch_bank group is typically used in cell and test_cell groups to

represent multibit registers.

latch_bank Group

The syntax is similar to that of the latch group. See Describing a Latch on page 130.

Syntax

library (lib_name) {

cell (cell_name) {

...

pin (pin_name) {

...

}

bundle (bus_name) {

...

}

latch_bank (variable1, variable2, bits) {

enable : "Boolean_expression" ;

data_in : "Boolean_expression" ;

clear : "Boolean_expression" ;

preset : "Boolean_expression" ;

clear_preset_var1 : value ;

clear_preset_var2 : value ;

}

Liberty User Guide Volume 1

R-2020.09

134

Chapter 5: Defining Sequential Cells

Describing a Multibit Latch

An input that is described in a pin group, such as the clk input, is fanned out to each

latch in the bank. Each primary output must be described in a bus or bundle group, and its

function statement must include either variable1 or variable2.

Three-state output pins are allowed; you can add a three_state attribute to an output

bus or bundle to define this function.

The bits value in the latch_bank definition is the number of bits in the multibit cell.

Example 33 4-Bit Register Modeled With latch_bank Group for Rising-Edge-Triggered D

Latches

cell (latch4) {

area: 16;

pin (G) { /* gate enable signal, active-high */

direction : input;

...

}

bundle (D) { /* data input with four member pins */

members(D1, D2, D3, D4);

/*must be first bundle attribute*/

direction : input;

...

}

bundle (Q) {

members(Q1, Q2, Q3, Q4);

direction : output;

function : "IQ" ;

...

}

bundle (QN) {

members (Q1N, Q2N, Q3N, Q4N);

direction : output;

function : "IQN";

...

}

latch_bank(IQ, IQN, 4) {

enable : "G" ;

data_in : "D" ;

}

...

}

Liberty User Guide Volume 1

R-2020.09

135

Chapter 5: Defining Sequential Cells

Describing a Multibit Latch

Figure 8 4-Bit Register Containing Enable-High D Latches With Clear

Example 34 is the cell description of the multibit register shown in Figure 8.

Example 34 4-Bit Register Modeled Using Enable-High D Latches With Clear

cell (DLT2) {

/* note: 0 hold time */

area : 1 ;

pin (EN) {

Liberty User Guide Volume 1

R-2020.09

136

Chapter 5: Defining Sequential Cells

Describing a Multibit Latch

direction : input ;

capacitance : 0 ;

min_pulse_width_low : 3 ;

min_pulse_width_high : 3 ;

}

bundle (D) {

members(DA, DB, DC, DD);

direction : input ;

capacitance : 0 ;

timing() {

related_pin : "EN" ;

timing_type : setup_falling ;

}

timing() {

related_pin : "EN" ;

timing_type : hold_falling ;

}

bundle (CLR) {

members(CLRA, CLRB, CLRC, CLRD);

direction : input ;

capacitance : 0 ;

timing() {

related_pin : "EN" ;

timing_type : recovery_falling ;

}

bundle (PRE) {

members(PREA, PREB, PREC, PRED);

direction : input ;

capacitance : 0 ;

timing() {

related_pin : "EN" ;

timing_type : recovery_falling ;

}

latch_bank(IQ, IQN, 4) {

data_in : "D" ;

enable : "EN" ;

clear : "CLR ’ " ;

preset : "PRE ’ " ;

clear_preset_var1 : H ;

clear_preset_var2 : H ;

}

bundle (Q) {

members(QA, QB, QC, QD);

direction : output ;

function : "IQ" ;

Liberty User Guide Volume 1

R-2020.09

137

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

timing() {

related_pin : "D" ;

}

timing() {

related_pin : "EN" ;

timing_type : rising_edge ;

}

timing() {

related_pin : "CLR" ;

timing_type : clear ;

timing_sense : positive_unate ;

}

timing() {

related_pin : "PRE" ;

timing_type : preset ;

timing_sense : negative_unate ;

}

bundle (QN) {

members(QNA, QNB, QNC, QND);

direction : output ;

function : "IQN" ;

timing() {

related_pin : "D" ;

}

timing() {

related_pin : "EN" ;

timing_type : rising_edge ;

}

timing() {

related_pin : "CLR" ;

timing_type : preset ;

timing_sense : negative_unate ;

}

timing() {

related_pin : "PRE" ;

timing_type : clear ;

timing_sense : positive_unate ;

}

} /* end of cell DLT2 */

Describing Sequential Cells With the Statetable Format

The statetable format provides an intuitive way to describe the function of complex

sequential cells. Using this format, the library developer can translate a state table in a

databook to a cell description.

Liberty User Guide Volume 1

R-2020.09

138

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

Figure 9 Generic Sequential Library Cell Model

OUT and OUTN

Sequential output ports of the sequential cell.

The set of all primary input ports in the sequential cell functionally related to

OUT and OUTN.

delay*

A small time delay. An asterisk suffix indicates a time delay.

Statetable

A sequential lookup table. The state table takes a number of inputs and their

delayed values and a number of internal nodes and their delayed values to form

an index to new internal node values. A sequential library cell can have only one

state table.

Internal Nodes

As storage elements, internal nodes store the output values of the state table.

There can be any number of internal nodes.

Liberty User Guide Volume 1

R-2020.09

139

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

Output Logic

A combinational lookup table. For the sequential cells supported in ff or latch

format, there are at most two internal nodes and the output logic must be a

buffer, an inverter, a three-state buffer, or a three-state inverter.

To capture the function of complex sequential cells, use the statetable group in the cell

group to define the statetable in Figure 9. The statetable group syntax maps to the truth

tables in databooks as shown in the example of Figure 10. For table input token values,

see statetable Group on page 141.

Figure 10 Mapping Databook Truth Table to Statetable

To map a databook truth table to a statetable, do the following:

When the databook truth table includes the name of an input port, replace that port

name with the tokens for low/high (L/H).

When the databook truth table includes the name of an output port, use L/H for the

current value of the output port and the next value of the output port.

When the databook truth table has the toggle flag tg (1), use L/H for the current value

of the output port and H/L for the next value of the output port.

Liberty User Guide Volume 1

R-2020.09

140

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

In the truth table, an output port preceded with a tilde symbol (~) is inverted.

Sometimes you must map f to ~R and r to ~F.

statetable Group

The statetable group contains a table consisting of a single string.

Syntax

statetable("input node names", "internal node names")

{

table : "input node values : current internal values \

: next internal values,\

input node values : current internal values : next internal values";

}

You need to follow these conventions when using a statetable group:

•

Give nodes unique names.

•

Separate node names with white space.

• Place each rule consisting of a set of input node values, current internal values, and

next internal values on a separate line, followed by a comma and the line continuation

character (\). To prevent syntax errors, the line continuation character must be followed

immediately by the next line character.

•

Separate node values and the colon delimiter (:) with white space.

•

Insert comments only where a character space is allowed. For example, you cannot

insert a comment within an H/L token or after the line continuation character (\).

Figure 11 statetable Group Example

Liberty User Guide Volume 1

R-2020.09

141

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

Table 13 Legitimate Values for Table Inputs (Input and Current Internal

Nodes)

Input node

values

Current internal

node values

State represented

L L Low

H H High

- - Don’t care

L/H L/H Expands to both L and H

H/L H/L Expands to both H and L

R Rising edge (from low to high)

F Falling edge (from high to low)

~R Not rising edge

~F Not falling edge

Table 14 Legitimate Values for Next Internal Node

Next internal node

values

State represented

L Low

H High

- Output is not specified

L/H Expands to both L and H

H/L Expands to both H and L

X Unknown

N No event from current value. Hold. Use only when all

asynchronous inputs and clocks are inactive

Note:

It is important to use the N token value appropriately. The output is never N

when any input (asynchronous or synchronous) is active. The output should be

N only when all the inputs are inactive.

Liberty User Guide Volume 1

R-2020.09

142

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

Using Shortcuts

To represent a statetable explicitly, list the next internal node one time for every

permutation of L and H for the current inputs, previous inputs, and current states.

Example 35 Fully Expanded statetable Group for a Data Latch With Active-Low clear

statetable(" G CD D", "IQ") {

table :" L L L : L : L,\

L L L : H : L,\

L L H : L : L,\

L L H : H : L,\

L H L : L : N,\

L H L : H : N,\

L H H : L : N,\

L H H : H : N,\

H L L : L : L,\

H L L : H : L,\

H L H : L : L,\

H L H : H : L,\

H H L : L : L,\

H H L : H : L,\

H H H : L : H,\

H H H : H : H";

}

You can use the following shortcuts when you represent your table.

don’t care symbol (-)

For the input and current internal node, the don’t care symbol represents all

permutations of L and H. For the next internal node, the don’t care symbol

means the rule does not define a value for the next internal node.

For example, a master-slave flip-flop can be written as follows:

statetable(" D CP CPN", "MQ SQ") {

table : " H/L R ~F : - - : H/L N,\

- ~R F : H/L - : N H/L,\

H/LR F : L - : H/L L,\

H/LR F : H - : H/L H,\

- ~R ~F : - - : N N";

}

Or it can be written more concisely as follows

statetable(" D CP CPN", "MQ SQ") {

table : " H/L R - : - - : H/L -,\

- ~R - : - - : N -,\

- - F : H/L - : - H/L,\

- - ~F : - - : - N";

}

Liberty User Guide Volume 1

R-2020.09

143

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

L/H and H/L

Both L/H and H/L represent two individual lines: one with L and the other with H.

For example, the following line

H H H/L : - : L/H,

is a concise version of the following lines.

H H H : - : L,

H H L : - : H,

R, ~R, F, and ~F (input edge-sensitive symbols)

The input edge-sensitive symbols represent permutations of L and H for the

delayed input and the current input. Every edge-sensitive input, one that has

at least one input edge symbol, is expanded into two level-sensitive inputs:

the current input value and the delayed input value. For example, the input

edge symbol R expands to an L for the delayed input value and to an H for the

current input value. In the following statetable of a D flip-flop, clock C can be

represented by the input pair C* and C. C* is the delayed input value, and C is

the current input value.

statetable ( "C D", "IQ") {

table : "R L/H : - : L/H, \

~R - : - : N";

Table 15 Internal Representation of the Cell

C* C D IQ

L H L/H L/H

H H - N

H L - N

L L - N

Priority ordering of outputs

The outputs follow a prioritized order. Two rules can cover the same input

combinations, but the rule defined first has priority over subsequent rules.

Note:

Use shortcuts with care. When in doubt, be explicit.

Liberty User Guide Volume 1

R-2020.09

144

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

Partitioning the Cell Into a Model

You can partition a structural netlist to match the general sequential output model

described in Example 36 by performing these tasks:

Represent every storage element by an internal node.

Separate the output logic from the internal node. The internal node must be a function

of only the sequential cell data input when the sequential cell is triggered.

Note:

There are two ways to specify that an output does not change logic values. One

way is to use the inactive N value as the next internal value, and the other way

is to have the next internal value remain the same as the current internal value

(see the italic lines in Example 36).

Example 36 JK Flip-Flop With Active-Low, Direct-Clear, and Negative-Edge Clock

statetable ("J K CN CD" , "IQ") {

table : " - - - L : - : L,\

- - ~F H : - : N,\

L L F H : L/H : L/H,\

H L F H : - : H,\

L H F H : - : L,\

H H F H : L/H : H/L" ;

}

In Example 36, the value of the next internal node of the second rule is N, because both

the clear CD and clock CN are inactive. The value of the next internal node of the third rule

is L/H, because the clock is active.

Defining an Output pin Group

Every output pin in the cell has either an internal_node attribute, which is the name of an

internal node, or a state_function attribute, which is a Boolean expression of ports and

internal pins.

Every output pin can also have an optional three_state expression.

An output pin can have one of the following combinations:

•

A state_function attribute and an optional three_state attribute

•

An internal_node attribute, an optional input_map attribute, and an optional

three_state attribute

Liberty User Guide Volume 1

R-2020.09

145

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

state_function Attribute

The state_function attribute defines output logic. Ports in the state_function Boolean

expression must be either input, inout that can be made three-state, or ports with an

internal_node attribute.

The state_function attribute specifies the purely combinational function of input and

internal pins. A port in the state_function expression refers only to the non-three-state

functional behavior of that port. For example, if E is a port of the cell that enables the

three-state, the state_function attribute cannot have a Boolean expression that uses pin

An inout port in the state_function expression is treated only as an input port.

Note:

Use the state_function attribute to define a cell with a state table. Use this

attribute when the functional expression does not reference any state table

signals, and is a function of only the input pins.

Example

pin(Q)

direction : output;

state_function : "A"; /*combinational feedthrough*/

internal_node Attribute

The internal_node attribute is used to resolve node names to real port names.

The statetable is in an independent, isolated name space. The term node refers to the

identifiers. Input node and internal node names can contain any characters except white

space and comments. These node names are resolved to the real port names by each

port with an internal_node attribute.

Each output defined by the internal_node attribute might have an optional input_map

attribute.

Example

internal_node :

"IQ";

input_map Attribute

The input_map attribute maps real port and internal pin names to each table input

and internal node specified in the state table. An input map is a listing of port names,

separated by white space, that correspond to internal nodes.

Liberty User Guide Volume 1

R-2020.09

146

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

Example

input_map : "Gx1 CDx1 Dx1 QN";/*QN is internal node*/

Mapping port and internal pin names to table input and internal nodes occurs by using

a combination of the input_map attribute and the internal_node attribute. If a node

name is not mapped explicitly to a real port name in the input map, it automatically

inherits the node name as the real port name. The internal node name specified by the

internal_node attribute maps implicitly to the output being defined. For example, to map

two input nodes, A and B, to real ports D and CP, and to map one internal node, Z, to port

Q, set the input_map attribute as follows:

input_map : "D CP Q"

You can use a don’t care symbol in place of a name to signify that the input is not used for

this output. Comments are allowed in the input_map attribute.

The delayed nature of outputs specified with the input_map attribute is implicit:

Internal node

When an output port is specified for this type of node, the internal node is forced

to map to the delayed value of the output port.

Synchronous data input node

When an output port is specified for this type of node, the input is forced to map

to the delayed value of the output port.

Asynchronous or clock input node

When an output port is specified for this type of node, the input is forced to map

to the undelayed value of the output port.

Figure 12 Circuit With Latch U1 and Flip-Flop U2

For example, in Figure 12, internal pin n1 should map to ports “Q0 G1 n1*" and output

Q0 should map to “n1* CP2 Q0*". The subtle significance is relevant during simultaneous

input transitions.

Liberty User Guide Volume 1

R-2020.09

147

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

With this input_map attribute, the functional syntax for ganged cells is identical to that

of nonganged cells. You can use the input map to represent the interconnection of any

network of sequential cells (for example, shift registers and counters).

The input_map attribute can be completely unspecified, completely specified, or can

specify only the beginning ports. The default for an incompletely defined input map is the

assumption that missing trailing primary input nodes and internal nodes are equal to the

node names specified in the statetable. The current state of the internal node should be

equal to the output port name.

inverted_output Attribute

You can define output as inverted or noninverted by using an inverted_output attribute

on the pin. The inverted_output attribute is a required Boolean attribute for the

statetable format that you can set for any output port. Set this attribute to false for

noninverting output. This is variable1 or IQ for flip-flop or latch groups. Set this attribute to

true for inverting output. This is variable2 or IQN for flip-flop or latch groups.

Example

inverted_output : true;

In the statetable format, an output is considered inverted if it has any data input with a

negative sense. This algorithm might be inconsistent with a user’s intentions. For example,

whether a toggle output is considered inverted or noninverted is arbitrary.

Internal Pin Type

In the flip-flop or latch format, the pin, bus, or bundle groups can have a direction

attribute with input, output, or inout values. In the statetable format, the direction

attribute of a pin of a library cell (combinational or sequential) can have the internal value.

A pin with the internal value to the direction attribute is treated like an output port,

except that it is hidden within the library cell. It can take any of the attributes of an output

pin, but it cannot have the three_state attribute.

An internal pin can have timing arcs and can have timing arcs related to it, allowing a

distributed delay model for multistate sequential cells.

Because a cell with a statetable model is considered a black box for synthesis, no checks

are performed to ensure consistency between timing and function.

Example

pin (n1) {

direction : internal;

internal_node :"IQ"; /* use default input_map */

...

}

pin (QN) {

Liberty User Guide Volume 1

R-2020.09

148

Chapter 5: Defining Sequential Cells

Describing Sequential Cells With the Statetable Format

direction : output;

internal_node :"IQN";

input_map : "Gx1 CDx1 Dx1 QN"; /* QN is internal node */

three_state : "EN2";

...

}

pin (QNZ) {

direction : output;

state_function :"QN"; /* ignores QN’s three state */

three_state : "EN";

...

}

pin (Y) {

direction : output;

state_function : "A"; /* combinational feedthrough */

...

}

Determining a Complex Sequential Cell’s Internal State

You can use the power_down_function string attribute to specify the Boolean condition

under which the cell’s output pin is switched off by the state of the power and ground pins

(when the cell is in off mode due to the external power pin states). The attribute should be

set under the statetable group. The power_down_function attribute also determines

the condition of the cell’s internal state.

For more information about the power_down_function attribute, see

power_down_function Attribute on page 121.

power_down_function Syntax for State Tables

The power_down_function attribute is specified after table, in the statetable group, as

shown in the following syntax:

statetable( "input node names", "internal node names" ){

table : " input node values : current internal values :\

next internal values,\

input node values : current internal values: \

next internal values" ;

power_down_function : "Boolean expression" ;

}

Liberty User Guide Volume 1

R-2020.09

149

Chapter 5: Defining Sequential Cells

Flip-Flop and Latch Examples

Example 37 D Flip-Flop

/* ff/latch format */

ff (IQ,IQN) {

next_state : "D" ;

clocked_on : "CP" ;

}

/* statetable format */

statetable(" D CP", "IQ") {

table : " H/L R : - : H/L,\

- ~R : - : N";

}

Example 38 D Flip-Flops With Master-Slave Clock Input Pins

/* ff/latch format */

ff (IQ,IQN) {

next_state : "D" ;

clocked_on : "CK" ;

clocked_on_also : "CKN’" ;

}

/* statetable format */

statetable(" D CK CKN", "MQSQ") {

table : " H/L R ~F : - - : H/L N,\

- ~R F : H/L - : N H/L,\

H/L R F : L - : H/L L,\

H/L R F : H - : H/L H,\

- ~R ~F : - - : N N";

}

Example 39 D Flip-Flop With Gated Clock

/* ff/latch format */

ff (IQ,IQN) {

next_state : "D" ;

clocked_on : "C1 * C2" ;

}

/* statetable format */

statetable(" D C1 C2", "IQ") {

table : " H/L H R : - : H/L,\

H/L R H : - : H/L,\

H/L R R : - : H/L,\

- - - : - : N";

Liberty User Guide Volume 1

R-2020.09

150

Chapter 5: Defining Sequential Cells

Flip-Flop and Latch Examples

}

Example 40 D Flip-Flop With Active-Low Direct-Clear and Active-Low Direct-Set

/* ff/latch format */

ff (IQ,IQN) {

next_state : "D" ;

clocked_on : "CP" ;

clear : " CD’ " ;

preset : " SD’ " ;

clear_preset_var1 : L ;

clear_preset_var2 : L ;

}

/* statetable format */

statetable("D CP CD SD","IQ IQN") {

table : "H/L R H H : - - : H/L L/H,\

- ~R H H : - - : N N,\

- - L H : - - : L H,\

- - H L : - - : H L,\

- - L L : - - : L L";

}

Example 41 D Flip-Flop With Active-Low Direct-Clear, Active-Low Direct-Set, and One Output

/* ff/latch format */

ff (IQ,IQN) {

next_state : "D" ;

clocked_on : "CP" ;

clear : " CD’ " ;

preset : " SD’ " ;

clear_preset_var1 : L ;

clear_preset_var2 : L ;

}

/* statetable format */

statetable(" D CP CD SD", "IQ") {

table : " H/L R H H : - : H/L,\

- ~R H H : - : N,\

- - L H/L : - : L,\

- - H L : - : H";

}

Example 42 JK Flip-Flop With Active-Low Direct-Clear and Negative-Edge Clock

/* ff/latch format */

ff (IQ, IQN) {

next_state : " (J’ K’ IQ) + (J K’) + (J K IQ’)"

Liberty User Guide Volume 1

R-2020.09

151

Chapter 5: Defining Sequential Cells

Flip-Flop and Latch Examples

;

clocked_on : " CN’" ;

clear : " CD’" ;

}

/* statetable format */

statetable(" J K CD CD", "IQ") {

table : " - - - L : - : L,\

- - ~F H : - : N,\

L L F H : L/H : L/H \

H L F H : - : H,\

L H F H : - : L,\

H H F H : L/H : H/L";

Example 43 D Flip-Flop With Scan Input Pins

/* ff/latch format */

ff (IQ,IQN) {

next_state : " (D TE’) + (TI TE)" ;

clocked_on : "CP" ;

}

/* statetable format */

statetable(" D TE TI CP", "IQ") {

table : " H/L L - R : - : H/L,\

- H H/L R : - : H/L,\

- - - ~R : - : N";

}

Example 44 D Flip-Flop With Synchronous Clear

/* ff/latch format */

ff (IQ, IQN) {

next_state : "D CR" ;

clocked_on : "CP" ;

}

/* statetable format */

statetable(" D CR CP", "IQ") {

table : " H/L H R : - : H/L,\

- L R : - : L,\

- - ~R : - : N";

}

Example 45 D Latch

/* ff/latch format */

latch (IQ,IQN) {

Liberty User Guide Volume 1

R-2020.09

152

Chapter 5: Defining Sequential Cells

Flip-Flop and Latch Examples

data_in : "D" ;

enable : "G" ;

}

/* statetable format */

statetable(" D G", "IQ") {

table : " H/L H : - : H/L,\

- L : - : N";

}

Example 46 SR Latch

/* ff/latch format */

latch (IQ,IQN) {

clear : "R" ;

preset : "S" ;

clear_preset_var1 : L ;

clear_preset_var2 : L ;

}

/* statetable format */

statetable(" R S", "IQ IQN") {

table : " H L : - - : L H,\

L H : - - : H L,\

H H : - - : L L,\

L L : - - : N N";

}

Example 47 D Latch With Active-Low Direct-Clear

/* ff/latch format */

latch (IQ,IQN) {

data_in : "D" ;

enable : "G" ;

clear : " CD’ " ;

}

/* statetable format */

statetable(" D G CD", "IQ") {

table : " H/L H H : - : H/L,\

- L H : - : N,\

- - L : - : L";

}

Example 48 Multibit D Latch With Active-Low Direct-Clear

/* ff/latch format */

Liberty User Guide Volume 1

R-2020.09

153

Chapter 5: Defining Sequential Cells

Cell Description Examples

latch_bank(IQ, IQN, 4) {

data_in : "D" ;

enable : "EN" ;

clear : "CLR’" ;

preset : "PRE’" ;

clear_preset_var1 : H ;

clear_preset_var2 : H ;

}

/* statetable format */

statetable(" D EN CL PRE","IQ IQN") {

table : "H/L H H H : - - : H/L L/H,\

- L H H : - - : N N,\

- - L H : - - : L H,\

- - H L : - - : H L,\

- - L L : - - : H H";

}

Example 49 D Flip-Flop With Scan Clock

statetable(" D S CD SC CP", "IQ") {

table : " H/L - ~R R : - : H/L,\

- H/L R ~R : - : H/L,\

- - ~R ~R : - : N,\

- - R R : - : X";

}

Cell Description Examples

Example 50 D Latches With Master-Slave Enable Input Pins

cell(ms_latch) {

area : 16;

pin(D) {

direction : input;

capacitance : 1;

}

pin(G1) {

direction : input;

capacitance : 2;

}

pin(G2) {

direction : input;

capacitance : 2;

}

pin(mq) {

internal_node : "Q";

direction : internal;

input_map : "D G1";

timing() {

Liberty User Guide Volume 1

R-2020.09

154

Chapter 5: Defining Sequential Cells

Cell Description Examples

related_pin : "G1";

}

pin(Q) {

direction : output;

function : "IQ";

internal_node : "Q";

input_map : "mq G2";

timing() {

related_pin : "G2";

}

pin(QN) {

direction : output;

function : "IQN";

internal_node : "QN";

input_map : "mq G2";

timing() {

related_pin : "G2";

}

ff(IQ, IQN) {

clocked_on : "G1";

clocked_on_also : "G2";

next_state : "D";

}

statetable ( "D G", "Q QN" ) {

table : "L/H H : - - : L/H H/L,\

- L : - - : N N";

}

Example 51 FF Shift Register With Timing Removed

cell(shift_reg_ff) {

area : 16;

pin(D) {

direction : input;

capacitance : 1;

}

pin(CP) {

direction : input;

capacitance : 2;

}

pin (Q0) {

direction : output;

internal_node : "Q";

input_map : "D CP";

}

pin (Q1) {

direction : output;

internal_node : "Q";

input_map : "Q0 CP";

Liberty User Guide Volume 1

R-2020.09

155

Chapter 5: Defining Sequential Cells

Cell Description Examples

}

pin (Q2) {

direction : output;

internal_node : "Q";

input_map : "Q1 CP";

}

pin (Q3) {

direction : output;

internal_node : "Q";

input_map : "Q2 CP";

}

statetable( "D CP", "Q QN" ) {

table : "- ~R : - - : N N,\

H/L R : - - : H/L L/H";

}

Example 52 FF Counter With Timing Removed

cell(counter_ff) {

area : 16;

pin(reset) {

direction : input;

capacitance : 1;

}

pin(CP) {

direction : input;

capacitance : 2;

}

pin (Q0) {

direction : output;

internal_node : "Q0";

input_map : "CP reset Q0 Q1";

}

pin (Q1) {

direction : output;

internal_node : "Q1";

input_map : "CP reset Q0 Q1";

}

statetable( "CP reset", "Q0 Q1" ) {

table : "- L : - - : L H,\

~R H : - - : N N,\

R H : L L : H L,\

R H : H L : L H,\

R H : L H : H H,\

R H : H H : L L";

}

Liberty User Guide Volume 1

R-2020.09

156

Defining Test Cells

A test cell contains information that supports a full-scan or a partial-scan methodology.

You must add test-specific details of scannable cells to your logic libraries. For example,

you must identify scannable flip-flops and latches and select the types of unscannable

cells they replace for a given scan methodology.

To do this, you must understand the following concepts described in this chapter:

• Describing a Scan Cell

• Describing a Multibit Scan Cell

• Scan Cell Modeling Examples

Describing a Scan Cell

To specify a cell as a scan cell, add the test_cell group to the cell description.

Only the nontest mode function of a scan cell is modeled in the test_cell group. The

nontest operation is described by its ff, ff_bank, latch, or latch_bank declaration and

pin function attributes.

test_cell Group

The test_cell group defines only the nontest mode function of a scan cell.

Liberty User Guide Volume 1

R-2020.09

157

Chapter 6: Defining Test Cells

Describing a Scan Cell

Figure 13 test_cell Group Defined in a Scan Cell

Ensure the following when you define a test_cell group in a scan cell:

•

Pin names in the scan cell and the test cell must match.

• The scan cell and the test cell must contain the same functional outputs.

Syntax

library (lib_name) { cell (cell_name) {

test_cell () {

... test cell

description ...

pin ( name ) {

... pin description ...

}

pin ( name ) {

...

pin description ...

}

You do not need to give the test_cell group a name, because the test cell takes the cell

name of the cell being defined. The test_cell group can contain ff, ff_bank, latch, or

latch_bank group statements and pin groups.

Pins in the test_cell Group

Both test pins and nontest pins can appear in pin groups within a test_cell group.

These groups are like pin groups in a cell group but must adhere to the following rules:

•

Each pin defined in the cell group must have a corresponding pin defined at the

test_cell group level with the same name.

Liberty User Guide Volume 1

R-2020.09

158

Chapter 6: Defining Test Cells

Describing a Scan Cell

• The pin group can contain only direction, function, test_output_only, and

signal_type attribute statements. The pin group cannot contain timing, capacitance,

fanout, or load information.

• The function attributes can reflect only the nontest behavior of the cell.

• Input pins must be referenced in an ff, ff_bank, latch, or latch_bank statement or

have a signal_type attribute assigned to them.

• An output pin must have either a function attribute, a signal_type attribute, or both.

Example 53 Multiplexed D Flip-Flop Scan Cell Modeled With Multiple test_cell Groups

cell(SDFF1) {

area : 9;

pin(D) {

direction : input;

capacitance : 1;

timing() {

timing_type : setup_rising;

related_pin : "CLK";

}

timing() {

timing_type : hold_rising;

related_pin : "CLK";

}

pin(CLK) {

direction : input;

capacitance : 1;

}

pin(SI) {

direction : input;

capacitance : 1;

prefer_tied : "0";

timing() {

timing_type : setup_rising;

related_pin : "CLK";

}

timing() {

timing_type : hold_rising;

related_pin : "CLK";

}

pin(SE) {

direction : input;

capacitance : 1;

timing() {

timing_type : setup_rising;

related_pin : "CLK";

}

timing() {

Liberty User Guide Volume 1

R-2020.09

159

Chapter 6: Defining Test Cells

Describing a Scan Cell

timing_type : hold_rising;

related_pin : "CLK";

}

ff("IQ","IQN") {

next_state : "(D & !SE) | (SI & SE)";

clocked_on : "CLK";

}

pin(Q) {

direction : output;

function : "IQ"

timing() {

timing_type : rising_edge;

related_pin : "CLK";

}

pin(QN) {

direction : output;

function : "IQN"

timing() {

timing_type : rising_edge;

related_pin : "CLK";

}

/* first test_cell group defines nontest

behavior with both Q and QN */

test_cell() {

pin(D,CLK) {

direction : input;

}

pin(SI) {

direction : input;

signal_type : "test_scan_in";

}

pin(SE) {

direction : input;

signal_type : "test_scan_enable";

}

ff ("IQ","IQN") {

next_state : "D";

clocked_on : "CLK";

}

pin(Q) {

direction : output;

function : "IQ";

signal_type : "test_scan_out";

}

pin(QN) {

direction : output;

function : "IQN";

signal_type : "test_scan_out_inverted";

}

Liberty User Guide Volume 1

R-2020.09

160

Chapter 6: Defining Test Cells

Describing a Scan Cell

/* second test_cell group defines nontest

behavior with only Q */

test_cell() {

pin(D,CLK) {

direction : input;

}

pin(SI) {

direction : input;

signal_type : "test_scan_in";

}

pin(SE) {

direction : input;

signal_type : "test_scan_enable";

}

ff ("IQ","IQN") {

next_state : "D";

clocked_on : "CLK";

}

pin(Q) {

direction : output;

function : "IQ";

signal_type : "test_scan_out";

}

pin(QN) {

direction : output;

/* notice no function attribute for QN pin */

signal_type : "test_scan_out_inverted";

}

test_output_only Attribute

This attribute indicates that an output port is set for test only (as opposed to function only,

or function and test).

Syntax

test_output_only : true | false ;

When you use statetable format to describe the functionality of a scan cell, you must

declare the output pin as set for test only by setting the test_output_only attribute to

true.

Example

test_output_only : true ;

Liberty User Guide Volume 1

R-2020.09

161

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

Multibit scan cells can have parallel or serial scan chains. The scan output of a multibit

scan cell can reuse the data output pins or have a dedicated scan output (SO) pin in

addition to the bus, or the bundle output pins.

Multibit scan cells with the following structures are supported:

•

Parallel scan chain without dedicated SO bus

•

Parallel scan chain with dedicated SO bus

• Serial scan chain without a dedicated SO pin

•

Serial scan chain with a dedicated SO pin

Multibit Scan Cell With Parallel Scan Chain

A multibit scan cell with parallel scan chain has parallel data and scan inputs, and parallel

functional and scan outputs.

Figure 14 shows the schematic diagram of a generic multibit scan cell with parallel input

and output buses for the normal and scan modes.

In the normal mode, the cell uses the input and output buses, D[0:n-1] and Q[0:n-1],

respectively.

The balloons represent combinational logic. The combinational logic at the input of each

sequential element of the cell is a multiplexer with data and scan inputs. At the input of

clock, CK, to each sequential element, the combinational logic is a clock pin or a clock-

gating logic.

In the scan mode, the cell functions as a parallel-in parallel-out shift register with the

scan input bus, SI[0:n-1], and either reuses the bus, Q[0:n-1], or uses a dedicated bus,

SO[0:n-1], to output the scan data. The scan enable signal can be a bus, SE[0:n-1], where

each bit of the bus enables a corresponding sequential element of the cell. The scan

enable signal can also be a single-bit pin to enable each sequential element of the cell.

Liberty User Guide Volume 1

R-2020.09

162

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

Figure 14 Generic Schematic Diagram of a Multibit Scan Cell With Parallel Scan Chain

Use the following syntax to model the multibit scan cell shown in Figure 14:

library(library_name) {

...

cell(cell_name) {

...

bus(scan_in_pin_name) {

/* cell scan in with signal_type "test_scan_in" from test_cell */

...

}

bus(scan_out_pin_name) {

/* cell scan out with signal_type "test_scan_out" from test_cell */

...

Liberty User Guide Volume 1

R-2020.09

163

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

}

bus | bundle (bus_bundle_name) {

direction : input | output;

}

test_cell() {

pin(scan_in_pin_name) {

signal_type : test_scan_in;

...

}

pin(scan_out_pin_name) {

signal_type : test_scan_out |

test_scan_out_inverted;

...

}

...

}

Example

4-bit Scan Cell With Parallel Scan Chains and Dedicated Scan Out Bus

Figure 15 shows the schematic of a 4-bit scan cell with parallel scan chains and a

dedicated scan output bus, SO[0:3]. The figure also shows an equivalent single-bit cell.

Liberty User Guide Volume 1

R-2020.09

164

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

Figure 15 4-Bit Scan Cell With Parallel Scan Chain and Single-Bit Equivalent Cell

Liberty User Guide Volume 1

R-2020.09

165

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

Each pin of the scan output bus, SO[0:3], has AND logic. The cell is defined using:

• The statetable group

•

The state_function attribute on the bus, SO

In the normal mode, the cell is a parallel shift register that uses the data input bus, D[0:3],

and the data output bus, Q[0:3].

In the scan mode, the cell functions as a shift register with parallel scan input, scan

enable, and scan output buses, SI[0:3], SE[0:3], and SO[0:3]. To use the cell in the scan

mode, set the signal_type attribute as test_scan_out on the bus, SO, in the test_cell

group. Do not define the state_function attribute for this bus in the test_cell group.

Example 54 describes a model of the multibit scan cell shown in Figure 15. The example

specifically models the multibit scan cell, and not the single-bit degenerate cell.

Example 54 Model of 4-Bit Scan Cell With Parallel Scan Chain and Dedicated Scan Output

cell (4-bit_Parallel_Scan_Cell) {

...

statetable ("D CK SI SE", "IQ, IQN") {

table : "- ~R - - :- -: N N, \

H/L R L - :- -: H/L H/L,\

- R H H/L :- -: H/L L/H";

}

/* functional output bus */

bus(Q) {

bus_type : bus4;

direction : output;

function : IQ;

...

}

/* dedicated scan output bus */

bus(SO) {

bus_type : bus4;

direction : output;

state_function : "Q * SE" ;

...

}

pin(CK) {

direction : input;

...

}

/* scan enable bus */

bus(SE) {

bus_type : bus4;

direction : input;

...

}

/* scan input bus */

Liberty User Guide Volume 1

R-2020.09

166

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

bus(SI) {

bus_type : bus4;

direction : input;

...

}

/* data input bus pins */

bus(D) {

bus_type : bus4;

direction : input;

...

}

...

test_cell () {

pin(CK){

direction : input;

}

bus(D) {

bus_type : bus4;

direction : input;

}

bus(SI) {

bus_type : bus4;

direction : input;

signal_type : "test_scan_in";

}

bus(SE) {

bus_type : bus4;

direction : input;

signal_type : "test_scan_enable";

}

ff_bank (IQ,IQN,4) {

next_state : "D";

clocked_on : "CK";

}

bus(Q) {

bus_type : bus4 ;

direction : output;

function : "IQ";

}

bus(SO) {

bus_type : bus4;

direction : output;

signal_type : "test_scan_out";

}

} /* end test_cell group */

}/* end cell group */

Multibit Scan Cell With Internal Scan Chain

A multibit scan cell with an internal scan chain has a serial scan chain and a dedicated pin

to output the scan signal.

Liberty User Guide Volume 1

R-2020.09

167

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

Figure 16 shows the schematic diagram of a generic multibit scan cell with an internal or

serial scan chain and the pin, SO, for the scan chain output.

In the normal mode, the cell is a shift register that uses the parallel input and output buses,

D[0:n-1] and Q[0:n-1], respectively.

The balloons represent combinational logic. The combinational logic at the input of each

sequential element of the cell is a multiplexer with data and scan inputs. At the input of

clock, CK, to each sequential element, the combinational logic is clock-gating logic.

In the scan mode, the cell functions as a shift register with the single-bit output pin, SO.

The serial scan chain is from the scan input (SI) pin to the scan output (SO) pin. The scan

chain is stitched using the data output, Q, of each sequential element of the cell.

Liberty User Guide Volume 1

R-2020.09

168

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

Figure 16 Generic Schematic Diagram of a Multibit Scan Cell With Serial Scan Chain

Liberty User Guide Volume 1

R-2020.09

169

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

Use the following syntax to model the multibit scan cell shown in Figure 16:

library(library_name) {

...

cell(cell_name) {

pin(scan_in_pin_name) {

/* cell scan in with signal_type "test_scan_in" from test_cell */

...

}

pin(scan_out_pin_name) {

/* cell scan out with signal_type "test_scan_out" from test_cell */

...

}

bus | bundle (bus_bundle_name) {

direction : inout | output;

}

test_cell() {

pin(scan_in_pin_name) {

signal_type : test_scan_in;

...

}

pin(scan_out_pin_name) {

signal_type : test_scan_out | test_scan_out_inverted;

...

}

...

}

Examples

The following sections show Liberty examples of multibit scan cells with internal scan

chains.

Liberty User Guide Volume 1

R-2020.09

170

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

4-Bit Scan Cell With Internal Scan Chain and Dedicated Scan Out Pin

Figure 17 4-Bit Scan Cell With Internal Scan Chain and Dedicated Scan Out Pin, SO

The 4-bit cell has the output bus Q[0:3], and a single-bit output pin (SO) with

combinational logic. The cell is defined using:

•

The statetable group

• The state_function attribute on the pin, SO

In the normal mode, the cell is a shift register that uses the output bus Q[0:3].

In scan mode, the cell functions as a shift register with the single-bit output pin, SO. To use

the cell in scan mode, set the signal_type attribute as test_scan_out on the pin, SO, in

the test_cell group. Do not define the function attribute of this pin.

Example 55 describes a model of the multibit scan cell shown in Figure 17. The example

specifically models the multibit scan cell, and not the single-bit degenerate cell, SB.

Example 55 Model of 4-Bit Multibit Scan Cell With Serial Scan Chain

cell (4-bit_Serial_Scan_Chain) {

Liberty User Guide Volume 1

R-2020.09

171

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

...

statetable ( " D CK SE SI " , "Q" ) {

table : " - ~R - - : - : N, \

H/L R L - : - : H/L, \

- R H H/L : - : H/L" ;}

bus(Q) {

bus_type : bus4;

direction : output;

internal_node: Q;

pin (Q[0]) { input_map : " D[0] CK SE SI "; }

pin (Q[1]) { input_map : " D[1] CK SE Q[0] "; }

pin (Q[2]) { input_map : " D[2] CK SE Q[1] "; }

pin (Q[3]) { input_map : " D[3] CK SE Q[2] "; }

...

}

/* dedicated scan output pin */

pin(SO) {

direction : output;

inverted_output : false;

state_function : "Q[3] * SE" ;

...

}

pin(CK) {

direction : input;

...

}

pin(SE) {

direction : input;

...

}

/* scan input pin */

pin(SI) {

direction : input;

...

}

/* data input bus pins */

bus(D) {

direction : input;

bus_type : bus4;

...

}

...

test_cell () {

pin(CK){

direction : input;

}

bus(D) {

bus_type : bus4;

direction : input;

}

pin(SI) {

direction : input;

Liberty User Guide Volume 1

R-2020.09

172

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

signal_type : "test_scan_in";

}

pin(SE) {

direction : input;

signal_type : "test_scan_enable";

}

ff_bank (IQ,IQN,4) {

next_state : "D";

clocked_on : "CK";

}

bus(Q) {

bus_type : bus4 ;

direction : output;

function : "IQ";

}

pin(SO) {

direction : output;

signal_type : "test_scan_out";

test_output_only : "true";

}

2-Bit Scan Cell Without Dedicated SO Pin

In Figure 18, the scan cell has scan and enable inputs and no dedicated scan output pin.

The output pin, Q1, is reused to output the scan signal.

Liberty User Guide Volume 1

R-2020.09

173

Chapter 6: Defining Test Cells

Describing a Multibit Scan Cell

Figure 18 2-Bit Scan Cell With Internal Scan Chain and Without SO Pin

The following example shows the relevant syntax to model the cell of Figure 18. In this

example, the statetable group describes the behavior of a single sequential element of

the cell. The input_map statements on pin Q0 and pin Q1 indicate the interconnections

between the sequential elements—for example, Q of bit 0 goes to TI of bit 1.

cell (FSX2) { ...

bundle (D) {

members (D0, D1);

...

}

bundle (Q) {

members (Q0, Q1);

...

pin (Q0) {

input_map : "D0 T SI SM";

...

}

pin (Q1) {

input_map : "D1 T Q0 SM";

...

}

pin (SI) {

...

}

pin (SM) {

...

}

Liberty User Guide Volume 1

R-2020.09

174

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

pin (T) {

...

}

pin (EN) {

...

}

statetable ( "D CP TI TE EN", "Q QN") {

/*D CP TI TE EN Q QN Q+ QN+ */

table : "- ~R - - -: - -: N N,\

- - - L L: - -: N N,\

- R H/L H -: - -: H/L L/H,\

H/L R - L H: - -: H/L L/H "

}

Scan Cell Modeling Examples

This section contains modeling examples for these test cells:

• Simple Multiplexed D Flip-Flop

•

D Flip-Flop With Gated Output

• Multibit Cells With Multiplexed D Flip-Flop and Enable

•

LSSD Scan Cell

•

Scan-Enabled LSSD Cell

• Clocked-Scan Test Cell

•

Scan D Flip-Flop With Auxiliary Clock

Simple Multiplexed D Flip-Flop

Example 56 Simple Multiplexed D Flip-Flop Scan Cell

cell(SDFF1) {

area : 9;

pin(D) {

direction : input;

capacitance : 1;

timing() {...}

}

pin(CP) {

direction : input;

capacitance : 1;

timing() {...}

}

pin(TI) {

direction : input;

capacitance : 1;

Liberty User Guide Volume 1

R-2020.09

175

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

timing() {...}

}

pin(TE) {

direction : input;

capacitance : 2;

timing() {...}

}

ff(IQ,IQN) {

/* model full behavior (if possible): */

next_state : "D TE’ + TI TE ";

clocked_on : "CP";

}

pin(Q) {

direction : output;

function : "IQ";

timing() {...}

}

pin(QN) {

direction : output;

function : "IQN";

timing() {...}

}

test_cell() {

pin(D) {

direction : input

}

pin(CP){

direction : input

}

pin(TI) {

direction : input;

signal_type : test_scan_in;

}

pin(TE) {

direction : input;

signal_type : test_scan_enable;

}

ff(IQ,IQN) {

/* just model nontest operation behavior */

next_state : "D";

clocked_on : "CP";

}

pin(Q) {

direction : output;

function : "IQ";

signal_type : test_scan_out;

}

pin(QN) {

direction : output;

function : "IQN";

signal_type : test_scan_out_inverted;

}

Liberty User Guide Volume 1

R-2020.09

176

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

}

D Flip-Flop With Gated Output

Example 57 shows the modeling syntax for the D flip-flop with gated output shown in

Figure 19.

Figure 19 D Flip-Flop With Gated Output

Example 57 D Flip-Flop With Gated Output

cell(DFF1) {

...

ff(IQ,IQN) {

clocked_on : "CP";

next_state : "((SE SI) + (!SE D))";

}

pin(Q) {

direction : output;

power_down_function : "!VDD + !VPP + VSS + VBB";

function : "(IQ EN)";

related_ground_pin : VSS;

}

...

test_cell() {

pin(Q) {

direction : output;

function : "(IQ EN)";

signal_type : test_scan_out;

}

pin(SI) {

direction : input;

signal_type : test_scan_in;

}

pin(D) {

direction : input

}

pin(EN) {

Liberty User Guide Volume 1

R-2020.09

177

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

direction : input

}

pin(SE) {

direction : input;

signal_type : test_scan_enable;

}

pin(CP){

direction : input

}

ff(IQ,IQN) {

clocked_on : "CP";

next_state : "D";

}

Multibit Cells With Multiplexed D Flip-Flop and Enable

Example 58 Library Containing Multibit Scan Cells With Multiplexed D Flip-Flops and Enable

library(banktest) {

...

default_inout_pin_cap : 1.0;

default_input_pin_cap : 1.0;

default_output_pin_cap : 0.0;

default_fanout_load : 1.0;

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1uA";

pulling_resistance_unit : "1kohm";

capacitive_load_unit (0.1,ff);

type (bus4) {

base_type : array;

data_type : bit;

bit_width : 4;

bit_from : 0;

bit_to : 3;

}

cell(FDSX4) {

area : 36;

bus(D) {

bus_type : bus4;

direction : input;

capacitance : 1;

timing() {

timing_type : setup_rising;

related_pin : "CP";

}

timing() {

timing_type : hold_rising;

related_pin : "CP";

Liberty User Guide Volume 1

R-2020.09

178

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

}

pin(CP) {

direction : input;

capacitance : 1;

}

pin(TI) {

direction : input;

capacitance : 1;

timing() {

timing_type : setup_rising;

related_pin : "CP";

}

timing() {

timing_type : hold_rising;

related_pin : "CP";

}

pin(TE) {

direction : input;

capacitance : 2;

timing() {

timing_type : setup_rising;

related_pin : "CP";

}

timing() {

timing_type : hold_rising;

related_pin : "CP";

}

statetable ( " D CP TI TE ", " Q QN") {

table : " - ~R - - : - - : N N, \

- R H/L H : - - : H/L L/H, \

H/L R - L : - - : H/L L/H" ;

}

bus(Q) {

bus_type : bus4;

direction : output;

inverted_output : false;

internal_node : "Q";

timing() {

timing_type : rising_edge;

related_pin : "CP";

}

pin(Q[0]) {

input_map : "D[0] CP TI TE";

}

pin(Q[1]) {

input_map : "D[1] CP Q[0] TE";

}

pin(Q[2]) {

input_map : "D[2] CP Q[1] TE";

}

Liberty User Guide Volume 1

R-2020.09

179

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

pin(Q[3]) {

input_map : "D[3] CP Q[2] TE";

}

bus(QN) {

bus_type : bus4;

direction : output;

inverted_output : true;

internal_node : "QN";

timing() {

timing_type : rising_edge;

rise_transition(scalar) {values( " 0.1458 "); }

fall_transition(scalar) {values( " 0.0523 "); }

related_pin : "CP";

}

pin(QN[0]) {

input_map : "D[0] CP TI TE";

}

pin(QN[1]) {

input_map : "D[1] CP Q[0] TE";

}

pin(QN[2]) {

input_map : "D[2] CP Q[1] TE";

}

pin(QN[3]) {

input_map : "D[3] CP Q[2] TE";

}

test_cell() {

bus (D) {

bus_type : bus4;

direction : input;

}

pin(CP) {

direction : input;

}

pin(TI) {

direction : input;

signal_type : "test_scan_in";

}

pin(TE) {

direction : input;

signal_type : "test_scan_enable";

}

ff_bank("IQ","IQN", 4) {

next_state : "D";

clocked_on : "CP";

}

bus(Q) {

bus_type : bus4;

direction : output;

function : "IQ";

signal_type : "test_scan_out";

Liberty User Guide Volume 1

R-2020.09

180

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

}

bus(QN) {

bus_type : bus4;

direction : output;

function : "IQN";

signal_type : "test_scan_out_inverted";

}

cell(SCAN2) {

area : 18;

bundle(D) {

members(D0, D1);

direction : input;

capacitance : 1;

timing() {

timing_type : setup_rising;

related_pin : "T";

}

timing() {

timing_type : hold_rising;

related_pin : "T";

}

pin(T) {

direction : input;

capacitance : 1;

}

pin(EN) {

direction : input;

capacitance : 2;

timing() {

timing_type : setup_rising;

related_pin : "T";

}

timing() {

timing_type : hold_rising;

related_pin : "T";

}

pin(SI) {

direction : input;

capacitance : 1;

timing() {

timing_type : setup_rising;

related_pin : "T";

}

timing() {

timing_type : hold_rising;

related_pin : "T";

}

pin(SM) {

Liberty User Guide Volume 1

R-2020.09

181

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

direction : input;

capacitance : 2;

timing() {

timing_type : setup_rising;

related_pin : "T";

}

timing() {

timing_type : hold_rising;

related_pin : "T";

}

statetable ( " T D EN SI SM", " Q QN") {

table : " ~R - - - - : - - : N N , \

- - L - L : - - : N N , \

R H/L H - L : - - : H/L L/H,\

R - - H/L H : - - : H/L L/H";

}

bundle(Q) {

members(Q0, Q1);

direction : output;

inverted_output : false;

internal_node : "Q";

timing() {

timing_type : rising_edge;

related_pin : "T";

}

pin(Q0) {

input_map : "T D0 EN SI SM";

}

pin(Q1) {

input_map : "T D1 EN Q0 SM";

}

bundle(QN) {

members(Q0N, Q1N);

direction : output;

inverted_output : true;

internal_node : "QN";

timing() {

timing_type : rising_edge;

related_pin : "T";

}

pin(Q0N) {

input_map : "T D0 EN SI SM";

}

pin(Q1N) {

input_map : "T D1 EN Q0 SM";

}

test_cell() {

bundle (D) {

members(D0, D1);

direction : input;

Liberty User Guide Volume 1

R-2020.09

182

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

}

pin(T) {

direction : input;

}

pin(EN) {

direction : input;

}

pin(SI) {

direction : input;

signal_type : "test_scan_in";

}

pin(SM) {

direction : input;

signal_type : "test_scan_enable";

}

ff_bank("IQ","IQN", 2) {

next_state : "D";

clocked_on : "T EN";

}

bundle(Q) {

members(Q0, Q1);

direction : output;

function : "IQ";

signal_type : "test_scan_out";

}

bundle(QN) {

members(Q0N, Q1N);

direction : output;

function : "IQN";

signal_type : "test_scan_out_inverted";

}

LSSD Scan Cell

Example 59 LSSD Scan Cell

cell(LSSD) {

area : 12;

pin(D) {

direction : input;

capacitance : 1;

timing() {

timing_type : setup_falling;

related_pin : "MCLK";

}

timing() {

timing_type : hold_falling;

related_pin : "MCLK";

}

Liberty User Guide Volume 1

R-2020.09

183

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

}

pin(SI) {

direction : input;

capacitance : 1;

prefer_tied : "0";

timing() {

timing_type : setup_falling;

related_pin : "ACLK";

}

timing() {

timing_type : hold_falling;

related_pin : "ACLK";

}

pin(MCLK,ACLK,SCLK) {

direction : input;

capacitance : 1;

}

pin(Q1) {

direction : output;

internal_node : "Q1";

timing() {

timing_type : rising_edge;

related_pin : "MCLK";

}

timing() {

timing_type : rising_edge;

related_pin : "ACLK";

}

timing() {

related_pin : "D";

}

timing() {

related_pin : "SI";

}

pin(Q1N) {

direction : output;

state_function : "Q1’";

timing() {

timing_type : rising_edge;

related_pin : "MCLK";

}

timing() {

timing_type : rising_edge;

related_pin : "ACLK";

}

timing() {

related_pin : "D";

}

timing() {

related_pin : "SI";

}

Liberty User Guide Volume 1

R-2020.09

184

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

}

pin(Q2) {

direction : output;

internal_node : "Q2";

timing() {

timing_type : rising_edge;

related_pin : "SCLK";

}

pin(Q2N) {

direction : output;

state_function : "Q2’";

timing() {

timing_type : rising_edge;

related_pin : "SCLK";

}

statetable("MCLK D ACLK SCLK SI", "Q1 Q2") {

table : " L - L - - : - - : N - , \

H L/H L - - : - - : L/H - , \

L - H - L/H : - - : L/H - , \

H - H - - : - - : X - , \

- - - L - : - - : - N , \

- - - H - : L/H - : - L/H";

}

test_cell() { /* for DLATCH */

pin(D,MCLK) {

direction : input;

}

pin(SI) {

direction : input;

signal_type : "test_scan_in";

}

pin(ACLK) {

direction : input;

signal_type : "test_scan_clock_a";

}

pin(SCLK) {

direction : input;

signal_type : "test_scan_clock_b";

}

latch ("IQ","IQN") {

data_in : "D";

enable : "MCLK";

}

pin(Q1) {

direction : output;

function : "IQ";

}

pin(Q1N) {

direction : output;

function : "IQN";

}

Liberty User Guide Volume 1

R-2020.09

185

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

pin(Q2) {

direction : output;

signal_type : "test_scan_out";

}

pin(Q2N) {

direction : output;

signal_type : "test_scan_out_inverted";

}

test_cell() { /* for MSFF1 */

pin(D,MCLK,SCLK) {

direction : input;

}

pin(SI) {

direction : input;

signal_type : "test_scan_in";

}

pin(ACLK) {

direction : input;

signal_type : "test_scan_clock_a";

}

ff ("IQ","IQN") {

next_state : "D";

clocked_on : "MCLK";

clocked_on_also : "SCLK";

}

pin(Q1,Q1N) {

direction : output;

}

pin(Q2) {

direction : output;

function : "IQ";

signal_type : "test_scan_out";

}

pin(Q2N) {

direction : output;

function : "IQN";

signal_type : "test_scan_out_inverted";

}

Note:

For latch-based designs, an LSSD scan cell has two test_cell groups for use

in either single-latch or double-latch mode.

Liberty User Guide Volume 1

R-2020.09

186

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

Scan-Enabled LSSD Cell

The scan-enabled LSSD cell is a variation of the LSSD scan cell in the double-latch mode.

Unlike the double-latch LSSD scan cell, a single clock controls the enable pins of both the

master and slave latches of the scan-enabled LSSD cell.

To recognize the scan-cell type, the signal_type attribute is used. If all the values of

the signal_type attribute, namely, test_scan_clock_a, test_scan_clock_b, and

test_scan_enable are present on the pins of a test cell, the corresponding scan cell is

recognized as a scan-enabled LSSD.

Figure 20 Scan-Enabled LSSD Cell Schematic

Functional Model of the Scan-Enabled LSSD Cell

To model the cell shown in figure in Scan-Enabled LSSD Cell, define the signal_type

attribute on the pins of the test_cell group, such as the pins, CLK and SELECT.

Example 60 shows the syntax to define the signal_type attribute on the CLK pin. When

you set the signal_type attribute on the clock pin, CLK, to test_scan_clock_b, it

indicates that the CLK input also enables the slave-latch in addition to the master-latch

of the scan-enabled LSSD cell. In figure in Scan-Enabled LSSD Cell, the clock pin, CLK,

controls both enable pins, C1 and C.

Example 60 The signal_type attribute on the Scan-Enabled LSSD Cell CLK pin

cell(cell_name) {

…

test_cell() {

…

Liberty User Guide Volume 1

R-2020.09

187

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

pin (pin_name) {

direction : input;

signal_type : "test_scan_clock_b";

...

}/* End pin group */

}/* End test_cell */

…

}

Example 61 shows the syntax to define the signal_type attribute on the select pin,

SELECT. When you set the signal_type attribute on the select pin, SELECT, to

test_scan_enable, the SELECT input is active and enables the scan mode of the LSSD

cell. When the SELECT input is inactive, the cell is in the normal mode.

Example 61 The signal_type Attribute on the Scan-Enabled LSSD Cell SELECT Pin

cell(cell_name) {

…

test_cell() {

…

pin (pin_name) {

direction : input;

signal_type : "test_scan_enable";

...

}/* End pin group */

}/* End test_cell */

…

}

Timing Model of the Scan-Enabled LSSD Cell

Figure 21 shows a timing arc constraint, from the clock pin, CLK, to the select pin,

SELECT, of the scan-enabled LSSD cell. In the normal mode, the constraint ensures that

the CLK input works correctly for the duration of the CLK pulse. Therefore, the SELECT

input must be stable for the setup period before the CLK pulse (tds), when the CLK pulse

is active (tdstable), and the hold period after (tdh) the CLK pulse.

Example 62 shows the syntax to model the timing arc, from the clock pin, CLK, to the

select pin, SELECT. Timing arcs are modeled by setting the timing_type attribute to

nochange values. As the CLK pin is active-low, set the timing_type attribute on the

select pin, SELECT, to nochange_low_low.

Liberty User Guide Volume 1

R-2020.09

188

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

Figure 21 A Timing-Arc Constraint of the Scan-Enabled LSSD Cell

Example 62 Scan-Enabled LSSD Timing Model Syntax

cell(cell_name) {

…

pin (SELECT) {

direction : input;

timing() {

timing_type: "nochange_low_low" ;

related_pin: "CLK" ;

fall_constraint(constraint) { /* tds */

…

}

rise_constraint(constraint) { /* tdh */

…

}

…

}/* End pin group */

…

}

Note:

Do not use the hold_rising (tds) and setup_falling (tdh) values to model,

the clock pin, CLK, to the select pin, SELECT, timing arc. These values of the

timing_type attribute do not cover the stable region of the SELECT input

(tdstable).

Liberty User Guide Volume 1

R-2020.09

189

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

Scan-Enabled LSSD Cell Model Example

Example 63 uses the syntax in examples in Functional Model of the Scan-Enabled LSSD

Cell and Timing Model of the Scan-Enabled LSSD Cell to model the scan-enabled LSSD

cell shown in figure in Scan-Enabled LSSD Cell .

Example 63 Example for the Scan-Enabled LSSD Cell Syntax

Cell(scan_enabled_LSSD) {

...

statetable ("CLK D SELECT A SI", "MQ Q") {

table : " L L/H L L - : - - : H/L -,\

H - - L - : - - : N -,\

L - H L - : - - : N -,\

L - L H - : - - : X -,\

H - L H L/H : - - : L/H -,\

- - H H L/H : - - : L/H -,\

L - - - - : - - : - N,\

H - - - - : L/H - : - L/H";

}

pin (CLK) {

direction : input ;

timing() {

timing_type: "min_pulse_width" ;

related_pin: "CLK" ;

...

}

pin (D) {

direction : input ;

timing() {

timing_type: "hold_rising" ;

related_pin: "CLK" ;

...

}

timing() {

timing_type: "setup_rising" ;

related_pin: "CLK" ;

...

}

pin (SELECT) {

direction : input;

timing() {

timing_type: "nochange_low_low" ;

related_pin: "CLK" ;

...

}

pin (SI) {

direction : input;

timing() {

Liberty User Guide Volume 1

R-2020.09

190

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

timing_type: "setup_falling" ;

related_pin: "A" ;

...

}

timing() {

timing_type: "hold_falling" ;

related_pin: "A"

...

}

pin (MQ) {

direction : "internal";

internal_node : "MQ";

}

pin (Q) {

direction : output ;

internal_node: "Q" ;

timing() {

timing_type: "rising_edge" ;

related_pin: "CLK" ;

...

}

...

test_cell () {

pin (CLK) {

direction : input ;

signal_type : "test_scan_clock_b";

}

pin (D) {

direction : input ;

}

pin (A) {

direction : input;

signal_type : "test_scan_clock_a";

}

pin ("SELECT") {

direction : input ;

signal_type : "test_scan_enable";

}

pin (SI) {

direction : input ;

signal_type : "test_scan_in";

}

pin (Q) {

direction : output ;

function : "IQ";

signal_type : "test_scan_out";

}

ff (IQ,IQN) {

next_state : "D" ;

clocked_on : "CLK" ;

}

Liberty User Guide Volume 1

R-2020.09

191

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

}

...

}

Scan-Enabled LSSD Cell With Asynchronous Inputs

Figure 22 Scan-Enabled LSSD Cell With Asynchronous Inputs, PRE and CLR

Example 64 shows the modeling syntax for the scan-enabled LSSD cell shown in

Figure 22.

Example 64 Modeling Syntax for Scan-Enabled LSSD Cell With Preset and Clear Inputs

cell(LSSD_with_clear_preset) {

…

statetable (" CLK D SELECT A SI CLR PRE", "MQ Q") {

table : " L L/H L L - L L : - - : H/L -,\

H - - L - L L : - - : N -,\

L - H L - L L : - - : N -,\

L - L H - L L : - - : X -,\

H - L H L/H L L : - - : L/H -,\

- - H H L/H L L : - - : L/H -,\

L - - - - L L : - - : - N,\

H - - - - L L : L/H - : - L/H,\

- - - - - H L : - - : L L,\

- - - - - L H : - - : H H,\

- - - - - H H : - - : L L";

}

…

test_cell () {

pin (CLK) {

Liberty User Guide Volume 1

R-2020.09

192

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

direction : input ;

signal_type : "test_scan_clock_b";

}

pin (D) {

direction : input ;

}

pin (CLR) {

direction : input ;

}

pin (PRE) {

direction : input ;

}

pin (A) {

direction : input;

signal_type : "test_scan_clock_a";

}

pin ("SELECT") {

direction : input ;

signal_type : "test_scan_enable";

}

pin (SI) {

direction : input ;

signal_type : "test_scan_in";

}

pin (Q) {

direction : output ;

function : "IQ";

signal_type : "test_scan_out";

}

ff (IQ,IQN) {

next_state : "D" ;

clocked_on : "CLK" ;

clear : "CLR" ;

preset : "PRE" ;

clear_preset_var1 : L ;

clear_preset_var2 : L ;

}

…

}

Liberty User Guide Volume 1

R-2020.09

193

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

Multibit Scan-Enabled LSSD Cell

Figure 23 Schematic of a 4-Bit Scan-Enabled LSSD Cell

Example 65 shows the modeling syntax for the cell shown in Figure 23.

Example 65 4-Bit Scan-Enabled LSSD Cell Modeling Syntax

cell(LSSD_multibit) {

…

statetable (" CLK D SELECT A SI", "MQ Q") {

table : " L L/H L L - : - - : H/L -,\

H - - L - : - - : N -,\

L - H L - : - - : N -,\

L - L H - : - - : X -,\

H - L H L/H : - - : L/H -,\

- - H H L/H : - - : L/H -,\

L - - - - : - - : - N,\

H - - - - : L/H - : - L/H";

}

bus(MQ) {

direction : internal;

internal_node: MQ;

bus_type : bus4;

Liberty User Guide Volume 1

R-2020.09

194

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

pin (MQ[0]) { input_map : "CLK D[0] SELECT A SI"; }

pin (MQ[1]) { input_map : "CLK D[1] SELECT A Q[0]"; }

pin (MQ[2]) { input_map : "CLK D[2] SELECT A Q[1]"; }

pin (MQ[3]) { input_map : "CLK D[3] SELECT A Q[2]"; }

…

}

bus(Q) {

direction : output;

internal_node: Q;

bus_type : bus4;

pin (Q[0]) { input_map : "CLK D[0] SELECT A SI MQ[0]"; }

pin (Q[1]) { input_map : "CLK D[1] SELECT A Q[0] MQ[1]"; }

pin (Q[2]) { input_map : "CLK D[2] SELECT A Q[1] MQ[2]"; }

pin (Q[3]) { input_map : "CLK D[3] SELECT A Q[2] MQ[3]"; }

…

}

…

test_cell() {

bus(D) {

bus_type : bus4;

direction : input; }

pin(CLK) {

direction : input;

signal_type : test_scan_clock_b; }

pin(SI) {

direction : input;

signal_type : test_scan_in; }

pin(A) {

direction : input;

signal_type : test_scan_clock_a; }

pin(SELECT) {

direction : input;

signal_type : test_scan_enable; }

ff_bank(IQ,IQN,4) {

next_state : "D";

clocked_on : "CLK";

}

bus(Q) {

direction : output;

bus_type : bus4;

function : "IQ"; }

pin(SO) {

direction : output;

signal_type : "test_scan_out";}

} /* End of test_cell */

…

}

Liberty User Guide Volume 1

R-2020.09

195

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

Clocked-Scan Test Cell

Example 66 shows the model of a level-sensitive latch with separate scan clocking. This

example shows the scan cell used in clocked-scan implementation.

Example 66 Clocked-Scan Test Cell

cell(SC_DLATCH) {

area : 12;

pin(D) {

direction : input;

capacitance : 1;

timing() {

timing_type : setup_falling;

related_pin : "G";

}

timing() {

timing_type : hold_falling;

related_pin : "G";

}

pin(SI) {

direction : input;

capacitance : 1;

prefer_tied : "0";

timing() {

timing_type : setup_rising;

related_pin : "ScanClock";

}

timing() {

timing_type : hold_rising;

related_pin : "ScanClock";

}

pin(G,ScanClock) {

direction : input;

capacitance : 1;

}

statetable( "D SI G ScanClock", " Q QN" ) {

table : "L/H - H L : - - : L/H H/L,\

- L/H L R : - - : L/H H/L,\

- - L ~R : - - : N N";

}

pin(Q) {

direction : output;

internal_node : "Q";

timing() {

timing_type : rising_edge;

related_pin : "G";

}

timing() {

related_pin : "D";

Liberty User Guide Volume 1

R-2020.09

196

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

}

timing() {

timing_type : rising_edge;

related_pin : "ScanClock";

}

pin(QN) {

direction : output;

internal_node : "QN";

timing() {

timing_type : rising_edge;

related_pin : "G";

}

timing() {

related_pin : "D";

}

timing() {

timing_type : rising_edge;

related_pin : "ScanClock";

timing() {

timing_type : rising_edge;

related_pin : "ScanClock";

}

test_cell() {

pin(D,G) {

direction : input;

}

pin(SI) {

direction : input;

signal_type : "test_scan_in";

}

pin(ScanClock) {

direction : input;

signal_type : "test_scan_clock";

}

pin(SE) {

direction : input;

signal_type : "test_scan_enable";

}

latch ("IQ","IQN") {

data_in : "D";

enable : "G";

}

pin(Q) {

direction : output;

function : "IQ";

signal_type : "test_scan_out";

}

pin(QN) {

direction : output;

function : "IQN";

signal_type : "test_scan_out_inverted";

Liberty User Guide Volume 1

R-2020.09

197

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

}

Scan D Flip-Flop With Auxiliary Clock

Example 67 Scan D Flip-Flop With an Input and an Auxiliary Clock

cell(AUX_DFF1) {

area : 12;

pin(D) {

direction : input;

capacitance : 1;

timing() {

timing_type : setup_rising;

related_pin : "CK";

}

timing() {

timing_type : hold_rising;

related_pin : "CK";

}

timing() {

timing_type : setup_rising;

related_pin : "IH";

}

timing() {

timing_type : hold_rising;

related_pin : "IH";

}

pin(CK,IH,A,B) {

direction : input;

capacitance : 1;

}

pin(SI) {

direction : input;

capacitance : 1;

prefer_tied : "0";

timing() {

timing_type : setup_falling;

related_pin : "A";

}

timing() {

timing_type : hold_falling;

related_pin : "A";

}

pin(Q) {

direction : output;

timing() {

timing_type : rising_edge;

Liberty User Guide Volume 1

R-2020.09

198

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

related_pin : "CK IH";

}

timing() {

timing_type : rising_edge;

related_pin : "B";

}

pin(QN) {

direction : output;

timing() {

timing_type : rising_edge;

related_pin : "CK IH";

}

timing() {

timing_type : rising_edge;

related_pin : "B";

}

statetable( "C TC D A B SI", "IQ1 IQ2" ) {

table : "\

/* C TC D A B SI IQ1 IQ2 */ \

H - - L - - : - - : N -, /* mast hold */\

- H - L - - : - - : N -, /* mast hold */\

H - - H - L/H : - - : L/H -, /* scan mast */\

- H - H - L/H : - - : L/H -, /* scan mast */\

L L L/H L - - : - - : L/H -, /* D in mast */\

L L - H - - : - - : X -, /* both active */\

H - - - L - : L/H - : - L/H, /* slave loads */\

- H - - L - : L/H - : - L/H, /* slave loads */\

L L - - - - : - - : - N, /* slave loads */\

- - - - H - : - - : - N"; /* slave loads */

}

test_cell(){

pin(D,CK){

direction : input

}

pin(IH){

direction : input;

signal_type : "test_clock";

}

pin(SI){

direction : input;

signal_type : "test_scan_in";

}

pin(A){

direction : input;

signal_type : "test_scan_clock_a";

}

pin(B){

direction : input;

signal_type : "test_scan_clock_b";

}

ff ("IQ","IQN"){

Liberty User Guide Volume 1

R-2020.09

199

Chapter 6: Defining Test Cells

Scan Cell Modeling Examples

next_state : "D";

clocked_on : "CK";

}

pin(Q){

direction : output;

function : "IQ";

signal_type : "test_scan_out";

pin(QB){

direction : output;

function : "IQN";

signal_type : "test_scan_out_inverted";

}

Liberty User Guide Volume 1

R-2020.09

200

Timing Arcs

Timing arcs are divided into two major areas: timing delays (the actual circuit timing) and

timing constraints (at the boundaries). This chapter explains the timing concepts and

describes the timing group attributes for setting constraints and defining delay.

The following sections describe how to specify timing delays, how to use timing

constraints:

• Understanding Timing Arcs

• Modeling Method Alternatives

• Defining the timing Group

• Describing Three-State Timing Arcs

• Describing Edge-Sensitive Timing Arcs

• Describing Clock Insertion Delay

• Describing Intrinsic Delay

• Describing Transition Delay

• Modeling Load Dependency

• Describing Slope Sensitivity

• Describing State-Dependent Delays

• Setting Setup and Hold Constraints

• Setting Nonsequential Timing Constraints

• Setting Recovery and Removal Timing Constraints

• Setting No-Change Timing Constraints

• Setting Skew Constraints

• Setting Conditional Timing Constraints

• Impossible Transitions

Liberty User Guide Volume 1

R-2020.09

201

Chapter 7: Timing Arcs

Understanding Timing Arcs

• Examples of NLDM Libraries

• Describing a Transparent Latch Clock Model

• Driver Waveform Support

• Sensitization Support

• Phase-Locked Loop Support

Understanding Timing Arcs

Timing arcs, along with netlist interconnect information, are the paths followed by the

path tracer during path analysis. Each timing arc has a startpoint and an endpoint. The

startpoint can be an input, output, or I/O pin. The endpoint is always an output pin or an

I/O pin. The only exception is a constraint timing arc, such as a setup or hold constraint

between two input pins. All delay information in a library refers to an input-to-output pin

pair or an output-to-output pin pair.

Figure 24 Timing Arcs (AC and BC) for AND Gate

You must distinguish between combinational and sequential timing types, because they

serve different purposes.

The Design Compiler tool uses combinational timing arc information to calculate the

physical delays in timing propagation and to trace paths. The timing analyzer uses path-

tracing arcs for circuit timing analysis.

The Design Compiler tool uses sequential timing arc information to determine rule-based

design optimization constraints. See the Synopsys Timing Constraints and Optimization

User Guide for more information about optimization constraints.

Liberty User Guide Volume 1

R-2020.09

202

Chapter 7: Timing Arcs

Understanding Timing Arcs

Combinational Timing Arcs

A combinational timing arc describes the timing characteristics of a combinational element.

The timing arc is attached to an output pin, and the related pin is either an input or an

output.

A combinational timing arc is of one of the following types:

•

combinational

•

combinational_rise

• combinational_fall

•

three_state_disable

•

three_state_disable_rise

• three_state_disable_fall

•

three_state_enable

•

three_state_enable_rise

•

three_state_enable_fall

For information about describing combinational timing types, see timing Group Attributes

on page 220.

Sequential Timing Arcs

Sequential timing arcs describe the timing characteristics of sequential elements. In

descriptions of the relationship between a clock transition and data output (input to output),

the timing arc is considered a delay arc. In descriptions of the relationship between a clock

transition and data input (input to input), the timing arc is considered a constraint arc.

A sequential timing arc is of one of the following types:

•

Edge-sensitive (rising_edge or falling_edge)

•

Preset or clear

• Setup or hold (setup_rising, setup_falling, hold_rising, or hold_falling)

•

Nonsequential setup or hold (non_seq_setup_rising, non_seq_setup_falling,

non_seq_hold_rising, non_seq_hold_falling)

•

Recovery or removal (recovery_rising, recovery_falling, removal_rising, or

removal_falling)

Liberty User Guide Volume 1

R-2020.09

203

Chapter 7: Timing Arcs

Modeling Method Alternatives

• No change (nochange_high_high, nochange_high_low, nochange_low_high,

nochange_low_low)

For information about describing sequential timing types, see timing Group Attributes on

page 220.

Modeling Method Alternatives

Timing information for combinational cells such as the one in Figure 25 can be modeled in

one of two ways, as Figure 26 shows.

Figure 25 Two-Inverter Cell

In Figure 26, Model A defines two timing arcs. The first timing arc starts at primary input

pin A and ends at primary output pin Y. The second timing arc starts at primary input pin A

and ends at primary output pin Z. This is the simple case.

Figure 26 Two Modeling Techniques for Two-Inverter Cell

Model B for this cell also has two arcs but is more accurate than Model A. The first arc

starts at pin A and ends at pin Y. This arc is modeled like the AY arc in Model A. The

second arc is different; it starts with primary output Y and ends with primary output Z,

modeling the effect the load on Y has on the delay on Z. Output-to-output timing arcs can

be used in either combinational or sequential cells.

Liberty User Guide Volume 1

R-2020.09

204

Chapter 7: Timing Arcs

Defining the timing Group

The timing group contains information to model timing arcs and trace paths. The timing

group defines the timing arcs through a cell and the relationships between clock and data

input signals.

The timing group describes

•

Timing relationships between an input pin and an output pin

•

Timing relationships between two output pins

• Timing arcs through a noncombinational element

•

Setup and hold times on flip-flop or latch input

•

Optionally, the names of the timing arcs

The timing group describes setup and hold information when the constraint information

refers to an input-to-input pin pair.

The timing group is defined in the pin group. This is the syntax:

library (lib_name) {

cell (cell_name) {

pin (pin_name) {

timing () {

... timing description ...

}

Define the timing group in the pin group of the endpoint of the timing arc, as illustrated

by pin C in figure in Understanding Timing Arcs.

Naming Timing Arcs Using the timing Group

Within the timing group, you can identify the name or names of different timing arcs.

A single timing arc can occur between an identified pin and a single related pin identified

with the related_pin attribute.

Multiple timing arcs can occur in many ways. The following list shows six possible multiple

timing arcs. The following descriptive sections explain how you configure other possible

multiple timing arcs:

•

Between a single related pin and the identified multiple members of a bundle.

•

Between multiple related pins and the identified multiple members of a bundle.

Liberty User Guide Volume 1

R-2020.09

205

Chapter 7: Timing Arcs

Defining the timing Group

• Between a single related pin and the identified multiple bits on a bus.

• Between multiple related pins and the identified multiple bits of a bus.

• Between the identified multiple bits of a bus and the multiple pins of related bus pins (of

a designated width).

•

Between the internal pin and all the bits of the endpoint bus group.

The following sections provide descriptions and examples for various timing arcs.

Timing Arc Between a Single Pin and a Single Related Pin

Identify the timing arc that occurs between a single pin and a single related pin by entering

a name in the timing group, as shown in the following example:

Example

cell (my_inverter) {

...

pin (A) {

direction : input;

capacitance : 1;

}

pin (B) {

direction : output

function : "A’";

timing (A_B) {

related_pin : "A";

...

}/* end timing() */

}/* end pin B */

}/* end cell */

The timing arc is as follows:

From pin To pin Label

A B A_B

Timing Arcs Between a Pin and Multiple Related Pins

This section describes how to identify the timing arcs when a timing group is within a pin

group and the timing arc has more than a single related pin.

Example

You identify the multiple timing arcs on a name list entered with the timing group as

shown in the following example.

Liberty User Guide Volume 1

R-2020.09

206

Chapter 7: Timing Arcs

Defining the timing Group

cell (my_and) {

...

pin (A) {

direction : input;

capacitance : 1;

}

pin (B) {

direction : input;

capacitance : 2;

}

pin (C) {

direction : output

function : "A B";

timing (A_C, B_C) {

related_pin : "A B";

...

}/* end timing() */

}/* end pin B */

}/* end cell */

The timing arcs are as follows:

From pin To pin Label

A C A_C

B C B_C

Timing Arcs Between a Bundle and a Single Related Pin

When the timing group is within a bundle group that has several members with a single

related pin, enter the names of the resulting multiple timing arcs in a name list in the

timing group.

See the following example.

Example

...

bundle (Q){

members (Q0, Q1, Q2, Q3);

direction : output;

function : "IQ";

timing (G_Q0, G_Q1, G_Q2, G_Q3){

timing_type : rising_edge;

related_pin : "G";

}

Liberty User Guide Volume 1

R-2020.09

207

Chapter 7: Timing Arcs

Defining the timing Group

If G is a pin, as opposed to another bundle group, the timing arcs are as follows:

From pin To pin Label

G Q0 G_Q0

G Q1 G_Q1

G Q2 G_Q2

G Q3 G_Q3

If G is another bundle of member size 4 and G0, G1, G2, and G3 are members of bundle

G, the timing arcs are as follows:

From pin To pin Label

G0 Q0 G_Q0

G1 Q1 G_Q1

G2 Q2 G_Q2

G3 Q3 G_Q3

Timing Arcs Between a Bundle and Multiple Related Pins

When the timing group is within a bundle group that has several members, each having

a corresponding related pin, enter the names of the resulting multiple timing arcs as a

name list in the timing group.

Example

bundle (Q){

members (Q0, Q1, Q2, Q3);

direction : output;

function : "IQ";

timing (G_Q0, H_Q0, G_Q1, H_Q1, G_Q2, H_Q2, G_Q3, H_Q3){

timing_type : rising_edge;

related_pin : "G H";

}

If G is a pin, as opposed to another bundle group, the timing arcs are as follows:

From pin To pin Label

G Q0 G_Q0

Liberty User Guide Volume 1

R-2020.09

208

Chapter 7: Timing Arcs

Defining the timing Group

H Q0 H_Q0

G Q1 G_Q1

H Q1 H_Q1

G Q2 G_Q2

H Q2 H_Q2

G Q3 G_Q3

H Q3 H_Q3

If G was another bundle of member size 4 and G0, G1, G2, and G3 are members of

bundle G, the timing arcs are as follows:

From pin To pin Label

G0 Q0 G_Q0

H Q0 H_Q0

G1 Q1 G_Q1

H Q1 H_Q1

G2 Q2 G_Q2

H Q2 H_Q2

G3 Q3 G_Q3

H Q3 H_Q3

The same rule applies if H is a size-4 bundle.

Timing Arcs Between a Bus and a Single Related Pin

This section describes how to identify the timing arcs created when a timing group is

within a bus group that has several bits with the same single related pin. You identify the

resulting multiple timing arcs by entering a name list with the timing group.

Example

...

bus (X){

/*assuming MSB is X[0] */

bus_type : bus4;

Liberty User Guide Volume 1

R-2020.09

209

Chapter 7: Timing Arcs

Defining the timing Group

direction : output;

capacitance : 1;

pin (X[0:3]){

function : "B’";

timing (B_X0, B_X1, B_X2, B_X3){

related_pin : "B";

}

If B is a pin, as opposed to another 4-bit bus, the timing arcs are as follows:

From pin To pin Label

B X[0] B_X0

B X[1] B_X1

B X[2] B_X2

B X[3] B_X3

If B is another 4-bit bus and B[0] is the MSB for bus B, the timing arcs are as follows:

From pin To pin Label

B[0] X[0] B_X0

B[1] X[1] B_X1

B[2] X[2] B_X2

B[3] X[3] B_X3

Timing Arcs Between a Bus and Multiple Related Pins

This section describes the timing arcs created when a timing group is within a bus group

that has several bits, where each bit has its own related pin. You identify the resulting

multiple timing arcs by entering a name list with the timing group.

Example

bus (X){

/*assuming MSB is X[0] */

bus_type : bus4;

direction : output;

capacitance : 1;

pin (X[0:3]){

function : "B’";

timing (B_X0, C_X0, B_X1, C_X1, B_X2, C_X2, B_X3,C_X3 ){

Liberty User Guide Volume 1

R-2020.09

210

Chapter 7: Timing Arcs

Defining the timing Group

related_pin : "B C";

}

If B and C are pins, as opposed to another 4-bit bus, the timing arcs are as follows:

From pin To pin Label

B X[0] B_X0

C X[0] C_X0

B X[1] B_X1

C X[1] C_X1

B X[2] B_X2

C X[2] C_X2

B X[3] B_X3

C X[3] C_X3

If B is another 4-bit bus and B[0] is the MSB for bus B, the timing arcs are as follows:

From pin To pin Label

B[0] X[0] B_X0

C X[0] C_X0

B[1] X[1] B_X1

C X[1] C_X1

B[2] X[2] B_X2

C X[2] C_X2

B[3] X[3] B_X3

C X[3] C_X3

The same rule applies if C is a 4-bit bus.

Liberty User Guide Volume 1

R-2020.09

211

Chapter 7: Timing Arcs

Defining the timing Group

Timing Arcs Between a Bus and a Related Bus Equivalent

You can generate an arc from each element in a starting bus to each element of an

ending bus, such as when you create arcs from each related bus pin defined with the

related_bus_pins attribute to each endpoint.

Instead of using this approach, you can use the related_bus_equivalent attribute to

generate a single timing arc for all paths from points in a group through an internal pin (I)

to given endpoints. Figure 27 compares the setup created with the related_bus_pins

attribute with a setup created with the related_bus_equivalent attribute.

Figure 27 Comparing related_bus_pins Setup With related_bus_equivalent Setup

This section describes the timing arcs created from all the bits of a related bus equivalent

group, which you define with the related_bus_equivalent attribute, to an internal pin (I)

and all the timing arcs created from the same internal pin to all the bits of the endpoint bus

group.

You identify the resulting multiple timing arcs by entering a name list, using the timing

group.

It is assumed that the first name in the name list is the arc going from the first bit (A[0])

of the related bus group to the internal pin (I), the second name in the name list is the

arc going from the second bit (A[1]) to the internal pin (I), and so on in order until all the

related bus group bits are used.

The next name on the name list is of the timing arc going from the internal pin (I) to the

first bit (X[0]) in the endpoint bus group, the following name in the name list is of the arc

going from the internal join pin (I) to the second bit (X[1]) of the bus group, and so on in

order until all the bits in the bus group are used. See the following example.

Liberty User Guide Volume 1

R-2020.09

212

Chapter 7: Timing Arcs

Defining the timing Group

Note:

The widths of bus A and bus X do not need to be identical.

Example

bus (X){...

bus_type : bus4;

direction : output;

capacitance : 1;

timing (A0_I, A1_I, A2_I, I_X0,I_X1, I_X2, I_X3,) {...

related_bus_equivalent : A;

}...

}

The following is a list of the timing arcs and their labels:

From pin To pin Label

A[0] I A0_I

A[1] I A1_I

A[2] I A2_I

I X[0] I_X0

I X[1] I_X1

I X[2] I_X2

I X[3] I_X3

Delay Model

The timing groups are defined by the timing group attributes. The delay model

determines the set of delay calculation attributes you specify in a timing group.

Cell delays are often modeled in a synthesis logic library, with an assortment of delay

models. Synthesis tools use these models to predict cell delays during and after

optimization. Net delays are estimated during synthesis on the basis of the wire load

models provided in the logic library.

The NLDM is characterized by tables that define the timing arcs. To describe delay or

constraint arcs with this model,

•

Use the library-level lu_table_template group to define templates of common

information to use in lookup tables.

Liberty User Guide Volume 1

R-2020.09

213

Chapter 7: Timing Arcs

Defining the timing Group

• Use the templates and the timing groups described in this chapter to create lookup

tables.

Lookup tables and their corresponding templates can be one-dimensional, two-

dimensional, or three-dimensional. Delay arcs allow a maximum of two dimensions.

Device degradation constraint tables allow only one dimension. Load-dependent

constraint modeling requires three dimensions.

delay_model Attribute

To specify the delay model, use the delay_model attribute in the library group.

The delay_model attribute must be the first attribute in the library if a technology

attribute is not present. Otherwise, it follows the technology attribute.

Example

library (demo) {

delay_model : table_lookup ;

}

Defining the NLDM Template

Table templates store common table information that multiple lookup tables can use. A

table template specifies the table parameters and the breakpoints for each axis. Assign

each template a name so that lookup tables can refer to it.

lu_table_template Group

Define your lookup table templates in the library group.

Syntax

lu_table_template(name) {

variable_1 : value;

variable_2 : value;

variable_3 : value;

index_1 ("float, ..., float");

index_2 ("float, ..., float");

index_3 ("float, ..., float");

}

Template Variables for Timing Delays

The table template specifying timing delays can have up to three variables (variable_1,

variable_2, and variable_3). The variables indicate the parameters used to index into

the lookup table along the first, second, and third table axes. The parameters are the input

transition time of a constrained pin, the output net length and capacitance, and the output

loading of a related pin.

Liberty User Guide Volume 1

R-2020.09

214

Chapter 7: Timing Arcs

Defining the timing Group

The following is a list of the valid values (divided into sets) that you can assign to a table:

• Set 1:

input_net_transition

•

Set 2:

total_output_net_capacitance

output_net_length

output_net_wire_cap

output_net_pin_cap

•

Set 3:

related_out_total_output_net_capacitance

related_out_output_net_length

related_out_output_net_wire_cap

related_out_output_net_pin_cap

The values you can assign to the variables of a table specifying timing delay depend on

whether the table is one-, two-, or three-dimensional.

For every table, the value you assign to a variable must be from a set different from the

set from which you assign a value to the other variables. For example, if you want a two-

dimensional table and you assign variable_1 with the input_net_transition value

from set 1, then you must assign variable_2 with one of the values from set 2. Table 16

lists the combinations of values you can assign to the different variables for the varying

dimensional tables specifying timing delays.

Table 16 Variable Values for Timing Delays

Template dimension Variable_1 Variable_2 Variable_3

1 set1

1 set2

2 set1 set2

2 set2 set1

3 set1 set2 set3

3 set1 set3 set2

3 set2 set1 set3

3 set2 set3 set1

3 set3 set1 set2

Liberty User Guide Volume 1

R-2020.09

215

Chapter 7: Timing Arcs

Defining the timing Group

Template dimension Variable_1 Variable_2 Variable_3

3 set3 set2 set1

Template Variables for Load-Dependent Constraints

The table template specifying load-dependent constraints can have up to three variables

(variable_1, variable_2, and variable_3). The variables indicate the parameters used

to index into the lookup table along the first, second, and third table axes. The parameters

are the input transition time of a constrained pin, the transition time of a related pin, and

the output loading of a related pin.

The following is a list of the valid values (divided into sets) that you can assign to a table.

•

Set 1:

constrained_pin_transition

•

Set 2:

related_pin_transition

•

Set 3:

related_out_total_output_net_capacitance

related_out_output_net_length

related_out_output_net_wire_cap

related_out_output_net_pin_cap

The values you can assign to the variables of a table specifying load-dependent

constraints depend on whether the table is one-, two-, or three-dimensional.

For every table, the value you assign to a variable must be from a set different from the

set from which you assign a value to the other variables. For example, if you want a two-

dimensional table and you assign variable_1 with the constrained_pin_transition

value from set 1, then you must assign variable_2 with one of the values from set 2.

Table 17 lists the combination of values you can assign to the different variables for the

varying dimensional tables specifying load-dependent constraints.

Table 17 Variable Values for Load-Dependent Constraint Tables

Template dimension Variable_1 Variable_2 Variable_3

1 set1

1 set2

2 set1 set2

Liberty User Guide Volume 1

R-2020.09

216

Chapter 7: Timing Arcs

Defining the timing Group

Template dimension Variable_1 Variable_2 Variable_3

2 set2 set1

3 set1 set2 set3

3 set1 set3 set2

3 set2 set1 set3

3 set2 set3 set1

3 set3 set1 set2

3 set3 set2 set1

Template Breakpoints

The index statements define the breakpoints for an axis. The breakpoints defined by

index_1 correspond to the parameter values indicated by variable_1. The breakpoints

defined by index_2 correspond to the parameter values indicated by variable_2.

The breakpoints defined by index_3 correspond to the parameter values indicated by

variable_3.

The index values are lists of floating-point numbers greater than or equal to 0.0. The

values in the list must be in increasing order. The size of each dimension is determined by

the number of floating-point numbers in the indexes.

You must define at least one index_1 in the lu_table_template group. For a one-

dimensional table, use only variable_1.

Creating Lookup Tables

The rules for specifying lookup tables apply to delay arcs as well as to constraints.

Defining Delay Arcs With Lookup Tables on page 237 shows the groups to use as

delay lookup tables. See the sections on the various constraints for the groups to use as

constraint lookup tables.

This is the syntax for lookup table groups:

lu_table(name) {

index_1 ("float, ..., float");

index_2 ("float, ..., float");

index_3 ("float, ..., float");

values("float, ..., float", ..., "float, ..., float");

}

Liberty User Guide Volume 1

R-2020.09

217

Chapter 7: Timing Arcs

Defining the timing Group

These rules apply to lookup table groups:

• Each lookup table has an associated name for the lu_table_template it uses.

The name of the template must be identical to the name defined in a library

lu_table_template group.

•

You can overwrite any or all of the indexes in a lookup table template, but the overwrite

must occur before the actual definition of values.

•

The delay value of the table is stored in a values attribute.

◦ Transition table delay values must be 0.0 or greater. Propagation tables and cell

tables can contain negative delay values.

◦

In a one-dimensional table, represent the delay value as a list of nindex_1 floating-

point numbers.

◦

In a two-dimensional table, represent the delay value as nindex_1 x nindex_2

floating-point numbers.

◦

If a table contains only one value, you can use the predefined scalar table template

as the template for that timing arc.

•

Each group of floating-point values enclosed in quotation marks represents a row in the

table.

◦

In a one-dimensional table, the number of floating-point values in the group must

equal nindex_1.

◦

In a two-dimensional table, the number of floating-point values in a group must

equal nindex_2 and the number of groups must equal nindex_1.

◦

In a three-dimensional table, the total number of groups is nindex_1 x nindex_2

and each group contains as many floating-point numbers as nindex_3. In a three-

dimensional table, the first group represents the value indexed by the (1, 1, 1) to the

(1, 1, nindex_3) points in the index. The first nindex_2 groups represent the value

indexed by the (1, 1, 1) to the (1, nindex_2, nindex_3) points in the index. The rest

of the groups are grouped in the same order.

Defining the Scalable Polynomial Delay Model Template

Polynomial templates store common format information that equations can use.

poly_template Group

You use a poly_template group to specify the equation variables, the variable ranges,

the voltage mapping, and the piecewise data. Assign each poly_template group a unique

name, so that equations in the timing group can refer to it.

Liberty User Guide Volume 1

R-2020.09

218

Chapter 7: Timing Arcs

Defining the timing Group

Syntax

poly_template(name

) {

variables(variable_i

enum

, ..., variable_n

enum

)

variable_i_range(float, float)

...

variable_n_range(float, float)

mapping(voltage

enum

, power_rail

)

domain(domain_name

) {

calc_mode : name

;

variables(variable_i

enum

)..., variable_n

enum

)

variable_i_range(float, float)

...

variable_n_range(float, float)

mapping(voltage

enum

, power_rail

)

}

poly_template Variables

The poly_template group that defines timing delays can have up to n variables

(variable_i, ..., variable_n), which you specify in the variables complex attribute. The

variables you specify represent the following in the equation:

•

The input transition time of a constrained pin

•

The output net length and capacitance

• The output loading of a related pin

•

The default power supply voltage

•

The frequency

• The voltagei for multivoltage cells

•

The temperature

•

User parameters ( parameter1...parameter5 )

The following list shows the valid values, divided into four sets, that you can assign to

variables in an equation:

•

Set 1:

input_net_transition

constrained_pin_transition

•

Set 2:

total_output_net_capacitance

output_net_length

Liberty User Guide Volume 1

R-2020.09

219

Chapter 7: Timing Arcs

Defining the timing Group

output_net_wire_cap

output_net_pin_cap

related_pin_transition

•

Set 3:

related_out_total_output_net_capacitance

related_out_output_net_length

related_out_output_net_wire_cap

related_out_output_net_pin_cap

•

Set 4:

frequency

temperature

voltagei

parametern

delay_model Simple Attribute

Use the delay_model attribute in the library group to specify the scalable polynomial

delay model.

library (demo) {

delay_model : polynomial ;

}

timing Group Attributes

Table 18 Attributes in timing Group for

NLDM

Purpose Attribute or group

To specify a default

timing arc

default_timing

To identify a timing arc

startpoint

related_pin

related_bus_pins

To describe a logical

effect of input pin on

output pin

timing_sense

To identify an arc

as combinational or

sequential

timing_type

To specify a propagation

delay in total cell delay.

(Used with transition

delay)

rise_propagation

fall_propagation

Liberty User Guide Volume 1

R-2020.09

220

Chapter 7: Timing Arcs

Defining the timing Group

Purpose Attribute or group

To specify a cell delay

independent of transition

delay

cell_rise

cell_fall

To specify a retain delay

within the delay arc

retaining_rise

retaining_fall

To specify an

output or I/O pin for

load-dependency model

related_output_ pin

To specify when a timing

arc is active

mode

related_pin Simple Attribute

The related_pin attribute defines the pin or pins that are the startpoint of the timing

arc. The primary use of related_pin is for multiple signals in ganged-logic timing. This

attribute is a required component of all timing groups.

Example

pin (B){

direction : output ;

function : "A’";

timing () {

related_pin : "A" ;

...

}

You can use the related_pin attribute statement as a shortcut for defining two identical

timing arcs for a cell. For example, for a 2-input NAND gate with identical delays from both

input pins to the output pin, you need to define only one timing arc with two related pins,

as shown in the following example.

pin (Z) {

direction : output;

function : "(A * B)’" ;

timing () {

related_pin : "A B" ;

... timing information ...

}

When you use a bus name in a related_pin attribute statement, the bus members or

the range of members is distributed across all members of the parent bus. In the following

Liberty User Guide Volume 1

R-2020.09

221

Chapter 7: Timing Arcs

Defining the timing Group

example, the timing arcs described are from each element in bus A to each element in bus

B: A(1) to B(1) and A(2) to B(2).

The width of the bus or range must be the same as the width of the parent bus.

bus (A) {

bus_type : bus2;

...

}

bus (B) {

bus_type : bus2;

direction : output;

function : "A’";

timing () {

related_pin : "A" ;

... timing information ...

}

related_bus_pins Simple Attribute

The related_bus_pins attribute defines the pin or pins that are the startpoint of the

timing arc. The primary use of related_bus_pins is for module generators.

Example

In this example, the timing arcs described are from each element in bus A to each element

in bus B: A(1) to B(1), A(1) to B(2), A(1) to B(3), and so on. The widths of bus A and bus B

do not need to be identical.

bus (A){

bus_type : bus2;

...

}

bus (B){

bus_type : bus4;

direction : output ;

function : "A";

timing () {

related_bus_pins : "A" ;

... timing information ...

}

timing_sense Simple Attribute

The timing_sense attribute describes the way an input pin logically affects an output pin.

Example

timing () {

timing_sense : positive_unate;

}

Liberty User Guide Volume 1

R-2020.09

222

Chapter 7: Timing Arcs

Defining the timing Group

The Design Compiler tool typically derives the timing_sense value from the pin’s logic

function. For example, the value derived for an AND gate is positive_unate, the value

for a NAND gate is negative_unate, and the value for an XOR gate is non_unate.

Do not define the timing_sense value of a pin, except when you must override the

derived value or you are characterizing a noncombinational gate such as a three-state

component. For example, you might define the timing sense manually when you model

multiple paths between an input pin and an output pin, as in an XOR gate.

A function is unate if a rising (or falling) change on a positive unate input variable causes

the output function variable to rise (or fall) or not change. A rising (or falling) change on

a negative unate input variable causes the output function variable to fall (or rise) or not

change. For a nonunate variable, further state information is required to determine the

effects of a particular state transition.

It is possible that one path is positive unate while another is negative unate. In this

case, the first timing arc gets a positive_unate designation and the second arc gets a

negative_unate designation.

Note:

When timing_sense describes the transition edge used to calculate delay

for the three_state_enable or three_state_disable pin, it has a meaning

different from its traditional one. If a 1 value on the control pin of a three-state

cell causes a Z value on the output pin, timing_sense is positive_unate

for the three_state_disable timing arc and negative_unate for the

three_state_enable timing arc. If a 0 value on the control pin of a three-state

cell causes a Z value on the output pin, timing_sense is negative_unate

for the three_state_disable timing arc and positive_unate for the

three_state_enable timing arc.

If a related_pin is an output pin, you must define timing_sense for that pin.

timing_type Simple Attribute

The timing_type attribute distinguishes between combinational and sequential cells,

by defining the type of timing arc. If this attribute is not assigned, the cell is considered

combinational.

You must distinguish between combinational and sequential timing types, because each

type serves a different purpose.

The Design Compiler tool uses the combinational timing arcs information to calculate the

physical delays in timing propagation and to trace paths. The timing analyzer uses path

tracing arcs for circuit timing analysis.

The Design Compiler tool uses the sequential timing arcs information to determine rule-

based design optimization constraints. More information about optimization constraints is

available in the Design Compiler documentation.

Liberty User Guide Volume 1

R-2020.09

223

Chapter 7: Timing Arcs

Defining the timing Group

Values for Combinational Timing Arcs

The timing type and timing sense define the signal propagation pattern. The default timing

type is combinational.

Timing sense

Timing type

positive_unate negative_unate non_unate

combinational

R->R,F->F R->F,F->R {R,F}->{R,F}

combinational_rise R->R F->R {R,F}->R

combinational_fall F->F R->F {R,F}->F

three_state_disable R->{0Z,1Z} F->{0Z,1Z} {R,F}->{0Z,1Z}

three_state_enable R->{Z0,Z1} F->{Z0,Z1} {R,F}->{Z0,Z1}

three_state_disable_rise R->0Z F->0Z {R,F}->0Z

three_state_disable_fall R->1Z F->1Z {R,F}->1Z

three_state_enable_rise R->Z1 F->Z1 {R,F}->Z1

three_state_enable_fall R->Z0 F->Z0 {R,F}->Z0

Values for Sequential Timing Arcs

You use sequential timing arcs to model the timing requirements for sequential cells.

rising_edge

Identifies a timing arc whose output pin is sensitive to a rising signal at the input

pin.

falling_edge

Identifies a timing arc whose output pin is sensitive to a falling signal at the input

pin.

preset

Preset arcs affect only the rise arrival time of the arc’s endpoint pin. A preset arc

implies that you are asserting a logic 1 on the output pin when the designated

related pin is asserted.

clear

Clear arcs affect only the fall arrival time of the arc’s endpoint pin. A clear arc

implies that you are asserting a logic 0 on the output pin when the designated

related pin is asserted.

Liberty User Guide Volume 1

R-2020.09

224

Chapter 7: Timing Arcs

Defining the timing Group

hold_rising

Designates the rising edge of the related pin for the hold check.

hold_falling

Designates the falling edge of the related pin for the hold check.

setup_rising

Designates the rising edge of the related pin for the setup check on clocked

elements.

setup_falling

Designates the falling edge of the related pin for the setup check on clocked

elements.

recovery_rising

Uses the rising edge of the related pin for the recovery time check. The clock is

rising-edge-triggered.

recovery_falling

Uses the falling edge of the related pin for the recovery time check. The clock is

falling-edge-triggered.

skew_rising

The timing constraint interval is measured from the rising edge of the reference

pin (specified in related_pin) to a transition edge of the parent pin in the

timing group. The rise_constraint value is the maximum skew time between

the reference pin rising and the parent pin rising. The fall_constraint value

is the maximum skew time between the reference pin falling and the parent pin

falling.

skew_falling

The timing constraint interval is measured from the falling edge of the reference

pin (specified in related_pin) to a transition edge of the parent pin in the

timing group. The rise_constraint value is the maximum skew time between

the reference pin falling and the parent pin rising. The fall_constraint value

is the maximum skew time between the reference pin falling and the parent pin

falling.

removal_rising

Used when the cell is a low-enable latch or a rising-edge-triggered flip-flop.

For active-low asynchronous control signals, define the removal time with the

rise_constraint group. For active-high asynchronous control signals, define

the removal time with the fall_constraint group.

Liberty User Guide Volume 1

R-2020.09

225

Chapter 7: Timing Arcs

Defining the timing Group

removal_falling

Used when the cell is a high-enable latch or a falling-edge-triggered flip-flop.

For active-low asynchronous control signals, define the removal time with the

rise_constraint group. For active-high asynchronous control signals, define

the removal time with the fall_constraint group.

min_pulse_width

This value, together with the minimum_period value, lets you specify the

minimum pulse width for a clock pin. The timing check is performed on the pin

itself, so the related pin should be the same. You can also include rise and fall

constraints, as with other timing checks.

Besides scalar values, table-based minimum pulse width is supported.

For an example, see “A Library With timing_type Statements” (example in

min_pulse_width and minimum_period Example).

minimum_period

This value, together with the min_pulse_width value, lets you specify the

minimum pulse width for a clock pin. The timing check is performed on the pin

itself, so the related pin should be the same. You can also include rise and fall

constraints as with other timing checks.

max_clock_tree_path

Used in timing groups under a clock pin. Defines the maximum clock tree path

constraint.

min_clock_tree_path

Used in timing groups under a clock pin. Defines the minimum clock tree path

constraint.

Values for Nonsequential Timing Arcs

In some nonsequential cells, the setup and hold timing constraints are specified on the

data pin with a nonclock pin as the related pin. The signal of a pin must be stable for a

specified period of time before and after another pin of the same cell range state for the

cell to function as expected.

non_seq_setup_rising

Defines (with non_seq_setup_falling) the timing arcs used for setup checks

between pins with nonsequential behavior. The related pin in a timing arc is

used for the timing check.

Liberty User Guide Volume 1

R-2020.09

226

Chapter 7: Timing Arcs

Defining the timing Group

non_seq_setup_falling

Defines (with non_seq_setup_rising) the timing arcs used for setup checks

between pins with nonsequential behavior. The related pin in a timing arc is

used for the timing check.

non_seq_hold_rising

Defines (with non_seq_hold_falling) the timing arcs used for hold checks

between pins with nonsequential behavior. The related pin in a timing arc is

used for the timing check.

non_seq_hold_falling

Defines (with non_seq_hold_rising) the timing arcs used for hold checks

between pins with nonsequential behavior. The related pin in a timing arc is

used for the timing check.

Values for No-Change Timing Arcs

You use no-change timing arcs to model the timing requirement for latch devices with

latch-enable signals. The four no-change timing types define the pulse waveforms of both

the constrained signal and the related signal in NLDM. The information is used in static

timing verification during synthesis.

nochange_high_high

Indicates a positive pulse on the constrained pin and a positive pulse on the

related pin.

nochange_high_low

Indicates a positive pulse on the constrained pin and a negative pulse on the

related pin.

nochange_low_high

Indicates a negative pulse on the constrained pin and a positive pulse on the

related pin.

nochange_low_low

Indicates a negative pulse on the constrained pin and a negative pulse on the

related pin.

mode Complex Attribute

You define the mode attribute within a timing group. A mode attribute pertains to an

individual timing arc. The timing arc is active when mode is instantiated with a name and a

value. You can specify multiple instances of the mode attribute, but only one instance for

each timing arc.

Liberty User Guide Volume 1

R-2020.09

227

Chapter 7: Timing Arcs

Defining the timing Group

Syntax

mode (mode_name, mode_value);

Example

timing() {

mode(rw, read);

}

Example 68 A mode Instance Description

pin(my_outpin) {

direction : output;

timing() {

related_pin : b;

timing_sense : non_unate;

mode(rw, read);

cell_rise(delay3x3) {

values("1.1, 1.2, 1.3", "2.0, 3.0, 4.0", "2.5, 3.5, 4.5");

}

rise_transition(delay3x3) {

values("1.0, 1.1, 1.2", "1.5, 1.8, 2.0", "2.5, 3.0, 3.5");

}

cell_fall(delay3x3) {

values("1.1, 1.2, 1.3", "2.0, 3.0, 4.0", "2.5, 3.5, 4.5");

}

fall_transition(delay3x3) {

values("1.0, 1.1, 1.2", "1.5, 1.8, 2.0", "2.5, 3.0, 3.5");

}

Example 69 Multiple mode Descriptions

library (MODE_EXAMPLE) {

delay_model : "table_lookup";

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1mA";

pulling_resistance_unit : "1kohm";

leakage_power_unit : "1nW" ;

capacitive_load_unit (1, pf);

nom_process : 1.0;

nom_voltage : 1.0;

nom_temperature : 125.0;

slew_lower_threshold_pct_rise : 10 ;

slew_upper_threshold_pct_rise : 90 ;

input_threshold_pct_fall : 50 ;

output_threshold_pct_fall : 50 ;

input_threshold_pct_rise : 50 ;

output_threshold_pct_rise : 50 ;

slew_lower_threshold_pct_fall : 10 ;

slew_upper_threshold_pct_fall : 90 ;

slew_derate_from_library : 1.0 ;

cell (mode_example) {

Liberty User Guide Volume 1

R-2020.09

228

Chapter 7: Timing Arcs

Defining the timing Group

mode_definition(RAM_MODE) {

mode_value(MODE_1) {

}

mode_value(MODE_2) {

}

mode_value(MODE_3) {

}

mode_value(MODE_4) {

}

interface_timing : true;

dont_use : true;

dont_touch : true;

pin(Q) {

direction : output;

max_capacitance : 2.0;

three_state : "!OE";

timing() {

related_pin : "CK";

timing_sense : non_unate

timing_type : rising_edge

mode(RAM_MODE,"MODE_1 MODE_2");

cell_rise(scalar) {

values( " 0.0 ");

}

cell_fall(scalar) {

values( " 0.0 ");

}

rise_transition(scalar) {

values( " 0.0 ");

}

fall_transition(scalar) {

values( " 0.0 ");

}

timing() {

related_pin : "OE";

timing_sense : positive_unate

timing_type : three_state_enable

mode(RAM_MODE, " MODE_2 MODE_3");

cell_rise(scalar) {

values( " 0.0 ");

}

cell_fall(scalar) {

values( " 0.0 ");

}

rise_transition(scalar) {

values( " 0.0 ");

}

fall_transition(scalar) {

values( " 0.0 ");

}

Liberty User Guide Volume 1

R-2020.09

229

Chapter 7: Timing Arcs

Defining the timing Group

timing() {

related_pin : "OE";

timing_sense : negative_unate

timing_type : three_state_disable

mode(RAM_MODE, MODE_3);

cell_rise(scalar) {

values( " 0.0 ");

}

cell_fall(scalar) {

values( " 0.0 ");

}

rise_transition(scalar) {

values( " 0.0 ");

}

fall_transition(scalar) {

values( " 0.0 ");

}

pin(A) {

direction : input;

capacitance : 1.0;

max_transition : 2.0;

timing() {

timing_type : setup_rising;

related_pin : "CK";

mode(RAM_MODE, MODE_2);

rise_constraint(scalar) {

values( " 0.0 ");

}

fall_constraint(scalar) {

values( " 0.0 ");

}

timing() {

timing_type : hold_rising;

related_pin : "CK";

mode(RAM_MODE, MODE_2);

rise_constraint(scalar) {

values( " 0.0 ");

}

fall_constraint(scalar) {

values( " 0.0 ");

}

pin(OE) {

direction : input;

capacitance : 1.0;

max_transition : 2.0;

}

pin(CS) {

direction : input;

Liberty User Guide Volume 1

R-2020.09

230

Chapter 7: Timing Arcs

Defining the timing Group

capacitance : 1.0;

max_transition : 2.0;

timing() {

timing_type : setup_rising;

related_pin : "CK";

mode(RAM_MODE, MODE_1);

rise_constraint(scalar) {

values( " 0.0 ");

}

fall_constraint(scalar) {

values( " 0.0 ");

}

timing() {

timing_type : hold_rising;

related_pin : "CK";

mode(RAM_MODE, MODE_1);

rise_constraint(scalar) {

values( " 0.0 ");

}

fall_constraint(scalar) {

values( " 0.0 ");

}

pin(CK) {

timing() {

timing_type : "min_pulse_width";

related_pin : "CK";

mode(RAM_MODE , MODE_4);

fall_constraint(scalar) {

values( " 0.0 ");

}

rise_constraint(scalar) {

values( " 0.0 ");

}

timing() {

timing_type : "minimum_period";

related_pin : "CK";

mode(RAM_MODE , MODE_4);

rise_constraint(scalar) {

values( " 0.0 ");

}

fall_constraint(scalar) {

values( " 0.0 ");

}

clock : true;

direction : input;

capacitance : 1.0;

max_transition : 1.0;

}

Liberty User Guide Volume 1

R-2020.09

231

Chapter 7: Timing Arcs

Describing Three-State Timing Arcs

cell_leakage_power : 0.0;

}

Describing Three-State Timing Arcs

Three-state arcs describe a three-state output pin in a cell.

Describing Three-State-Disable Timing Arcs

To designate a three-state-disable timing arc when defining a three-state pin,

Assign related_pin to the enable pin of the three-state function.

Define the 0-to-Z propagation time with the cell_rise or rise_transition

statement.

3. Define the 1-to-Z propagation time with the cell_fall or fall_transition

statement.

4. Include the timing_type : three_state_disable statement.

Example

timing () {

related_pin : "OE" ;

timing_type : three_state_disable ;

/* 0 to Z modeling */

cell_rise(scalar) {

values( " 0.0 ");

}

rise_transition(scalar) {

values( " 0.0 ");

}

/* 1 to Z modeling */

cell_fall(scalar) {

values( " 0.0 ");

}

fall_transition(scalar) {

values( " 0.0 ");

}

Note:

The timing_sense attribute, which describes the transition edge used to

calculate delay for a timing arc, has a nontraditional meaning when it is included

in a timing group that also contains a three_state_disable attribute. See

timing_sense Simple Attribute on page 222 for more information.

Liberty User Guide Volume 1

R-2020.09

232

Chapter 7: Timing Arcs

Describing Three-State Timing Arcs

Describing Three-State-Enable Timing Arcs

To designate a three-state-enable timing arc when defining a three-state pin,

Assign related_pin to the enable pin of the three-state function.

Define the Z-to-1 propagation time with the cell_rise or rise_transition group.

3. Define the Z-to-0 propagation time with the cell_fall or fall_transition group.

Include the timing_type : three_state_enable statement.

Example

timing () {

related_pin : "OE" ;

timing_type : three_state_enable ;

/* 0 to Z modeling */

cell_rise(scalar) {

values( " 0.0 ");

}

rise_transition(scalar) {

values( " 0.0 ");

}

/* 1 to Z modeling */

cell_fall(scalar) {

values( " 0.0 ");

}

fall_transition(scalar) {

values( " 0.0 ");

}

Example 70 Three-State Cell With Both Disable and Enable Timing Arcs

library(example){

date : "January 14, 2015";

revision : 2015.01;

technology (cmos);

...

cell(TRI_INV2) {

area : 3;

pin(A) {

direction : input;

capacitance : 2;

}

pin(E) {

direction : input;

capacitance : 2;

}

pin(Z) {

direction : output;

Liberty User Guide Volume 1

R-2020.09

233

Chapter 7: Timing Arcs

Describing Edge-Sensitive Timing Arcs

function : "A’";

three_state : "E’";

timing() {

related_pin : "A";

}

timing() {

timing_type : three_state_enable;

related_pin : "E";

}

timing() {

timing_type : three_state_disable;

related_pin : "E";

}

Note:

The timing_sense attribute that describes the transition edge used to calculate

delay for a timing arc has a nontraditional meaning when it is included in

a timing group that also contains a three_state_enable attribute. See

timing_sense Simple Attribute on page 222 for more information.

Describing Edge-Sensitive Timing Arcs

Edge-sensitive timing arcs, such as the arc from the clock on a flip-flop, are identified by

the following values of the timing_type attribute in the timing group.

rising_edge

Identifies a timing arc whose output pin is sensitive to a rising signal at the input

pin.

falling_edge

Identifies a timing arc whose output pin is sensitive to a falling signal at the input

pin.

These arcs are path-traced; the path tracer propagates only the active edge (rise or fall)

path values along the timing arc.

See timing_type Simple Attribute on page 223 for information about the timing_type

attribute.

The following example shows the timing arc for the QN pin of a JK flip-flop.

Example

pin(QN) {

direction : output ;

Liberty User Guide Volume 1

R-2020.09

234

Chapter 7: Timing Arcs

Describing Clock Insertion Delay

function : "IQN" ;

timing() {

related_pin : "CP" ;

timing_type : rising_edge ;

}

The QN pin makes a transition after the clock signal rises.

Describing Clock Insertion Delay

Arrival timing paths are the timing paths from an input clock pin to the clock pins that are

internal to a cell. The arrival timing paths describe the minimum and the maximum timing

constraint for a pin driving an internal clock tree for each input transition, as shown in

Figure 28.

Figure 28 Minimum and Maximum Clock Tree Paths

The max_clock_tree_path and min_clock_tree_path attributes let you define the

maximum and minimum clock tree path constraints.

The clock tree path for any one clock can have up to eight values depending on the

unateness of the pins and the fastest and slowest paths.

You can use lookup tables to model the cell delays. Lookup tables are indexed only by the

input transition time of the clock.

Liberty User Guide Volume 1

R-2020.09

235

Chapter 7: Timing Arcs

Describing Intrinsic Delay

Polynomials can include only the following variables in piecewise domains:

input_net_transition, voltage, voltagei, and temperature.

For timing groups whose timing_sense attribute is set to non_unate and whose only

variable is input_net_transition, use pairs of lookup tables to model both positive

unate and negative unate.

Describing Intrinsic Delay

The intrinsic delay of an element is the zero-load (fixed) component of the total delay

equation. Intrinsic delay attributes have different meanings, depending on whether they

are for an input or an output pin.

When describing an output pin, the intrinsic delay attributes define the fixed delay from

input to output pin. These values are used to calculate the intrinsic delay of the total delay

equation.

When describing an input pin, such as in a setup or hold timing arc, intrinsic attributes

define the timing requirements for that pin. Timing constraints are not used in the delay

equation. The description of intrinsic delay is inherent in the lookup tables you create.

In the CMOS Piecewise Linear Delay Model

You describe the intrinsic delay in the CMOS piecewise linear delay model the same way

you describe it in the CMOS generic delay model.

In the Scalable Polynomial Delay Model

The description of intrinsic delay is inherent in the polynomials you create for this delay

model. See Defining the Scalable Polynomial Delay Model Template on page 218 to

learn how to create and use templates for scalable polynomials in a library, using the

CMOS scalable polynomial nonlinear delay model.

Describing Transition Delay

The transition delay of an element is the time it takes the driving pin to change state.

Transition delay attributes represent the resistance encountered in making logic

transitions.

The components of the total delay calculation depend on the timing delay model used.

Include the transition delay attributes that apply to the delay model you are using.

Liberty User Guide Volume 1

R-2020.09

236

Chapter 7: Timing Arcs

Describing Transition Delay

Transition time is the time it takes for an output signal to make a transition between the

high and low logic states. It is computed by table lookup and interpolation. Transition delay

is a function of capacitance at the output pin and input transition time.

Defining Delay Arcs With Lookup Tables

These timing group attributes provide valid lookup tables for delay arcs:

•

cell_rise

•

cell_fall

• rise_propagation

•

fall_propagation

•

retaining_rise

• retaining_fall

•

retain_rise_slew

•

retain_fall_slew

Note:

For timing groups with timing type clear, only fall groups are valid. For

timing groups with timing type preset, only rise groups are valid.

There are two methods for defining delay arcs. Choose the method that best fits your

library data characterization. .

Method 1

To specify cell delay independently of transition delay, use one of these timing group

attributes as your lookup table:

•

cell_rise

•

cell_fall

Method 2

To specify transition delay as a term in the total cell delay, use one of these timing group

attributes as your lookup table:

•

rise_propagation

•

fall_propagation

Liberty User Guide Volume 1

R-2020.09

237

Chapter 7: Timing Arcs

Describing Transition Delay

retaining_rise and retaining_fall Groups

The retaining delay is the time during which an output port retains its current logical value

after a voltage rise or fall at a related input port.

The retaining delay is part of the arc delay (I/O path delay); therefore, its time cannot

exceed the arc delay time. Because retaining delay is part of the arc delay, the retaining

delay tables are placed within the timing arc.

The value you enter for the retaining_rise attribute determines how long the output pin

retains its current value, 0, after the value at the related input port has changed.

The value you enter for the retaining_fall attribute determines how long the output

retains its current value, 1, after the value at the related input port has changed.

Figure 29 shows retaining delay in regard to changes in a related input port.

Figure 29 Retaining Time Delay

Example 71 shows how to use the retaining_rise and retaining_fall attributes.

Example 71 Retaining Time Delay

library(foo) {

...

lu_table_template (retaining_table_template){

...

variable_1: total_output_net_capacitance;

variable_2: input_net_transition;

Liberty User Guide Volume 1

R-2020.09

238

Chapter 7: Timing Arcs

Describing Transition Delay

index_1 ("0.0, 1.5");

index_2 ("1.0, 2.1");

}

...

cell (cell_name){

...

pin (A) {

direction : output;

...

timing(){

related_pin : "B"

...

retaining_rise (retaining_table_template){

values ("0.00, 0.23", "0.11, 0.28");

}

retaining_fall (retaining_table_template){

values ("0.01, 0.30", 0.12, 0.18");

}

}/*end of pin() */

...

}/*end of cell() */

...

}/*end of library() */

See Specifying Delay Scaling Attributes on page 56 for information about calculating delay

factors.

retain_rise_slew and retain_fall_slew Groups

These groups let you specify a slew table for the retain arc that is separate from the table

of the parent delay arc. This retain arc represents the time it takes until an output pin starts

losing its current logical value after a related input pin is changed. This decaying of the

output logic value occurs at a different time than the propagation of the final logical value,

and at a different rate.

The retain delay is part of the arc delay (I/O path delay), and therefore its time cannot

exceed the arc delay time. Because the retain delay is part of the arc delay, the retain

delay tables are placed within the timing arc.

The value you enter for the retain_rise_slew attribute determines how long the output

pin retains its current value, 0, after the value at the related input port has changed.

The value you enter for the retain_fall_slew attribute determines how long the output

retains its current value, 1, after the value at the related input port has changed.

Liberty User Guide Volume 1

R-2020.09

239

Chapter 7: Timing Arcs

Describing Transition Delay

Figure 30 Timing Diagram of Synchronous RAM

Liberty User Guide Volume 1

R-2020.09

240

Chapter 7: Timing Arcs

Describing Transition Delay

Example

library(library_name) {

...

lu_table_template (retaining_table_template){

...

variable_1: total_output_net_capacitance;

variable_2: input_net_transition;

index_1 ("0.0, 1.5");

index_2 ("1.0, 2.1");

}

...

cell (cell_name){

...

pin (A) {

direction : output;

...

timing(){

related_pin : "B"

...

retaining_rise (retaining_table_template){

values ("0.00, 0.23", "0.11, 0.28");

}

retaining_fall (retaining_table_template){

values ("0.01, 0.30", 0.12, 0.18");

}

retain_rise_slew(retaining_time_template){

values("0.01,0.02");

}

retain_fall_slew(retaining_time_template){

values("0.01,0.02");

}

}/*end of pin() */

...

}/*end of cell() */

...

}/*end of library() */

See Specifying Delay Scaling Attributes on page 56 for information about calculating delay

factors.

Modeling Transition Time Degradation

Current nonlinear delay models are based on the assumption that the transition time at the

load pin is the same as the transition time created at the driver pin. In reality, the net acts

as a low-pass filter and the transition flattens out as it propagates from the driver of the

net to each load, as shown in Figure 31. The higher the interconnect load, the greater the

flattening effect and the greater the transition delay.

Liberty User Guide Volume 1

R-2020.09

241

Chapter 7: Timing Arcs

Describing Transition Delay

Figure 31 Transition Time Degradation

To model the degradation of the transition time as it propagates from an output pin over

the net to the next input pin, include these library-level groups in your library:

•

rise_transition_degradation

• fall_transition_degradation

These groups contain the values describing the degradation functions for rise and fall

transitions in the form of lookup tables. The lookup tables are indexed by

•

Transition time at the net driver

•

Connect delay between the driver and a load

These are the supported values for transition degradation (variable_1 and variable_2):

•

output_pin_transition

•

connect_delay

You can assign either connect_delay or output_pin_transition to variable_1 or

variable_2, if the index and table values are consistent with the assignment.

The values you use in the table compute the degradation transition according to the

following formula:

degraded_transition =

table_lookup(f(output_pin_transition, connect_delay))

Liberty User Guide Volume 1

R-2020.09

242

Chapter 7: Timing Arcs

Describing Transition Delay

Design Compiler uses transition degradation tables when it indexes into any

delay table in a library that uses the table parameters input_net_transition,

constrained_pin_transition, or related_pin_transition in an lu_table_template

group. Transition degradation tables in a library have no effect on computations related to

cells from other libraries.

The k-factors for process, voltage, and temperature are not supplied for the new tables.

The output_pin_transition value and the connect_delay value are computed at the

current, rather than nominal, operating conditions.

In Example 72, trans_deg is the name of the template for the transition degradation.

Example 72 Using Degradation Tables

library (simple_tlu) {

delay_model : table_lookup;

/* define the table templates */

lu_table_template(prop) {

variable_1 : input_net_transition ;

variable_2 : total_output_net_capacitance ;

index_1("0, 1, 2");

index_2("0, 1, 2");

}

lu_table_template(tran) {

variable_1 : total_output_net_capacitance ;

variable_2 : input_net_transition ;

index_1("0, 1, 2");

index_2("0, 1, 2");

}

lu_table_template(constraint) {

variable_1 : constrained_pin_transition ;

index_1("0, 1, 2");

variable_2 : related_pin_transition ;

index_2("0, 1, 2");

}

lu_table_template(trans_deg) {

variable_1 : output_pin_transition ;

index_1("0, 1");

variable_2 : connect_delay ;

index_2("0, 1");

}

/* the new degradation tables */

rise_transition_degradation(trans_deg) {

values("0.0, 0.6", "1.0, 1.6");

}

Liberty User Guide Volume 1

R-2020.09

243

Chapter 7: Timing Arcs

Modeling Load Dependency

fall_transition_degradation(trans_deg) {

values("0.0, 0.8", "1.0, 1.8");

}

/* other library level defaults */

default_inout_pin_cap : 1.0;

...

k_process_fall_transition : 1.0;

...

nom_process : 1.0;

nom_temperature : 25.0;

nom_voltage : 5.0;

operating_conditions(BASIC_WORST) {

process : 1.5 ;

temperature : 70 ;

voltage : 4.75 ;

tree_type : "worst_case_tree" ;

}

/* list of cell descriptions */

cell(AN2) {

....

}

Any linear function of output_pin_transition and connect_delay can be represented

with four table points, because the Design Compiler interpolation and extrapolation

mechanism is linear. Larger tables are required to represent more complex degradation

functions, and breakpoints must be chosen so that the interpolation error is acceptable.

Modeling Load Dependency

Describing Transition Delay on page 236 describes how to model the transition time

dependency of a constrained pin and its related pin on timing constraints. You can further

model the effect of unbuffered output on timing constraints by modeling load dependency.

Constraints can also be load-dependent.

This is the procedure for modeling load dependency.

In the timing group of the output pin, set the timing_type attribute .

Use the related_output_pin attribute in the timing group to specify which output pin

to use to calculate the load dependency.

Create a three-dimensional table template that uses two variables and indexes to

model transition time and the third variable and index to model load. The variable

values for representing output loading on the related_output_pin are

Liberty User Guide Volume 1

R-2020.09

244

Chapter 7: Timing Arcs

Modeling Load Dependency

related_out_total_output_net_capacitance

related_out_output_net_length

related_out_output_net_wire_cap

related_out_output_net_pin_cap

See Defining the NLDM Template on page 214.

Create a three-dimensional lookup table, using the table template and the index_3

attribute in the lookup table group. (See Creating Lookup Tables on page 217 .) The

following groups are valid lookup tables for output load modeling:

•

rise_constraint

•

fall_constraint

See Setting Setup and Hold Constraints on page 252 for information about these

groups.

Example 73 Load-Dependent Model in a Library

library(load_dependent) {

delay_model : table_lookup;

...

lu_table_template(constraint) {

variable_1 : constrained_pin_transition;

variable_2 : related_pin_transition;

variable_3 : related_out_total_output_net_capacitance;

index_1 ("1, 5, 10");

index_2 ("1, 5, 10");

index_3 ("1, 5, 10");

}

cell(selector) {

...

pin(d) {

direction : input ;

capacitance : 4 ;

timing() {

related_pin : "sel";

related_output_pin : "so";

timing_type : non_seq_hold_rising;

rise_constraint(constraint) {

values("1.5, 2.5, 3.5", "1.6, 2.6, 3.6", "1.7, 2.7, 3.7", \

"1.8, 2.8, 3.8", "1.9, 2.9, 3.9", "2.0, 3.0, 4.0", \

"2.1, 3.1, 4.1", "2.2, 3.2, 4.2", "2.3, 3.3, 4.3");

}

fall_constraint(constraint) {

values("1.5, 2.5, 3.5", "1.6, 2.6, 3.6", "1.7, 2.7, 3.7", \

"1.8, 2.8, 3.8", "1.9, 2.9, 3.9", "2.0, 3.0, 4.0", \

"2.1, 3.1, 4.1", "2.2, 3.2, 4.2", "2.3, 3.3, 4.3");

}

...

}

...

}

Liberty User Guide Volume 1

R-2020.09

245

Chapter 7: Timing Arcs

Modeling Load Dependency

In the CMOS Scalable Polynomial Delay Model

This is the procedure for modeling load dependency.

In the timing group of the output pin, set the timing_type attribute value.

Specify the output pin used to figure the load dependency with the

related_output_pin attribute described later.

3. Create a three-dimensional table template that uses two variables to model transition

time and a third variable, poly_template, to model load. The variable values for

representing output loading on the related_output_pin are

related_out_total_output_net_capacitance

related_out_output_net_length

related_out_output_net_wire_cap

related_out_output_net_pin_cap

See Defining the Scalable Polynomial Delay Model Template on page 218.

4. Create a three-dimensional lookup table, using the table template and the index_3

attribute in the lookup table group.

Express the delay equation in terms of scalable polynomial delay coefficients, using

the variable_3 variable and the variable_3_range attribute in the poly_template

group.

•

rise_constraint

•

fall_constraint

Example 74 is an example of a library that includes a load-dependent model.

Example 74 Load-Dependent Model

library(load_dependent) {

...

technology (cmos) ;

delay_model : polynomial ;

...

poly_template ( const ) {

variables (constrained_pin_transition, related_pin_transition, \

related_out_total_output_net_capacitance);

variable_1_range (0.0000, 4.0000);

variable_2_range (0.0000, 4.0000);

variable_3_range (0.0000, 4.0000);

}

...

cell(example) {

...

pin(D) {

direction : input ;

capacitance : 1.00 ;

timing() {

Liberty User Guide Volume 1

R-2020.09

246

Chapter 7: Timing Arcs

Describing Slope Sensitivity

timing_type : setup_rising ;

fall_constraint(const) {

orders ("2, 1, 1")

coefs ("1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0");

}

rise_constraint(const){

orders ("2, 1, 1")

coefs ("1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0");

}

related_pin : "CP" ;

related_output_pin : "Q";

}

timing() {

timing_type : hold_rising ;

rise_constraint(const) {

orders ("1, 1, 1")

coefs ("1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0");

}

fall_constraint(const){

orders ("1, 1, 1")

coefs ("1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0");

}

related_pin : "CP" ;

related_output_pin : "Q";

}

...

} /* end cell */

...

} /* end library */

Describing Slope Sensitivity

The slope delay of an element is the incremental time delay due to slowing changing input

signals. Slope delay is calculated with the transition delay at the previous output pin with a

slope sensitivity factor.

A slope sensitivity factor accounts for the time during which the input voltage begins to rise

but has not reached the threshold level at which channel conduction begins.

Describing State-Dependent Delays

These timing attributes describe the delay values for specified conditions.

In the timing group of a logic library, you need to specify state-dependent delays that

correspond to entries in Open Verilog International Standard Delay Format (OVI SDF 2.1)

syntax.

To define a state-dependent timing arc, you can specify the following attributes in each

timing group:

•

when

Liberty User Guide Volume 1

R-2020.09

247

Chapter 7: Timing Arcs

Describing State-Dependent Delays

• char_when

• char_when_rise

• char_when_fall

•

sdf_cond

You must define mutually exclusive conditions for state-dependent timing arcs. Mutually

exclusive means that no more than one condition (defined in the when attribute) can be

met at any time. Use the default_timing attribute to specify a default timing arc in the

case of multiple timing arcs with when attributes.

See for information about conditional path delays in an SDF file.

when Simple Attribute

The when attribute is a Boolean expression in the timing group that specifies the

condition on which a timing arc depends to activate a path. Conditional timing lets you

control the output pin of a cell with respect to the various states of the input pins.

Table 19 Valid Boolean Operators

Operator Description

’ Invert previous expression

! Invert following expression

^ Logical XOR

* Logical AND

& Logical AND

space Logical AND

+ Logical OR

| Logical OR

1 Signal tied to logic 1

0 Signal tied to logic 0

The order of precedence of the operators is left to right, with inversion performed first, then

XOR, then AND, then OR.

Liberty User Guide Volume 1

R-2020.09

248

Chapter 7: Timing Arcs

Describing State-Dependent Delays

Example

when : "B";

Figure 32 XOR Gate With State-Dependent Timing Arc

The example in sdf_cond Simple Attribute shows how to use the when attribute for an XOR

gate. In the description of the XOR cell, pin A sets conditional timing for the output pin

“out” when you define the timing arc for related_pin B. In this example, when you set

conditional timing for related_pin A with the when : “B” statement, the output pin gets the

negative_unate value of A when the condition is B.

There are limitations on the pin types that can be used with different types of cells with the

when attribute.

For a combinational cell, these pins are valid with the when attribute:

•

Pins in the function attribute for regular combinational timing arcs

• Pins in the three_state attribute for the endpoint of the timing arc

For a sequential cell, valid pins or variables to use with the when attribute are determined

by the timing type of the arc.

•

For timing types rising_edge and falling_edge: Pins in these attributes are allowed

in the when attribute:

◦

next_state

◦

clocked_on

◦ clocked_on_also

◦

enable

◦

data_in

•

For timing type clear

◦ If the pin’s function is the first state variable in the flip-flop or latch group, the

pin that defines the clear condition in the flip-flop or latch group is allowed in

the when construct.

Liberty User Guide Volume 1

R-2020.09

249

Chapter 7: Timing Arcs

Describing State-Dependent Delays

◦ If the pin’s function is the second state variable in the flip-flop or latch group,

the pin that defines the preset condition in the flip-flop or latch group is allowed

in the when construct.

• For timing type preset

◦ If the pin’s function is the first state variable in the flip-flop or latch group, the

pin that defines the preset condition in the flip-flop or latch group is allowed in

the when construct.

◦

If the pin’s function is the second state variable in the flip-flop or latch group,

the pin that defines the clear condition in the flip-flop or latch group is allowed

in the when construct.

See timing_type Simple Attribute on page 223 for more information.

All input pins in a black box cell (a cell without a function attribute) are allowed in the

when attribute.

sdf_cond Simple Attribute

Defined in the state-dependent timing group, the sdf_cond attribute supports Standard

Delay Format (SDF) file generation and condition matching during back-annotation.

Example

sdf_cond : "SE ==1’B1";

Synopsys tools, such as PrimeTime, Design Compiler, and IC Compiler use the when

expression instead of the sdf_cond expression. For a library file with the sdf_cond

attribute, these tools:

•

Read the corresponding SDF file without issuing an error.

•

Write the sdf_cond expressions in the SDF file.

The sdf_cond attribute must be logically equivalent to the when attribute for the same

timing arc. If the two Boolean expressions are not equivalent, back-annotation is not

performed properly.

The sdf_cond expressions must be syntax-compliant with SDF 2.1. If the expressions do

not meet this standard, errors are generated later in the flow during the generation and

reuse of the SDF files.

For simple delay paths, such as IOPATH, you can use the Boolean operators, such as &&

and ||, with the sdf_cond attribute. However, Verilog timing check statements, including

setup, hold, recovery, and removal do not support Boolean operators.

Liberty User Guide Volume 1

R-2020.09

250

Chapter 7: Timing Arcs

Describing State-Dependent Delays

In Example 75, the delay between pin A and pin OUT is 1.3 for rising and 1.5 for falling

when pin B = 1. There is an additional timing arc between the same two pins that has a

rise delay of 1.4 and a fall delay of 1.6 when pin B = 0.

Example 75 2-Input XOR Cell With State-Dependent Timing

cell(XOR) {

pin(A) {

direction : input;

...

}

pin(B) {

direction : input;

...

}

pin(out) {

direction : output;

function : "A ^ B";

timing() {

related_pin : "A";

timing_sense : negative_unate;

when : "B";

sdf_cond : " B == 1’B1 ";

cell_rise(scalar) {

values( " 1.3 ") ;

}

cell_fall(scalar) {

values( " 1.5 ") ;

}

timing() {

related_pin : "A";

timing_sense : positive_unate;

when : "!B";

sdf_cond : " B == 1’B0 ";

cell_rise(scalar) {

values( " 1.4 ") ;

}

cell_fall(scalar) {

values( " 1.6 ") ;

}

timing() { /* default timing arc */

related_pin : "A";

timing_sense : non_unate;

cell_rise(scalar) {

values( " 1.4 ") ;

}

cell_fall(scalar) {

values( " 1.6 ") ;

}

timing() {

Liberty User Guide Volume 1

R-2020.09

251

Chapter 7: Timing Arcs

Setting Setup and Hold Constraints

related_pin : "B";

timing_sense : negative_unate;

when : "A";

sdf_cond : "A == 1’B1 ";

cell_rise(scalar) {

values( " 1.3 ") ;

}

cell_fall(scalar) {

values( " 1.5 ") ;

}

timing() {

related_pin : "B";

timing_sense : positive_unate;

when : "!A";

sdf_cond : "A == 1’B0 ";

cell_rise(scalar) {

values( " 1.4 ") ;

}

cell_fall(scalar) {

values( " 1.6 ") ;

}

timing() { /* default timing arc */

related_pin : "B";

timing_sense : non_unate;

cell_rise(scalar) {

values( " 1.4 ") ;

}

cell_fall(scalar) {

values( " 1.6 ") ;

}

Setting Setup and Hold Constraints

Signals arriving at an input pin have ramp times. Therefore, you must ensure that the data

signal has stabilized before latching its value by defining setup and hold arcs as timing

requirements.

•

Setup constraints describe the minimum time allowed between the arrival of the data

and the transition of the clock signal. During this time, the data signal must remain

constant. If the data signal makes a transition during the setup time, an incorrect value

might be latched.

•

Hold constraints describe the minimum time allowed between the transition of the

clock signal and the latching of the data. During this time, the data signal must remain

Liberty User Guide Volume 1

R-2020.09

252

Chapter 7: Timing Arcs

Setting Setup and Hold Constraints

constant. If the data signal makes a transition during the hold time, an incorrect value

might be latched.

By combining a setup time and a hold time, you can ensure the stability of data that is

latched.

The timing checks for flip-flops use the activating edge of the clock, which is the rising

edge for the case shown in Figure 33.

Figure 33 Setup and Hold Constraints for Rising-Edge-Triggered Flip-Flop

The timing checks for latches generally use the deactivating edge of the enable signal,

which is the falling edge for the case shown in Figure 34. However, the method used

depends on the vendor.

Figure 34 Setup and Hold Constraints for High-Enable Latch

NLDM supports timing constraints sensitive to clock or data-input transition times.

Liberty User Guide Volume 1

R-2020.09

253

Chapter 7: Timing Arcs

Setting Setup and Hold Constraints

Each constraint is defined by a timing group with two lookup tables:

• rise_constraint group

•

fall_constraint group

rise_constraint and fall_constraint Groups

These are constraint tables. The format of the lookup table template and the format of

the lookup table are the same as described previously in Defining the NLDM Template on

page 214 and Creating Lookup Tables on page 217.

These are valid variable values for the timing constraint template:

constrained_pin_transition

Value for the transition time of the pin that owns the timing group.

related_pin_transition

Value for the transition time of the related_pin defined in the timing group.

For each timing group containing one of the following timing_type attribute values, at

least one lookup table is required:

• setup_rising

•

setup_falling

•

hold_rising

•

hold_falling

•

skew_rising

•

skew_falling

•

non_seq_setup_rising

•

non_seq_setup_falling

•

non_seq_hold_rising

•

non_seq_hold_falling

•

nochange_high_high

•

nochange_high_low

•

nochange_low_high

•

nochange_low_low

Liberty User Guide Volume 1

R-2020.09

254

Chapter 7: Timing Arcs

Setting Setup and Hold Constraints

For each timing group with one of the following timing_type attribute values, only one

lookup table is required:

•

recovery_rising

•

recovery_falling

• removal_rising

•

removal_falling

Example 76 Using Lookup Tables to Specify Setup Constraints for Flip-Flop

library( vendor_b ) {

/* 1. Use delay lookup table */

delay_model : table_lookup;

/* 2. Define template of size 3 x 3*/

lu_table_template(constraint_template) {

variable_1 : constrained_pin_transition;

variable_2 : related_pin_transition;

index_1 ("0.0, 0.5, 1.5");

index_2 ("0.0, 2.0, 4.0");

}

. . .

cell(dff) {

pin(d) {

direction: input;

timing() {

related_pin : "clk";

timing_type : setup_rising;

/* Inherit the constraint_template template */

rise_constraint(constraint_template) {

/* Specify all the values */

values ("0.0, 0.13, 0.19", \

"0.21, 0.23, 0.41", \

"0.33, 0.37, 0.50");

}

fall_constraint(constraint_template) {

values ("0.0, 0.14, 0.20", \

"0.22, 0.24, 0.42", \

"0.34, 0.38, 0.51");

}

. . .

}

In the Scalable Polynomial Delay Model

Example 77 shows how to specify constraint in a scalable polynomial delay model.

Example 77 CMOS Scalable Polynomial Delay Model Using Constraint

library(vendor_b) {

Liberty User Guide Volume 1

R-2020.09

255

Chapter 7: Timing Arcs

Setting Nonsequential Timing Constraints

/* Use polynomial delay model */

delay_model : polynomial;

/* Define template */

poly_template ( constraint_template_poly ) {

variables (constrained_pin_transition, related_pin_transition);

variable_1_range (0.01, 3.00);

variable_2_range (0.01, 3.00);

}

.......

cell(dff) {

pin(D) {

direction : input ;

timing() {

related_pin : "CP" ;

timing_type : setup_rising ;

rise_constraint ( constraint_template_poly ) {

orders("1, 1");

/* (a

+ a

)(b

+ b

) = A

+ A

coefs ("0.2487 +0.0520 -0.0268 -0.0053 " ) ;

variable_1_range (0.01, 3.00);

variable_2_range (0.01, 3.00);

}

fall_constraint ( constraint_template_poly ) {

orders("1, 2");

/* (a

+ a

)(b

+ b

) = */

/* A

+ A

coefs ("0.2732 +0.0668 +0.0216 -0.0002 -0.0003 +0.0000 " ) ;

variable_1_range (0.01, 3.00);

variable_2_range (0.01, 3.00);

}

.......

}

.....

}

Identifying Interdependent Setup and Hold Constraints

To reduce slack violation, use pairs of interdependence_id attributes to identify

interdependent pairs of setup and hold constraint tables. Interdependence data is

supported in conditional constraint checking. The interdependence_id increases

independently for each condition. Interdependence data can be specified in pin or bus and

bundle groups..

Setting Nonsequential Timing Constraints

You can set constraints requiring that the data signal on an input pin remain stable for a

specified amount of time before or after another pin in the same cell changes state. These

cells are termed nonsequential cells, because the related pin is not a clock signal.

All Synopsys delay models supporting sequential setup and hold constraint modeling also

support nonsequential setup and hold modeling.

Liberty User Guide Volume 1

R-2020.09

256

Chapter 7: Timing Arcs

Setting Nonsequential Timing Constraints

Scaling of nonsequential setup and hold constraints based on the environment use k-

factors for sequential setup and hold constraints.

The values you can assign to a timing_type attribute to model nonsequential setup and

hold constraints are

non_seq_setup_rising

Designates the rising edge of the related pin for the setup check.

non_seq_setup_falling

Designates the falling edge of the related pin for the setup check.

non_seq_hold_rising

Designates the rising edge of the related pin for the hold check.

non_seq_hold_falling

Designates the falling edge of the related pin for the hold check.

To model nonsequential setup and hold constraints for a cell,

Assign a value to the timing_type attribute in a timing group of an input or I/O pin.

Specify a related pin with the related_pin attribute in the timing group. The related

pin in a timing arc is the pin used for the timing check.

Use any pin in the same cell, except for output pins, and the constrained pin itself as

the related pin.

You can use both rising and falling edges as the active edge of the related pin for one

cell.

Example

pin(T) {

timing() {

timing_type : non_seq_setup_falling;

rise_constraint(scalar) {

values (" 1.5 ") ;

}

fall_constraint(scalar) {

values (" 1.5 ") ;

}

related_pin : "S";

}

Figure 35 shows the waveforms for the nonsequential timing arc described in the

preceding example. In this timing arc, the constrained pin is T and its related pin is S. The

Liberty User Guide Volume 1

R-2020.09

257

Chapter 7: Timing Arcs

Setting Recovery and Removal Timing Constraints

intrinsic rise value describes setup time C or hold time B. The intrinsic fall value describes

setup time A or hold time D.

Figure 35 Nonsequential Setup and Hold Constraints

Setting Recovery and Removal Timing Constraints

Use the recovery and removal timing arcs for asynchronous control pins such as clear and

preset.

Recovery Constraints

The recovery timing arc describes the minimum allowable time between the control pin

transition to the inactive state and the active edge of the synchronous clock signal (time

between the control signal going inactive and the clock edge that latches data in).

The asynchronous control signal must remain constant during this time, or else an

incorrect value might appear at the outputs.

Liberty User Guide Volume 1

R-2020.09

258

Chapter 7: Timing Arcs

Setting Recovery and Removal Timing Constraints

Figure 36 Recovery Timing Constraint for a Rising-Edge-Triggered Flip-Flop With Active-

Low Clear

Figure 37 Recovery Timing Constraint for a Low-Enable Latch With Active-High Preset

The values you can assign to a timing_type attribute to define a recovery time constraint

are

recovery_rising

Uses the rising edge of the related pin for the recovery time check; the clock is

rising-edge-triggered.

recovery_falling

Uses the falling edge of the related pin for the recovery time check; the clock is

falling-edge-triggered.

To define a recovery time constraint for an asynchronous control pin,

Assign a value to the timing_type attribute.

Use recovery_rising for rising-edge-triggered flip-flops and low-enable latches; use

recovery_falling for negative- edge-triggered flip-flops and high-enable latches.

Identify the synchronous clock pin as the related_pin.

Liberty User Guide Volume 1

R-2020.09

259

Chapter 7: Timing Arcs

Setting Recovery and Removal Timing Constraints

For active-low control signals, define the recovery time with the rise_constraint

statement.

For active-high control signals, define the recovery time with the fall_constraint

statement.

Example

This example shows a recovery timing arc for the active-low clear signal in a rising-edge-

triggered flip-flop. The rise_constraint value represents clock recovery time A in

Figure 36.

pin (Clear) {

direction : input ;

capacitance : 1 ;

timing() {

related_pin : "Clock" ;

timing_type : recovery_rising;

rise_constraint(scalar) {

values (" 1.0 ") ;

}

The following example shows a recovery timing arc for the active-high preset signal in

a low-enable latch. The fall_constraint value represents clock recovery time A in

Figure 37.

pin (Preset) {

direction : input ;

capacitance : 1 ;

timing() {

related_pin : "Enable" ;

timing_type : recovery_rising;

fall_constraint(scalar) {

values (" 1.0 ") ;

}

Removal Constraint

This constraint is also known as the asynchronous control signal hold time. The removal

constraint describes the minimum allowable time between the active edge of the clock

Liberty User Guide Volume 1

R-2020.09

260

Chapter 7: Timing Arcs

Setting Recovery and Removal Timing Constraints

pin while the asynchronous pin is active and the inactive edge of the same asynchronous

control pin (see Figure 38).

Figure 38 Timing Diagram for Removal Constraint

The values you can assign to a timing_type attribute to define a removal constraint are

removal_rising

Use when the cell is a low-enable latch or a rising-edge-triggered flip-flop.

removal_falling

Use when the cell is a high-enable latch or a falling-edge-triggered flip-flop.

To define a removal constraint,

Assign a value to the timing_type attribute.

Identify the synchronous clock pin as the related_pin.

For active-low asynchronous control signals, define the removal time with the

rise_constraint attribute.

For active-high asynchronous control signals, define the removal time with the

fall_constraint attribute.

Example

pin ( SET ) {

....

timing() {

timing_type : removal_rising;

related_pin : " CK1 ";

rise_constraint(scalar) {

values (" 1.0 ") ;

}

Liberty User Guide Volume 1

R-2020.09

261

Chapter 7: Timing Arcs

Setting No-Change Timing Constraints

You can model no-change timing checks to use in static timing verification during

synthesis.

A no-change timing check checks a constrained signal against a level-sensitive related

signal. The constrained signal must remain stable during an established setup period, for

the width of the related pulse, and during an established hold period.

For example, you can use the no-change timing check to model the timing requirements of

latch devices with latch enable signals. To ensure correct latch sampling, the latch enable

signal must remain stable during the clock pulse and the setup and hold time around the

clock pulse.

You can also use the no-change timing check to model the timing requirements of memory

devices. To guarantee correct read/write operations, the address or data must remain

stable during a read/write enable pulse and the setup and hold margins around the pulse.

Figure 39 No-Change Timing Check Between a Constrained Pin and its Level-Sensitive

Related Pin

The values you can assign to a timing_type attribute to define a no-change timing

constraint are

nochange_high_high

Specifies a positive pulse on the constrained pin and a positive pulse on the

related pin.

Liberty User Guide Volume 1

R-2020.09

262

Chapter 7: Timing Arcs

Setting No-Change Timing Constraints

nochange_high_low

Specifies a positive pulse on the constrained pin and a negative pulse on the

related pin.

nochange_low_high

Specifies a negative pulse on the constrained pin and a positive pulse on the

related pin.

nochange_low_low

Specifies a negative pulse on the constrained pin and a negative pulse on the

related pin.

Figure 40 shows the waveforms for these constraints.

Figure 40 No-Change Setup and Hold Constraint Waveforms

To model no-change timing constraints,

Assign a value to the timing_type attribute.

Specify a related pin with the related_pin attribute in the timing group.

The related pin in the timing arc is the pin used for the timing check.

Specify delay attribute values according to the delay model you use, as summarized in

the following table.

Liberty User Guide Volume 1

R-2020.09

263

Chapter 7: Timing Arcs

Setting No-Change Timing Constraints

No-change constraint Setup attribute for nonlinear

delay models

Hold attribute for nonlinear

delay models

nochange_high_high rise_constraint fall_constraint

nochange_high_low rise_constraint fall_constraint

nochange_low_high fall_constraint rise_constraint

nochange_low_low fall_constraint rise_constraint

Note:

With no-change timing constraints, conditional timing constraints have

different interpretations than they do with other constraints. See Setting

Conditional Timing Constraints on page 266 for more information.

Specify setup time with the rise_constraint attribute and the hold time with the

fall_constraint attribute.

This is the syntax for the no-change timing check:

timing () {

timing_type : nochange_high_high | nochange_high_low | \

nochange_low_high | nochange_low_low ;

related_pin : related_pinname;

rise_constraint (template_name

) {

/* constrained signal rising */

values (float, ..., float) ;

}

fall_constraint (template_name

) {

/* constrained signal falling */

values (float, ..., float) ;

}

Example

This is an example of a no-change timing check in a logic library:

library (the_lib) {

delay_model : table_lookup;

k_process_nochange_rise : 1.0; /* no-change scaling factors */

k_process_nochange_fall : 1.0;

k_volt_nochange_rise : 0.0;

k_volt_nochange_fall : 0.0;

k_temp_nochange_rise : 0.0;

k_temp_nochange_fall : 0.0;

cell (the_cell) {

pin(EN {

timing () {

timing_type : nochange_high_low;

Liberty User Guide Volume 1

R-2020.09

264

Chapter 7: Timing Arcs

Setting Skew Constraints

related_pin : CLK;

rise_constraint (temp) { /* setup time */

values (2.98);

}

fall_constraint (temp) { /* hold time */

values (0.98);

}

...

}

...

}

...

}

Setting Skew Constraints

The skew constraint defines the maximum separation time allowed between two clock

signals.

Figure 41 Timing Diagram for Skew Constraint

The values you can assign to a timing_type attribute to define a skew constraint are

skew_rising

The timing constraint interval is measured from the rising edge of the reference

pin (specified in related_pin ) to a transition edge of the parent pin of the

timing group.

skew_falling

The timing constraint interval is measured from the falling edge of the reference

pin (specified in related_pin ) to a transition edge of the parent pin of the

timing group.

Liberty User Guide Volume 1

R-2020.09

265

Chapter 7: Timing Arcs

Setting Conditional Timing Constraints

To set skew constraint,

1. Assign a value to the timing_type attribute.

Define only one of these attributes in the timing group:

• rise_constraint

•

fall_constraint

Use the related_pin attribute in the timing group to specify a reference clock pin.

Only the following attributes in a skew timing group are used (all others are ignored):

•

timing_type

•

related_pin

• rise_constraint

•

fall_constraint

Example

This example shows how to model constraint CK1 rise to CK2 rise skew:

pin (CK2) {

....

timing() {

timing_type : skew_rising;

related_pin : " CK1 ";

rise_constraint(scalar) { /* constrained signal rising */

values (" float ") ;

}

Setting Conditional Timing Constraints

A conditional timing constraint describes a check when a specified condition is met. You

can specify conditional timing checks in pin, bus, and bundle groups.

Use the following attributes and groups to specify conditional timing checks.

Attributes:

•

when

•

sdf_cond

• when_start

•

sdf_cond_start

Liberty User Guide Volume 1

R-2020.09

266

Chapter 7: Timing Arcs

Setting Conditional Timing Constraints

• when_end

• sdf_cond_end

• sdf_edges

Groups:

•

min_pulse_width

•

minimum_period

when and sdf_cond Simple Attributes

The when attribute defines enabling conditions for timing checks such as setup, hold, and

recovery.

If you define when, you must define sdf_cond.

Using the when and sdf_cond pair is a short way of specifying when_start,

sdf_cond_start, when_end, and sdf_cond_end when the start condition is identical to

the end condition.

Describing State-Dependent Delays on page 247 describes the sdf_cond and when

attributes in defining state-dependent timing arcs.

when_start Simple Attribute

In a timing group, when_start defines a timing check condition specific to a start event.

The expression in this attribute contains any pin, including input, output, I/O, and internal

pins. You must use real pin names. Bus and bundle names are not allowed.

Example

when_start : "SIG_A"; /*SIG_A must be a declared pin */

The when_start attribute requires an sdf_cond_start attribute in the same timing

group.

The end condition is considered always true if a timing group contains when_start but

no when_end.

sdf_cond_start Simple Attribute

In a timing group, sdf_cond_start defines a timing check condition specific to a start

event in OVI SDF 2.1 syntax.

Liberty User Guide Volume 1

R-2020.09

267

Chapter 7: Timing Arcs

Setting Conditional Timing Constraints

Example

sdf_cond_start : "SIG_A";

The sdf_cond_start attribute requires a when_start attribute in the same timing group.

The end condition is considered always true if a timing group contains sdf_cond_start

but no sdf_cond_end.

when_end Simple Attribute

In a timing group, when_end defines a timing check condition specific to an end event.

The expression in this attribute contains any pin, including input, output, I/O, and internal

pins. Pins must use real pin names. Bus and bundle names are not allowed.

Example

when_end : "CD * SD";

The when_end attribute requires an sdf_cond_end attribute in the same timing group.

The start condition is considered always true if a timing group contains when_end but no

when_start.

sdf_cond_end Simple Attribute

In a timing group, sdf_cond_end defines a timing check condition specific to an end in

OVI SDF 2.1 syntax.

Example

sdf_cond_end : "SIG_0 == 1’b1";

The sdf_cond_end attribute requires a when_end attribute in the same timing group.

The start condition is considered always true if a timing group contains sdf_cond_end

but no sdf_cond_start.

sdf_edges Simple Attribute

The sdf_edges attribute defines edge-specific information for both the start pins and the

end pins. Edge types can be noedge, start_edge, end_edge, or both_edges. The default

is noedge.

Example

sdf_edges : both_edges;

Liberty User Guide Volume 1

R-2020.09

268

Chapter 7: Timing Arcs

Setting Conditional Timing Constraints

min_pulse_width Group

In a pin, bus, or bundle group, the min_pulse_width group models the enabling

conditional minimum pulse width check. In the case of a pin, the timing check is performed

on the pin itself, so the related pin must be the same.

min_pulse_width Example

The following example shows the min_pulse_width group with the constraint_high

and constraint_low attributes specified.

Example 78 min_pulse_width Example

min_pulse_width() {

constraint_high : 3.0; /* min_pulse_width_high */

constraint_low : 3.5; /* min_pulse_width_low */

when : "SE";

sdf_cond : "SE == 1’B1";

}

constraint_high and constraint_low Simple Attributes

At least one of these attributes must be defined in the min_pulse_width group. The

constraint_high attribute defines the minimum length of time the pin must remain at

logic 1. The constraint_low attribute defines the minimum length of time the pin must

remain at logic 0.

when and sdf_cond Simple Attributes

These attributes define the enabling condition for the timing check. Both attributes are

required in the min_pulse_width group.

minimum_period Group

In a pin, bus, or bundle group, the minimum_period group models the enabling

conditional minimum period check. In the case of a pin, the check is performed on the pin

itself, so the related pin must be the same. The attributes in this group are constraint,

when, and sdf_cond.

minimum_period Example

minimum_period() {

constraint : 9.5; /* min_period */

when : "SE";

sdf_cond : "SE == 1’B1";

}

Liberty User Guide Volume 1

R-2020.09

269

Chapter 7: Timing Arcs

Setting Conditional Timing Constraints

constraint Simple Attribute

This required attribute defines the minimum clock period for the pin.

when and sdf_cond Simple Attributes

These attributes define the enabling condition for the timing check. Both attributes are

required in the minimum_period group.

min_pulse_width and minimum_period Example

Example 79 shows how to specify a lookup table with the timing_type attribute and

min_pulse_width and minimum_period values. The rise_constraint group defines

the rising pulse width constraint for min_pulse_width, and the fall_constraint group

defines the falling pulse width constraint. For minimum_period, the rise_constraint

group is used to model the period when the pulse is rising and the fall_constraint

group is used to model the period when the pulse is falling. You can specify the

rise_constraint group, the fall_constraint group, or both groups.

Example 79 Library With timing_type Statements

library(example) {

technology (cmos) ;

delay_model : table_lookup ;

/* 2-D table template */

lu_table_template ( mpw ) {

variable_1 : constrained_pin_transition;

/* You can replace the constrained_pin_transition value with

related_pin_transition, but you cannot specify both values. */

variable_2 : related_out_total_output_net_capacitance;

index_1("1, 2, 3");

index_2("1, 2, 3");

}

/* 1-D table template */

lu_table_template( f_ocap ) {

variable_1 : total_output_net_capacitance;

index_1 (" 0.0000, 1.0000 ");

}

cell( test ) {

area : 200.000000 ;

dont_use : true ;

dont_touch : true ;

pin ( CK ) {

direction : input;

rise_capacitance : 0.00146468;

Liberty User Guide Volume 1

R-2020.09

270

Chapter 7: Timing Arcs

Setting Conditional Timing Constraints

fall_capacitance : 0.00145175;

capacitance : 0.00146468;

clock : true;

timing ( mpw_constraint) {

related_pin : "CK";

timing_type : min_pulse_width;

related_output_pin : "Z";

fall_constraint ( mpw) {

index_1("0.1, 0.2, 0.3");

index_2("0.1, 0.2");

values( "0.10 0.11", \

"0.12 0.13" \

"0.14 0.15");

}

rise_constraint ( mpw) {

index_1("0.1, 0.2, 0.3");

index_2("0.1, 0.2");

values( "0.10 0.11", \

"0.12 0.13" \

"0.14 0.15");

timing ( mpw_constraint) {

related_pin : "CK";

timing_type : minimum_period;

related_output_pin : "Z";

fall_constraint ( mpw) {

index_1("0.2, 0.4, 0.6");

index_2("0.2, 0.4");

values( "0.20 0.22", \

"0.24 0.26" \

"0.28 0.30");

}

rise_constraint ( mpw) {

index_1("0.2, 0.4, 0.6");

index_2("0.2, 0.4");

values( "0.20 0.22", \

"0.24 0.26" \

"0.28 0.30");

}

...

} /* end of arc */

} /* end of cell */

} /* end of library */

Liberty User Guide Volume 1

R-2020.09

271

Chapter 7: Timing Arcs

Setting Conditional Timing Constraints

Using Conditional Attributes With No-Change Constraints

As shown in Table 20, conditional timing check attributes have different interpretations

when you use them with no-change timing constraints. See Setting No-Change Timing

Constraints on page 262 for a description of no-change timing constraint values.

Table 20 Conditional Timing Attributes With No-Change Constraints

Conditional attributes With no-change constraints

when sdf_cond Defines both the constrained and related signal-enabling

conditions

when_start sdf_cond_start Defines the constrained signal-enabling condition

when_end sdf_cond_end Defines the related signal-enabling condition

sdf_edges : start_edge Adds edge specification to the constrained signal

sdf_edges : end_edge Adds edge specification to the related signal

sdf_edges : both_edges Specifies edges to both signals

sdf_edges : noedges Specifies edges to neither signal

Figure 42 Interpretation of Conditional Timing Constraints With No-Change Constraints

Liberty User Guide Volume 1

R-2020.09

272

Chapter 7: Timing Arcs

Impossible Transitions

This information applies to the table lookup delay model and only to combinational and

three-state timing arcs. Certain output transitions cannot result from a single input change

when function, three_state, and x_function share input.

In the following table, Y is the function of A, B, and C.

A B C Y

0 0 0 Z

0 0 1 1

0 1 0 0

0 1 1 X

1 0 0 0

1 0 1 1

1 1 0 Z

1 1 1 X

No isolated signal change on C can cause the 0-to-1 or 1-to-0 transitions on Y. Therefore,

there is no combinational arc from C to Y, although the two are functionally related.

Further, no isolated change on A causes the 1-to-Z or Z-to-1 transitions on Y.

three_state_enable has no rising value (Z to1), and three_state_disable has no

falling value (1 to Z).

Examples of NLDM Libraries

This section contains examples of libraries using the CMOS nonlinear delay model.

CMOS Piecewise Linear Delay Model

In the CMOS piecewise linear D flip-flop description in Example 80, pin D contains setup

and hold constraints; pins Q and QN contain preset, clear, and edge-sensitive arcs.

Example 80 D Flip-Flop Description (CMOS Piecewise Linear Delay Model)

library (example){

date : "January 14, 2002";

Liberty User Guide Volume 1

R-2020.09

273

Chapter 7: Timing Arcs

Examples of NLDM Libraries

revision : 2000.01;

delay_model : piecewise_cmos;

technology (cmos);

piece_define("0,15,40");

cell( DFLOP_CLR_PRE ) {

area : 11 ;

ff ( IQ , IQN ) {

clocked_on : " CLK ";

next_state : " D ";

clear : " CLR’ " ;

preset : " PRE’ " ;

clear_preset_var1 : L ;

clear_preset_var2 : L ;

}

pin ( D ){

direction : input;

capacitance : 1 ;

timing () {

related_pin : "CLK" ;

timing_type : hold_rising;

intrinsic_rise : 0.12;

intrinsic_fall : 0.12 ;

}

timing (){

related_pin : "CLK" ;

timing_type : setup_rising ;

intrinsic_rise : 2.77 ;

intrinsic_fall : 2.77 ;

}

pin ( CLK ){

direction : input;

capacitance : 1 ;

}

pin ( PRE ) {

direction : input ;

capacitance : 2 ;

}

pin ( CLR ){

direction : input ;

capacitance : 2 ;

}

pin ( Q ) {

direction : output;

function : "IQ" ;

timing () {

related_pin : "PRE" ;

timing_type : preset ;

timing_sense : positive_unate ;

intrinsic_rise : 0.65 ;

rise_delay_intercept (0,0.054); /* piece 0 */

rise_delay_intercept (1,0.0); /* piece 1 */

rise_delay_intercept (2,-0.062); /* piece 2 */

Liberty User Guide Volume 1

R-2020.09

274

Chapter 7: Timing Arcs

Examples of NLDM Libraries

rise_pin_resistance (0,0.25); /* piece 0 */

rise_pin_resistance(1,0.50); /* piece 1 */

rise_pin_resistance (2,1.00); /* piece 2 */

}

timing (){

related_pin : "CLR" ;

timing_type : clear ;

timing_sense : negative_unate ;

intrinsic_fall : 1.45 ;

fall_delay_intercept (0,1.0); /* piece 0 */

fall_delay_intercept (1,0.0); /* piece 1 */

fall_delay_intercept (2,-1.0); /* piece 2 */

fall_pin_resistance (0,0.25); /* piece 0 */

fall_pin_resistance (1,0.50); /* piece 1 */

fall_pin_resistance (2,1.00); /* piece 2 */

}

timing (){

related_pin : "CLK" ;

timing_type : rising_edge;

intrinsic_rise : 1.40 ;

intrinsic_fall : 1.91 ;

rise_pin_resistance (0,0.25); /* piece 0 */

rise_pin_resistance (1,0.50); /* piece 1 */

rise_pin_resistance (2,1.00); /* piece 2 */

fall_pin_resistance (0,0.15); /* piece 0 */

fall_pin_resistance (1,0.40); /* piece 1 */

fall_pin_resistance (2,0.90); /* piece 2 */

}

pin ( QN ){

direction : output ;

function : "IQN" ;

timing (){

related_pin : "PRE" ;

timing_type : clear ;

timing_sense : negative_unate ;

intrinsic_fall : 1.87 ;

fall_delay_intercept (0,1.0); /* piece 0 */

fall_delay_intercept (1,0.0); /* piece 1 */

fall_delay_intercept (2,-1.0); /* piece 2 */

fall_pin_resistance (0,0.25); /* piece 0 */

fall_pin_resistance (1,0.50); /* piece 1 */

fall_pin_resistance (2,1.00); /* piece 2 */

}

timing (){

related_pin : "CLR" ;

timing_type : preset ;

timing_sense : positive_unate ;

intrinsic_rise : 0.68 ;

rise_delay_intercept (0,0.054); /* piece 0 */

rise_delay_intercept (1,0.0); /* piece 1 */

rise_delay_intercept (2,-0.062); /* piece 2 */

rise_pin_resistance (0,0.25); /* piece 0 */

Liberty User Guide Volume 1

R-2020.09

275

Chapter 7: Timing Arcs

Examples of NLDM Libraries

rise_pin_resistance(1,0.50); /* piece 1 */

rise_pin_resistance (2,1.00); /* piece 2 */

}

timing (){

related_pin : "CLK" ;

timing_type : rising_edge;

intrinsic_rise : 2.37 ;

intrinsic_fall : 2.51 ;

rise_pin_resistance (0,0.25); /* piece 0 */

rise_pin_resistance (1,0.50); /* piece 1 */

rise_pin_resistance (2,1.00); /* piece 2 */

fall_pin_resistance (0,0.15); /* piece 0 */

fall_pin_resistance (1,0.40); /* piece 1 */

fall_pin_resistance (2,0.90); /* piece 2 */

}

Library With Timing Constraints

In the nonlinear library description in Example 81, pin D contains setup and hold

constraints; pins Q and QN contain preset, clear, and edge-sensitive arcs.

Example 81 D Flip-Flop Description

library (NLDM){

date : "January 14, 2015";

revision : 2015.01;

delay_model : table_lookup;

technology (cmos);

/* Define template of size 2 x 2*/

lu_table_template(cell_template) {

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

index_1 ("0.0, 1.5");

index_2 ("0.0, 4.0");

}

/* Define one-dimensional lu_table of size 4 */

lu_table_template(tran_template) {

variable_1 : total_output_net_capacitance;

index_1 ("0.0, 0.5, 1.5, 2.0");

}

cell( DFLOP_CLR_PRE ) {

area : 11 ;

ff ( IQ , IQN ) {

clocked_on : " CLK ";

next_state : " D ";

clear : " CLR’ " ;

preset : " PRE’ " ;

clear_preset_var1 : L ;

clear_preset_var2 : L ;

Liberty User Guide Volume 1

R-2020.09

276

Chapter 7: Timing Arcs

Examples of NLDM Libraries

}

pin ( D ){

direction : input;

capacitance : 1 ;

timing () {

related_pin : "CLK" ;

timing_type : hold_rising;

rise_constraint(scalar) {

values("0.12");

}

fall_constraint(scalar) {

values("0.29");

}

timing (){

related_pin : "CLK" ;

timing_type : setup_rising ;

rise_constraint(scalar) {

values("2.93");

}

fall_constraint(scalar) {

values("2.14");

}

pin ( CLK ){

direction : input;

capacitance : 1 ;

}

pin ( PRE ) {

direction : input ;

capacitance : 2 ;

}

pin ( CLR ){

direction : input ;

capacitance : 2 ;

}

pin ( Q ) {

direction : output;

function : "IQ" ;

timing () {

related_pin : "PRE" ;

timing_type : preset ;

timing_sense : negative_unate ;

cell_rise(cell_template) {

values("0.00, 0.23", "0.11, 0.28");

}

rise_transition(tran_template) {

values("0.01, 0.12, 0.15, 0.40");

}

timing (){

Liberty User Guide Volume 1

R-2020.09

277

Chapter 7: Timing Arcs

Examples of NLDM Libraries

related_pin : "CLR" ;

timing_type : clear ;

timing_sense : positive_unate ;

cell_fall(cell_template) {

values("0.00, 0.24", "0.15, 0.26");

}

fall_transition(tran_template) {

values("0.03, 0.15, 0.18, 0.38");

}

timing (){

related_pin : "CLK" ;

timing_type : rising_edge;

cell_rise(cell_template) {

values("0.00, 0.25", "0.11, 0.28");

}

rise_transition(tran_template) {

values("0.01, 0.08, 0.15, 0.40");

}

cell_fall(cell_template) {

values("0.00, 0.33", "0.11, 0.38");

}

fall_transition(tran_template) {

values("0.01, 0.11, 0.18, 0.40");

}

pin ( QN ){

direction : output ;

function : "IQN" ;

timing (){

related_pin : "PRE" ;

timing_type : clear ;

timing_sense : positive_unate ;

cell_fall(cell_template) {

values("0.00, 0.23", "0.11, 0.28");

}

fall_transition(tran_template) {

values("0.01, 0.12, 0.15, 0.40");

}

timing (){

related_pin : "CLR" ;

timing_type : preset ;

timing_sense : negative_unate ;

cell_rise(cell_template) {

values("0.00, 0.23", "0.11, 0.28");

}

rise_transition(tran_template) {

values("0.01, 0.12, 0.15, 0.40");

}

timing (){

Liberty User Guide Volume 1

R-2020.09

278

Chapter 7: Timing Arcs

Examples of NLDM Libraries

related_pin : "CLK" ;

timing_type : rising_edge;

cell_rise(cell_template) {

values("0.00, 0.25", "0.11, 0.28");

}

rise_transition(tran_template) {

values("0.01, 0.08, 0.15, 0.40");

}

cell_fall(cell_template) {

values("0.00, 0.33", "0.11, 0.38");

}

fall_transition(tran_template) {

values("0.01, 0.11, 0.18, 0.40");

}

Library With Clock Insertion Delay

library( vendor_a ) {

delay_model :table_lookup;

/* 1. Define library-level one-dimensional lu_table of size 4 */

lu_table_template(lu_template) {

variable_1 :input_net_transition;

index_1 ("0.0, 0.5, 1.5, 2.0");

}

/* 2. Define a cell and pins within it which has clock tree path*/

cell (general) {

...

pin(clk) {

direction:input;

timing() {

timing_type :max_clock_tree_path;

timing_sense :positive_unate;

cell_rise(lu_template) {

values ("0.1, 0.15, 0.20, 0.29");

}

cell_fall(lu_template) {

values ("0.2, 0.25, 0.30, 0.39");

}

timing() {

timing_type :min_clock_tree_path;

timing_sense :positive_unate;

cell_rise(lu_template) {

values ("0.2, 0.35, 0.40, 0.59");

}

cell_fall(lu_template) {

values ("0.3, 0.45, 0.50, 0.69");

}

...

}

Liberty User Guide Volume 1

R-2020.09

279

Chapter 7: Timing Arcs

Describing a Transparent Latch Clock Model

The tlatch group lets you specify a functional latch when the latch arcs are absent. You

use the tlatch group at the data pin level to specify the relationship between the data pin

and the enable pin on a latch.

Figure 43 Transparent Latch Timing Model

Syntax

library (name

string

) {

cell (name

string

) {

...

timing_model_type : value

enum

;

...

pin (data_pin_name

string

) {

tlatch (enable_pin_name

string

){

edge_type : value

enum

;

tdisable : value

Boolean

;

}

The tlatch name specifies the enable pin that defines the latch clock pin. You

define the tlatch group in a pin group, but it is only effective if you also define the

timing_model_type attribute in the cell that the pin belongs to. The timing_model_type

attribute can have the following values: abstracted, extracted, and quick timing model.A

tlatch group is optional. You can define one or more tlatch groups for a pin, but you

must not define more than two tlatch groups between the same pair of data and enable

pins, one rising and one falling. Also, the data pin and the enable pin must be different.

Liberty User Guide Volume 1

R-2020.09

280

Chapter 7: Timing Arcs

Describing a Transparent Latch Clock Model

Pins in the tlatch group can be input or inout pins or internal pins. When a tlatch group

is not present, a timing analysis tool infers the latch clock pin based on the presence of:

•

A related_pin statement in a timing group with either a rising_edge or

falling_edge timing_type value within a latch output pin

•

A related_pin statement in a timing group with a setup, hold_rising, or falling

timing_type value within a latch input pin

The edge_type attribute defines whether the latch is positive (high) transparent or

negative (low) transparent. The rising and falling edge_type values specify the opening

edge, and therefore the transparent window of the latch, and completely define the latch to

be level-high transparent or level-low transparent.

When a tlatch group is not present, a timing analysis tool infers transparency on

an output pin based on the timing arc attribute and the presence of a latch functional

construct on that pin.

The rising and falling edge_type attribute values explicitly define the transparency

windows

•

When the rising_edge and falling_edge timing_type values are missing

•

When the rising_edge and falling_edge timing_type values are different from the

latch transparency

The tdisable attribute disables transparency in a latch. During path propagation, timing

analysis tools disable and ignore all data pin output pin arcs that reference a tlatch group

whose tdisable attribute is set to true on an edge triggered flip-flop.

Example

pin (D) {

tlatch (CP) {

edge_type : rising ;

tdisable : true ;

}

pin (Q) {

direction : output ;

timing () {

timing_)sense : positive_unate ;

related_pin : D ;

cell_rise ...

}

timing () {

/* optional arc that can differ from edge_type */

timing_type : falling_edge ;

related_pin : CP ;

cell_fall ...

}

Liberty User Guide Volume 1

R-2020.09

281

Chapter 7: Timing Arcs

Driver Waveform Support

}

Driver Waveform Support

In cell characterization, the shape of the waveform driving the characterized circuit can

have a significant impact on the final results. Typically, the waveform is generated by a

simple piecewise linear (PWL) waveform or an active-driver cell (a buffer or inverter).

Liberty supports driver waveform syntax, which specifies the type of waveform that is

applied to library cells during characterization. The driver waveform syntax helps facilitate

the characterization process for existing libraries and correlation checking. The driver

waveform requirements can vary.

Possible usage models include:

•

Using a common driver waveform for all cells.

•

Using a different driver waveform for different categories of cells.

• Using a pin-specific driver waveform for complex cell pins.

•

Using a different driver waveform for rise and fall timing arcs.

Syntax

The driver waveform syntax is as follows:

library(library_name) {

…

lu_table_template (waveform_template_name) {

variable_1: input_net_transition;

variable_2: normalized_voltage;

index_1 ("float…, float");

index_2 ("float…, float");

}

normalized_driver_waveform(waveform_template_name) {

driver_waveform_name : string; /* Specifies the name of the driver

waveform table */

index_1 ("float…, float"); /* Specifies input net transition */

index_2 ("float…, float"); /* Specifies normalized voltage */

values ( "float…, float", \ /* Specifies the time in library units */

…, \

"float…, float");

}

…

cell (cell_name) {

…

driver_waveform : string;

driver_waveform_rise : string;

driver_waveform_fall : string;

pin (pin_name) {

driver_waveform : string;

driver_waveform_rise : string;

driver_waveform_fall : string;

…

Liberty User Guide Volume 1

R-2020.09

282

Chapter 7: Timing Arcs

Driver Waveform Support

}

}/* end of library*/

In the driver waveform syntax, the first index value in the table specifies the input slew and

the second index value specifies the voltage normalized to VDD. The values in the table

specify the time in library units (not scaled) when the waveform crosses the corresponding

voltages. The driver_waveform_name attribute specified for the driver waveform table

differentiates the tables when multiple driver waveform tables are defined.

The cell-level driver_waveform, driver_waveform_rise and driver_waveform_fall

attributes meet cell-specific and rise- and fall-specific requirements. The attributes refer to

the driver waveform table name predefined at the library level.

Similar to the cell-level driver waveform attributes, the pin group includes the

driver_waveform, driver_waveform_rise and driver_waveform_fall attributes

to meet pin-specific predriver requirements for complex cell pins (such as macro cells).

These attributes also refer to the predefined driver waveform table name.

Library-Level Tables, Attributes, and Variables

This section describes driver waveform tables, attributes, and variables that are specified

at the library level.

normalized_voltage Variable

The normalized_voltage variable is specified under the lu_table_template table to

describe a collection of waveforms with various input slew values. For a given input slew

in index_1 (for example, index_1[0] = 1.0 ns), the index_2 values are a set of points that

represent how the voltage rises from 0 to VDD in a rise arc, or from VDD to 0 in a fall arc.

Rise Arc Example

normalized_driver_waveform (waveform_template) {

index_1 ("1.0"); /* Specifies the input net transition*/

index_2 ("0, 0.1, 0.3, 0.5, 0.7, 0.9, 1.0"); /* Specifies

the voltage normalized to VDD */

values ("0, 0.2, 0.4, 0.6, 0.8, 0.9, 1.1"); /* Specifies the

time when the voltage reaches the index_2 values*/

}

The lu_table_template table represents an input slew of 1.0 ns, when the voltage is 0%,

10%, 30%, 50%, 70%, 90% or 100% of VDD, and the time values are 0, 0.2, 0.4, 0.6, 0.8,

0.9, 1.1 (ns). The time value can go beyond the corresponding input slew because a long

tail might exist in the waveform before it reaches the final status.

Liberty User Guide Volume 1

R-2020.09

283

Chapter 7: Timing Arcs

Driver Waveform Support

normalized_driver_waveform Group

The library-level normalized_driver_waveform group represents a collection of driver

waveforms under various input slew values. The index_1 specifies the input slew and

index_2 specifies the normalized voltage.

The slew index in the normalized_driver_waveform table is based on the slew derate

and slew trip points of the library (global values). When applied on a pin or cell with

different slew or slew derate, the new slew should be interpreted from the waveform.

driver_waveform_name Attribute

The driver_waveform_name string attribute differentiates the driver waveform table from

other driver waveform tables when multiple tables are defined. Cell-specific, rise-specific,

and fall-specific driver waveform usage modeling depend on this attribute.

The driver_waveform_name attribute is optional. You can define a driver waveform table

without the attribute, but there can be only one table in a library, and that table is regarded

as the default driver waveform table for all cells in the library. If more than one table is

defined without the attribute, the last table is used. The other tables are ignored and not

stored in the library database.

Cell-Level Attributes

This section describes driver waveform attributes defined at the cell level.

driver_waveform Attribute

The driver_waveform attribute is an optional string attribute that allows you to define a

cell-specific driver waveform. The value must be the driver_waveform_name predefined

in the normalized_driver_waveform table.

When the attribute is defined, the cell uses the specified driver waveform during

characterization. When it is not specified, the common driver waveform (the

normalized_driver_waveform table without the driver_waveform_name attribute) is

used for the cell.

driver_waveform_rise and driver_waveform_fall Attributes

The driver_waveform_rise and driver_waveform_fall string attributes are similar

to the driver_waveform attribute. These two attributes allow you to define rise-specific

and fall-specific driver waveforms. The driver_waveform attribute can coexist with

the driver_waveform_rise and driver_waveform_fall attributes, though the

driver_waveform attribute becomes redundant.

Liberty User Guide Volume 1

R-2020.09

284

Chapter 7: Timing Arcs

Driver Waveform Support

You should specify a driver waveform for a cell by using the following priority:

1. Use the driver_waveform_rise for a rise arc and the driver_waveform_fall for

a fall arc during characterization. If they are not defined, specify the second and third

priority driver waveforms.

Use the cell-specific driver waveform (defined by the driver_waveform attribute).

3. Use the library-level default driver waveform (defined by the

normalized_driver_waveform table without the driver_waveform_name attribute).

The driver_waveform_rise attribute can refer to a normalized_driver_waveform

that is either rising or falling. You can invert the waveform automatically during runtime if

necessary.

Pin-Level Attributes

This section describes driver waveform attributes defined at the pin level.

driver_waveform Attribute

The driver_waveform attribute is the same as the driver_waveform attribute specified

at the cell level. For more information, see driver_waveform Attribute on page 284.

driver_waveform_rise and driver_waveform_fall Attributes

The driver_waveform_rise and driver_waveform_fall attributes are the same as the

driver_waveform_rise and driver_waveform_fall attributes specified at the cell level.

For more information, see driver_waveform_rise and driver_waveform_fall Attributes on

page 284.

Driver Waveform Example

library(test_library) {

lu_table_template(waveform_template) {

variable_1 : input_net_transition;

variable_2 : normalized_voltage;

index_1 ("0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7");

index_2 ("0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

}

/* Specifies the default library-level driver waveform table (the

default driver waveform without the driver_waveform attribute) */

normalized_driver_waveform (waveform_template) {

values ("0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.07, 0.08, 0.09", \

"0.11, 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19", \

… … …

"0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

Liberty User Guide Volume 1

R-2020.09

285

Chapter 7: Timing Arcs

Driver Waveform Support

}

/* Specifies the driver waveform for the clock pin */

normalized_driver_waveform (waveform_template) {

driver_waveform_name : clock_driver;

index_1 ("0.15, 0.25, 0.35, 0.45, 0.55, 0.65, 0.75");

index_2 ("0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

values ("0.012, 0.03, 0.045, 0.06, 0.075, 0.090, 0.105, 0.13,

0.145", \

… … …

"0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

}

/* Specifies the driver waveform for the bus */

normalized_driver_waveform (waveform_template) {

driver_waveform_name : bus_driver;

index_1 ("0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7");

index_2 ("0.15, 0.25, 0.35, 0.45, 0.55, 0.65, 0.75, 0.85, 0.95");

values ("0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.07, 0.08, 0.09", \

"0.11, 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19", \

… … …

"0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

}

/* Specifies the driver waveform for the rise */

normalized_driver_waveform (waveform_template) {

driver_waveform_name : rise_driver;

index_1 ("0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7");

index_2 ("0.15, 0.25, 0.35, 0.45, 0.55, 0.65, 0.75, 0.85, 0.95");

values ("0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.07, 0.08, 0.09", \

"0.11, 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19", \

… … …

"0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

}

/* Specifies the driver waveform for the fall */

normalized_driver_waveform (waveform_template) {

driver_waveform_name : fall_driver;

index_1 ("0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7");

index_2 ("0.15, 0.25, 0.35, 0.45, 0.55, 0.65, 0.75, 0.85, 0.95”);

values ("0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.07, 0.08, 0.09", \

"0.11, 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19", \

… … …

"0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

}

…

cell (my_cell1) {

driver_waveform : clock_driver;

…

}

cell (my_cell2) {

driver_waveform : bus_driver;

…

}

cell (my_cell3) {

driver_waveform_rise : rise_driver;

driver_waveform_fall : fall_driver;

Liberty User Guide Volume 1

R-2020.09

286

Chapter 7: Timing Arcs

Sensitization Support

…

}

cell (my_cell4) {

/* No driver_waveform attribute is specified. Use the default driver

waveform */

…

}

} /* End library */

Sensitization Support

Timing information specified in libraries results from circuit simulator (library

characterization) tools. The models themselves often represent only a partial record

of how a particular arc was sensitized during characterization. To fully reproduce the

conditions that allowed the model to be generated, the states of all the input pins on the

cell must be known.

In composite current source (CCS) models, the accuracy requirements are very high (the

expectation is as high as 2 percent compared to SPICE). To achieve this level of accuracy,

correlation with SPICE requires that the cell conditions be represented exactly as during

characterization. For more information about CCS models, see Chapter 10, Composite

Current Source Modeling.”

The following sections describe the pin sensitization condition information details used

to characterize the timing data. The syntax predeclares state vectors as reusable

sensitization patterns in the library. The patterns are referenced and instantiated as stimuli

waveforms specific to timing arcs. The same sensitization pattern can be referenced by

multiple cells or multiple timing arcs. One cell can also reference multiple sensitization

patterns, which saves storage resources. The Liberty attributes and groups highlighted

in the following sections help to specify the sensitization information of timing arcs during

simulation and characterization.

sensitization Group

The sensitization group defined at the library level describes the complete state

patterns for a specific list of pins (defined by the pin_names attribute) that is referenced

and instantiated as stimuli in the timing arc.

Vector attributes in the group define all possible pin states used as stimuli. Actual stimulus

waveforms can be described by a combination of these vectors. Multiple sensitization

groups are allowed in a library. Each sensitization group can be referenced by multiple

cells, and each cell can make reference to multiple sensitization groups.

The following attributes are library-level attributes under the sensitization group.

Liberty User Guide Volume 1

R-2020.09

287

Chapter 7: Timing Arcs

Sensitization Support

pin_names Attribute

The pin_names complex attribute defines a list of pin names. All vectors in this

sensitization group are the exhaustive list of all possible transitions of the input pins

and their subsequent output response.

The pin_names attribute is required, and it must be declared in the sensitization group

before all vector declarations.

vector Attribute

Similar to the pin_names attribute, the vector attribute describes a transition pattern for

the specified pins. The stimulus is described by an ordered list of vectors.

The two arguments for the vector attribute are as follows:

vector id

The vector id argument is an identifier to the vector string. The vector id

value must be an integer greater than or equal to zero and unique among all

vectors in the current sensitization group.

vector string

The vector string argument represents a pin transition state. The string

consists of the following transition status values: 0, 1, X, and Z where each

character is separated by a space. The number of elements in the vector string

must equal the number of arguments in pin_names.

The vector attribute can also be declared as:

vector (positive_integer, "[0|1|X|Z] [0|1|X|Z]…");

Example

sensitization(sensitization_nand2) {

pin_names ( IN1, IN2, OUT1 );

vector ( 1, "0 0 1" );

vector ( 2, "0 1 1" );

vector ( 3, "1 0 1" );

vector ( 4, "1 1 0" );

Cell-Level Attributes

Generally, one cell references one sensitization group for cells. A cell-level attribute

that can link the cell with a specific sensitization group helps to simplify sensitization

usage. The following cell-level attributes ensure that sensitization groups can be

referenced by cells with similar functionality but can have different pin names.

Liberty User Guide Volume 1

R-2020.09

288

Chapter 7: Timing Arcs

Sensitization Support

sensitization_master Attribute

The sensitization_master attribute defines the sensitization group referenced by the

cell to generate stimuli for characterization. The attribute is required if the cell contains

sensitization information. Its string value should be any sensitization group name

predefined in the current library.

pin_name_map Attribute

The pin_name_map attribute defines the pin names that are used to generate stimuli from

the sensitization group for all timing arcs in the cell. The pin_name_map attribute is

optional when the pin names in the cell are the same as the pin names in the sensitization

master, but it is required when they are different.

If the pin_name_map attribute is set, the number of pins must be the same as that in the

sensitization master, and all pin names should be legal pin names in the cell.

timing Group Attributes

This section describes the sensitization_master and pin_name_map timing-arc

attributes. These attributes enable a complex cell (a macro in most cases) to refer to

multiple sensitization groups. You can also specify a sampling vector and user-defined

time intervals between vectors. The wave_rise and wave_fall attributes, which describe

characterization stimuli (instantiated in pin timing arcs), are also discussed in this section.

sensitization_master Attribute

The sensitization_master simple attribute defines the sensitization group specific to

the current timing group to generate stimulus for characterization. The attribute is optional

when the sensitization master used for the timing arc is the same as that defined in the

current cell, and it is required when they are different. Any sensitization group name

predefined in the current library is a valid attribute value.

pin_name_map Attribute

Similar to the pin_name_map attribute defined in the cell level, the timing-arc

pin_name_map attribute defines pin names used to generate stimulus for the current timing

arc. The attribute is optional when pin_name_map pin names are the same as the following

(listed in order of priority):

Pin names in the sensitization_master of the current timing arc.

Pin names in the pin_name_map attribute of the current cell group.

3. Pin names in the sensitization_master of the current cell group.

The pin_name_map attribute is required when pin_name_map pin names are different from

all of the pin names in the previous list.

Liberty User Guide Volume 1

R-2020.09

289

Chapter 7: Timing Arcs

Sensitization Support

wave_rise and wave_fall Attributes

The wave_rise and wave_fall attributes represent the two stimuli used in

characterization. The value for both attributes is a list of integer values, and each value is

a vector ID predefined in the library sensitization group. The following example describes

the wave_rise and wave_fall attributes:

wave_rise (vector_id[m]…, vector_id[n]);

wave_fall (vector_id[j]…, vector_id[k]);

Example

library(my_library) {

…

sensitization(sensi_2in_1out) {

pin_names (IN1, IN2, OUT);

vector (0, "0 0 0");

vector (1, "0 0 1");

vector (2, "0 1 0");

vector (3, "0 1 1");

vector (4, "1 0 0");

vector (5, "1 0 1");

vector (6, "1 1 0");

vector (7, "1 1 1");

}

cell (my_nand2) {

sensitization_master : sensi_2in_1out;

pin_name_map (A, B, Z); /* these are pin names for the sensitization

in this cell. */

…

pin(A) {

…

}

Pin(B) {

…

}

pin(Z) {

…

timing() {

related_pin : "A";

wave_rise (6, 3);

/* 6, 3 - vector id in sensi_2in_1out sensitization group. Waveform

interpretation of wave_rise is (for "A, B, Z" pins): 10 1 01 */

wave_fall (3, 6);

…

}

timing() {

related_pin : "B";

wave_rise (7, 4); /* 7, 4 - vector id in sensi_2in_1out

sensitization group. */

wave_fall (4, 7);

Liberty User Guide Volume 1

R-2020.09

290

Chapter 7: Timing Arcs

Sensitization Support

…

}

} /* end pin(Z)*/

} /* end cell(my_nand2) */

…

} /* end library */

wave_rise_sampling_index and wave_fall_sampling_index

Attributes

The wave_rise_sampling_index and wave_fall_sampling_index simple attributes

override the default behavior of the wave_rise and wave_fall attributes. (The wave_rise

and wave_fall attributes select the first and the last vectors to define the sensitization

patterns of the input to the output pin transition that are predefined inside the sensitization

template specified at the library level).

Example

wave_rise (2, 5, 7, 6); /* wave_rise ( wave_rise[0],

wave_rise[1], wave_rise[2], wave_rise[3] );*/

In the previous example, the wave rise vector delay is measured from the last

transition (vector 7 changing to vector 6) to the output transition. The default

wave_rise_sampling_index value is the last entry in the vector, which is 3 in this case

(because the numbering begins at 0).

To override this default, set the wave_rise_sampling_index attribute, as shown:

wave_rise_sampling_index : 2 ;

When you specify this attribute, the delay is measured from the second last transition of

the sensitization vector to the final output transition, in other words from the transition of

vector 5 to vector 7.

Note:

You cannot specify a value of 0 for the wave_rise_sampling_index attribute.

wave_rise_time_interval and wave_fall_time_interval Attributes

The wave_rise_time_interval and wave_fall_time_interval attributes control the

time interval between transitions. By default, the stimuli (specified in wave_rise and

wave_fall) are widely spaced apart during characterization (for example, 10 ns from one

vector to the next) to allow all output transitions to stabilize. The attributes allow you to

specify a short duration between one vector to the next to characterize special purpose

cells and pessimistic timing characterization.

The wave_rise_time_interval and wave_fall_time_interval attributes are optional

when the default time interval is used for all transitions, and they are required when you

Liberty User Guide Volume 1

R-2020.09

291

Chapter 7: Timing Arcs

Sensitization Support

need to define special time intervals between transitions. Usually, the special time interval

is smaller than the default time interval.

The wave_rise_time_interval and wave_fall_time_interval attributes can have

an argument count from 1 to n-1, where n is the number of arguments in corresponding

wave_rise or wave_fall. Use 0 to imply the default time interval used between vectors.

Example

wave_rise (2, 5, 7, 6); /* wave_rise ( wave_rise[0],

wave_rise[1], wave_rise[2], wave_rise[3] );*/

wave_rise_time_interval (0.0, 0.3);

The previous example suggests the following:

•

Use the default time interval between wave_rise[0] and wave_rise[1] (in other

words, vector 2 and vector 5).

•

Use 0.3 between wave_rise[1] and wave_rise[2] (in other words, vector 5 and

vector 7).

•

Use the default time interval between wave_rise[2] and wave_rise[3] in other

words, vector 7 and vector 6).

timing Group Syntax

library(library_name) {

...

sensitization (sensitization_group_name) {

pin_names (string…, string);

vector (integer, string);

...

vector (integer, string);

}

...

cell(cell_name) {

sensitization_master : sensitization_group_name;

pin_name_map (string…, string);

...

pin(pin_name) {

...

timing() {

related_pin : string;

sensitization_master : sensitization_group_name;

pin_name_map (string,..., string);

wave_rise (integer,..., integer);

wave_fall (integer,..., integer);

wave_rise_sampling_index : integer;

wave_fall_sampling_index : integer;

Liberty User Guide Volume 1

R-2020.09

292

Chapter 7: Timing Arcs

Sensitization Support

wave_rise_timing_interval (float…, float);

wave_fall_timing_interval (float…, float);

...

}/*end of timing */

}/*end of pin */

}/*end of cell */

...

}/* end of library*/

NAND Cell Example

The following is an example of a NAND cell with sensitization information.

library(cell1) {

sensitization(sensitization_nand2) {

pin_names ( IN1, IN2, OUT1 );

vector ( 1, "0 0 1" );

vector ( 2, "0 1 1" );

vector ( 3, "1 0 1" );

vector ( 4, "1 1 0" );

}

cell (nand2) {

sensitization_master : sensitization_nand2;

pin_name_map (A, B, Y);

pin (A) {

direction : input ;

...

}

pin (B) {

direction : input ;

...

}

pin (Y) {

direction : output;

...

timing() {

related_pin : "A";

timing_sense : negative_unate;

wave_rise ( 4, 2 ); /* 10 1 01 */

wave_fall ( 2, 4 ); /* 01 1 10 */

...

}

timing() {

related_pin : "B";

timing_sense : negative_unate;

wave_rise ( 4, 3 );

wave_fall ( 3, 4 );

...

}

} /* end pin(Y) */

} /* end cell(nand2) */

Liberty User Guide Volume 1

R-2020.09

293

Chapter 7: Timing Arcs

Sensitization Support

} /* end library */

Complex Macro Cell Example

The following is an example of a complex macro cell highlighting the usage of the

sensitization_master group inside the timing group.

library(cell1) {

sensitization(sensitization_2in_1out) {

pin_names ( IN1, IN2, OUT );

vector ( 1, "0 0 1" );

vector ( 2, "0 1 1" );

vector ( 3, "1 0 1" );

vector ( 4, "1 1 0" );

}

sensitization(sensitization_3in_1out) {

pin_names ( IN1, IN2, IN3, OUT );

vector ( 0, "0 0 0 0" );

vector ( 1, "0 0 0 1" );

vector ( 2, "0 0 1 0" );

vector ( 3, "0 0 1 1" );

vector ( 4, "0 1 0 0" );

vector ( 5, "0 1 0 1" );

vector ( 6, "0 1 1 0" );

vector ( 7, "0 1 1 1" );

vector ( 8, "1 0 0 0" );

vector ( 9, "1 0 0 1" );

vector ( 10, "1 0 1 0" );

vector ( 11, "1 0 1 1" );

vector ( 12, "1 1 0 0" );

vector ( 13, "1 1 0 1" );

vector ( 14, "1 1 1 0" );

vector ( 15, "1 1 1 1" );

}

cell (nand2) {

sensitization_master : sensitization_2in_1out;

pin_name_map (A, B, Y);

pin (A) {

direction : input ;

...

}

pin (B) {

direction : input ;

...

}

pin (CIN0) {

direction : input ;

...

}

pin (CIN1) {

direction : input ;

...

Liberty User Guide Volume 1

R-2020.09

294

Chapter 7: Timing Arcs

Sensitization Support

}

pin (CK) {

direction : input;

...

}

pin (Y) {

direction : output;

...

timing() {

related_pin : "A";

/* inherit sensitization_master & pin_name_map from cell level */

timing_sense : negative_unate;

wave_rise ( 4, 2 );

wave_fall ( 2, 4 );

...

}

timing() {

related_pin : "B";

timing_sense : negative_unate;

wave_rise ( 4, 3 );

wave_fall ( 3, 4 );

...

}

} /* end pin(Y) */

pin (Z) {

direction : output;

...

timing () {

related_pin : "CK";

sensitization_master : sensitization_3in_1out; /* timing arc

specific sensitization master, overwrite the cell level attribute. */

pin_name_map (CIN0, CIN1, CK, Z); /* timing arc specific

pin_name_map, overwrite the cell level attribute. */

wave_rise (14, 4, 0, 3, 10, 5); /* the waveform describe here

has no real meaning, just select random vector id in sensitization

sensitization_3in_1out group. */

wave_fall (15, 9, 3, 1, 6, 7);

wave_rise_sampling_index : 3; /* sampling index, specific for

this timing arc. */

wave_fall_sampling_index : 3;

wave_rise_timing_interval(0, 0.3, 0.3); /* special timing

interval, specific for this timing arc. */

wave_fall_timing_interval(0, 0.3, 0.3);

}

} /* end pin (Z) */

} /* end cell(nand2) */

} /* end library */

Liberty User Guide Volume 1

R-2020.09

295

Chapter 7: Timing Arcs

Phase-Locked Loop Support

A phase-locked loop (PLL) is a feedback control system that automatically adjusts the

phase of a locally-generated signal to match the phase of an input signal. Phase-locked

loops contain the following pins:

•

The reference clock pin where the reference clock is connected

•

The phase-locked loop output clock pin where the phase-locked loop generates a

phase-shifted version of the reference clock

• The feedback pin where the feedback path from the output of the clock ends

A phase-locked loop reduces the large skew between the clocks arriving at the launch

point and at the flip-flops. The large skew results in an extremely tight delay constraint for

the combinational logic.

Figure 44 Phase-Locked Loop Circuit

The phase-locked loop generates a phase-shifted version of the reference clock at the

output pin so that the phase of the feedback clock matches the phase of the reference

clock.

In Figure 44, if the clock arrives at the reference pin of the phase-locked loop at the time,

D_clock, and the delay of the feedback path is D_feedback, the source latency of the

clock generated at the output of the phase-locked loop is D_clock - D_feedback. The

clock arrives at the feedback pin at time, D_clock, which is the same as the time the clock

arrives at the reference pin. Therefore, the phase-locked loop eliminates the latency on the

launch path and relaxes the delay constraint on the combinational logic.

The phase-locked loop information that a library must contain are pins and timing

arcs inside the phase-locked loop. In Figure 45, the forward arcs from REF_CLK to

PLL_OUT_CLK_* in the figure simulate the phase shift behavior of the phase-locked loop.

Liberty User Guide Volume 1

R-2020.09

296

Chapter 7: Timing Arcs

Phase-Locked Loop Support

There are two half-unate arcs from the reference clock to each output of the phase-locked

loop.

Figure 45 Simple Phase-Locked Loop Model

Phase-Locked Loop Syntax

cell (cell_name) {

is_pll_cell : true;

pin (ref_pin_name) {

is_pll_reference_pin : true;

direction : output;

...

}

pin (feedback_pin_name) {

is_pll_feedback_pin : true;

direction : output;

...

}

pin (output_pin_name) {

is_pll_output_pin : true;

direction : output;

...

}

Cell-Level Attribute

This section describes a cell-level attribute.

is_pll_cell Attribute

The is_pll_cell Boolean attribute identifies a phase-locked loop cell.

Pin-Level Attributes

This section describes pin-level attributes.

Liberty User Guide Volume 1

R-2020.09

297

Chapter 7: Timing Arcs

Phase-Locked Loop Support

is_pll_reference_pin Attribute

The is_pll_reference_pin Boolean attribute tags a pin as a reference pin on the phase-

locked loop. In a phase-locked loop cell group, the is_pll_reference_pin attribute

should be set to true in only one input pin group.

is_pll_feedback_pin Attribute

The is_pll_feedback_pin Boolean attribute tags a pin as a feedback pin on a phase-

locked loop. In a phase-locked loop cell group, the is_pll_feedback_pin attribute should

be set to true in only one input pin group.

is_pll_output_pin Attribute

The is_pll_output_pin Boolean attribute tags a pin as an output pin on a phase-locked

loop. In a phase-locked loop cell group, the is_pll_output_pin attribute should be set to

true in one or more output pin groups.

Phase-Locked Loop Example

cell(my_pll) {

is_pll_cell : true;

pin( REFCLK ) {

direction : input;

is_pll_reference_pin : true;

}

pin( FBKCLK ) {

direction : input;

is_pll_feedback_pin : true;

}

pin (OUTCLK_1x) {

direction : output;

is_pll_output_pin : true;

timing() {/* Timing Arc */

related_pin: "REFCLK";

timing_type: combinational_rise;

timing_sense: positive_unate;

. . .

}

timing() {/* Timing Arc */

related_pin: "REFCLK";

timing_type: combinational_fall;

timing_sense: positive_unate;

. . .

}

Liberty User Guide Volume 1

R-2020.09

298

Chapter 7: Timing Arcs

Phase-Locked Loop Support

pin (OUTCLK_2x) {

direction : output;

is_pll_output_pin : true;

timing() {/* Timing Arc */

related_pin: "REFCLK";

timing_type: combinational_rise;

timing_sense: positive_unate;

. . .

}

timing() {/* Timing Arc */

related_pin: "REFCLK";

timing_type: combinational_fall;

timing_sense: positive_unate;

. . .

}

} /* End pin group */

} /* End cell group */

Liberty User Guide Volume 1

R-2020.09

299

Modeling Power and Electromigration

This chapter provides an overview of modeling static and dynamic power for CMOS

technology.

To model CMOS static and dynamic power, you must understand the topics covered in the

following sections:

• Modeling Power Terminology

• Switching Activity

• Modeling for Leakage Power

• Representing Leakage Power Information

• Threshold Voltage Modeling

• Modeling for Internal and Switching Power

• Representing Internal Power Information

• Defining Internal Power Groups

• Modeling Libraries With Integrated Clock-Gating Cells

• Modeling Electromigration

Modeling Power Terminology

The power a circuit dissipates falls into two broad categories:

• Static power

•

Dynamic power

Static Power

Static power is the power dissipated by a gate when it is not switching—that is, when it is

inactive or static.

Liberty User Guide Volume 1

R-2020.09

300

Chapter 8: Modeling Power and Electromigration

Modeling Power Terminology

Static power is dissipated in several ways. The largest percentage of static power results

from source-to-drain subthreshold leakage. This leakage is caused by reduced threshold

voltages that prevent the gate from turning off completely. Static power also results when

current leaks between the diffusion layers and substrate. For this reason, static power is

often called leakage power.

Dynamic Power

Dynamic power is the power dissipated when a circuit is active. A circuit is active anytime

the voltage on a net changes due to some stimulus applied to the circuit. Because voltage

on a net can change without necessarily resulting in a logic transition, dynamic power can

result even when a net does not change its logic state.

The dynamic power of a circuit is composed of

•

Internal power

•

Switching power

Internal Power

During switching, a circuit dissipates internal power by the charging or discharging of any

existing capacitances internal to the cell. The definition of internal power includes power

dissipated by a momentary short circuit between the P and N transistors of a gate, called

short-circuit power.

Figure 46 shows the cause of short-circuit power. In this figure, there is a slow rising signal

at the gate input IN. As the signal makes a transition from low to high, the N-type transistor

turns on and the P-type transistor turns off. However, during signal transition, both the P-

and N-type transistors can be on simultaneously for a short time. During this time, current

flows from VDD to GND, resulting in short-circuit power.

Liberty User Guide Volume 1

R-2020.09

301

Chapter 8: Modeling Power and Electromigration

Modeling Power Terminology

Figure 46 Components of Power Dissipation

Short-circuit power varies according to the circuit. For circuits with fast transition times, the

amount of short-circuit power can be small. For circuits with slow transition times, short-

circuit power can account for up to 30 percent of the total power dissipated. Short-circuit

power is also affected by the dimensions of the transistors and the load capacitance at the

output of the gate.

In most simple library cells, internal power is due primarily to short-circuit power. For

this reason, the terms internal power and short-circuit power are often considered

synonymous.

Note:

A transition implies either a rising or a falling signal; therefore, if the power

characterization involves running a full-cycle simulation, which includes

both rising and falling signals, then you must average the energy dissipation

measurement by dividing by 2.

Switching Power

The switching power, or capacitance power, of a driving cell is the power dissipated by the

charging and discharging of the load capacitance at the output of the cell. The total load

capacitance at the output of a driving cell is the sum of the net and gate capacitances on

the driver.

Liberty User Guide Volume 1

R-2020.09

302

Chapter 8: Modeling Power and Electromigration

Switching Activity

where is the toggle-rate activity. This equation is applied to each net in the design.

Because such charging and discharging is the result of the logic transitions at the output of

the cell, switching power increases as logic transitions increase. The switching power of a

cell is the function of both the total load capacitance at the cell output and the rate of logic

transitions.

Figure 46 shows how the capacitance (Cload) is charged and discharged as the N or P

transistor turns on. Switching power accounts for 70 to 90 percent of the power dissipation

of an active CMOS circuit.

Note:

Two measures of power dissipation are useful to designers: average power

and peak power. Average power is the power dissipated by a circuit over

a representative set of input stimuli. Peak power is the maximum power

dissipated by a circuit over all the input stimuli. Peak power is normally

associated with a particular stimulus.

Switching Activity

Switching activity is a metric used to measure the number of transitions (0-to-1 and 1-to-0)

for every net in a circuit when input stimuli are applied. Switching activity is the average

activity of the circuit with a set of input stimuli.

A circuit with higher switching activity is likely to dissipate more power than a circuit with

lower switching activity.

For more information about switching activity and power consumption, see the Power

Compiler User Guide.

Modeling for Leakage Power

Regardless of the physical reasons for leakage power, library developers can annotate

gates with the approximate total leakage power dissipated by the gate.

Leakage power characterization requires measuring the supply current ( ) of the

quiescent state of the cell. This requires a DC analysis of the circuit with steady-state

voltages at the inputs to the cell.

Vendors can characterize leakage power of multiple combinations of input states to

generate state-dependent leakage power models. This is especially important when

leakage power dissipation varies greatly from one state to another and requires iterating

Liberty User Guide Volume 1

R-2020.09

303

Chapter 8: Modeling Power and Electromigration

Representing Leakage Power Information

across all possible inputs and measuring the supply current for each vector. For each

vector or state, leakage power can be computed as

Alternatively, leakage power can also be characterized with two simulation runs: one

for output high and one for output low. The average of these two measurements is then

used as the cell’s leakage power. This method reduces the characterization effort at the

expense of accuracy.

Representing Leakage Power Information

You can represent leakage power information in the library as:

• Cell-level state-independent leakage power with the cell_leakage_power attribute

•

Cell-level state-dependent leakage power with the leakage_power group

• The associated library-level attributes that specify scaling factors, units, and a default

for both leakage and power density

cell_leakage_power Simple Attribute

This attribute specifies the leakage power of a cell. If this attribute is missing or negative,

the value of the default_cell_leakage_power attribute is used.

Syntax

cell_leakage_power : value ;

Note:

You must define this attribute for cells with state-dependent leakage power

to provide the leakage power value for those states where the state-specific

leakage power has not been specified using the leakage_power group.

Using the leakage_power Group for a Single Value

This group specifies the leakage power of a cell when the leakage power depends on

the logical condition of that cell. This type of leakage power is called state-dependent. To

model state-dependent leakage power, use the following attributes:

•

when

•

value

Liberty User Guide Volume 1

R-2020.09

304

Chapter 8: Modeling Power and Electromigration

Representing Leakage Power Information

Syntax

leakage_power ( ) {

mode (mode_name, mode_value);

when : "Boolean expression";

value: float;

}

when Simple Attribute

This attribute specifies the state-dependent condition that determines whether the leakage

power is accessed.

Syntax

when : "Boolean expression";

Boolean expression

The name or names of pins, buses, and bundles with their corresponding

Boolean operators.

Table 21 Valid Boolean Operators

Operator Description

’ invert previous expression

! invert following expression

^ logical XOR

* logical AND

& logical AND

space logical AND

+ logical OR

| logical OR

1 signal tied to logic 1

0 signal tied to logic 0

The order of precedence of the operators is left to right, with inversion performed first, then

XOR, then AND, then OR.

Liberty User Guide Volume 1

R-2020.09

305

Chapter 8: Modeling Power and Electromigration

Representing Leakage Power Information

You must define mutually exclusive conditions for state-dependent leakage power and

internal power. Mutually exclusive means that only one condition defined in the when

attribute can be met at any given time.

You cannot directly reference a bus or a bundle in the when attribute in the leakage_power

group. However, you can reference the pins of buses and bundles in the when attribute in

the leakage_power group, as shown here:

Example

cell(Z) {

...

cell_leakage_power : 3.0 ;

leakage_power () {

when : " !A[0] * !A[1] * !A[2] * !A[3] " ;

value : 2.0 ;

}

bus(A) {

bus_type : bus4 ;

direction : input ;

fanout_load : 1.00 ;

capacitance : 0.15

...

}

value Simple Attribute

The value attribute represents the leakage power for a given state of a cell. The value for

this attribute is a floating-point number.

Example

cell (my cell) {

...

leakage_power () {

when : "! A";

value : 2.0;

}

cell_leakage_power : 3.0;

}

leakage_power_unit Simple Attribute

This attribute indicates the units of the leakage-power values in the library.

Liberty User Guide Volume 1

R-2020.09

306

Chapter 8: Modeling Power and Electromigration

Representing Leakage Power Information

Table 22 Valid Unit Values and

Mathematical Equivalents

Text entry Mathematical

equivalent

1mW 1mW

100uW 100 micro W

10uW 10 micro W

1uW 1 micro W

100nW 100nW

10nW 10nW

1nW 1nW

100pW 100pW

10pW 10pW

1pW 1pW

Example

leakage_power_unit : 100uW;

default_cell_leakage_power Simple Attribute

The default_cell_leakage_power attribute indicates the default leakage power for

those cells for which you have not set the cell_leakage_power attribute. This attribute

must be a nonnegative floating-point number. The default is 0.0.

Example

default_cell_leakage_power : 0.5;

if the library has cell_leakage_power information but does not have the

default_cell_leakage_power attribute defined.

Example

library(leakage) {

delay_model : table_lookup;

Liberty User Guide Volume 1

R-2020.09

307

Chapter 8: Modeling Power and Electromigration

Representing Leakage Power Information

/* unit attributes */

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1mA";

pulling_resistance_unit : "1kohm";

leakage_power_unit : "1pW";

capacitive_load_unit (1.0,pf);

cell (NAND2) {

cell_leakage_power : 1.0 ;

leakage_power() {

related_pg_pin : "VDD1";

when : "!A1 !A2" ;

value : 1.5 ;

}

leakage_power() {

related_pg_pin : "VDD1";

when : "!A1 A2" ;

value : 2.0 ;

}

leakage_power() {

related_pg_pin : "VDD1";

when : "A1 !A2" ;

value : 3.0 ;

}

leakage_power() {

related_pg_pin : "VDD1";

when : "A1 A2" ;

value : 4.0 ;

}

leakage_power() {

related_pg_pin : "VDD2";

when : "!A1 !A2" ;

value : 3.5 ;

}

leakage_power() {

related_pg_pin : "VDD2";

when : "!A1 A2" ;

value : 3.0 ;

}

leakage_power() {

related_pg_pin : "VDD2";

when : "A1 !A2" ;

value : 4.0 ;

}

leakage_power() {

related_pg_pin : "VDD2";

when : "A1 A2" ;

value : 5.0 ;

}

area : 1.0 ;

pin(A1) {

Liberty User Guide Volume 1

R-2020.09

308

Chapter 8: Modeling Power and Electromigration

Representing Leakage Power Information

direction : input;

capacitance : 0.1 ;

}

pin(A2) {

direction : input;

capacitance : 0.1 ;

}

pin(ZN) {

direction : output;

max_capacitance : 0.1;

function : "(A1*A2)’";

timing() {

timing_sense : "negative_unate"

related_pin : "A1"

cell_rise( scalar ) {

values("0.0");

}

rise_transition( scalar ) {

values("0.0");

}

cell_fall( scalar ) {

values("0.0");

}

fall_transition( scalar ) {

values("0.0"); }

}

internal_power() {

related_pin : " A1 "

related_pg_pin : "VDD1";

rise_power( scalar ) {

values("0.0");

}

fall_power( scalar ) {

values("0.0");

}

} /* end of internal power */

internal_power() {

related_pin : " A1 "

related_pg_pin : "VDD2";

rise_power( scalar ) {

values("0.0");

}

fall_power( scalar ) {

values("0.0");

}

}/* end of internal power */

} /* end of timing for related pin A1 */

timing() {

timing_sense : "negative_unate"

related_pin : "A2"

cell_rise( scalar ) {

values("0.0");

}

Liberty User Guide Volume 1

R-2020.09

309

Chapter 8: Modeling Power and Electromigration

Threshold Voltage Modeling

rise_transition( scalar ) {

values("0.0");

}

cell_fall( scalar ) {

values("0.0");

}

fall_transition( scalar ) {

values("0.0");

}

internal_power() {

related_pin : " A2 "

related_pg_pin : "VDD1";

rise_power( scalar ) {

values("0.0");

}

fall_power( scalar ) {

values("0.0");

}

}/* end of internal power */

internal_power() {

related_pin : " A2 "

related_pg_pin : "VDD2";

rise_power( scalar ) {

values("0.0");

}

fall_power( scalar ) {

values("0.0");

}

} /* end of internal power */

} /* end of timing for related pin A2 */

} /* end of pin ZN */

} /* end of cell */

} /* end of library */

Threshold Voltage Modeling

Multiple threshold power saving flows require library cells to be categorized according to

the transistor’s threshold voltage characteristics, such as high threshold voltage cells and

low threshold voltage cells. High threshold voltage cells exhibit lower power leakage but

run slower than low threshold voltage cells.

Liberty User Guide Volume 1

R-2020.09

310

Chapter 8: Modeling Power and Electromigration

Threshold Voltage Modeling

You can specify low threshold voltage cells and high threshold voltage cells in the

same library, simplifying library management and setup, by using the following optional

attributes:

•

default_threshold_voltage_group

Specify the default_threshold_voltage_group attribute at the library level, as

shown, to specify a cell’s category based on its threshold voltage characteristics:

default_threshold_voltage_group : group_nameid ;

The group_name value is a string representing the name of the category, such as

high_vt_cell to represent a high voltage cell.

•

threshold_voltage_group

Specify the threshold_voltage_group attribute at the cell level, as shown, to specify

a cell’s category based on its threshold voltage characteristics:

threshold_voltage_group : group_nameid ;

The group_name value is a string representing the name of the category. Typically, you

would specify a pair of threshold_voltage_group attributes, one representing the

high voltage and one representing the low voltage. However, there is no limit to the

number of threshold_voltage_group attributes you can have in a library. If you omit

this attribute, the value of the default_threshold_voltage_group attribute is applied

to the cell.

Example

library ( mixed_vt_lib ) {

...

default_threshold_voltage_group : "high_vt_cell" ;

...

cell(ht_cell) {

threshold_voltage_group : "high_vt_cell" ;

...

}

cell(lt_cell) {

threshold_voltage_group : "low_vt_cell" ;

...

}

Liberty User Guide Volume 1

R-2020.09

311

Chapter 8: Modeling Power and Electromigration

Modeling for Internal and Switching Power

These are two compatible definitions of internal or short-circuit power:

• Short-circuit power is the power dissipated by the instantaneous short-circuit

connection between Vdd and GND while the gate is in transition.

•

Internal power is all the power dissipated within the boundary of the gate. This

definition does not distinguish between the cell’s short-circuit power and the component

of switching power that is being dissipated internally to the cell as a result of the drain-

to-substrate capacitance that is being charged and discharged. In this definition,

the interconnect switching power is the power dissipated because of lumped wire

capacitance and input pin capacitances but not because of the output pin capacitance.

Library developers must choose one of these definitions and specify internal power and

capacitance numbers accordingly. Library developers can choose

•

To include the effect of the output capacitance in the internal_power attribute, which

gives the output pins zero capacitance

•

To give the output pins a real capacitance, which causes them to be included in the

switching power, and model only short-circuit power as the cell’s internal power

Together, internal power and switching power contribute to the total dynamic power

dissipation. Like switching power, internal power is dissipated whenever an output pin

makes a transition.

Some power is also dissipated as a result of internal transitions that do not cause output

transitions. However, those are relatively minor in comparison (they consume much less

power) and should be ignored.

Liberty User Guide Volume 1

R-2020.09

312

Chapter 8: Modeling Power and Electromigration

Modeling for Internal and Switching Power

Figure 47 Input Transitions Not Resulting in Output Transitions

In Figure 47 Case 1, input B of the AND2 gate undergoes a 0-to-1 transition but the

output remains stable at 0. This might consume a small amount of power as one of the N-

transistors opens, but the current flow is very small.

In Figure 47 Case 2, input D of the multilevel gate AO22 undergoes a 1-to-0 transition,

causing a 1-to-0 transition at internal pin Y. However, output Z remains stable at 1. The

significance of the power dissipation in this case depends on the load of the internal wire

connected to Y. In Case 1, power dissipation is negligible, but in Case 2, power dissipation

might result in some inaccuracy.

You can set the internal_power group attribute so that multiple input or output pins that

share logic can transition together within the same time period.

Pins transitioning within the same time period can lower the level of power consumption.

Modeling Internal Power Lookup Tables

You should measure the energy dissipated by varying either input voltage transition or

output load while holding the other constant. Because a table indexed by T input transition

times and C output load capacitances has TxC entries, the cell’s internal power must

be characterized TxC times, one time for each input transition time and output load

capacitance combination. For example, if internal power is modeled by use of a 3x3

table at the output of the cell, the design has 9 input voltage transitions—output load

combinations where energy dissipation must be measured.

Liberty User Guide Volume 1

R-2020.09

313

Chapter 8: Modeling Power and Electromigration

Modeling for Internal and Switching Power

The library group supports a one-, two-, or three-dimensional internal power lookup

table indexed by the total output load capacitances (best model), the input transition time,

or both. The internal power lookup table uses the same syntax as the nonlinear lookup

table for delay.

You can set the internal_power attributes for input pins, which are indexed by input

transition time. In this way, you can model gate AO22 in figure in Modeling for Internal and

Switching Power or, more important, the power consumed by the flip-flop clock or reset

pins.

Note:

The input pin power is added to the output pin power. When you model the

library, avoid double counting.

Figure 48 shows how to calculate the input pin power information for the one-dimensional

lookup table describing internal cell U1.

Figure 48 Internal Power for Cell U1

To calculate the internal power for cell U1, use the following equation:

Int

Total internal power for the cell.

Internal energy for the pin.

Liberty User Guide Volume 1

R-2020.09

314

Chapter 8: Modeling Power and Electromigration

Representing Internal Power Information

Activity factor.

Accurate sequential modeling requires a separate table for the clock and for the output

pin the clock controls. The two tables are used to ensure that clock pin power and output

power are accounted for separately, because a clock pin often toggles without causing any

observable state change on the output pin. The separate power table scheme ensures that

power dissipated within the cell is accounted for properly when the clock pin toggles but

the output pin does not. The following discussion pertains to single-output, single-clock

sequential cells, but the concept is also extendable to multioutput, multiclock cells.

Figure is an example of the two-dimensional lookup table for modeling output pin power in

a cell.

Figure 49 Internal Power Table for Cell Output

Representing Internal Power Information

You can describe power dissipation in your libraries by using lookup tables.

Specifying the Power Model

Use the library level power_model attribute to specify the power model for your library. The

valid value is table_lookup. .

Liberty User Guide Volume 1

R-2020.09

315

Chapter 8: Modeling Power and Electromigration

Representing Internal Power Information

Using Lookup Table Templates

To represent internal power, you can create templates of common information that multiple

lookup tables can use. Use the following groups and attributes to define your lookup

tables:

•

The library-level power_lut_template group

•

The internal_power group (see Defining Internal Power Groups on page 318)

• The associated library-level attributes that specify the scaling factors and a default

power_lut_template Group

Use this library-level group to create templates of common information that multiple lookup

tables can use. A table template specifies the table parameters and the breakpoints for

each axis. Assign each template a name. Make the template name the group name of a

fall_power group, power group, or rise_power group in the internal_power group.

Syntax

power_lut_template(name) {

variable_1 : string ;

variable_2 : string ;

variable_3 : string ;

index_1("float, ... , float") ;

index_2("float, ... , float") ;

index_3("float, ... , float") ;

}

Template Variables

The lookup table template for specifying power uses three associated variables to

characterize cells in the library for internal power:

•

variable_1, which specifies the first dimensional variable

•

variable_2, which specifies the second dimensional variable

• variable_3, which specifies the third dimensional variable

These variables indicate the parameters used to index into the lookup table along the first,

second, and third table axes.

Following are valid values for variable_1, variable_2, and variable_3:

total_output_net_capacitance

The loading of the output net capacitance of the pin specified in the pin group

that contains the internal_power group.

Liberty User Guide Volume 1

R-2020.09

316

Chapter 8: Modeling Power and Electromigration

Representing Internal Power Information

equal_or_opposite_output_net_capacitance

The loading of the output net capacitance of the pin specified in the

equal_or_opposite_output attribute in the internal_power group.

input_transition_time

The input transition time of the pin specified in the related_pin attribute in the

internal_power group.

For information about the related_pin attribute, see Defining Internal Power Groups on

page 318.

Template Breakpoints

The index statements define the breakpoints for an axis. The breakpoints defined by

index_1 correspond to the parameter values indicated by variable_1. The breakpoints

defined by index_2 correspond to the parameter values indicated by variable_2.

The breakpoints defined by index_3 correspond to the parameter values indicated by

variable_3.

You can overwrite the index_1, index_2, and index_3 attribute values by providing the

same index_x attributes in the fall_power group, power group, or rise_power group in

the internal_power group.

The index values are lists of floating-point numbers greater than or equal to 0.0. The

values in the list must be in an increasing order.

The number of floating-point numbers in the indexes determines the size of each

dimension, as Example 82 illustrates.

For each power_lut_template group, you must define at least one variable_1 and one

index_1.

Example 82 power_lut_template Groups With One, Two, and Three-Dimensional Templates

power_lut_template (output_by_cap) {

variable_1 : total_output_net_capacitance ;

index_1 ("0.0, 5.0, 20.0") ;

}

power_lut_template (output_by_cap_and_trans) {

variable_1 : total_output_net_capacitance ;

variable_2 : input_transition_time ;

index_1 ("0.0, 5.0, 20.0") ;

index_2 ("0.1, 1.0, 5.0") ;

}

power_lut_template (input_by_trans) {

variable_1 : input_transition_time ;

index_1 ("0.0, 1.0, 5.0") ;

}

Liberty User Guide Volume 1

R-2020.09

317

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

power_lut_template (output_by_cap2_and_trans) {

variable_1 : total_output_net_capacitance ;

variable_2 : input_transition_time ;

variable_3 : equal_or_output_net_capacitance ;

index_1 ("0.0, 5.0, 20.0") ;

index_2 ("0.1, 1.0, 5.0") ;

index_3 ("0.1, 0.5, 1.0") ;

}

Scalar power_lut_template Group

Use this group to model cells with no power consumption.

The syntax has a predefined template named scalar; its value size is 1. You can specify

scalar as the group name of a fall_power group, power group, or rise_power group in

the internal_power group.

Defining Internal Power Groups

To specify the cell’s internal power consumption, use the internal_power group within

the pin group in the cell.

If the internal_power group is not present in a cell, it is assumed that the cell does not

consume any internal power. You can define the optional complex attribute index_1,

index_2, or index_3 in this group to overwrite the index_1, index_2, or index_3 attribute

defined in the library-level power_lut_template to which it refers.

Naming Power Relationships, Using the internal_power Group

Within the internal_power group you can identify the name or names of different power

relationships. A single power relationship can occur between an identified pin and a single

related pin identified with the related_pin attribute. Multiple power relationships can

occur in many ways.

This list shows seven possible multiple power relationships. These relationships are

described in more detail in the following sections:

•

Between a single pin and a single related pin

•

Between a single pin and multiple related pins

• Between a bundle and a single related pin

•

Between a bundle and multiple related pins

•

Between a bus and a single related pin

Liberty User Guide Volume 1

R-2020.09

318

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

• Between a bus and multiple related pins

• Between a bus and related bus pins

Power Relationship Between a Single Pin and a Single Related Pin

Identify the power relationship that occurs between a single pin and a single related pin

by entering a name in the internal_power group attribute as shown in the following

example:

Example

cell (my_inverter) {

...

pin (A) {

direction : input;

capacitance : 1;

}

pin (B) {

direction : output

function : "A’";

internal_power (A_B) {

related_pin : "A";

...

}/* end internal_power() */

}/* end pin B */

}/* end cell */

The power relationship is as follows:

From pin To pin Label

A B A_B

Power Relationships Between a Single Pin and Multiple Related

Pins

This section describes how to identify the power relationships when an internal_power

group is within a pin group and the power relationship has more than a single related

pin. You identify the multiple power relationships on a name list entered with the

internal_power group attribute as shown in the following example:

Example

cell (my_and) {

...

pin (A) {

direction : input;

capacitance : 1;

}

Liberty User Guide Volume 1

R-2020.09

319

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

pin (B) {

direction : input;

capacitance : 2;

}

pin (C) {

direction : output

function : "A B";

internal_power (A_C, B_C) {

related_pin : "A B";

...

}/* end internal_power() */

}/* end pin B */

}/* end cell */

The power relationships are as follows:

From pin To pin Label

A C A_C

B C B_C

Power Relationships Between a Bundle and a Single Related Pin

When the internal_power group is within a bundle group that has several members that

have a single related pin, enter the names of the resulting multiple power relationships in a

name list in the internal_power group.

Example

...

bundle (Q){

members (Q0, Q1, Q2, Q3);

direction : output;

function : "IQ";

internal_power (G_Q0, G_Q1, G_Q2, G_Q3) {

related_pin : "G";

}

If G is a pin, as opposed to another bundle group, the power relationships are as follows:

From pin To pin Label

G Q0 G_Q0

G Q1 G_Q1

G Q2 G_Q2

Liberty User Guide Volume 1

R-2020.09

320

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

G Q3 G_Q3

If G is another bundle of member size 4 and G0, G1, G2, and G3 are members of bundle

G, the power relationships are as follows:

From pin To pin Label

G0 Q0 G_Q0

G1 Q1 G_Q1

G2 Q2 G_Q2

G3 Q3 G_Q3

Note:

If G is a bundle of a member size other than 4, it is an error due to incompatible

width.

Power Relationships Between a Bundle and Multiple Related Pins

When the internal_power group is within a bundle group that has several members,

each having a corresponding related pin, enter the names of the resulting multiple power

relationships as a name list in the internal_power group.

Example

bundle (Q){

members (Q0, Q1, Q2, Q3);

direction : output;

function : "IQ";

internal_power (G_Q0, H_Q0, G_Q1, H_Q1, G_Q2, H_Q2, G_Q3, H_Q3) {

related_pin : "G H";

}

If G is a pin, as opposed to another bundle group, the power relationships are as follows:

From pin To pin Label

G Q0 G_Q0

H Q0 H_Q0

G Q1 G_Q1

From pin To pin Label

Liberty User Guide Volume 1

R-2020.09

321

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

H Q1 H_Q1

G Q2 G_Q2

H Q2 H_Q2

G Q3 G_Q3

H Q3 H_Q3

If G is another bundle of member size 4 and G0, G1, G2, and G3 are members of bundle

G, the power relationships are as follows:

From pin To pin Label

G0 Q0 G_Q0

H Q0 H_Q0

G1 Q1 G_Q1

H Q1 H_Q1

G2 Q2 G_Q2

H Q2 H_Q2

G3 Q3 G_Q3

H Q3 H_Q3

The same rule applies if H is a size 4 bundle.

Note:

If G is a bundle of a member size other than 4, it’s an error due to incompatible

width.

Power Relationships Between a Bus and a Single Related Pin

This section describes how to identify the power relationships created when an

internal_power group is within a bus group that has several bits that have the same

single related pin. You identify the resulting multiple power relationships by entering a

name list, using the internal_power group attribute.

Example

...

bus (X){

Liberty User Guide Volume 1

R-2020.09

322

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

/*assuming MSB is X[0] */

bus_type : bus4;

direction : output;

capacitance : 1;

pin (X[0:3]){

function : "B’";

internal_power (B_X0, B_X1, B_X2, B_X3){

related_pin : "B";

}

If B is a pin, as opposed to another 4-bit bus, the power relationships are as follows:

From pin To pin Label

B X[0] B_X0

B X[1] B_X1

B X[2] B_X2

B X[3] B_X3

If B is another 4-bit bus and B[0] is the MSB for bus B, the power relationships are as

follows:

From pin To pin Label

B[0] X[0] B_X0

B[1] X[1] B_X1

B[2] X[2] B_X2

B[3] X[3] B_X3

Power Relationships Between a Bus and Multiple Related Pins

This section describes the power relationships created when an internal_power group

is within a bus group that has several bits, where each bit has its own related pin. You

identify the resulting multiple power relationships by entering a name list, using the

internal_power group attribute.

Example

bus (X){ /*assuming MSB is X[0] */

bus_type : bus4;

direction : output;

Liberty User Guide Volume 1

R-2020.09

323

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

capacitance : 1;

pin (X[0:3]){

function : "B’";

internal_power (B_X0, C_X0, B_X1, C_X1, B_X2, C_X2, B_X3,C_X3){

related_pin : "B C";

}

If B and C are pins, as opposed to another 4-bit bus, the power relationships are as

follows:

From pin To pin Label

B X[0] B_X0

C X[0] C_X0

B X[1] B_X1

C X[1] C_X1

B X[2] B_X2

C X[2] C_X2

B X[3] B_X3

C X[3] C_X3

If B is another 4-bit bus and B[0] is the MSB for bus B, the power relationships are as

follows:

From pin To pin Label

B[0] X[0] B_X0

C X[0] C_X0

B[1] X[1] B_X1

C X[1] C_X1

B[2] X[2] B_X2

C X[2] C_X2

B[3] X[3] B_X3

C X[3] C_X3

Liberty User Guide Volume 1

R-2020.09

324

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

The same rule applies if C is a 4-bit bus.

Power Relationships Between a Bus and Related Bus Pins

This section describes the power relationships created when an internal_power group is

within a bus group that has several bits that have to be matched with several related bus

pins of a required width. Identify the resulting multiple power relationships by entering a

name list, using the internal_power group attribute.

The first name in the name list is the relationship between the first pin of the related

bus pins of the necessary width and the MSB in the bus group, the second name is the

relationship between the second pin of the related bus pins and the second MSB in the

bus group, and so on.

Example

/* assuming related_bus_pins is width of 2 bits */

bus (X){

/*assuming MSB is X[0] */

bus_type : bus4;

direction : output;

capacitance : 1;

pin (X[0:3]){

function : "B’";

internal_power (B0_X0, B0_X1, B0_X2, B0_X3, B1_X0, B1_X1, \

B1_X2,B1_X3){

related_bus_pins : "B";

}

If B is another 2-bit bus and B[0] is its MSB, the power relationships are as follows:

From pin To pin Label

B[0] X[0] B0_X0

B[0] X[1] B0_X1

B[0] X[2] B0_X2

B[0] X[3] B0_X3

B[1] X[0] B1_X0

B[1] X[1] B1_X1

B[1] X[2] B1_X2

B[1] X[3] B1_X3

Liberty User Guide Volume 1

R-2020.09

325

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

internal_power Group

To define an internal_power group in a pin group, use these simple attributes, complex

attributes, and groups:

Simple attributes:

•

equal_or_opposite_output

•

falling_together_group

• related_pg_pin

•

related_pin

•

rising_together_group

• switching_interval

•

switching_together_group

•

when

Complex attribute:

•

mode

Groups:

•

fall_power

•

power

•

rise_power

equal_or_opposite_output Simple Attribute

This attribute designates an optional output pin or pins whose capacitance can be used to

access a three-dimensional table in the internal_power group.

Syntax

equal_or_opposite_output : "name |name_list" ;

name | name_list

Name of output pin or pins.

Note:

This pin (or these pins) have to be functionally equal to or the opposite of the

pin named in the same pin group.

Liberty User Guide Volume 1

R-2020.09

326

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

Example

equal_or_opposite_output : "Q" ;

Note:

The output capacitance of this pin (or pins) is used as the

equal_or_opposite_output_net_capacitance value in the internal power

lookup table.

falling_together_group Simple Attribute

Use the falling_together_group attribute to identify the list of two or more input or

output pins that share logic and are falling together during the same time period. Set

this time period with the switching_interval attribute. See switching_interval Simple

Attribute on page 329 for details.

Together, the falling_together_group attribute and the switching_interval attribute

settings determine the level of power consumption.

Define a falling_together_group attribute in the internal_power group in a pin

group, as shown here.

cell (name

string

) {

pin (name

string

) {

internal_power () {

falling_together_group : "list of pins" ;

rising_together_group : "list of pins" ;

switching_interval : float;

rise_power () {

...

}

fall_power () {

...

}

list of pins

The names of the input or output pins that share logic and are falling during the

same time period.

related_pin Simple Attribute

This attribute associates the internal_power group with a specific input or output pin. If

related_pin is an output pin, it must be functionally equal to or the opposite of the pin in

that pin group.

Liberty User Guide Volume 1

R-2020.09

327

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

If related_pin is an input pin or output pin, the pin’s transition time is used as a variable

in the internal power lookup table.

Syntax

related_pin : "name | name_list" ;

name | name_list

Name of the input or output pin or pins

Example

related_pin : "A B" ;

The pin or pins in the related_pin attribute denote the path dependency for the

internal_power group.

If you want to define a two-dimensional or three-dimensional table, specify all functionally

related pins in a related_pin attribute.

rising_together_group Simple Attribute

The rising_together_group attribute identifies the list of two or more input or output

pins that share logic and are rising during the same time period. This time period is

defined with the switching_interval attribute. See the following “switching_interval

Simple Attribute,” section for details.

Together, the rising_together_group attribute and switching_interval attribute

settings determine the level of power consumption.

Define the rising_together_group attribute in the internal_power group, as shown

here.

cell (name

string

) {

pin (name

string

) {

internal_power () {

falling_together_group : "list of pins" ;

rising_together_group : "list of pins" ;

switching_interval : float;

rise_power () {

...

}

fall_power () {

...

}

Liberty User Guide Volume 1

R-2020.09

328

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

list of pins

The names of the input or output pins that share logic and are rising during the

same time period.

switching_interval Simple Attribute

The switching_interval attribute defines the time interval during which two or more pins

that share logic are falling, rising, or switching (either falling or rising) during the same time

period.

Set the switching_interval attribute together with the falling_together_group,

rising_together_group, or switching_together_group attribute. Together with one of

these attributes, the switching_interval attribute defines a level of power consumption.

For details about the attributes that are set together with the switching_interval

attribute, see falling_together_group Simple Attribute on page 327;

rising_together_group Simple Attribute on page 328; and the following

“switching_together_group Simple Attribute,” section.

Syntax

switching_interval : float ;

float

A floating-point number that represents the time interval during which two or

more pins that share logic are switching together.

Example

pin (Z) {

direction : output;

internal_power () {

switching_together_group : "A B";

/*if pins A, B, and Z switch*/ ;

switching_interval : 5.0;

/*switching within 5 time units */;

power () {

...

}

switching_together_group Simple Attribute

The switching_together_group attribute identifies the list of two or more input or output

pins that share logic, are either falling or rising during the same time period, and are not

affecting power consumption.

Liberty User Guide Volume 1

R-2020.09

329

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

Define the time period with the switching_interval attribute. See switching_interval

Simple Attribute on page 329 for details.

Define the switching_together_group attribute in the internal_power group, as shown

here.

cell (name

string

) {

pin (name

string

) {

internal_power () {

switching_together_group : "list of pins" ;

switching_interval : float;

power () {

...

}

list of pins

The names of the input or output pins that share logic, are either falling or rising

during the same time period, and are not affecting power consumption.

when Simple Attribute

This attribute specifies a state-dependent condition that determines whether the internal

power table is accessed.

You can use the when attribute to define one-, two-, or three-dimensional tables in the

internal_power group.

Syntax

when : "Boolean expression" ;

Boolean expression

Name or names of input and output pins, buses, and bundles with

corresponding Boolean operators.

The table in when Simple Attribute lists the Boolean operators valid in a when statement.

Example

when : "A B" ;

fall_power Group

Use a fall_power group to define a fall transition for a pin. If you specify a fall_power

group, you must also specify a rise_power group.

Liberty User Guide Volume 1

R-2020.09

330

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

You define a fall_power group in an internal_power group in a cell-level pin group, as

shown here:

cell (name

string

) {

pin (name

string

) {

internal_power () {

fall_power (template name) {

... fall power description ...

}

Complex Attributes

index_1 ("float, ..., float") ; /* lookup table */

index_2 ("float, ..., float") ; /* lookup table */

index_3 ("float, ..., float") ; /* lookup table */

values ("float, ..., float") ; /* lookup table */

index_1, index_2, index_3 Attributes

These attributes identify internal cell consumption per fall transition. Define these attributes

in the internal_power group or in the library-level power_lut_template group.

values Attribute

This attribute defines internal cell consumption per fall transition.

Example

values ("2.2, 3.7, 4.3", "1.7, 2.1, 3.5", "1.0, 1.5, 2.8");

You must ensure that the internal power units exactly match the derived units of

switching power (CV

). This is necessary because the Design Compiler tool adds the

internal_power value and switching power to get the dynamic power consumption

without any consideration of units.

The Design Compiler tool converts the values attribute information to power consumption

by multiplying the unit by the factor transition or per_unit_time, as shown here:

•

nindex_1 floating-point numbers if the lookup table is one-dimensional

•

nindex_1 x nindex_2 floating-point numbers if the lookup table is two-dimensional

• nindex_1 x nindex_2 x nindex_3 floating-point numbers if the lookup table is three-

dimensional

The nindex_1, nindex_2, and nindex_3 numbers are the size of index_1, index_2, and

index_3 in this group or in the power_lut_template group it inherits. Quotation marks

enclose a group. Each group represents a row in the table.

Liberty User Guide Volume 1

R-2020.09

331

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

power Group

The power group is defined within an internal_power group in a pin group at the cell

level, as shown here:

library (name) {

cell (name) {

pin (name) {

internal_power () {

power (template name) {

... power template description ...

}

Complex Attributes

index_1 ("float, ..., float") ; /* lookup table */

index_2 ("float, ..., float") ; /* lookup table */

index_3 ("float, ..., float") ; /* lookup table */

values ("float, ..., float") ; /* lookup table */

index_1, index_2, index_3 Attributes

These attributes identify internal cell consumption per transition. Define these attributes in

the internal_power group or in the library-level power_lut_template group.

values Attribute

This attribute defines internal cell power consumption per rise or fall transition.

This power information is accessed when the pin has a rise transition or a fall transition.

The values in the table specify the average power per transition.

Note:

The internal power value is derived from the capacitance unit exponent (with

mantissa discarded) and the voltage unit.

rise_power Group

A rise_power group is defined in an internal_power group at the cell level, as shown

here:

cell (name) {

pin (name) {

internal_power () {

rise_power (template name) {

... rise power description ...

}

Liberty User Guide Volume 1

R-2020.09

332

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

}

Rise power is accessed when the pin has a rise transition. If you have a rise_power

group, you must have a fall_power group.

Complex Attributes

index_1 ("float, ..., float") ; /* lookup table */

index_2 ("float, ..., float") ; /* lookup table */

index_3 ("float, ..., float") ; /* lookup table */

values ("float, ..., float") ; /* lookup table */

index_1, index_2, index_3 Attributes

These attributes identify internal cell consumption per rise transition. Define these

attributes in the internal_power group or in the library-level power_lut_template group.

values Attribute

This attribute defines internal cell power consumption per rise transition.

Note:

The Design Compiler tool converts the values attribute information to power

consumption, by multiplying the unit by the factor transition or per_unit_time.

For more information, see values Attribute on page 331.

Syntax for One-Dimensional, Two-Dimensional, and Three-Dimensional Tables

You can define a one-, two-, or three-dimensional table in the internal_power group in

either of the following two ways:

•

Using the power group. For two- and three-dimensional tables, define the power group

and the related_pin attribute.

•

Using a combination of the related_pin attribute, the fall_power group, and the

rise_power group.

The syntax for a one-dimensional table using the power group is shown here:

internal_power() {

power (template name) {

values("float, ..., float") ;

}

The syntax for a one-dimensional table using the fall_power and rise_power groups is

shown here:

internal_power() {

fall_power (template name) {

values("float, ..., float");

Liberty User Guide Volume 1

R-2020.09

333

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

}

rise_power (template name) {

values("float, ..., float");

}

The syntax for a two-dimensional table using the power and related_pin groups is

shown here:

internal_power() {

related_pin : "name | name_list" ;

power (template name) {

values("float, ..., float") ;

}

The syntax for a two-dimensional table using the related_pin, fall_power, and

rise_power groups is shown here:

internal_power() {

related_pin : "name | name_list" ;

fall_power (template name) {

values("float, ..., float");

}

rise_power (template name) {

values("float, ..., float");

}

The syntax for a three-dimensional table using the power and related_pin groups is

shown here:

internal_power() {

related_pin : "name | name_list" ;

power (template name) {

values("float, ..., float") ;

}

equal_or_opposite_output : "name | name_list" ;

}

Example 83 Library With Internal Power Information in pin Groups

library(internal_power_example) {

...

power_lut_template(output_by_cap_and_trans) {

variable_1 : total_output_net_capacitance ;

variable_2 : input_transition_time ;

index_1 ("0.0, 5.0, 20.0");

index_2 ("0.0, 1.0, 20.0");

}

...

cell(AN2) {

pin(Z) {

Liberty User Guide Volume 1

R-2020.09

334

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

direction : output ;

internal_power {

power(output_by_cap_and_trans) {

values ("2.2, 3.7, 4.3", "1.7, 2.1, 3.5", "1.0, 1.5, 2.8");

}

related_pin : "A B" ;

}

pin(A) {

direction : input ;

...

}

pin(B) {

direction : input ;

...

}

The syntax for a three-dimensional table using the related_pin, fall_power, and

rise_power groups is shown here:

internal_power() {

related_pin : "name | name_list" ;

fall_power (template name) {

values ("float, ..., float") ;

}

rise_power (template name) {

values ("float, ..., float") ;

}

equal_or_opposite_output : "name | name_list" ;

}

Internal Power Examples

The examples in this section show how to describe the internal power of the 2-input

sequential gate in Figure 50, using one-, two-, and three-dimensional lookup tables.

Figure 50 Library Cells With Internal Power Information

Liberty User Guide Volume 1

R-2020.09

335

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

One-Dimensional Power Lookup Table

Example 84 is the library description of the cell shown in figure in Internal Power

Examples, cell with one-dimensional internal power table defined in the pin groups.

Example 84 One-Dimensional Internal Power Table

library(internal_power_example) {

...

power_lut_template(output_by_cap) {

variable_1 : total_output_net_capacitance ;

index_1("0.0, 5.0, 20.0") ;

}

...

power_lut_template(input_by_trans) {

variable_1 : input_transition_time ;

index_1 ("0.0, 1.0, 2.0") ;

}

...

cell(FLOP1) {

pin(CP) {

direction : input ;

internal_power()

power (input_by_trans) {

values("1.5, 2.6, 4.7") ;

}

...

pin(Q) {

direction : input ;

internal_power() {

power(output_by_cap) {

values("9.0, 5.0, 2.0") ;

}

In Example 84, the input transition time at pin CP is 1.0. The output load at pin Q is 5.0.

The toggle rate at pin CP is two transitions per 100 ns. The toggle rate at pin Q is one

transition per 100 ns. Using this information to index into the table, you get the following

results:

= 2.6

= 5.0

If the time_unit attribute value in the logic library is 1 ns, the total internal power

consumed by this gate is

int

= (E

x AF

) + (E

x AF

)

Liberty User Guide Volume 1

R-2020.09

336

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

= (2.6 x 2 x 10-2) + (5.0 x 1 x 10-2)

= 0.102

The activity factors AF

and AF

are adjusted to the time_unit specified in

the logic library. The unit of P

int

depends on the unit of the voltage_unit and

capacitive_load_unit attributes in the logic library.

If the following attributes and values are specified in the logic library, the unit of the

internal_power group is 10

–15

joule/transition.

voltage_unit : "1V";

capacitive_load_unit(1.0, "ff");

Because the unit of the activity factor is transition/ns, the total internal power dissipation of

this gate is

0.102 x 10-15 joule/transition x transition/10-9second = 0.102 uW.

Note:

For a detailed explanation of how to calculate internal power, see the Power

Compiler User Guide.

Two-Dimensional Power Lookup Table

Example 85 is the library description of the cell in figure in Internal Power Examples, a cell

with a two-dimensional internal power table defined in the pin groups.

Example 85 Two-Dimensional Internal Power Table

library(internal_power_example) {

...

power_lut_template(output_by_cap_and_trans) {

variable_1 : total_output_net_capacitance ;

variable_2 : input_transition_time ;

index_1 ("0.0, 5.0, 20.0");

index_2 ("0.0, 1.0, 20.0");

}

...

cell(AN2) {

pin(Z) {

direction : output ;

internal_power {

power(output_by_cap_and_trans) {

values ("2.2, 3.7, 4.3", "1.7, 2.1, 3.5", "1.0, 1.5, 2.8");

}

related_pin : "A B" ;

}

pin(A) {

direction : input ;

...

}

pin(B) {

direction : input ;

...

Liberty User Guide Volume 1

R-2020.09

337

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

}

In this example, the input transition time at pin A is 1.25. The input transition time at pin

B is 2.5. The output load at pin Z is 5.0. The toggle rate at pin A is 2 transitions per 100

ns. The toggle rate at pin B is three transitions per 100 ns. The toggle rate at pin Z is one

transition per 100 ns.

With this information, the weighted input transition time is calculated as follows. (In this

case, you use the weighted input transition time because there are two inputs.)

(1.25 x 2 x 10-2 + 2.5 x 3 x 10-2) / (2 x 10-2 + 3 x 10-2 ) = 2.0

Because the output load at pin Z is 5.0, the following power table values are used:

2.1 = 1.0A + B

3.5 = 20.0A + B

Consequently, the values for A and B become

A = 0.0739

B = 2.0263

and the resulting values for Ez and Pint are

Ez = 2.0 x 0.0739 + 2.0263

= 2.1741

= 2.2

int

= Ez x AFz

= 2.2 x 1 x 10-E2

= 0.022

The activity factor AF

is adjusted to the time_unit specified in the logic library. The unit

of internal_power can be applied here.

Three-Dimensional Power Lookup Table

Example 86 is the library description for the cell in figure in Internal Power Examples, a

cell with a three-dimensional internal power table.

Example 86 Three-Dimensional Internal Power Table

library(internal_power_example) {

...

power_lut_template(output_by_cap1_cap2_and_trans) {

variable_1 : total_output1_net_capacitance ;

variable_2 : equal_or_opposite_output_net_capacitance ;

variable_3 : input_transition_time ;

index_1 ("0.0, 5.0, 20.0") ;

index_2 ("0.0, 5.0, 20.0") ;

index_3 ("0.0, 1.0, 2.0") ;

}

Liberty User Guide Volume 1

R-2020.09

338

Chapter 8: Modeling Power and Electromigration

Defining Internal Power Groups

...

cell(FLOP1) {

pin(CP) {

direction : input ;

...

}

pin(D) {

direction : input ;

...

}

pin(S) {

direction : input ;

...

}

pin(R) {

direction : input ;

...

}

pin(Q) {

direction : output ;

internal_power() {

power(output_by_cap1_cap2_and_trans) {

values("2.2, 3.7, 4.3", "1.7, 2.1, 3.5", "1.0, 1.5,\

.8", "2.1, 3.6, 4.2", "1.6, 2.0, 3.4", "0.9, 1.5, .7" \

"2.0, 3.5, 4.1", "1.5, 1.9, 3.3", "0.8, 1.4,2.6");

}

equal_or_opposite_output : "QN" ;

related_pin : "CP" ;

}

...

}

...

}

In this example, the input transition time at pin CP is 1.0. The output load at pin QN is 5.0.

The output load at pin Q is 5.0. The toggle rate at pin Q is one transition per 100 ns.

Using the transition time and the loading at pin Q and QN to index into the table, you get

the following results:

EQ = 2.0

If the time_unit in the logic library is 1 ns, the total internal power consumed by this gate

int

= EQ x AF

=2.0 x 1 x 10-2

=0.020

The activity factor AF

is adjusted to the time_unit specified in the logic library. The unit

of internal_power can be applied here.

Liberty User Guide Volume 1

R-2020.09

339

Chapter 8: Modeling Power and Electromigration

Modeling Libraries With Integrated Clock-Gating Cells

Power optimization achieved at high levels of abstraction has a significant impact on

reduction of power in the final gate-level design. Clock gating is an important high-level

technique for reducing power.

You can perform automatic clock gating at the register transfer level, using the HDL

Compiler and Power Compiler tools from Synopsys.

What Clock Gating Does

Clock gating provides a power-efficient implementation of register banks that are disabled

during some clock cycles.

A register bank is a group of flip-flops that share the same clock and synchronous control

signals and that are inferred from the same HDL variable. Synchronous control signals

include synchronous load-enable, synchronous set, synchronous reset, and synchronous

toggle.

Without clock gating, the Design Compiler tool implements register banks using a

feedback loop and multiplexer. When such register banks maintain the same value

through multiple cycles, they use power unnecessarily.

Figure 51 shows a simple implementation of a register bank using a multiplexer and a

feedback loop.

Figure 51 Synchronous Load-Enable Register Using a Multiplexer

Liberty User Guide Volume 1

R-2020.09

340

Chapter 8: Modeling Power and Electromigration

Modeling Libraries With Integrated Clock-Gating Cells

When the synchronous load-enable signal (EN) is at logic state 0, the register bank is

disabled. In this state, the circuit uses the multiplexer to feed the Q output of each storage

element in the register bank back to the D input. When the EN signal is at logic state 1, the

Such feedback loops can use some power unnecessarily. For example, if the same value

is reloaded in the register throughout multiple clock cycles (EN equals 0), the register bank

and its clock net consume power while values in the register bank do not change. The

multiplexer also consumes power.

By controlling the clock signal for the register, you can eliminate the need for reloading

the same value in the register through multiple clock cycles. Clock gating inserts a 2-input

gate into the register bank’s clock network, creating the control to eliminate unnecessary

Clock gating reduces the clock network’s power dissipation and often relaxes the datapath

timing. If your design has large multibit registers, clock gating can save power and reduce

the number of gates in the design. However, for smaller register banks, the overhead

of adding logic to the clock tree might not compare favorably to the power saved by

eliminating a few feedback nets and multiplexers.

Using integrated clock-gating cell functionality, you have the option of doing the following:

•

Use latch-free or latch-based clock gating.

•

Insert logic to increase testability.

For details, see “Using an Integrated Clock-Gating Cell” and Setting Pin Attributes for an

Integrated Cell on page 343.

Looking at a Gated Clock

Clock gating saves power by eliminating the unnecessary activity associated with

reloading register banks. Clock gating eliminates the feedback net and multiplexer shown

in figure in What Clock Gating Does, by inserting a 2-input gate in the clock net of the

clock signal from clocking the gated register.

Clock gating can also insert inverters or buffers to satisfy timing or clock waveform and

duty requirements.

Figure 52 shows the 2-input clock gate as an AND gate; however, depending on the type

of register and the gating style, gating can use NAND, OR, and NOR gates instead.

Liberty User Guide Volume 1

R-2020.09

341

Chapter 8: Modeling Power and Electromigration

Modeling Libraries With Integrated Clock-Gating Cells

Figure 52 Latch-Based Clock Gating

The clock input to the register bank, ENCLK, is gated on or off by the AND gate. ENL is

the enabling signal that controls the gating; it derives from the EN signal on the multiplexer

shown in figure in What Clock Gating Does. The register is triggered by the rising edge of

the ENCLK signal.

The latch prevents glitches on the EN signal from propagating to the register’s clock pin.

When the CLK input of the 2-input AND gate is at logic state 1, any glitching of the EN

signal could, without the latch, propagate and corrupt the register clock signal. The latch

eliminates this possibility, because it blocks signal changes when the clock is at logic state

In latch-based clock gating, the AND gate blocks unnecessary clock pulses, by

maintaining the clock signal’s value after the trailing edge. For example, for flip-flops

inferred by HDL constructs of positive-edge clocks, the clock gate forces the clock-gated

signal to maintain logic state 0 after the falling edge of the clock.

Using an Integrated Clock-Gating Cell

Consider using an integrated clock-gating cell if you are experiencing timing problems

caused by the introduction of random logic on the clock line.

Liberty User Guide Volume 1

R-2020.09

342

Chapter 8: Modeling Power and Electromigration

Modeling Libraries With Integrated Clock-Gating Cells

Create an integrated clock-gating cell that integrates the various combinational and

sequential elements of the clock-gating circuitry into a single cell, which is compiled to

gates and located in the logic library.

Setting Pin Attributes for an Integrated Cell

The clock-gating software requires the pins of your integrated cells to be set with the

attributes listed in Table 23. Setting some of the pin attributes, such as those for test and

observability, is optional.

Table 23 Pin Attributes for Integrated Clock-Gating Cells

Integrated cell pin name Data direction Required attribute

clock in clock_gate_clock_pin

enable in clock_gate_enable_pin

test_mode

scan_enable

in clock_gate_test_pin

observability out clock_gate_obs_pin

enable_clock out clock_gate_out_pin

For more details about the clock_gating_integrated_cell attribute and the

corresponding pin attributes, see the Power Compiler User Guide.

clock_gate_clock_pin Attribute

The clock_gate_clock_pin attribute identifies an input pin connected to a clock signal.

Syntax

clock_gate_clock_pin : true | false ;

true | false

A true value labels the pin as a clock pin. A false value labels the pin as not a

clock pin.

Example

clock_gate_clock_pin : true;

Liberty User Guide Volume 1

R-2020.09

343

Chapter 8: Modeling Power and Electromigration

Modeling Libraries With Integrated Clock-Gating Cells

clock_gate_enable_pin Simple Attribute

The clock_gate_enable_pin attribute a design containing gated clocks.

The clock_gate_enable_pin attribute identifies an input pin connected to an enable

signal for nonintegrated clock-gating cells and integrated clock-gating cells.

Syntax

clock_gate_enable_pin : true | false ;

true | false

A true value labels the input pin of a clock-gating cell connected to an enable

signal as the enable pin. A false value does not label the input pin as an enable

pin.

Example

clock_gate_enable_pin : true;

For clock-gating cells, you can set this attribute to true on only one input port of a 2-input

AND, NAND, OR, or NOR gate. If you do so, the other input port is the clock.

For more information about identifying pins on integrated clock-gating cells, see Using an

Integrated Clock-Gating Cell on page 342.

For additional information about integrated clock gating, see the Power Compiler User

Guide.

clock_gate_test_pin Attribute

The clock_gate_test_pin attribute identifies an input pin connected to a test_mode or

scan_enable signal.

Syntax

clock_gate_test_pin : true | false ;

true | false

A true value labels the pin as a test (test_mode or scan_enable) pin. A false

value labels the pin as not a test pin.

Example

clock_gate_test_pin : true;

clock_gate_obs_pin Attribute

The clock_gate_obs_pin attribute identifies an output pin connected to an observability

signal.

Liberty User Guide Volume 1

R-2020.09

344

Chapter 8: Modeling Power and Electromigration

Modeling Libraries With Integrated Clock-Gating Cells

Syntax

clock_gate_obs_pin : true | false ;

true | false

A true value labels the pin as an observability pin. A false value labels the pin as

not an observability pin.

Example

clock_gate_obs_pin : true;

clock_gate_out_pin Attribute

The clock_gate_out_pin attribute identifies an output port connected to an

enable_clock signal.

Syntax

clock_gate_out_pin : true | false ;

true | false

A true value labels the pin as a clock-gated output (enable_clock) pin. A false

value labels the pin as not a clock-gated output pin.

Example

clock_gate_out_pin : true;

Clock-Gating Timing Considerations

The clock gate must not alter the waveform of the clock—other than turning the clock

signal on and off.

Figure 53 and Figure 54 show the relationship of setup and hold times to a clock waveform

for AND and OR clock gates.

Liberty User Guide Volume 1

R-2020.09

345

Chapter 8: Modeling Power and Electromigration

Modeling Libraries With Integrated Clock-Gating Cells

Figure 53 Setup and Hold Times for an AND Clock Gate

The setup time specifies how long the clock-gate input (ENL) must be stable before the

clock input (CLK) makes a transition to a noncontrolling value. The hold time ensures

that the clock-gate input (ENL) is stable for the time you specify after the clock input

(CLK) returns to a controlling value. The setup and hold times ensure that the ENL signal

is stable for the entire time the CLK signal has a noncontrolling value, which prevents

clipping or glitching of the ENCLK clock signal.

Liberty User Guide Volume 1

R-2020.09

346

Chapter 8: Modeling Power and Electromigration

Modeling Libraries With Integrated Clock-Gating Cells

Figure 54 Setup and Hold Times for an OR Clock Gate

Timing Considerations for Integrated Cells

Clock gating requires certain timing arcs on your integrated cell.

For latch-based clock gating,

•

Define setup and hold arcs on the enable pins with respect to the same controlling

edge of the clock.

•

Define combinational arcs from the clock and enable inputs to the output.

For latch-free clock gating,

• Define no-change arcs on the enable pins. These arcs must be no-change arcs,

because they are defined with respect to different clock edges.

•

Define combinational arcs from the clock and enable inputs to the output.

Liberty User Guide Volume 1

R-2020.09

347

Chapter 8: Modeling Power and Electromigration

Modeling Libraries With Integrated Clock-Gating Cells

Set the setup and the hold arcs on the enable pin as specified by the

clock_gate_enable_pin attribute with respect to the value entered for the

clock_gating_integrated_cell attribute.

For the latch- and flip-flop-based styles, the setup and hold arcs are the conventional type

and are set with respect to the same clock edge. However, for the latch-free style, the

setup and hold arcs are set with respect to different clock edges and therefore must be

specified as no-change arcs. Note that all arcs for integrated cells must be combinational

arcs.

Table 24 Values of the clock_gating_integrated_cell Attribute for Setup and Hold Arcs

clock_gating_integrated_cell attribute value Setup arc Hold arc

latch_posedge rising rising

latch_negedge falling falling

none_posedge falling rising

none_negedge rising falling

ff_posedge falling falling

ff_negedge rising rising

Integrated Clock-Gating Cell Example

Example 87 uses the latch_posedge_precontrol_obs value option for the

clock_gating_integrated_cell attribute.

Example 87 Integrated Clock-Gating Cell

cell(CGLPCO) {

area : 1;

clock_gating_integrated_cell : "latch_posedge_precontrol_obs";

dont_use : true;

statetable(" CLK EN SE", "IQ") {

table : " L L L : - : L ,\

L L H : - : H ,\

L H L : - : H ,\

L H H : - : H ,\

H - - : - : N ";

}

pin(IQ) {

direction : internal;

internal_node : "IQ";

}

pin(EN) {

direction : input;

capacitance : 0.017997;

clock_gate_enable_pin : true;

timing() {

Liberty User Guide Volume 1

R-2020.09

348

Chapter 8: Modeling Power and Electromigration

Modeling Libraries With Integrated Clock-Gating Cells

timing_type : setup_rising;

cell_rise(scalar) {

values( " 0.4 ");

}

cell_fall(scalar) {

values( " 0.4 ");

}

related_pin : "CLK";

}

timing() {

timing_type : hold_rising;

cell_rise(scalar) {

values( " 0.4 ");

}

cell_fall(scalar) {

values( " 0.4 ");

}

related_pin : "CLK";

}

pin(SE) {

direction : input;

capacitance : 0.017997;

clock_gate_test_pin : true;

}

pin(CLK) {

direction : input;

capacitance : 0.031419;

clock_gate_clock_pin : true;

min_pulse_width_low : 0.319;

}

pin(GCLK) {

direction : output;

state_function : "CLK * IQ";

max_capacitance : 0.500;

clock_gate_out_pin : true;

timing() {

timing_sense : positive_unate;

cell_rise(scalar) {

values( " 0.4 ");

}

rise_transition(scalar) {

values( " 0.1 ");

}

cell_fall(scalar) {

values( " 0.4 ");

}

fall_transition(scalar) {

values( " 0.1 ");

}

related_pin : "EN CLK";

}

internal_power (){

rise_power(li4X3){

index_1("0.0150, 0.0400, 0.1050, 0.3550");

index_2("0.050, 0.451, 1.501");

values("0.141, 0.148, 0.256",\

"0.162, 0.145, 0.234",\

"0.192, 0.200, 0.284",\

"0.199, 0.219, 0.297");

}

Liberty User Guide Volume 1

R-2020.09

349

Chapter 8: Modeling Power and Electromigration

Modeling Electromigration

fall_power(li4X3){

index_1("0.0150, 0.0400, 0.1050, 0.3550");

index_2("0.050, 0.451, 1.500");

values("0.141, 0.148, 0.256",\

"0.162, 0.145, 0.234",\

"0.192, 0.200, 0.284",\

"0.199, 0.219, 0.297");

}

related_pin : "CLK EN" ;

}

pin(OBS) {

direction : output;

state_function : "EN";

max_capacitance : 0.500;

clock_gate_obs_pin : true;

}

Modeling Electromigration

When high-density current passes through a thin metal wire, the high-energy electrons

exert forces upon the atoms that causes electromigration of the atoms. Electromigration

can drastically reduce the lifetime of a chip by increasing the resistivity of the metal wire or

creating a short circuit between adjacent lines.

Controlling Electromigration

You can control electromigration by establishing an upper boundary for the output toggle

rate. You achieve this by annotating cells with electromigration characterization tables

representing the net’s maximal toggle rates.

Specifically, do the following to control electromigration:

Use the em_lut_template group to name an index template to be used by the

em_max_toggle_rate group, which you use to set the net’s maximum toggle rates. The

em_lut_template group has variable_1, variable_2, index_1, and index_2 attributes.

•

Use the variable_1 and the variable_2 attributes to specify the variables.

Both variable_1 and variable_2 can take the input_transition_time or the

total_output_net_capacitance value.

•

Use the index_1 attribute to specify the points along the variable_1 table axis, and

the index_2 attribute to specify the points along the variable_2 table axis.

The pin-level electromigration group contains the em_max_toggle_rate group,

which you use to specify the maximum toggle rate and the related_pin and

related_bus_pins attributes.

Liberty User Guide Volume 1

R-2020.09

350

Chapter 8: Modeling Power and Electromigration

Modeling Electromigration

• Use the related_pin attribute to identify the input pin with which the

electromigration group is associated.

• Use the related_bus_pins attribute to identify the bus group of the pin or pins with

which the electromigration group is associated.

•

To select the template you want the em_max_toggle_rate group to use,

assign the name of the library-level em_lut_template group to the pin-level

em_max_toggle_rate group.

The em_max_toggle_rate group contains the values complex attribute; the related_pin

and related_bus_pins simple attributes; and, optionally, the index_1 and index_2

complex attributes.

•

Use the values complex attribute to specify the nets’ maximum toggle rates for every

index_1 breakpoint along the variable_1 axis if the table is one-dimensional.

• If the table is two-dimensional, use values to specify the nets’ maximum toggle

rates for all points where the breakpoints of index_1 intersect with the breakpoints

of index_2. The value for these points is equal to nindex_1 x nindex_2, where

index_1 and index_2 are the size to which the em_lut_template group’s index_1

and index_2 attributes are set.

•

You can also use the em_max_toggle_rate group’s optional index_1 and index_2

attributes to overwrite the em_lut_template group’s index_1 and index_2 values.

•

State dependency in both lookup tables and polynomials.

Use the optional em_temp_degradation_factor at the library level or the cell level to

specify the electromigration temperature exponential degradation factor. If this factor is

not defined, the nominal temperature electromigration tables are used for all operating

temperatures.

Use the report_lib -em command to get a report on electromigration for a specified

library.

em_lut_template Group

Use the em_lut_template group at the library level to specify the name of the index

template to be used by the em_max_toggle_rate group, which you use to set the net’s

maximum toggle rates to control electromigration.

Syntax

library (name) {

em_lut_template(name

string

) {

variable_1: input_transition_time | total_output_net_capacitance ;

variable_2: input_transition_time | total_output_net_capacitance ;

index_1("float, ..., float");

Liberty User Guide Volume 1

R-2020.09

351

Chapter 8: Modeling Power and Electromigration

Modeling Electromigration

index_2("float, ..., float");

}

variable_1 and variable_2 Simple Attributes

Use variable_1 to assign values to the first dimension and variable_2 to assign values

to the second dimension for the templates on electromigration tables. The values can be

either input_transition_time or total_output_net_capacitance.

Syntax

variable_1: input_transition_time |

total_output_net_capacitance ;

variable_2: input_transition_time |

total_output_net_capacitance ;

The value you assign to variable_1 is determined by how the index_1 complex attribute

is measured, and the value you assign to variable_2 is determined by how the index_2

complex attribute is measured.

Assign input_transition_time for variable_1 if the complex attribute index_1 is

measured with the input net transition time of the pin specified in the related_pin

attribute or the pin associated with the electromigration group. Assign

total_output_net_capacitance to variable_1 if the complex attribute index_1 is

measured with the loading of the output net capacitance of the pin associated with the

em_max_toggle_rate group.

Assign input_transition_time for variable_2 if the complex attribute index_2 is

measured with the input net transition time of the pin specified in the related_pin

attribute, in the related_bus_pins attribute, or in the pin associated with the

electromigration group.

Assign total_output_net_capacitance to variable_2 if the complex attribute index_2

is measured with the loading of the output net capacitance of the pin associated with the

electromigration group.

Example

variable_1 : total_output_net_capacitance ;

variable_2 : input_transition_time ;

index_1 and index_2 Complex Attributes

You can use the index_1 optional attribute to specify the breakpoints of the first dimension

of an electromigration table used to characterize cells for electromigration within the

library. You can use the index_2 optional attribute to specify the breakpoints of the second

dimension of an electromigration table used to characterize cells for electromigration

within the library.

Liberty User Guide Volume 1

R-2020.09

352

Chapter 8: Modeling Power and Electromigration

Modeling Electromigration

Syntax

index_1 : ("float, ..., float") ;

index_2 : ("float, ..., float") ;

float

Floating-point numbers that identify the maximum toggle rate frequency from 1

to 0 and from 0 to 1.

You can overwrite the values entered for the em_lut_template group’s index_1, by

entering a value for the em_max_toggle_rate group’s index_1. You can overwrite the

values entered for the em_lut_template group’s index_2, by entering a value for the

em_max_toggle_rate group’s index_2.

The following are the rules for the relationship between variables and indexes:

•

If you have variable_1, you can have only index_1.

•

If you have variable_1 and variable_2, you can have index_1 and index_2.

•

The value you enter for variable_1 (used for one-dimensional tables) is determined

by how index_1 is measured. The value you enter for variable_2 (used for two-

dimensional tables) is determined by how index_2 is measured.

Example

index_1 ("0.0, 5.0, 20.0") ;

index_2 ("0.0, 1.0, 2.0") ;

electromigration Group

An electromigration group is defined in a pin group, as shown here:

library (name) {

cell (name) {

pin (name) {

electromigration () {

... electromigration description ...

}

Simple Attributes

related_pin : "name | name_list" ;/* path dependency */

related_bus_pins : "list of pins" ;/* list of pin names */

Liberty User Guide Volume 1

R-2020.09

353

Chapter 8: Modeling Power and Electromigration

Modeling Electromigration

Group Statements

em_max_toggle_rate (em_template_name) {}

These attributes and groups are described in the following sections.

related_pin Simple Attribute

This attribute associates the electromigration group with a specific input pin. The input

pin’s input transition time is used as a variable in the electromigration lookup table.

If more than one input pin is specified in this attribute, the weighted input transition time of

all input pins specified is used to index the electromigration table.

Syntax

related_pin : "name | name_list" ;

name | name_list

Name of input pin or pins.

related_bus_pins Simple Attribute

This attribute associates the electromigration group with the input pin or pins of

a specific bus group. The input pin’s input transition time is used as a variable in the

electromigration lookup table.

If more than one input pin is specified in this attribute, the weighted input transition time of

all input pins specified is used to index the electromigration table.

Syntax

related_bus_pins : "name1 [name2 name3 ... ]" ;

Example

related_bus_pins : "A" ;

The pin or pins in the related_bus_pins attribute denote the path dependency for the

electromigration group. A particular electromigration group is accessed if the input

pin or pins named in the related_bus_pins attribute cause the corresponding output

pin named in the pin group to toggle. All functionally related pins must be specified in a

related_bus_pins attribute if two-dimensional tables are being used.

lifetime_profile Simple Attribute

The optional lifetime_profile attribute specifies a label that describes the lifetime of

a chip. To support electromigration analysis at different lifetimes in downstream tools,

define multiple electromigration groups with different values of the lifetime_profile

attribute. This attribute does not have a default value.

Liberty User Guide Volume 1

R-2020.09

354

Chapter 8: Modeling Power and Electromigration

Modeling Electromigration

An electromigration group where the lifetime_profile attribute is not specified, is

considered to be the default cell electromigration model.

Syntax

lifetime_profile : profile_name ;

Example

lifetime_profile : lpf_alpf_a ;

em_max_toggle_rate Group

The em_max_toggle_rate group is a pin-level group that is defined within the

electromigration pin group. The toggle rate is the number of toggles per unit of time where

the unit of time is specified by the library-level time_unit attribute.

library (name) {

cell (name) {

pin (name) {

electromigration () {

em_max_toggle_rate(em_template_name) {

... em_max_toggle_rate description ...

}

Simple Attribute

current_type

The current_type attribute is defined in the following section.

current_type Simple Attribute

The optional current_type attribute specifies the type of current for the

em_max_toggle_rate lookup table. Valid values are average, rms, and peak.

Syntax

current_type: average | rms | peak ;

Example

current_type: average ;

Complex Attributes

index_1 ("float, ..., float") ; /*this attribute is

optional*/

index_2 ("float, ..., float") ; /*this attribute is

Liberty User Guide Volume 1

R-2020.09

355

Chapter 8: Modeling Power and Electromigration

Modeling Electromigration

optional*/

values ("float, ...,float ") ;

These attributes are defined in the following sections.

Index_1 and Index_2 Complex Attributes

You can use the index_1 optional attribute to specify the breakpoints of the first dimension

of an electromigration table to characterize cells for electromigration within the library. You

can use the index_2 optional attribute to specify breakpoints of the second dimension of

an electromigration table used to characterize cells for electromigration within the library.

You can overwrite the values entered for the em_lut_template group’s index_1, by

entering values for the em_max_toggle_rate group’s index_1. You can overwrite the

values entered for the em_lut_template group’s index_2, by entering values for the

em_max_toggle_rate group’s index_2.

Syntax

index_1 ("float, ..., float") ; /*this attribute is

optional*/

index_2 ("float, ..., float") ; /*this attribute is

optional*/

float

Floating-point numbers that identify the maximum toggle rate frequency.

Example

index_1 ("0.0, 5.0, 20.0") ;

index_2 ("0.0, 1.0, 2.0") ;

values Complex Attribute

This complex attribute is used to specify the net’s maximum toggle rates.

This attribute can be a list of nindex_1 positive floating-point numbers if the table is one-

dimensional.

This attribute can also be nindex_1 x nindex_2 positive floating-point numbers if the table

is two-dimensional, where nindex_1 is the size of index_1 and nindex_2 is the size of

index_2 that is specified for these two indexes in the em_max_toggle_rate group or in

the em_lut_template group.

Syntax

values("float, ..., float") ;

float

Floating-point numbers that identify the maximum toggle rate frequency.

Liberty User Guide Volume 1

R-2020.09

356

Chapter 8: Modeling Power and Electromigration

Modeling Electromigration

Example (One-Dimensional Table)

values : ("1.5, 1.0, 0.5") ;

Example (Two-Dimensional Table)

values : ("2.0, 1.0, 0.5", "1.5, 0.75, 0.33","1.0, 0.5, 0.15",) ;

em_temp_degradation_factor Simple Attribute

The em_temp_degradation_factor attribute specifies the electromigration exponential

degradation factor.

Syntax

em_temp_degradation_factor : value

float

;

value

A floating-point number in centigrade units consistent with other temperature

specifications throughout the library.

Example

em_temp_degradation_factor : 40.0 ;

Example

related_pin : "A B" ;

The pin or pins in the related_pin attribute denote the path dependency for the

electromigration group. A particular electromigration group is accessed if the input pin

or pins named in the related_pin attribute cause the corresponding output pin named in

the pin group to toggle. All functionally related pins must be specified in a related_pin

attribute if two-dimensional tables are being used.

Cell Electromigration Example

The following example shows a complete cell electromigration model.

library (em) {

...

em_temp_degradation_factor : 40.0;

em_lut_template(output_by_cap) {

variable_1 : total_output_net_capacitance;

index_1 ("0.0, 0.087, 0.272, 0.329");

domain ( best ) {

calc_mode : best;

}

em_lut_template(input_by_trans) {

variable_1 : input_transition_time;

Liberty User Guide Volume 1

R-2020.09

357

Chapter 8: Modeling Power and Electromigration

Modeling Electromigration

index_1 ("0.0, 0.889, 5.0");

}

em_lut_template(output_by_cap_and_trans) {

variable_1 : total_output_net_capacitance;

variable_2 : input_transition_time;

index_1 ("0.0, 0.087, 0.272, 0.329");

index_2 ("0.0, 0.889, 5.0");

}

cell(testcell) {

...

pin(Z) {

...

electromigration() {

em_max_toggle_rate(output_by_cap_and_trans) {

values("0.009, 0.163, 0.758",\

"0.609, 0.628, 0.758",\

"1.792, 1.792, 2.003",\

"2.162, 2.162, 2.313");

}

related_pin : "A";

when : "!A & !Z";

}

electromigration() {

em_max_toggle_rate(output_by_cap) {

values("1.0 2.087 2.272 6.329");

domain ( best ) {

values("1.0 2.087 2.272 6.329");

}

/* related_pin : "Z"; */

when : "!Z";

}

timing(){

...

}

} /* end pin group Z */

...

pin(A) {

direction : input;

capacitance : 1.000;

electromigration() {

em_max_toggle_rate(input_by_trans) {

values("1.0, 2.889, 5.0");

}

/* related_pin : "A"; */

when : "!A";

}

Liberty User Guide Volume 1

R-2020.09

358

Chapter 8: Modeling Power and Electromigration

Modeling Electromigration

electromigration() {

em_max_toggle_rate(input_by_trans) {

values("1.0, 2.889, 5.0");

}

electromigration() {

em_max_toggle_rate(input_by_trans) {

values("1.0, 2.889, 5.0");

}

} /* end pin group A */

} /* end cell */

} /* end library */

Liberty User Guide Volume 1

R-2020.09

359

Advanced Low-Power Modeling

Advanced low-power design methodologies such as multivoltage and multithreshold-

CMOS require special library cells. These cells include power management attributes to

drive implementation tools during library cell selection. This chapter describes the power

and ground (PG) pin syntax and provides modeling examples of the special cells, such as

the level-shifter, isolation, switch, and retention cells.

Note:

To model very deep submicron (VDSM) logic libraries, you must use the PG pin

syntax.

This chapter includes the following sections:

• Power and Ground (PG) Pins

• PG Pin Power Mode Modeling

• Feedthrough Signal Pin Modeling

• Overdrive and Underdrive Voltage Modeling

• Internally Unconnected Pin Modeling

• Silicon-on-Insulator (SOI) Cell Modeling

• Level-Shifter Cells in a Multivoltage Design

• Isolation Cell Modeling

• Switch Cell Modeling

• Retention Cell Modeling

• Always-On Cell Modeling

• Macro Cell Modeling

• Modeling Antenna Diodes

Liberty User Guide Volume 1

R-2020.09

360

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

The syntax supports power and ground (PG) library pins. A power pin is a current source

pin, and a ground pin is a current sink pin. This section provides an overview of PG pins.

Example Libraries With Multiple Power Supplies

Example 88 shows a library with multiple power supplies defined at the library, cell, and pin

levels.

Example 88 Library With a power_supply Group and Power Supplies Defined at the Library,

Cell, and Pin Levels

library(pow) {

...

voltage_unit : "1V";

power_supply() {

default_power_rail : VDD0;

power_rail(VDD1, 5.0);

power_rail(VDD2, 3.3);

}

operating_conditions(WCCOM) {

process : 1.5 ;

temperature : 70 ;

voltage : 4.75 ;

tree_type : "worst_case_tree" ;

power_rail(VDD1, 4.8);

power_rail(VDD2, 2.9);

}

cell(IBUF1) {

...

rail_connection(PV1, VDD1);

rail_connection(PV2, VDD2);

pin(A) {

direction : input;

...

input_signal_level : VDD1;

}

pin(EN) {

direction : input;

...

input_signal_level : VDD1;

}

pin(Z) {

direction : output;

output_signal_level : VDD2;

...

}

pin(Z1) {

direction : inout;

Liberty User Guide Volume 1

R-2020.09

361

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

...

input_signal_level : VDD2;

output_signal_level : VDD2;

}

Example 89 Library Defining All Power Supplies With Nominal Operating Conditions

power_supply() {

default_power_rail : VDD0;

power_rail : (VDD1, 5.0);

power_rail : (VDD2, 3.3 ) ;

}

operating_conditions (MPSCOM) {

process : 1.5;

temperature : 70;

voltage : 4.75;

tree_type : worst_case_tree;

power_rail : (VDD1, 5.8);

power_rail : (VDD2, 3.3);

}

Example 90 Cell With Default Power Supply

cell(with_no_power_supply) {

area : 10;

pin (A) {

direction: input;

capacitance: 1.0;

}

pin (Z) {

direction: output;

function : "!A";

}

} /* end cell */

Example 91 Cell With One Power Supply

cell(with_one_power_supply) {

area : 10;

rail_connection (PV1, VDD1) ;

pin (A) {

direction: input;

capacitance: 1.0;

}

pin (Z) {

direction: output;

function : "!A";

}

} /* end cell */

Liberty User Guide Volume 1

R-2020.09

362

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

Example 92 Cell With Two Power Supplies

cell(with_2_power_supplies) {

area : 0;

rail_connection (PV1, VDD1) ;

rail_connection (PV2, VDD2) ;

pin (A) {

direction: input;

capacitance: 1.0;

input_signal_level: VDD1;

}

pin (EB) {

direction: input;

capacitance: 1.0;

input_signal_level: VDD1;

}

pin (Z) {

direction: output;

function : "A";

three_state: "EB";

output_signal_level: VDD2;

}

} /* end cell */

Example 93 Cell With Two Power Supplies and a Bidirectional Pin

cell(bidir_with_2_power_supplies) {

area : 0

rail_connection (PV1, VDD1) ;

rail_connection (PV2, VDD2) ;

pin(PAD) {

direction : inout;

function : "A";

three_state : "EN";

input_signal_level: VDD1;

output_signal_level: VDD2;

}

pin(A) {

direction : input;

capacitance : 3;

input_signal_level: VDD1;

}

pin(EN) {

direction : input;

capacitance : 3;

input_signal_level: VDD1;

}

pin(X) {

direction : output;

function : "PAD";

output_signal_level: VDD2;

}

} /* end cell */

Liberty User Guide Volume 1

R-2020.09

363

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

Partial PG Pin Cell Modeling

Partial PG pin cells are cells that have only power pins, only ground pins, or do not have

power or ground PG pins.

Table 25 Categories of Partial PG Pin Cells

Partial PG Pin Cell Description

Cells with one power pin and one ground pin These cells are defined as having

• One or more primary power PG pins

•

One or more primary ground PG pins

•

Zero, or at least one, backup or internal power

PG pins

•

Zero, or at least one, backup or internal ground

PG pins

•

Zero, or at least one, nwell bias PG pins

• Zero, or at least one, pwell bias PG pins

Cells with one power pin and no ground pins These cells are defined as having

• One or more primary power PG pins

• No primary ground PG pins

•

Zero, or at least one, backup or internal power

PG pins

•

Zero, or at least one, backup or internal ground

PG pins

•

Zero, or at least one, nwell bias PG pins

•

Zero, or at least one, pwell bias PG pins

Liberty User Guide Volume 1

R-2020.09

364

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

Partial PG Pin Cell Description

Cells with no power pins and one ground pin These cells are defined as having

• No primary power PG pins

•

At least one primary ground PG pin

•

Zero, or at least one, backup or internal power

PG pins

•

Zero, or at least one, backup or internal ground

PG pins

•

Zero, or at least one, nwell bias PG pins

• Zero, or at least one, pwell bias PG pins

Cells with no power pins or ground pins These cells are defined as having

• No primary power PG pins

• No primary ground PG pins

•

No backup or internal power PG pin

•

No backup or internal ground PG pin

• Zero, or at least one, nwell bias PG pins

•

Zero, or at least one, pwell bias PG pins

Special Partial PG Pin Cells

The following types of partial PG pin cells are acceptable with certain conditions.

•

ETM cells

ETM cells do not need a pair of PG pins. A cell is identified as an ETM cell if it has the

interface_timing or timing_model_type attribute.

•

Black box cells

A black box cell with no timing, noise, or power information does not need at least one

power pin and one ground PG pin.

•

Metal fills and antenna cells

Black box cells without functions do not need at least power pin and one ground pin.

Liberty User Guide Volume 1

R-2020.09

365

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

• Cells without signal pins

Cells without signal pins do not need at least one power pin and one ground PG pin.

• Load cells

Cells without inout or output signal pins require either a power or a ground pin, but it is

not necessary to have both.

•

Tied-off cells and extensions

The following types of cells can be specified with one power pin and no ground PG

pins:

◦

Cells with at least one inout or output pin with the function attribute set to 1.

◦

Cells with a pull-up signal, for example with the driver_type attribute set to

pull_up or pull_up_function.

◦ Cells with a resistive_1 signal, for example with the driver_type attribute set to

resistive_1 or resistive_1_function.

The following types of cells can be specified with no power pins and one ground PG

pin:

◦

Cells with at least one inout or output pin with the function attribute set to 0.

◦

Cells with a pull-down signal, for example with the driver_type attribute set to

pull_down or pull_down_function.

◦

Cells with a resistive_0 signal, for example with the driver_type attribute set to

resistive_0 o resistive_0_function.

Supported Attributes

Cells with at least one power pin and no ground pins, cells with no power pins and at

least one ground pin, and cells with no power pins or ground pins support the following

attributes:

•

To prevent a cell from being automatically inserted into the netlist, specify the

dont_touch or the dont_use attribute. The dont_touch attribute set to true indicates

that all instances of the cell must remain in the network. The dont_use attribute set to

true indicates that a cell must not be added to a design during optimization.

•

Cells with partial PG pins are reported using the following attributes:

◦ 1p0g

Reports cells with at least one power pin and no ground PG pins.

Liberty User Guide Volume 1

R-2020.09

366

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

◦ 0p1g

Reports cells with no power pins and at least one ground PG pin.

◦ 0p0g

Reports cells with no power pins or ground PG pins.

For more information about library reports for partial PG pin cells, see the “Generating

Library Reports” chapter in the Library Quality Assurance System User Guide.

Partial PG Pin Cell Example

Example 94 shows a cell with only one primary ground pin.

Example 94 Partial PG Pin Cell With Only One Primary Ground Pin

cell (PULLDOWN) {

pg_pin ( VSS ) {

voltage_name : VSS;

pg_type : primary_ground;

}

area : 1.0;

dont_touch : true;

dont_use : true;

pin (X) {

related_ground_pin : VSS;

direction : output;

function : "0";

three_state : "!A";

max_capacitance : 0.19;

timing() {

related_pin : "A";

timing_type : three_state_enable;

cell_rise(scalar) { values ( "0.1");}

rise_transition(scalar) { values ( "0.1");}

cell_fall(scalar) { values ( "0.1");}

fall_transition(scalar) { values ( "0.1");}

}

timing() {

related_pin : "A";

timing_type : three_state_disable;

cell_rise(scalar) { values ( "0.1");}

rise_transition(scalar) { values ( "0.1");}

cell_fall(scalar) { values ( "0.1");}

fall_transition(scalar) { values ( "0.1");}

}

pin (A) {

related_ground_pin : VSS;

Liberty User Guide Volume 1

R-2020.09

367

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

direction : input;

capacitance : 0.1;

rise_capacitance : 0.1;

rise_capacitance_range (0.1, 0.2);

fall_capacitance : 0.1;

fall_capacitance_range (0.1, 0.2);

}

PG Pin Syntax

The power and ground pin syntax for generic cells is as follows:

library(library_name) {

...

voltage_map(voltage_name, voltage_value);

...

operating_conditions(oc_name) {

...

voltage : value;

...

}

...

default_operating_conditions : oc_name;

cell(cell_name) {

pg_pin (pg_pin_name_p1) {

voltage_name : voltage_name_p1;

pg_type : type_value;

}

pg_pin (pg_pin_name_g1) {

voltage_name : voltage_name_g1;

pg_type : type_value;

}

pg_pin (pg_pin_name_p2) {

voltage_name : voltage_name_p2;

pg_type : type_value;

}

pg_pin (pg_pin_name_g2) {

voltage_name : voltage_name_g2;

pg_type : type_value;

}

...

leakage_power() {

related_pg_pin : pg_pin_name_p1;

...

}

...

pin (pin_name1) {

direction : input | inout;

related_power_pin : pg_pin_name_p1;

related_ground_pin : pg_pin_name_g1;

Liberty User Guide Volume 1

R-2020.09

368

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

...

}

...

pin (pin_name2) {

direction : inout | output;

power_down_function : (!pg_pin_name_p1 + !pg_pin_name_p2 + \

!pg_pin_name_g1 + !pg_pin_name_g2) ;

related_power_pin : pg_pin_namen_p2;

related_ground_pin : pg_pin_namen_g2;

output_signal_voltage_low : float;

output_signal_voltage_high : float;

timing () {

...

output_signal_voltage_low : float;

output_signal_voltage_high : float;

}

internal_power() {

related_pg_pin : pg_pin_name_p2;

...

} /* end internal_power group */

...

}/* end pin group*/

...

}/* end cell group*/

...

}/* end library group*/

Library-Level Attributes

This section describes library-level attributes.

voltage_map Complex Attribute

The voltage_map attribute associates the voltage name with the relative voltage values.

These voltage names are referenced by the pg_pin groups defined at the cell level. When

specified in a library, this attribute identifies the library as a power and ground pin library.

At least one voltage map in the library should have a value of 0, which becomes the

reference value to which other voltage map values relate.

default_operating_conditions Simple Attribute

The default_operating_conditions attribute specifies the name of the default

operating_conditions group in the library, which helps to identify the operating

condition process, voltage, and temperature (PVT) points that are used during library

characterization.

Cell-Level Attributes

This section describes cell-level attributes for pg_pin groups.

Liberty User Guide Volume 1

R-2020.09

369

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

pg_pin Group

The pg_pin groups are used to represent the power and ground pins of a cell. Library

cells can have multiple power and ground pins. The pg_pin groups are mandatory for

each cell using the power and ground pin syntax, and a cell must have at least one

primary_power power pin and at least one primary_ground ground pin.

is_pad Simple Attribute

The is_pad attribute identifies a pad pin on any I/O cell. The valid values are true and

false. You can also specify the is_pad attribute on a PG pin. If the cell-level pad_cell

attribute is specified on an I/O cell, you must set the is_pad attribute to true in either a

pg_pin group or on a signal pin for that cell.

voltage_name Simple Attribute

The voltage_name string attribute is mandatory in all pg_pin groups except for a level-

shifter cell not powered by the switching power domains. The voltage_name attribute

specifies the associated voltage name of the power and ground pin defined using the

voltage_map complex attribute at the library level.

Note:

To allow implementation tools to include a level-shifter cell not powered by

the switching domains in any other power domain, the voltage value of the

PG pin with the std_cell_main_rail attribute is ignored. So for this cell,

the voltage_name attribute is optional in the pg_pin group that has the

std_cell_main_rail attribute and not connected to the signal pins.

pg_type Simple Attribute

The pg_type attribute, optional in pg_pin groups, specifies the type of power and

ground pin. The pg_type attribute can have the following values: primary_power,

primary_ground, backup_power, backup_ground, internal_power, internal_ground,

pwell, nwell, deepnwell and deeppwell.

The pg_type attribute also supports substrate-bias modeling. Substrate bias is a

technique in which a bias voltage is varied on the substrate terminal of a CMOS device.

This increases the threshold voltage, the voltage required by the transistor to switch, which

helps reduce transistor power leakage. The pg_type attribute provides the pwell, nwell,

deepnwell and deeppwell values to support substrate-bias modeling. The pwell and

nwell values specify regular wells, and deeppwell and deepnwell specify isolation wells.

Table 26 describes the pg_type values.

Liberty User Guide Volume 1

R-2020.09

370

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

Table 26 pg_type Values

Value Description

primary_power Specifies that pg_pin is a primary power source (the default).

If the pg_type attribute is not specified, primary_power is

the pg_type value.

primary_ground Specifies that pg_pin is a primary ground source.

backup_power Specifies that pg_pin is a backup (secondary) power source

(for retention registers, always-on logic, and so on).

backup_ground Specifies that pg_pin is a backup (secondary) ground source

(for retention registers, always-on logic, and so on).

internal_power Specifies that pg_pin is an internal power source for switch

cells.

internal_ground Specifies that pg_pin is an internal ground source for switch

cells.

pwell Specifies regular p-wells for substrate-bias modeling.

nwell Specifies regular n-wells for substrate-bias modeling.

deepnwell Specifies isolation n-wells for substrate-bias modeling.

deeppwell Specifies isolation p-wells for substrate-bias modeling.

physical_connection Simple Attribute

The physical_connection attribute can have the following values: device_layer and

routing_pin. The device_layer value specifies that the bias connection is physically

external to the cell. In this case, the library provides biasing tap cells that connect through

the device layers. The routing_pin value specifies that the bias connection is inside a

cell and is exported as a physical geometry and a routing pin. Macros with pin access

generally use the routing_pin value if the cell has bias pins with geometry that is visible

in the physical view.

related_bias_pin Attribute

The related_bias_pin attribute defines all bias pins associated with a power or ground

pin within a cell. The related_bias_pin attribute is required only when the attribute is

declared in a pin group but it does not specify a complete relationship between the bias

pin and power and ground pin for a library cell.

The related_bias_pin attribute also defines all bias pins associated with a signal pin.

To associate substrate-bias pins to signal pins, use the related_bias_pin attribute

Liberty User Guide Volume 1

R-2020.09

371

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

to specify one of the following pg_type values: pwell, nwell, deeppwell, deepnwell.

Figure 55 shows transistors with p-well and n-well substrate-bias pins.

Figure 55 Transistors With p-well and n-well Substrate-Bias Pins

user_pg_type Simple Attribute

The user_pg_type optional attribute allows you to customize the type of power and

ground pin. It accepts any string value. The following example shows a pg_pin library with

the user_pg_type attribute specified.

pg_pin (pg_pin_name) {

voltage_name : voltage_name;

pg_type : primary_power | primary_ground |

backup_power | backup_ground |

internal_power | internal_ground;

user_pg_type : user_pg_type_name;

}

Pin-Level Attributes

This section describes pin-level attributes.

direction Attribute

The direction attribute declares a pin as being an input, output, inout (bidirectional),

or internal pin. The default is input.

power_down_function Attribute

The power_down_function string attribute specifies the Boolean condition under which

the cell’s output pin is switched off by the state of the power and ground pins (when the

cell is in off mode due to the external power pin states).

Liberty User Guide Volume 1

R-2020.09

372

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

You specify the power_down_function attribute for combinational and sequential cells.

For simple and complex sequential cells, power_down_function also determines the

condition of the cell’s internal state.

For more information about using the power_down_function attribute for sequential cells,

see Chapter 5, Defining Sequential Cells”.

related_power_pin and related_ground_pin Attributes

The related_power_pin and related_ground_pin attributes associate a predefined

power and ground pin with the signal pin, in which they are defined. This behavior only

applies to standard cells. For special cells, explicitly specify this relationship.

The pg_pin groups are mandatory for each cell. Because a cell must have at least one

primary_power and at least one primary_ground pin, a default related_power_pin and

related_ground_pin always exists in any cell.

output_signal_level_low and output_signal_level_high Attributes

You can define the output_signal_level_low and output_signal_level_high

attributes for output and inout pins. The regular signal swings are derived for regular cells

using the related_power_pin and related_ground_pin specifications.

You can also define the output_signal_level_low and output_signal_level_high

attributes in timing arcs. See output_signal_level_low and output_signal_level_high

Attributes on page 374.

input_signal_level_low and input_signal_level_high Attributes

The input_signal_level_low and input_signal_level_high attributes can be defined

at the pin level for the input pins. The regular signal swings are derived for regular cells

using the related_power_pin and related_ground_pin specifications.

related_pg_pin Attribute

The related_pg_pin attribute is used to associate a power and ground pin with leakage

power and internal power tables. (The leakage power and internal power tables must be

associated with the cell’s power and ground pins.)

In the absence of a related_pg_pin attribute, the internal_power and leakage_power

specifications apply to the whole cell (cell-specific power specification).

Timing-Level Attributes

This section describes timing-level attributes.

Liberty User Guide Volume 1

R-2020.09

373

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

output_signal_level_low and output_signal_level_high Attributes

The optional output_signal_level_low and output_signal_level_high attributes

specify the actual output voltages of an output pin after a transition through a timing arc.

The output_signal_level_low attribute specifies the minimum voltage after a falling

transition to state 0.

The output_signal_level_high attribute specifies the maximum voltage value after a

rising transition to state 1.

Define the output_signal_level_low and output_signal_level_high attributes in the

timing group when the following occur together:

•

The cell output exhibits partial voltage swing (and not rail-to-rail swing).

•

The voltages are different in different timing arcs.

Specify the voltages with respect to the voltage_unit defined in the library. The voltage

values that you specify in the timing group override the voltages specified under the pin

group. The attributes do not have a default.

Specifying Delay and Slew Attributes in Voltage Range

When partial voltage swing is defined in a pin or a timing group, the nonlinear

delay model (NLDM) data in that group is for the partial swing. You must apply

the following threshold and trip point attributes only in the voltage range from the

output_signal_level_low value to the output_signal_level_high value:

•

input_threshold_pct_rise

•

output_threshold_pct_rise

• input_threshold_pct_fall

•

output_threshold_pct_fall

•

slew_lower_threshold_pct_rise

• slew_upper_threshold_pct_rise

•

slew_lower_threshold_pct_fall

•

slew_upper_threshold_pct_fall

The following example shows a library description with the output_signal_level_low

and output_signal_level_high attributes defined in both the pin and the timing

groups.

library (lib1) {

…

cell (cell1) {

Liberty User Guide Volume 1

R-2020.09

374

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

…

pin(pin1) {

direction: output;

output_signal_level_low: 0.15;

output_signal_level_high: 0.75;

timing() {

…

related_pin : "CLKIN" ;

timing_type : rising_edge ;

output_signal_level_low: 0.1;

output_signal_level_high: 0.7;

…

} /* end of timing */

…

} /* end of pin */

…

} /* end of cell */

…

} /* end of library */

Standard Cell With One Power and Ground Pin Example

Figure 56 shows a standard cell with a power and ground pin. The figure is followed by an

example.

Figure 56 Standard Cell Buffer Schematic

library(standard_cell_library_example) {

voltage_map(VDD, 1.0);

voltage_map(VSS, 0.0);

operating_conditions(XYZ) {

Liberty User Guide Volume 1

R-2020.09

375

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

voltage : 1.0;

...

}

default_operating_conditions : XYZ;

cell(BUF) {

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

leakage_power() {

related_pg_pin : VDD;

when : "!A";

value : 1.5;

}

pin(A) {

related_power_pin : VDD;

related_ground_pin : VSS;

}

pin(Y) {

direction : output;

power_down_function : "!VDD + VSS";

related_power_pin : VDD;

related_ground_pin : VSS;

timing() {

related_pin : A;

cell_rise(template) {

...

}

cell_fall(template) {

...

}

rise_transition(template) {

...

}

fall_transition(template) {

...

}

internal_power() {

related_pin : A;

related_pg_pin : VDD;

...

}

Liberty User Guide Volume 1

R-2020.09

376

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

}/* end pin group*/

...

}/*end cell group*/

...

}/*end library group*/

Inverter With Substrate-Bias Pins Example

Figure 57 shows an inverter with substrate-bias pins. The figure is followed by an

example.

Figure 57 Inverter With Substrate-Bias Pins

library(low_power_cells) {

delay_model : table_lookup;

/* unit attributes */

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1mA";

pulling_resistance_unit : "1kohm";

leakage_power_unit : "1pW";

capacitive_load_unit (1.0,pf);

voltage_map(VDD, 0.8); /* primary power */

voltage_map(VSS, 0.0); /* primary ground */

voltage_map(VNW, 0.8); /* bias power */

voltage_map(VPW, 0.0); /* bias ground */

Liberty User Guide Volume 1

R-2020.09

377

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

/* operation conditions */

operating_conditions(XYZ) {

process: 1;

temperature: 125;

voltage: 0.8;

tree_type: balanced_tree

}

default_operating_conditions : XYZ;

/* threshold definitions */

slew_lower_threshold_pct_fall : 30.0;

slew_upper_threshold_pct_fall : 70.0;

slew_lower_threshold_pct_rise : 30.0;

slew_upper_threshold_pct_rise : 70.0;

input_threshold_pct_fall : 50.0;

input_threshold_pct_rise : 50.0;

output_threshold_pct_fall : 50.0;

output_threshold_pct_rise : 50.0;

/* default attributes */

default_cell_leakage_power: 0.0;

default_fanout_load: 1.0;

default_output_pin_cap: 0.0;

default_inout_pin_cap: 0.1;

default_input_pin_cap: 0.1;

default_max_transition: 1.0;

cell(std_cell_inv) {

cell_footprint : inv;

area : 1.0;

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

related_bias_pin : "VNW";

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

related_bias_pin : "VPW";

}

pg_pin(VNW) {

voltage_name : VNW;

pg_type : nwell;

physical_connection : device_layer;

}

pg_pin(VPW) {

voltage_name : VPW;

pg_type : pwell;

physical_connection : device_layer;

}

pin(A) {

direction : input;

Liberty User Guide Volume 1

R-2020.09

378

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

capacitance : 1.0;

related_power_pin : VDD;

related_ground_pin : VSS;

related_bias_pin : "VPW VNW";

}

pin(Y) {

direction : output;

function : "A'";

related_power_pin : VDD;

related_ground_pin : VSS;

related_bias_pin : "VPW VNW";

power_down_function : "!VDD + VSS + VNW' + VPW";

internal_power() {

related_pg_pin : VDD;

related_pin : "A";

rise_power(scalar) { values ( "1.0");}

fall_power(scalar) { values ( "1.0");}

}

timing() {

related_pin : "A";

timing_sense : positive_unate;

cell_rise(scalar) { values ( "0.1");}

rise_transition(scalar) { values ( "0.1");}

cell_fall(scalar) { values ( "0.1");}

fall_transition(scalar) { values ( "0.1");}

}

max_capacitance : 0.1;

}

cell_leakage_power : 1.0;

leakage_power() {

when :"!A";

value : 1.5;

}

leakage_power() {

when :"A";

value : 0.5;

}

Insulated Bias Modeling

Example 95 is a .lib description of a low-power library with the following two cells:

•

An always-on cell with an insulated bias PG pin

•

A cell where the bias PG pin is tied to the primary power supply

Liberty User Guide Volume 1

R-2020.09

379

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

Figure 58 shows the schematics of these cells.

Figure 58 An Always-On Cell With Insulated Bias and Cell Where the Bias PG pin is Tied to

Primary Power

Example 95 A Low-Power Library Using the is_insulated and tied_to Attributes

library (mylib) {

delay_model : table_lookup;

/* library unit and slew attributes */

voltage_map(VDD, 1.0); /* Primary Power */

voltage_map(VSS, 0.0); /* Primary Ground */

voltage_map(VDDB, 1.0); /* Backup Power */

Liberty User Guide Volume 1

R-2020.09

380

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

voltage_map(VSSB, 0.0); /* Backup Ground */

voltage_map(VPW, 1.0); /* nwell */

voltage_map(VNW, 0.0); /* pwell */

voltage_map(VPW_INS, 1.0); /* insulated nwell */

voltage_map(VNW_INS, 0.0); /* insulated pwell */

/* operation conditions */

nom_process : 1.0;

nom_temperature : 25;

nom_voltage : 1.0;

operating_conditions(XYZ) {

process : 1.0;

temperature : 25;

voltage : 1.0;

tree_type : balanced_tree

}

default_operating_conditions : XYZ;

/* AO cell with insulated bias pg_pins */

cell(AO_with_insulated_bias) {

area : 1.0;

…

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

related_bias_pin : VPW;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

related_bias_pin : VNW;

}

pg_pin(VDDB) {

voltage_name : VDDB;

pg_type : backup_power;

related_bias_pin : VPW_INS;

}

pg_pin(VSSB) {

voltage_name : VSSB;

pg_type : backup_ground;

related_bias_pin : VNW_INS;

}

pg_pin(VPW) {

voltage_name : VPW;

pg_type : nwell;

direction : inout;

physical_connection : device_layer;

}

pg_pin(VNW) {

voltage_name : VNW;

pg_type : pwell;

direction : inout;

physical_connection : device_layer;

Liberty User Guide Volume 1

R-2020.09

381

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

}

pg_pin(VNW_INS) {

pg_type : pwell;

voltage_name : VNW_INS;

is_insulated : true;

tied_to : VSSB;

direction : internal;

}

pg_pin(VPW_INS) {

pg_type : nwell;

voltage_name : VPW_INS;

is_insulated : true;

tied_to : VDDB;

direction : internal;

}

pin(A) {

direction : input;

related_power_pin : VDDB;

related_ground_pin : VSSB;

…

}

pin(Y) {

direction : output;

function : "A";

related_power_pin : VDDB;

related_ground_pin : VSSB;

power_down_function : "!VDDB + !VPW_INS + VSSB + VNW_INS";

…

} /* end pin group */

} /* end cell group */

/* cell with bias pg_pin tied to Primary Power */

cell(cell_with_bias_pg_pin_tied_to_power) {

area : 1.0;

…

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

related_bias_pin : VPW;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

related_bias_pin : VNW;

}

pg_pin(VDDB) {

voltage_name : VDDB;

pg_type : backup_power;

related_bias_pin : VPW_INS;

}

pg_pin(VPW) {

voltage_name : VPW;

pg_type : nwell;

Liberty User Guide Volume 1

R-2020.09

382

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

direction : inout;

tied_to : VDD;

}

pg_pin(VNW) {

voltage_name : VNW;

pg_type : pwell;

direction : inout;

physical_connection : device_layer;

}

pin(A) {

direction : input;

related_power_pin : VDDB;

related_ground_pin : VSSB;

…

}

pin(Y) {

direction : output;

function : "A";

related_power_pin : VDDB;

related_ground_pin : VSSB;

power_down_function : "!VDDB + !VPW + VSSB + VNW";

…

} /* end pin group */

} /* end cell group */

} /* end library group */

Same PG Pin as Both Power Pin and Ground Pin

Typically in a cell, a supply rail provides either power or ground voltage. In the complex

power scheme for a macro cell or a pad cell, the same supply might simultaneously act as

a power rail for some section and as a ground rail for some other section.

To enable compiling cells containing such complex signal pin,

related_power_pin and related_ground_pin associations, set the

lc_allow_same_pg_pin_as_related_power_and_ground variable to true, as shown:

lc_allow_same_pg_pin_as_related_power_and_ground true

The default value is false.

Some recommendations to model such a cell are as follows:

•

Specify the PG pin with the highest voltage as a power pin.

•

Specify the PG pin with the lowest voltage as a ground pin.

•

For rest of the PG pins, specify the ones with voltage above 0.0 V as power pins, and

the ones with voltage equal and less than 0.0 V as ground pins.

•

The power_down_function Boolean expression of the related power pin must have

negative logic.

Liberty User Guide Volume 1

R-2020.09

383

Chapter 9: Advanced Low-Power Modeling

Power and Ground (PG) Pins

• The power_down_function Boolean expression of the related ground pin must have

positive logic.

Figure 59 shows the schematic of a cell that uses the pin, VSS with voltage 0.0 V, as both

the related power pin and the related ground pin. The subsequent Liberty snippet shows

the PG pin model for the cell.

Figure 59 A Cell With Same Pin as Both Power Pin and Ground Pin

cell(same_pin_both_pg1) {

pg_pin(VDD_PHY){

pg_type: primary_power ;

}

pg_pin(VSS){

pg_type: primary_ground ;

}

pg_pins(VDD_NEG){

pg_type: primary_ground ;

}

pin(OUT1) {

related_power_pin: "VDD_PHY" ;

related_ground_pin: "VSS" ;

power_down_function: "!VDD_PHY + VSS" ;

}

pin(OUT2) {

related_power_pin: "VSS" ;

related_ground_pin: "VDD_NEG";

power_down_function: "!VSS + VDD_NEG" ;

}

Liberty User Guide Volume 1

R-2020.09

384

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

Figure 60 shows the schematic of a cell that uses the pin, VDDL with a positive voltage

value, as both the power pin and the ground pin. The following Liberty snippet shows the

PG pin model for the cell.

Figure 60 A Cell With a Positive Voltage Pin as Both Power Pin and Ground Pin

cell(same_pin_both_pg2) {

pg_pin(VDDH) {

pg_type: primary_power ;

}

pg_pin(VDDL){

pg_type: primary_power ;

}

pg_pins(VSS){

pg_type: primary_ground ;

}

pin(OUT1) {

related_power_pin: "VDDH" ;

related_ground_pin: "VDDL" ;

power_down_function: "!VDDH + VDDL" ;

}

pin(OUT2){

related_power_pin: "VDDL" ;

related_ground_pin: "VSS" ;

power_down_function: "!VDDL + VSS" ;

}

PG Pin Power Mode Modeling

In complex library cells such as retention and macro cells, power pins can have more

power states (or PG modes) apart from the regular ON and OFF states. The following

syntax allows you to model such power states of PG pins and the relationship between

these states, so that complex power states or modes can be captured.

Liberty User Guide Volume 1

R-2020.09

385

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

The syntax enables you to

• Extend power supply state and voltage range definitions

•

Define system power states as function of power supplies

• Define transitions between system power states

•

Associate a PG mode to each conditional timing, power, and noise group

Syntax

library (library_name) {

voltage_map (voltage_name, voltage_value);

voltage_state_range_list (voltage_name) {

voltage_state_range(pg_state, nom_voltage);

voltage_state_range(pg_state, min_voltage, max_voltage);

voltage_state_range(pg_state, min_voltage,

nom_voltage, max_voltage);

…

} /* end voltage_state_range_list group */

cell (cell_name) {

pg_pin (pg_name) {

voltage_name : volt_name;

…

} /* end pg_pin group */

pg_setting_definition (psd_name) {

pg_setting_value(psv_name) {

pg_pin_active_state (pg_pin, pg_state);

pg_pin_condition : Boolean expression of PG and signal pins;

pg_setting_active_state (psd_name2, psv_name2);

pg_setting_condition : Boolean expression of

psd_name2 and signal pin;

} /* end pg_setting_value group */

default_pg_setting : psv_name;

pg_setting_transition (pst_name) {

is_illegal : true | false;

start_setting : psv_name;

end_setting : psv_name;

} /* end pg_setting_transition group */

illegal_transition_if_undefined : true | false;

} /* end pg_setting_definition group */

mode_definition (mode_def) {

mode_value (mode_name) {

Liberty User Guide Volume 1

R-2020.09

386

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

pg_setting (psd_name, psv_name);

} /* end mode_value group */

} /* end mode_definition group */

pin (pin_name) {

minimum_period([minimum_period_name]){

mode(mode_def_name, mode_name);

} /* end minimum_period group */

min_pulse_width([min_pulse_width_name]) {

mode(mode_def_name, mode_name);

} /* end min_pulse_width group */

} /* end pin group */

} /* end cell group */

} /* end library group */

Library-Level Groups and Attributes

Use the following syntax to model power and ground (PG) modes other than the regular

on and off states.

voltage_state_range_list Group

The voltage_state_range_list group defines the voltage range of all the states

for a specified power rail. It only applies to a power rail with multiple states. The name

of the group (voltage_name) is a power rail name, which must also be defined in the

same library using the voltage_map attribute. Each voltage_name can have only one

corresponding voltage_state_range_list group.

voltage_state_range Attribute

The voltage_state_range attribute defines the corner-independent operating

voltages for the state, pg_state, of the power rail. Specify this attribute in the

voltage_state_range_list group.

Syntax

voltage_state_range_list (voltage_name) {

voltage_state_range(pg_state, nom_voltage);

voltage_state_range(pg_state, min_voltage, max_voltage);

voltage_state_range(pg_state, min_voltage, nom_voltage, max_voltage);

•

pg_state is the state name of the power rail

•

The value can be a nominal voltage, a pair specifying the minimum and maximum

voltages, or a triplet specifying the minimum, nominal and maximum voltages.

◦

min_voltage and max_voltage are floating-point numbers for the minimum and

maximum operating voltage of the state.

Liberty User Guide Volume 1

R-2020.09

387

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

◦ nom_voltage is a floating-point number and the default operating voltage that

applies to all designs. The instance-specific nominal voltage specification at the top-

design level overrides the default nominal voltage.

◦ These values represent the nominal voltage range and do not include the power

supply uncertainty or tolerance.

•

For each pg_state defined in the voltage_state_range_list group:

◦ min_voltage must be less than or equal to max_voltage or nom_voltage.

◦

nom_voltage must be less than or equal to max_voltage.

◦ Different pg_state can have overlapped operating voltage range.

Example

voltage_map (VDD, 0.8);

voltage_state_range_list(VDD) {

voltage_state_range(normal, 0.81, 0.9, 0.99);

voltage_state_range(under_drive, 0.665, 0.77);

voltage_state_range(on, 0.7);

}

Cell-Level Groups and Attributes

Use the following syntax to define the system power states as a function of the power

supply states, and the legality of transition between these power states.

pg_setting_definition Group

The pg_setting_definition group defines the following:

•

The system power states (pg_setting_value group).

•

The legality of transitions (pg_setting_transition group) between the system power

states.

• The default power state of the cell.

•

The legality of undefined transitions.

psd_name is the name of the pg_setting_definition group. The system power states

must be mutually exclusive.

Syntax

pg_setting_definition(psd_name) {

…

}

Liberty User Guide Volume 1

R-2020.09

388

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

psd_name is the name of the pg_setting_definition group. The system power states

must be mutually exclusive.

Example

pg_setting_definition(psd) {

…

}

pg_setting_value Group

The pg_setting_value group defines a system power state named psv_name. Specify

this group in the pg_setting_definition group.

•

You must define all the legal power states. Undefined power states are considered

illegal.

•

A legal power state is a state that is expected to occur during normal operation.

• An illegal power state is a state that is not expected to occur during normal operation.

Syntax

pg_setting_value (psv_name) {

pg_pin_active_state (pg_pin, pg_state);

pg_pin_condition : Boolean expression of pg_pin and pin;

pg_setting_active_state (psd_name2, psv_name2);

pg_setting_condition : Boolean expression of psd_name2 and pin;

}

Example

pg_setting_definition(psd) {

pg_setting_value (psv1) {

…

}

The pg_setting_value group contains the following attributes.

pg_pin_active_state and pg_pin_condition Attributes

These attributes define a system power state as the function of the PG pins and the signal

pins in the pg_setting_value group.

The pg_pin_active_state complex attribute defines the active power supply state,

pg_state, for a specified PG pin. The attribute only applies to a multi-state power supply.

For a PG pin with a single state, the pin is active when it is on.

The pg_pin_condition attribute specifies the logic condition when the system is in the

power state named psv_name. For a single-state PG pin, this condition evaluates to true

when the PG pin is in the on state. For a multi-state PG pin, this condition evaluates to

Liberty User Guide Volume 1

R-2020.09

389

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

true whenever the PG pin is in the active state specified by the pg_pin_active_state

attribute.

Syntax

pg_setting_value (psv_name) {

pg_pin_active_state (pg_pin, pg_state);

pg_pin_condition : Boolean expression of pg_pin and signal pin;

}

Example

pg_setting_definition (psd) {

pg_setting_value (on) {

pg_pin_active_state(VDD, normal);

pg_pin_condition : "VDD * !VSS" ;

}

pg_setting_value (sleep) {

pg_pin_active_state(VDD, under_drive);

pg_pin_condition : "VDD * !VSS * sig_sleep" ;

}

pg_setting_active_state and pg_setting_condition Attributes

These attributes define a system power state as a function of other system power states

and signal pins in the pg_setting_value group. Because they define the system power

states hierarchically, you do not need to repeat the complete list of PG pin conditions and

states for a large block.

The pg_setting_active_state complex attribute specifies the active system power

state, psv_name2, of another pg_setting_definition group (named psd_name2) in the

system power state, psv_name.

The pg_setting_condition attribute specifies the logic condition when the system is in

the power state, psv_name. This condition evaluates to true whenever psd_name2 is in the

active state specified by the pg_setting_active_state attribute.

Syntax

pg_setting_value (psv_name) {

pg_setting_active_state (psd_name2, psv_name2);

pg_setting_condition : Boolean expression of psd_name2 & signal pin;

}

Example

pg_setting_definition(psd) {

pg_setting_value (psv1) {… }

pg_setting_value (psv2) {… }

}

pg_setting_definition(psd2) {

Liberty User Guide Volume 1

R-2020.09

390

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

pg_setting_value (psv1) {… }

pg_setting_value (psv2) {… }

}

pg_setting_definition(top_psd) {

pg_setting_value (psv1) {

pg_setting_active_state(psd, psv1);

pg_setting_active_state(psd2, psv2);

pg_setting_condition : "psd * psd2" ;

}

pg_setting_value (psv2) {

pg_setting_active_state(psd, psv2);

pg_setting_active_state(psd2, psv1);

pg_setting_condition : "psd * psd2" ;

}

default_pg_setting Attribute

The default_pg_setting attribute specifies a default power state to match when

the explicitly defined power states do not completely cover the state space of the

pg_setting_definition group. The default power state also acts as the initial power

state of the pg_setting_definition group.

psv_name is the name of a pg_setting_value group specified in the same

pg_setting_definition group.

Syntax

pg_setting_definition (psd_name) {

...

default_pg_setting : psv_name ;

}

Example

pg_setting_definition (psd) {

default_pg_setting : "psv1" ;

}

pg_setting_transition Group

The pg_setting_transition group specifies the legal and illegal transitions between the

PG modes defined in the pg_setting_definition group.

pst_name is the name you assign to the transition.

Syntax

pg_setting_transition (pst_name) {

is_illegal : [ true | false ];

start_setting : psv_name1;

end_setting : psv_name2;

Liberty User Guide Volume 1

R-2020.09

391

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

}

pst_name is the name you assign to the transition.

Example

pg_setting_transition (sleep) {

start_setting : on;

end_setting : sleep;

}

The pg_setting_transition group contains the following attributes.

is_illegal Attribute

The is_illegal attribute specifies if the transition, pst_name, is illegal. The default is

false.

start_setting and end_setting Attributes

The start_setting attribute specifies the power state from where the transition,

pst_name, starts. The end_setting attribute specifies the power state where the

transition, pst_name, ends. Both the power states must be defined in the same

pg_setting_definition group.

If you do not specify the start_setting attribute, it means that all the power states in the

same pg_setting_definition group can be the start states for the transition, pst_name.

If you do not specify the end_setting attribute, it means that all the power states in the

same pg_setting_definition group can be the end states for the transition, pst_name.

illegal_transition_if_undefined Attribute

The illegal_transition_if_undefined attribute, if set to true, means that all the

undefined transitions in the pg_setting_definition group are illegal or invalid. By

default, all undefined transitions are valid.

Syntax

pg_setting_definition(psd_name) {

illegal_transition_if_undefined : true | false ;

}

Specifying Power States in Timing, Power, and Noise Models

Use the following syntax to make the conditional timing, power, and noise models power-

state aware and to address frequency-scaled power states.

Liberty User Guide Volume 1

R-2020.09

392

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

pg_setting Attribute in mode_value Group

The pg_setting complex attribute specifies the power state of a cell mode by referencing

a power state (psv_name) defined in the pg_setting_definition group of the cell.

You can define multiple pg_setting attributes in a mode_value group provided

each of the pg_setting attributes references a power state from a different

pg_setting_definition group.

Syntax

cell (cell_name) {

mode_definition (mode_def) {

mode_value (mode_name) {

pg_setting (psd_name, psv_name);

}

mode Attribute in minimum_period and min_pulse_width Groups

The mode complex attribute enables conditional data modeling in the frequency-scaled

groups, that is, the minimum_period and min_pulse_width groups.

The mode attribute uses the mode_name to reference a mode_value group defined in the

cell. When you specify the pg_setting attribute in the referenced mode_value group, the

frequency-scaled group where the mode is referenced also becomes power-state aware.

Syntax

pin (pin_name) {

minimum_period(minimum_period_name){

mode(mode_def_name, mode_name);

}

min_pulse_width(min_pulse_width_name) {

mode(mode_def_name, mode_name);

}

Defining PG Modes in Macro Cells

To include the PG mode syntax in you current design flow, remember the following:

•

PG mode syntax is corner-independent.

You must define the operating voltage ranges for all the PG states, if multi-state.

To maintain consistency between different corners, you must define all the PG modes

for a cell.

Liberty User Guide Volume 1

R-2020.09

393

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

• For a power rail with only on and off states, you do not need to specify a voltage range.

The PG modes are active in all corners.

• The default nominal voltage of a PG state (nom_voltage in the voltage_state_range

attribute definition) is the default voltage that applies to all the designs of your

intellectual property (IP).

PG Mode Examples

The following examples illustrate the use of the PG mode syntax in modeling different

cells.

Cell With Different Power States

The following is an example of a cell with multiple power states. The cell has two power

pins, VDD and VDDS and one ground pin, VSS. The following table lists the voltage

ranges of the PG pins.

PG pin Voltage range

in state1

Voltage range

in state 2

VDD 1.08 0.92~1.00

(nominal: 0.96)

VDDS 1.08 X

VSS 0 X

library (mylib) {

voltage_map("VM1", 1.08);

voltage_map("VM2", 1.08);

voltage_map("VG", 0);

voltage_state_range_list(VM1) {

/* state1 */

voltage_state_range(HV, 1.08);

/* state2 */

voltage_state_range(HV_L, 0.92, 0.96, 1.00);

/* state not used in cell(mycell) */

voltage_state_range(HV_H, 0.98, 1.08);

}

cell (mycell) {

pg_pin (VDD) {

pg_type : primary_power;

voltage_name: "VM1";

}

pg_pin(VDDS){

Liberty User Guide Volume 1

R-2020.09

394

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

pg_type : primary_power;

voltage_name: "VM2";

}

pg_pin(VSS) {

pg_type : primary_ground;

voltage_name: "VG";

}

pg_setting_definition (pst) {

pg_setting_value(ps_1) {

pg_pin_condition : "VDD * VDDS * !VSS";

pg_pin_active_state(VDD, HV);

}

pg_setting_value(ps_2) {

pg_pin_condition : "VDD * !VDDS * !VSS";

pg_pin_active_state (VDD, HV_L);

}

pg_setting_value(off) {

pg_pin_condition : "!VDD * !VDDS + VSS";

}

default_pg_setting : ps_1 ;

}

}/* end cell group */

}/* end library group */

Power State Transition

The following is an example of a cell with transition between the power states. The cell

has two blocks: one powered by VDD, and the other powered by VDDS. The table lists the

voltage ranges of the PG pins.

PG pin Voltage range

in state1

Voltage range

in state 2

VDD 0.7~0.9 0.6

VDDS 0.8~1.0 X

VSS1 0 X

library (mylib) {

voltage_map("VM1", 0.8);

voltage_map("VM2", 0.9);

voltage_map("VG", 0);

voltage_state_range_list(VM1) {

voltage_state_range(on, 0.7, 0.9);

voltage_state_range(pon, 0.6);

}

voltage_state_range_list(VM2) {

voltage_state_range(on, 0.8, 1.0);

Liberty User Guide Volume 1

R-2020.09

395

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

/* this state not used in cell(mycell) */

voltage_state_range(pon, 0.6);

}

cell (mycell) {

pg_pin (VDD) {

pg_type : primary_power;

voltage_name: "VM1";

}

pg_pin(VDDS){

pg_type : primary_power;

voltage_name: "VM2";

}

pg_pin(VSS) {

pg_type : primary_ground;

voltage_name: "VG";

}

/* power state of block 1 */

pg_setting_definition(PD_SSAH) {

/* state1 */

pg_setting_value(GO) {

pg_pin_condition : "VDD * !VSS";

pg_pin_active_state(VDD, on);

}

/* state2 */

pg_setting_value(SLEEP) {

pg_pin_condition: "VDD * !VSS * sp_on";

pg_pin_active_state(VDD, pon);

}

/* state off */

pg_setting_value(OFF) {

pg_pin_condition: "!VDD + VSS ";

}

/* transition */

pg_setting_transition(turn_sleep) {

start_setting : GO;

end_setting : SLEEP;

}

illegal_transition_if_undefined : true ;

} /* end of PD_SSAH */

/* power state of block 2 */

pg_setting_definition (PD_SSBH) {

pg_setting_value (ON) {

pg_pin_condition : "VDDS * !VSS";

pg_pin_active_state(VDDS, on);

}

pg_setting_value (OFF) {

pg_pin_condition : "!VDDS + VSS";

}

}/* end of PD_SSBH */

Liberty User Guide Volume 1

R-2020.09

396

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

/* power state of the cell */

pg_setting_definition (PD) {

pg_setting_value (S1) {

pg_setting_condition : "PD_SSAH * PD_SSBH" ;

pg_setting_active_state(PD_SSAH, GO);

pg_setting_active_state(PD_SSBH, ON);

}

pg_setting_value (S2) {

pg_setting_condition : "PD_SSAH * PD_SSBH" ;

pg_setting_active_state(PD_SSAH, SLEEP);

pg_setting_active_state(PD_SSBH, OFF);

}

pg_setting_value (OFF) {

pg_setting_condition : "PD_SSAH * PD_SSBH" ;

pg_setting_active_state(PD_SSAH, OFF);

pg_setting_active_state(PD_SSBH, OFF);

}

}/* end cell group */

}/* end library group */

Macro Cell With PG Modes

The following example shows a Liberty model of a macro cell that contains two blocks

(block1 and block2). block1 has primary power pin, VDD1, and backup power pin, VDD3.

block2 has primary power pin, VDD2.

PG pin Voltage range in state1 Voltage range in state 2

VDD1 0.81~0.99

(nominal: 0.9)

0.9~1.05

(nominal: 1.0)

VDD2 0.72~0.88 0.9~1.15

VDD3 0.9 X

VSS1/VSS2 0 X

library (mylib) {

voltage_map("VM1", 0.9);

voltage_map("VM2", 0.8);

voltage_map("VM3", 0.9);

voltage_map("VG", 0);

voltage_state_range_list(VM1) {

voltage_state_range(v1_l, 0.81, 0.9, 0.99);

voltage_state_range(v1_h, 0.9, 1.0, 1.05 );

}

voltage_state_range_list(VM2) {

Liberty User Guide Volume 1

R-2020.09

397

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

voltage_state_range(v2_l, 0.72, 0.88);

voltage_state_range(v2_h, 0.9, 1.15);

}

cell (my_macro_cell) {

pg_pin(VDD1) {

pg_type : primary_power;

voltage_name : "VM1";

}

pg_pin(VDD2) {

pg_type : primary_power;

voltage_name : "VM2";

}

pg_pin(VDD3) {

pg_type : backup_power;

voltage_name : "VM3";

}

pg_pin(VSS1) {

pg_type : primary_ground;

voltage_name : "VG";

}

pg_pin(VSS2) {

pg_type : primary_ground;

voltage_name : "VG";

}

/* Block1 power states: VDD1/VDD3/VSS1 */

pg_setting_definition(P1) {

pg_setting_value(sleep) {

pg_pin_condition : "!VDD1 * VDD3 * !VSS1";

}

pg_setting_value(normal) {

pg_pin_condition : "VDD1 * VDD3 * !VSS1";

pg_pin_active_state(VDD1, v1_l);

}

pg_setting_value(power_mode) {

pg_pin_condition : "VDD1 * VDD3 * !VSS1";

pg_pin_active_state(VDD1, v1_h);

}

pg_setting_value(off) {

pg_pin_condition : "!VDD1 * !VDD3 + VSS";

}

default_pg_setting : sleep ;

pg_setting_transition(turn_on) {

end_setting : normal ;

}

pg_setting_transition(no_way) {

is_illegal : true ;

start_setting : power_mode ;

end_setting : sleep ;

}

pg_setting_transition(power_save) {

start_setting : normal ;

end_setting : sleep ;

}

Liberty User Guide Volume 1

R-2020.09

398

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

illegal_transition_if_undefined : true ;

}

/* Block2 power states: VDD2/VSS2 */

pg_setting_definition(P2) {

pg_setting_value(low_speed) {

pg_pin_condition : "VDD2 * !VSS2";

pg_pin_active_state(VDD2, v2_l);

}

pg_setting_value(high_speed) {

pg_pin_condition : "VDD2 * !VSS2";

pg_pin_active_state(VDD2, v2_h);

}

pg_setting_value(off) {

pg_pin_condition : "!VDD2 + VSS";

}

pg_setting_transition(power_mode) {

start_setting : low_speed ;

end_setting : high_speed ;

}

pg_setting_transition(power_save) {

start_setting : high_speed ;

end_setting : low_speed ;

}

default_pg_setting: low_speed ;

}

/* Cell power states: block1 & block2 */

pg_setting_definition(TOP) {

pg_setting_value(power_save) {

pg_setting_condition : "P1 * P2";

pg_setting_active_state (P1, sleep);

pg_setting_active_state (P2, low_speed);

}

pg_setting_value(normal_mode) {

pg_setting_condition : "P1 * P2";

pg_setting_active_state (P1, normal);

pg_setting_active_state (P2, low_speed);

}

pg_setting_value(power_mode) {

pg_setting_condition : "P1 * P2";

pg_setting_active_state (P1, high_speed);

pg_setting_active_state (P2, high_speed);

}

pg_setting_value(off) {

pg_setting_condition : "P1 * P2";

pg_setting_active_state (P1, off);

pg_setting_active_state (P2, off);

}

default_pg_setting : normal_mode ;

}

mode_definition(block1) {

Liberty User Guide Volume 1

R-2020.09

399

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

mutually_exclusive_mode_values : true;

initial_mode : "Idle" ;

mode_value(Idle) {

when : "!Enable";

pg_setting(p1, sleep);

}

mode_value(Active) {

when : "Enable & CS1";

pg_setting(p1, normal);

}

mode_value(Standby) {

when : "Enable & !CS1";

pg_setting(p1, normal);

}

…

} /* end cell group */

} /* end library group */

Retention Cell Leakage Power in Different Power Modes

Retention Cell With Two Modes

The cell operates in the normal mode when VDD is on, and in the retention mode when

VDD is off. VDD is the primary power supply and VDDG is the always-on (backup) power

supply. RETN is the save or restore pin. The data is saved when the pin is high and

restored when the pin is low.

Pin Working

voltage (V)

pg_setting_value

Normal Retention

RETN - 1/0/r/f 0

CK - 1/0/r/f X

D - 1/0 X

VDD 0.63 1 OFF

VDDG 0.63 1 1

VSS/VSSG 0/0 0 0

To model different leakage power values when VDD is on or off, specify the PG pin and

signal pin states for the different modes of operation of the cell.

library(mylib) {

voltage_map (VDD, 0.63); /* Switchable Power */

voltage_map (VDDG, 0.63); /* Backup Power */

Liberty User Guide Volume 1

R-2020.09

400

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

voltage_map (VSS, 0); /* Primary Ground */

voltage_map (VSSG, 0); /* Backup Ground */

…

cell (my_retention_cell) {

…

pg_pin (VDD) {

pg_type : primary_power;

voltage_name : "VDD";

}

pg_pin (VDDG) {

pg_type : backup_power;

voltage_name : "VDDG";

}

pg_pin (VSS) {

pg_type : primary_ground;

voltage_name : "VSS";

}

pg_pin (VSSG) {

pg_type : backup_ground;

voltage_name : "VSSG";

}

pg_setting_definition (PD) {

pg_setting_value (normal) {

pg_pin_condition : "VDDG & VDD & !VSS & !VSSG";

}

pg_setting_value (retention) {

pg_pin_condition : "VDDG & !VDD & !VSS & !VSSG";

}

pg_setting_value (off) {

pg_pin_condition : "!VDDG & !VDD + VSS + VSSG";

}

mode_definition (power_state){

/* signal: CK/D/RETN could be 1/0 */

mode_value (active) {

pg_setting (PD, normal);

}

/* signal: CK/D are X, RETN is 0 */

mode_value (retained) {

when : "!RETN" ;

pg_setting (PD, retention);

}

/* pin definitions are omitted */

/* only 2 leakage power groups possible in retention mode */

leakage_power () {

mode (power_state, retained);

when : "(!RETN)";

value : 0;

related_pg_pin : VDD;

}

leakage_power () {

Liberty User Guide Volume 1

R-2020.09

401

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

mode (power_state, retained);

when : "(!RETN)";

value : 1.31337e-06;

related_pg_pin : VDDG;

}

/* 16 leakage power groups with different CK/D/RETN signal pin states */

leakage_power () {

mode (power_state, active);

value : 6.87551e-06;

when : "(CK&D&RETN)";

related_pg_pin : VDD;

}

leakage_power () {

mode (power_state, active);

value : 9.57963e-07;

when : "(CK&D&RETN)";

related_pg_pin : VDDG;

}

leakage_power () {

mode (power_state, active);

value : 7.02861e-06;

when : "(CK&D&!RETN)";

related_pg_pin : VDD;

}

leakage_power () {

mode (power_state, active);

value : 1.21337e-06;

when : "(CK&D&!RETN)";

related_pg_pin : VDDG;

}

……

}/* end cell group */

}/* end library group */

Retention Cell With Three Modes

Compared to the retention cell with two modes, the retention cell in this example has an

extra mode to save more power in the deep retention mode. The cell has three modes:

normal, retention, and retention_low.

VDDG is the always-on (backup) power supply that works at two voltage values:

•

A high voltage of 0.63 V (operating range is 0.56 ~ 0.70)

•

A low voltage of 0.45 V (operating range is 0.41 ~ 0.49) to save more power

pg_setting_valuePin

Normal Retention

RETN

1/0/r/f 0

Liberty User Guide Volume 1

R-2020.09

402

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

pg_setting_valuePin

Normal Retention

1/0/r/f X

D 1/0 X

VDD 1 OFF

VDDG 1 1/1

VSS/VSSG 0 0

To model this retention cell, the following two corner libraries are needed:

•

PVT1.lib: VDD = 0.63 V; VDDG = 0.63 V

•

PVT2.lib: VDD = 0.58 V; VDDG = 0.45 V

PVT1.lib

library(mylib) {

voltage_map (VDD, 0.63);

voltage_map (VDDG, 0.63); /* characterization voltage */

voltage_map (VSS, 0);

voltage_map (VSSG, 0);

voltage_state_range_list(VDDG) {

voltage_state_range(high, 0.56, 0.63, 0.70); /* min/nom/max */

voltage_state_range(low, 0.41, 0.45, 0.49); /* min/nom/max */

}

cell (my_retention_cell) {

pg_setting_definition (PD) {

pg_setting_value (normal) {

pg_pin_condition : " VDDG & VDD & !VSS & !VSSG";

pg_active_state(VDDG, high);

}

pg_setting_value (retention) {

pg_pin_condition : " VDDG & !VDD & !VSS & !VSSG";

pg_active_state(VDDG, high);

}

pg_setting_value (retention_low) {

pg_pin_condition : " VDDG & !VDD & !VSS & !VSSG";

pg_active_state(VDDG, low);

}

pg_setting_value (off) {

pg_pin_condition : "!VDDG & !VDD + VSS + VSSG";

}

/* PG mode cannot directly move from

active to retention_low mode or vice-versa */

pg_setting_transition(normal_to_low) {

Liberty User Guide Volume 1

R-2020.09

403

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

is_illegal : true;

start_setting : normal;

end_setting : retention_low;

}

pg_setting_transition(low_to_normal) {

is_illegal : true;

start_setting : retention_low;

end_setting : normal;

}

mode_definition (power_state){

/* signal: CK/D/RETN could be 1/0 */

mode_value (active) {

pg_setting (PD, normal);

}

/* signal: CK/D are X, RETN is 0 */

mode_value (retained) {

when : "!RETN" ;

pg_setting (PD, retention);

}

/* signal: CK/D are X, RETN is 0 */

mode_value (retained_low) {

when : "!RETN" ;

pg_setting (PD, retention_low);

}

/* retained mode works in this corner */

leakage_power () {

mode (power_state, retained);

when : "(!RETN)";

value : 0;

related_pg_pin : VDD;

}

leakage_power () {

mode (power_state, retained);

when : "(!RETN)";

value : 1.31337e-06;

related_pg_pin : VDDG;

}

/* active mode is same as example 12.1.4.1 */

}/* end cell group */

}/* end library group */

PVT2.lib

library(mylib) {

voltage_map (VDD, 0.58);

voltage_map (VDDG, 0.45); /* characterization voltage */

voltage_map (VSS, 0);

voltage_map (VSSG, 0);

voltage_state_range_list(VDDG) {

voltage_state_range(high, 0.56, 0.63, 0.70); /* min/nom/max */

voltage_state_range(low, 0.41, 0.45, 0.49); /* min/nom/max */

Liberty User Guide Volume 1

R-2020.09

404

Chapter 9: Advanced Low-Power Modeling

PG Pin Power Mode Modeling

}

cell (my_retention_cell) {

pg_setting_definition (PD) {

pg_setting_value (normal) {

pg_pin_condition : " VDDG & VDD & !VSS & !VSSG";

pg_active_state(VDDG, high);

}

pg_setting_value (retention) {

pg_pin_condition : " VDDG & !VDD & !VSS & !VSSG";

pg_active_state(VDDG, high);

}

pg_setting_value (retention_low) {

pg_pin_condition : " VDDG & !VDD & !VSS & !VSSG";

pg_active_state(VDDG, low);

}

pg_setting_value (off) {

pg_pin_condition : "!VDDG & !VDD + VSS + VSSG";

}

/* PG mode cannot directly move from

active to retention_low mode and vice-versa */

pg_setting_transition(normal_to_low) {

is_illegal : true;

start_setting : normal;

end_setting : retention_low;

}

pg_setting_transition(low_to_normal) {

is_illegal : true;

start_setting : retention_low;

end_setting : normal;

}

mode_definition (power_state){

/* signal: CK/D/RETN could be 1/0 */

mode_value (active) {

pg_setting (PD, normal);

}

/* signal: CK/D are X, RETN is 0 */

mode_value (retained) {

when : "!RETN" ;

pg_setting (PD, retention);

}

/* signal: CK/D are X, RETN is 0 */

mode_value (retained_low) {

when : "!RETN" ;

pg_setting (PD, retention_low);

}

/* retained_low mode works in this corner */

leakage_power () {

mode (power_state, retained_low) ;

when : "(!RETN)";

value : 0;

related_pg_pin : VDD;

Liberty User Guide Volume 1

R-2020.09

405

Chapter 9: Advanced Low-Power Modeling

Feedthrough Signal Pin Modeling

}

leakage_power () {

mode (power_state, retained_low) ;

when : "(!RETN)";

value : 1.31337e-07;

related_pg_pin : VDDG;

}

/* No leakage power group in active mode as VDDG is in low state */

}/* end cell group */

}/* end library group */

Feedthrough Signal Pin Modeling

A feedthrough is created when two or more pins of a cell share the same physical or

unbuffered logical net. Some feedthroughs have no electrical connections with the cell

power pins and do not affect cell behavior.

Feedthrough pins can be of two types:

•

Multipin, also known as logical feedthroughs or shorted pins

•

Single-pin, also known as a pass-through, physical feedthrough, or floating pin

Feedthrough pins can also be part of buses.

Multipin Feedthroughs

Figure 61 is a schematic of a two-pin feedthrough cell with feedthrough pins, A and Y. Pins

A and Y appear in all the model views (such as Verilog) as two separate external pins.

Figure 61 A Two-Pin Feedthrough

Multipin Feedthrough Syntax

library (library_name) {

Liberty User Guide Volume 1

R-2020.09

406

Chapter 9: Advanced Low-Power Modeling

Feedthrough Signal Pin Modeling

cell(cell_name) {

...

short(pin_name, pin_name, ...);

...

pin (pin_name) {

direction : inout;

...

} /* end pin group */

...

} /* end cell group */

} /* end library group */

To model multipin feedthroughs as shown in Figure 61, use the short attribute in the cell

group.

Single-Pin Feedthrough

Figure 62 is a schematic of a single-pin feedthrough cell, with feedthrough pin A. In all the

model views, only one external pin, bus, or bundle, A, is declared even though the signal

can establish one or more physical connections with other cells.

Figure 62 Single-Pin Feedthrough

Single-Pin Feedthrough Syntax

library (library_name) {

cell(cell_name) {

…

pin (single_pin_feedthrough_name) {

direction : inout;

} /* end pin group */

…

} /* end cell group */

} /* end library group */

Liberty User Guide Volume 1

R-2020.09

407

Chapter 9: Advanced Low-Power Modeling

Overdrive and Underdrive Voltage Modeling

To model a single-pin feedthrough, as shown in Figure 62:

• Specify the feedthrough pin as a floating or unused signal pin without parasitics.

•

Do not specify any related_power_pin and related_ground_pin associations for

these pins.

Example 96 is a library model of the cell shown in Figure 62.

Example 96 A Single-Pin Feedthrough Model

library(mylib) {

cell (mycell) {

…

pg_pin (VDD) {

voltage_name : "VDD";

pg_type : "primary_power";

}

pg_pin (VSS) {

voltage_name : "VSS";

pg_type : "primary_ground";

}

pin (B C) {

related_power_pin : "VDD";

related_ground_pin : "VSS";

direction : "input";

…

}

pin (A) { /* Do not specify related_power_pin or related_ground_pin */

/* set pin direction based on actual cell characteristics */

direction : "inout";

…

}

pin (Z) {

related_power_pin : "VDD";

related_ground_pin : "VSS";

direction : "output";=

function : "B * C";

timing () {

related_pin : "B C";

…

}

…

} /* end pin group */

} /* end cell group*/

…

} /* end library group */

Overdrive and Underdrive Voltage Modeling

The voltage of an input signal may slightly differ from the supply voltage to the cell.

Liberty User Guide Volume 1

R-2020.09

408

Chapter 9: Advanced Low-Power Modeling

Overdrive and Underdrive Voltage Modeling

The optional max_input_delta_overdrive_high and

max_input_delta_underdrive_high attributes specify the allowed overdrive and

underdrive delta voltage values of the signal pin with respect to the related_power_pin

voltage. Together, these attributes establish the legal voltage range of operation for a

driver pin.

The voltage values of these two attributes must be either a constant or a linear function of

the related_power_pin voltage. The attribute value units are taken from the library-level

voltage_unit attribute.

You can specify this attribute only for input and inout signal pins of macro cells, memory

cell, switching cells, level-shifter cells, and pad cells.

Syntax

pin(pin_name) {

direction : input | inout ;

max_input_delta_overdrive_high : "float" ;

max_input_delta_underdrive_high : "float" ;

related_power_pin : pg_pin ;

} /* end pin group */

The following example shows a library corner where the overdrive and underdrive voltage

values are within both the input_voltage_range and output_voltage_range values.

The input pin, D, of the cell, mycell, is allowed an overdrive of 0.3 V and an underdrive of

0.2 V.

library (mylib) {

voltage_map(VDD, 1.0);

voltage_map(VDD1, 1.2);

voltage_map(VSS, 0.0);

input_voltage (OD_and_UD){

vil : VSS;

vih : VDD - 0.2;

vimin : VSS;

vimax : VDD + 0.3;

}

…

cell (mycell) {

pg_pin (PWR) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin (PWR1) {

voltage_name : VDD1;

pg_type : primary_power;

}

pg_pin (VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

Liberty User Guide Volume 1

R-2020.09

409

Chapter 9: Advanced Low-Power Modeling

Overdrive and Underdrive Voltage Modeling

pin (D) {

direction : input;

related_power_pin : PWR;

related_ground_pin : VSS;

level_shifter_data_pin : true;

max_input_delta_overdrive_high : 0.3;

max_input_delta_underdrive_high : 0.2;

input_voltage : OD_and_UD;

input_voltage_range (0.5, 1.5);

}

pin (Y) {

direction : output;

function : “D”;

related_power_pin : PWR1;

related_ground_pin : VSS;

output_voltage_range (0.5, 1.5);

}

} /* end cell */

} /* end library */

The following example shows a library corner where the overdrive voltage exceeds

the maximum allowable voltage (1.5 V) for pin D. The underdrive voltage is within the

input_voltage_range and output_voltage_range values.

library (mylib) {

voltage_map(VDD, 1.3);

voltage_map(VDD1, 1.4);

voltage_map(VSS, 0.0);

input_voltage (OD_and_UD){

vil : VSS;

vih : VDD - 0.2;

vimin : VSS;

vimax : VDD + 0.3;

}

…

cell (mycell) {

pg_pin (PWR) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin (PWR1) {

voltage_name : VDD1;

pg_type : primary_power;

}

pg_pin (VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

pin (D) {

direction : input;

related_power_pin : PWR;

related_ground_pin : VSS;

level_shifter_data_pin : true;

Liberty User Guide Volume 1

R-2020.09

410

Chapter 9: Advanced Low-Power Modeling

Internally Unconnected Pin Modeling

max_input_delta_overdrive_high : 0.3;

max_input_delta_underdrive_high : 0.2;

input_voltage : OD_and_UD;

input_voltage_range (0.5, 1.5);

}

pin (Y) {

direction : output;

related_power_pin : PWR1;

related_ground_pin : VSS;

output_voltage_range (0.5, 1.5);

}

} /* end cell */

} /* end library */

When the values of the max_input_delta_overdrive_high or the

max_input_delta_underdrive_high attribute exceed the input_voltage_range values:

•

Reduce the allowable overdrive voltage to the high value in the input voltage range.

•

Reduce the allowable underdrive voltage to the low value in the input voltage range.

Internally Unconnected Pin Modeling

By default, a pin is considered to be internally not connected when:

• The pin has no related power or related ground pins.

•

The pin is not part of a feedthrough path that is marked with the short attribute.

To explicitly mark the pin that meets both these conditions as not connected, use the

is_unconnected attribute in the pin group. You can also define this attribute in the bus or

bundle group. Valid value is true or false.

Note:

It is optional to specify the is_unconnected attribute for signal pins of a PG pin

library.

Syntax

library (library_name) {

cell(cell_name) {

…

pin (pin_name) {

is_unconnected : true | false ;

…

}/* End pin group */

…

}/* End cell group */

}/* End library group */

Liberty User Guide Volume 1

R-2020.09

411

Chapter 9: Advanced Low-Power Modeling

Silicon-on-Insulator (SOI) Cell Modeling

The following example shows how to mark an internally unconnected pin with the

is_unconnected attribute.

library(short) {

cell(BLOCK) {

...

pin(y) {

is_unconnected : true;

}

Silicon-on-Insulator (SOI) Cell Modeling

Silicon-on-insulator (SOI) devices are fabricated on a silicon layer that rests upon an

insulating layer on the substrate. The presence of the insulating layer makes the drain

and source junctions shallow, with small capacitances. Therefore, the SOI devices have

better electrical characteristics resulting in improved switching speed and reduced power

dissipation.

The isolation of the silicon layer from the substrate improves the operating speed, reduces

leakage to the substrate, and reduces the number of latch-ups. It is easy to closely pack

these inherently insulated structures for high device densities. Further, the SOI fabrication

process requires only minor changes to the bulk-CMOS process flow.

Depending on the thickness of the silicon layer, an SOI cell is of two types:

•

Fully depleted SOI (FDSOI) cell, where the channel depletion width is greater than the

thickness of the silicon layer. Therefore, the channel is fully depleted.

•

Partially depleted SOI (PDSOI) cell, where the channel depletion width is less than the

thickness of the silicon layer. Therefore, the channel is partially depleted.

Figure 63 shows a typical SOI cell schematic.

Liberty User Guide Volume 1

R-2020.09

412

Chapter 9: Advanced Low-Power Modeling

Silicon-on-Insulator (SOI) Cell Modeling

Figure 63 A Typical SOI Cell Schematic

The modeling syntax of the SOI cell is:

library(library_name) {

...

is_soi: true | false;

...

cell(cell_name) {

...

is_soi: true | false;

...

}/* End cell group */

} /* End Library group */

Table 27 shows the differences in modeling substrate-bias pins between a bulk-CMOS and

the SOI cell.

Table 27 Differences in Substrate-Bias Pin Modeling Between Bulk-CMOS and SOI Cell

Bulk-CMOS SOI

For a substrate-bias pin associated with a

primary power pin, the pg_type attribute must

be nwell.

For a substrate-bias pin associated with a primary

power pin, the pg_type attribute can be pwell or

nwell.

For a substrate-bias pin associated with a

primary ground pin, the pg_type attribute must

be pwell.

For a substrate-bias pin associated with a primary

ground pin, the pg_type attribute can be pwell or

nwell.

Example 97 shows a typical SOI library and cell model.

Liberty User Guide Volume 1

R-2020.09

413

Chapter 9: Advanced Low-Power Modeling

Silicon-on-Insulator (SOI) Cell Modeling

Example 97 An SOI Library and Cell Description

library(SOI) {

delay_model : table_lookup;

/* unit attributes */

...

is_soi : true;

...

/* operation conditions */

...

/* threshold definitions */

...

/* default attributes */

...

cell(std_cell_inv) {

is_soi : true;

cell_footprint : inv;

area : 1.0;

pg_pin(vdd) {

voltage_name : vdd;

pg_type : primary_power;

related_bias_pin : "vpw";

}

Library-Level Attribute

This section describes a library-level attribute of SOI cells.

is_soi Attribute

The is_soi attribute specifies that all the cells in a library are SOI cells. The default is

false, which means that the library cells are bulk-CMOS cells.

If the is_soi attribute is specified at both the library and cell levels, the cell-level value

overrides the library-level value.

Cell-Level Attribute

This section describes a cell-level attribute of SOI cells.

is_soi Attribute

The is_soi attribute specifies that the cell is an SOI cell. The default is false, which

means that the cell is a bulk-CMOS cell.

Liberty User Guide Volume 1

R-2020.09

414

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

Level-shifter cells (or buffer-type level-shifter cells) and isolation cells are used to connect

the netlist in different power domains, to meet design constraints. In multivoltage and shut-

down designs, both level shifting and isolation are required.

Implementation tools need the following information about level-shifter cells from the cell

library:

•

Which power and ground pin of the level-shifter cell is used for voltage boundary

hookup during its insertion. This information allows the optimization tools to determine

on which side of the voltage boundary a particular level-shifter cell is allowed.

•

Which voltage conversions the particular level-shifter cell can handle. Specifically, does

the level-shifter cell work for conversion from high voltage to low voltage (HL), from low

voltage to high voltage (LH), or both (HL_LH)?

•

What the input and output voltage ranges are for a level-shifter cell under all operating

conditions.

Operating Voltages

In a multivoltage design, each design instance can operate at its specified operating

voltage. Therefore, each voltage must correspond to one or more logical hierarchies. All

cells in a hierarchy operate at the same voltage except for level shifters.

The operating voltages are annotated on the top design, design instances, or hierarchical

ports through PVT operating conditions.

Level Shifter Functionality

A level shifter functions like a buffer, except that the input pin and output pin voltages are

different. These cells are necessary in a multivoltage design because the nets connecting

pins at two different operating voltages can cause a design violation. Level shifters provide

these nets with the needed voltage adjustments.

A level shifter has two components:

•

Two power supplies

•

Specified input and output voltages

The functionality of level shifters includes

• Identifying nets in the design that need voltage adjustments

•

Analyzing the target library for the availability of level shifters

Liberty User Guide Volume 1

R-2020.09

415

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

• Ripping the net and instantiating level shifters where appropriate

Basic Level-Shifter Syntax

The basic syntax for level-shifter cells is as follows:

cell(level_shifter) {

is_level_shifter : true ;

level_shifter_type : HL | LH | HL_LH ;

input_voltage_range ("float, float");

output_voltage_range ("float, float");

...

pg_pin(pg_pin_name_P) {

pg_type : primary_power;

std_cell_main_rail : true;

...

}

pg_pin(pg_pin_name_G) {

pg_type : primary_ground;

...

}

pin (data) {

direction : input;

input_signal_level : "voltage_rail_name";

input_voltage_range ("float , float");

level_shifter_data_pin : true ;

...

}/* End pin group */

pin (enable) {

direction : input;

input_voltage_range ("float , float");

level_shifter_enable_pin : true ;

...

}/* End pin group */

pin (output) {

direction : output;

output_voltage_range ("float , float");

power_down_function : (!pg_pin_name_P + pg_pin_name_G);

...

}/* End pin group */

...

}/* End Cell group */

Cell-Level Attributes

This section describes cell-level attributes for level-shifter cells.

Liberty User Guide Volume 1

R-2020.09

416

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

is_level_shifter Attribute

The is_level_shifter simple attribute identifies a cell as a level shifter. The valid values

of this attribute are true or false. If not specified, the default is false, meaning that the

cell is a standard cell.

level_shifter_type Attribute

The level_shifter_type complex attribute specifies the supported voltage conversion

type. The valid values are

Low to high

High to low

HL_LH

High to low and low to high

The level_shifter_type attribute is optional. The default is HL_LH.

input_voltage_range Attribute

The input_voltage_range attribute specifies the allowed voltage range of the level-

shifter input pin and the voltage range for all input pins of the cell under all possible

operating conditions (defined across multiple libraries). The attribute defines two floating

values: the first is the lower bound, and the second is the upper bound.

The input_voltage_range syntax differs from the pin-level input_signal_level_low

and input_signal_level_high syntax in the following ways:

•

The input_signal_level_low and input_signal_level_high attributes are defined

on the input pins under one operating condition (the default operating condition of the

library).

•

The input_signal_level_low and input_signal_level_high attributes specify

the partial voltage swing of an input pin. Use these attributes to specify partial swings

rather than the full rail-to-rail swing. The input_voltage_range attribute is not related

to the voltage swing.

Note:

The input_voltage_range and output_voltage_range attributes must be

defined together.

Liberty User Guide Volume 1

R-2020.09

417

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

output_voltage_range Attribute

The output_voltage_range attribute is similar to the input_voltage_range attribute

except that it specifies the allowed voltage range of the level shifter for the output pin

instead of the input pin.

The output_voltage_range syntax differs from the pin-level output_signal_level_low

and output_signal_level_high syntax in the following ways:

•

The output_signal_level_low and output_signal_level_high attributes are

defined on the output pins under one operating condition (the default operating

condition of the library).

•

The output_signal_level_low and output_signal_level_high attributes specify

the partial voltage swing of an output pin. Use these attributes to specify partial swings

rather than the full rail-to-rail swing. The output_voltage_range attribute is not

related to the voltage swing.

Note:

The input_voltage_range and output_voltage_range attributes must be

defined together.

ground_input_voltage_range Attribute

The ground_input_voltage_range attribute specifies the ground voltage range of all the

input pins of a level-shifter cell, under all possible operating conditions.

ground_output_voltage_range Attribute

The ground_output_voltage_range attribute specifies the ground voltage range of all

the output pins of a level-shifter cell, under all possible operating conditions.

Note:

To specify the ground voltage range using the ground_input_voltage_range

or ground_output_voltage_range attributes, define a lower bound and an

upper bound of the ground voltage. Specify the lower bound before the upper

bound and ensure that the lower bound is less than or equal to the upper

bound.

Pin-Level Attributes

This section describes pin-level attributes for level-shifter cells.

Liberty User Guide Volume 1

R-2020.09

418

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

std_cell_main_rail Attribute

The std_cell_main_rail attribute is defined in a primary_power power pin. When the

attribute is set to true, the pg_pin is used to determine which power pin is the main rail in

the cell.

level_shifter_data_pin Attribute

The level_shifter_data_pin attribute identifies a data pin of a level-shifter cell. The

default is false, meaning that the pin is a regular signal pin.

level_shifter_enable_pin Attribute

The level_shifter_enable_pin attribute identifies an enable pin of a level-shifter cell.

The default is false, meaning that the pin is a regular signal pin.

input_voltage_range and output_voltage_range Attributes

The input_voltage_range and output_voltage_range attributes specify the allowed

voltage ranges of the input or an output pin of the level-shifter cell. The attributes define

two floating values where the first value is the lower bound and the second value is the

upper bound.

Note:

The pin-level attribute specifications always override the cell-level

specifications.

ground_input_voltage_range Attribute

The ground_input_voltage_range attribute specifies the ground voltage range of an

input pin of a level-shifter cell.

ground_output_voltage_range Attribute

The ground_output_voltage_range attribute specifies the ground voltage range of an

output pin of a level-shifter cell.

Note:

To specify the ground voltage range using the ground_input_voltage_range

or ground_output_voltage_range attributes, define a lower bound and an

upper bound of the ground voltage. Specify the lower bound before the upper

bound and ensure that the lower bound is less than or equal to the upper

bound.

Liberty User Guide Volume 1

R-2020.09

419

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

input_signal_level Attribute

The input_signal_level attribute is defined at the pin level and is used to specify which

signal is driving the input pin. The attribute defines special overdrive cells that do not have

a physical relationship with the power and ground on input pins.

If the input_signal_level, related_power_pin, and related_ground_pin attributes

are defined on any input pin, the full voltage swing derived from the input_signal_level

attribute takes precedence over the voltage swing derived from the related_power_pin

and related_ground_pin attributes during timing calculations.

power_down_function Attribute

The power_down_function attribute identifies the Boolean condition under which the

cell's signal output pin is switched off (when the cell is in the off mode due to the external

power pin states).

alive_during_power_up Attribute

The optional alive_during_power_up attribute specifies an active data pin that is

the data pin is active while its related power pin is active.

You can specify this attribute only in a pin group where the isolation_cell_data_pin or

the level_shifter_data_pin attribute is set to true.

Enable Level-Shifter Cell

An enable level-shifter cell generates a voltage shift between the input and output. An

additional enable input controls the output.

Differential Level-Shifter Cell

A differential level-shifter cell has a pair of complementary data input pins to generate a

voltage difference or shift between the input and output levels, with only a single supply

voltage. This voltage shift is significantly greater that generated by other level-shifter cells.

The syntax for modeling the differential level-shifter cell is as follows:

cell(cell_name) {

is_level_shifter : true ;

pin_opposite ("pin_name", "pin_name");

contention_condition : "boolean_expression";

...

pin (pin_name) {

direction : input;

level_shifter_data_pin : true ;

input_signal_level : voltage_rail_name;

...

Liberty User Guide Volume 1

R-2020.09

420

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

}/* End pin group */

pin (pin_name) {

direction : input;

level_shifter_data_pin : true ;

input_signal_level : voltage_rail_name;

timing(){/* optional */

related_pin : "pin_name";

timing_type : non_seq_setup_rising | non_seq_setup_falling |

non_seq_hold_rising | non_seq_hold_falling;

rise_constraint(template_name) {

index_1 ("float, ..., float");

index_2 ("float, ..., float");

values("float, ..., float", ..., "float, ..., float");

}

fall_constraint(template_name) {

index_1 ("float, ..., float");

index_2 ("float, ..., float");

values("float, ..., float", ..., "float, ..., float");

}

...

}/* End pin group */

pin (pin_name) {

direction : input;

level_shifter_enable_pin : true ;

...

}/* End pin group */

pin (pin_name) {

direction : output;

function : "boolean_expression";

...

}/* End pin group */

...

pg_pin (pg_pin_name) {

pg_type : primary_power;

...

}/* End pg_pin group */

pg_pin (pg_pin_name) {

pg_type : primary_ground;

...

}/* End pg_pin group */

}/* End Cell group */

Note:

This syntax is applicable to all types of differential level-shifter cells including

low-to-high and high-to-low differential level-shifter cells, and differential level-

shifter cells with or without enable inputs.

Cell-Level Attributes

This section describes a cell-level attribute for differential level-shifter cells.

Liberty User Guide Volume 1

R-2020.09

421

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

is_differential_level_shifter Attribute

The is_differential_level_shifter attribute identifies a level-shifter cell as

a differential level-shifter cell. The is_differential_level_shifter attribute is

automatically set on a level-shifter cell that has pins with the pin_opposite and

contention_condition attributes.

Pin-Level Attributes

This section describes pin-level attributes for level-shifter cells.

pin_opposite Attribute

The pin_opposite attribute specifies the logical inverse pin groups of a differential level-

shifter cell. All the input pins used in the pin_opposite attribute must be data pins with

the level_shifter_data_pin attribute set to true.

contention_condition Attribute

The contention_condition attribute specifies the Boolean expression of the

invalid condition for a differential level-shifter cell. All the input pins used in the

contention_condition attribute must be data pins with the level_shifter_data_pin

attribute set to true.

Note:

A cell that has pins with the pin_opposite and contention_condition

attributes is identified as a differential level-shifter cell and the

is_differential_level_shifter and dont_use attributes are automatically

set on this cell.

Asynchronous Timing Constraints

Use the timing group to specify the nonsequential setup and hold constraints between

the two complementary input signals on the arrival of data. To set the asynchronous setup

and hold constraints at the input pins, model the timing arcs with the following values of

the timing_type attribute:

•

non_seq_setup_rising: Checks the setup constraint of the rising edge of the related

pin to the signal pin.

•

non_seq_setup_falling: Checks the setup constraint of the falling edge of the related

pin to the signal pin.

•

non_seq_hold_rising: Checks the hold constraint for the rising edge of the related

pin to the signal pin.

•

non_seq_hold_falling: Checks the hold constraint for the falling edge of the related

pin to the signal pin.

Liberty User Guide Volume 1

R-2020.09

422

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

Note:

The related pin is an input pin without the level_shifter_enable_pin

attribute.

Clamping Enable Level-Shifter Cell Outputs

In enable level-shifter (ELS) cells with multiple enable pins, clamping the outputs might be

required to maintain them at particular logic levels, such as 0, 1, z, or a previously-latched

value.

The clamp function modeling syntax for an enable level-shifter cell and its pins is as

follows:

cell (cell_name) {

is_level_shifter : true;

...

pin(input_pin) {

direction : input;

level_shifter_data_pin : true;

...

}

pin(input_pin) {

direction : input;

level_shifter_enable_pin : true;

...

}

pin(input_pin) {

direction : input;

level_shifter_enable_pin : true;

...

}

pin(output_pin_name) {

direction : output;

clamp_0_function : "Boolean expression" ;

clamp_1_function : "Boolean expression" ;

clamp_z_function : "Boolean expression" ;

clamp_latch_function : "Boolean expression" ;

illegal_clamp_condition : "Boolean expression" ;

...

}

...

}

Pin-Level Attributes

This section describes the pin-level clamp function attributes to clamp the output pins of an

enable level-shifter cell.

Liberty User Guide Volume 1

R-2020.09

423

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

clamp_0_function Attribute

The clamp_0_function attribute specifies the input condition for the enable pins of an

enable level-shifter cell when the output clamps to 0.

clamp_1_function Attribute

The clamp_1_function attribute specifies the input condition for the enable pins of an

enable level-shifter cell when the output clamps to 1.

clamp_z_function Attribute

The clamp_z_function attribute specifies the input condition for the enable pins of an

enable level-shifter cell when the output clamps to z.

clamp_latch_function Attribute

The clamp_latch_function attribute specifies the input condition for the enable pins of

an enable level-shifter cell when the output clamps to the previously latched value.

illegal_clamp_condition Attribute

The illegal_clamp_condition attribute specifies the invalid condition for the enable

pins of an enable level-shifter cell. If the illegal_clamp_condition attribute is not

specified, the invalid condition does not exist.

Note:

All the input pins used in the Boolean expressions of the clamp_0_function,

clamp_1_function, clamp_z_function, and clamp_latch_function

attributes must be enable pins with the level_shifter_enable_pin

attribute set to true. The Boolean expressions of the clamp_0_function,

clamp_1_function, clamp_z_function, clamp_latch_function, and

illegal_clamp_condition attributes must be mutually exclusive.

Level Shifter Modeling Examples

The following sections provide examples to model various types of level-shifter cells.

Level-Shifter Cell Without Enable Pin

A single-bit level-shifter cell without an enable pin has one data input and one output pin.

An N-bit multibit level-shifter cell without enable pins, has N data input and N output pins.

The output pin Liberty model of such cells must have a clamp function attribute. During

compilation, the tool automatically sets the cell-level is_no_enable attribute to true for

such cells.

The following example shows the Liberty model of a level-shifter cell without any enable

pin. D and Z are the input and output pins, respectively. VDD is the related power pin of

Liberty User Guide Volume 1

R-2020.09

424

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

the input, and VDDO is the related power pin of the output. The output clamps to latch

condition when the input circuit is powered off and the output circuit remains powered on.

library (mylib) {

…

voltage_map(VDD, 0.80);

voltage_map(VDDO, 1.20);

…

cell(No_Enable_LS) {

is_level_shifter : true;

level_shifter_type : HL_LH;

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin(VDDO) {

voltage_name : VDDO;

pg_type : primary_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

pin(D) {

direction : input;

related_power_pin : VDD;

related_ground_pin : VSS;

input_voltage_range (0.7, 0.9);

level_shifter_data_pin : true;

}

pin(Z) {

direction : output;

related_power_pin : VDDO;

related_ground_pin : VSS;

function : "D";

clamp_latch_function : "!VDD";

power_down_function : "!VDDO + VSS";

timing() {

related_pin : "D";

…

} /* end timing group */

}/* end pin group*/

}/*end cell group*/

}/*end library group*/

Simple Buffer Type Low-to-High Level Shifter

Figure 64 shows a simple buffer type low-to-high level-shifter cell modeled using the power

and ground pin syntax and level-shifter attributes. The figure is followed by an example.

Liberty User Guide Volume 1

R-2020.09

425

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

Figure 64 Buffer Type Low-to-High Level-Shifter Cell

library(level_shifter_cell_library_example) {

voltage_map(VDD1, 0.8);

voltage_map(VDD2, 1.2);

voltage_map(VSS, 0.0);

operating_conditions(XYZ) {

process : 1.0;

voltage : 3.0;

temperature : 25.0;

}

default_operating_conditions : XYZ;

cell(Buffer_Type_LH_Level_shifter) {

is_level_shifter : true;

level_shifter_type : LH ;

pg_pin(VDD1) {

voltage_name : VDD1;

pg_type : primary_power;

std_cell_main_rail : true;

}

pg_pin(VDD2) {

voltage_name : VDD2;

pg_type : primary_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

leakage_power() {

when : "!A";

value : 1.5;

Liberty User Guide Volume 1

R-2020.09

426

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

related_pg_pin : VDD1;

}

leakage_power() {

when : "!A";

value : 2.7;

related_pg_pin : VDD2;

}

pin(A) {

direction : input;

related_power_pin : VDD1;

related_ground_pin : VSS;

input_voltage_range ( 0.7 , 0.9);

}

pin(Z) {

direction : output;

related_power_pin : VDD2;

related_ground_pin : VSS;

function : "A";

power_down_function : "!VDD1 + !VDD2 + VSS";

output_voltage_range (1.1 , 1.3);

timing() {

related_pin : A;

cell_rise(template) {

...

}

cell_fall(template) {

...

}

rise_transition(template) {

...

}

fall_transition(template) {

...

}

internal_power() {

related_pin : A;

related_pg_pin : VDD1;

...

}

internal_power() {

related_pin : A;

related_pg_pin : VDD2;

...

}

} /* end pin group*/

...

} /*end cell group*/

Liberty User Guide Volume 1

R-2020.09

427

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

...

} /*end library group*/

Simple Buffer Type High-to-Low Level Shifter

Figure 65 shows a simple buffer type high-to-low level-shifter cell. The cell is modeled

using the power and ground pin syntax and level-shifter attributes. Shifting the signal level

from high to low voltage can be useful for timing accuracy. When you do this, the level-

shifter cell receives a higher voltage signal as its input, which is characterized in the delay

tables of the cell description.

Figure 65 Buffer Type High-to-Low Level-Shifter Cell

library(level_shifter_cell_library_example) {

voltage_map(VDD1, 1.2);

voltage_map(VDD2, 0.8);

voltage_map(VSS, 0.0);

operating_conditions(XYZ) {

process : 1.0;

voltage : 3.0;

temperature : 25.0;

}

default_operating_conditions : XYZ;

cell(Buffer_Type_HL_Level_shifter) {

is_level_shifter : true;

level_shifter_type : HL ;

pg_pin(VDD1) {

voltage_name : VDD1;

pg_type : primary_power;

std_cell_main_rail : true;

}

Liberty User Guide Volume 1

R-2020.09

428

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

pg_pin(VDD2) {

voltage_name : VDD2;

pg_type : primary_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

leakage_power() {

when : "!A";

value : 1.5;

related_pg_pin : VDD1;

}

leakage_power() {

when : "!A";

value : 2.7;

related_pg_pin : VDD2;

}

pin(A) {

direction : input;

related_power_pin : VDD1;

related_ground_pin : VSS;

input_voltage_range ( 0.7 , 0.9);

}

pin(Z) {

direction : output;

related_power_pin : VDD2;

related_ground_pin : VSS;

function : "A";

power_down_function : "!VDD1 + !VDD2 + VSS";

output_voltage_range (1.1 , 1.3);

timing() {

related_pin : A;

cell_rise(template) {

...

}

cell_fall(template) {

...

}

rise_transition(template) {

...

}

fall_transition(template) {

...

}

internal_power() {

related_pin : A;

Liberty User Guide Volume 1

R-2020.09

429

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

related_pg_pin : VDD1;

...

}

internal_power() {

related_pin : A;

related_pg_pin : VDD2;

...

}

} /* end pin group*/

...

} /*end cell group*/

...

} /*end library group*/

Power-and-Ground Level-Shifter Cell

Figure 66 shows the block diagram of a power-and-ground level-shifter cell. The cell

connects the PD1 and PD2 power domains. PD1 and PD2 have power supply voltages,

VDD_IN and VDD_OUT, and ground voltages, VSS_IN and VSS_OUT, respectively.

Figure 66 A Simple Power-and-Ground Level-Shifter Cell

Level-shifter cell insertion is supported for the following conditions:

•

VDD_IN ³ VDD_OUT; VSS_IN ³ VSS_OUT

• VDD_IN ³ VDD_OUT; VSS_IN £ VSS_OUT

•

VDD_IN £ VDD_OUT; VSS_IN ³ VSS_OUT

•

VDD_IN £ VDD_OUT; VSS_IN £ VSS_OUT

Example 98 shows the Liberty model of a simple power-and-ground level-shifter cell.

Example 98 Library Model of a Power-and-Ground Level-Shifter Cell

library(mylib) {

Liberty User Guide Volume 1

R-2020.09

430

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

delay_model : table_lookup ;

...

voltage_map(VDD_IN, 0.8) ; /* primary power */

voltage_map(VDD_OUT, 1.2) ; /* primary power */

voltage_map(VSS_IN, 0.5) ; /* primary ground */

voltage_map(VSS_OUT, 0.0) ; /* primary ground */

/* operation conditions */

operating_conditions(XYZ) {

process : 1 ;

temperature : 125 ;

voltage : 0.8 ;

tree_type : balanced_tree ;

}

default_operating_conditions : XYZ;

...

cell(up_shift ){

area : 1.0 ;

is_level_shifter : true ;

level_shifter_type : LH ;

pg_pin(VDD_IN) {

voltage_name : VDD_IN ;

pg_type : primary_power ;

std_cell_main_rail : true ;

}

pg_pin(VDD_OUT) {

voltage_name : VDD_OUT ;

pg_type : primary_power ;

}

pg_pin(VSS_IN) {

voltage_name : VSS_IN ;

pg_type : primary_ground ;

std_cell_main_rail : true ;

}

pg_pin(VSS_OUT) {

voltage_name : VSS_OUT ;

pg_type : primary_ground ;

}

pin(IN) {

direction : input ;

capacitance : 1.0 ;

related_power_pin : VDD_IN ;

related_ground_pin : VSS_IN ;

input_voltage_range (0.8, 1.0) ;

ground_input_voltage_range (0.4, 0.5) ;

}

pin(OUT) {

direction : output ;

related_power_pin : VDD_OUT ;

related_ground_pin : VSS_OUT ;

function : "IN" ;

power_down_function : "!VDD_IN + !VDD_OUT + \

VSS_IN + VSS_OUT" ;

output_voltage_range (1.0, 1.2) ;

Liberty User Guide Volume 1

R-2020.09

431

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

ground_output_voltage_range (0.0 , 0.1) ;

timing() {

related_pin : IN ;

cell_rise(scalar) {

values ("1.0") ;

}

rise_transition (scalar) {

values ("1.0") ;

}

cell_fall(scalar) {

values ("1.0") ;

}

fall_transition (scalar) {

values ("1.0") ;

}

} /* end cell group */

} /* end library group */

Multibit Level-Shifter Cell

Figure 67 shows a multibit buffer-type level-shifter cell with four data input and four data

output pins. Each of the outputs is a linear function of the respective input. The input data

pins are powered by the PG pin, VDD1, and the output data pins are powered by the PG

pin, VDD2. The example following the figure is a model of the level-shifter cell.

Liberty User Guide Volume 1

R-2020.09

432

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

Figure 67 4-bit Level-Shifter Cell

cell (4_bit_ls) {

is_level_shifter : true;

pg_pin (VDD1) {

pg_type : primary_power;

voltage_name : VDD1;

}

pg_pin (VDD2) {

pg_type : primary_power;

voltage_name : VDD2;

}

pg_pin (VSS) {

pg_type : primary_ground;

voltage_name : VSS;

}

...

pin (a1) {

level_shifter_data_pin : true;

related_power_pin : VDD1;

related_ground_pin : VSS;

...

}

pin (a2) {

Liberty User Guide Volume 1

R-2020.09

433

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

level_shifter_data_pin : true;

related_power_pin : VDD1;

related_ground_pin : VSS;

...

}

pin (a3) {

level_shifter_data_pin : true;

related_power_pin : VDD1;

related_ground_pin : VSS;

...

}

pin (a4) {

level_shifter_data_pin : true;

related_power_pin : VDD1;

related_ground_pin : VSS;

...

}

pin (z1) {

direction : output;

related_power_pin : VDD2;

related_ground_pin : VSS;

power_down_function : !VDD1+!VDD2+VSS;

function : a1;

...

}

pin (z2) {

direction : output;

related_power_pin : VDD2;

related_ground_pin : VSS;

power_down_function : !VDD1+!VDD2+VSS;

function : a2;

...

}

pin (z3) {

direction : output;

related_power_pin : VDD2;

related_ground_pin : VSS;

power_down_function : !VDD1+!VDD2+VSS;

function : a3;

...

}

pin (z4) {

direction : output;

related_power_pin : VDD2;

related_ground_pin : VSS;

power_down_function : !VDD1+!VDD2+VSS;

function : a4;

}

} /* end cell */

Liberty User Guide Volume 1

R-2020.09

434

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

Overdrive Level-Shifter Cell

The cell in Figure 68 is known as an overdrive level-shifter cell. To model an overdrive

level-shifter cell, specify the related_ground_pin attribute and the input_signal_level

attribute, as shown in the example that follows the figure.

Note:

The area of a multiple-rail level-shifter cell (as shown in the figure in Simple

Buffer Type High-to-Low Level Shifter) is larger than that of an overdrive level-

shifter cell (as shown in Figure 68). Keep the area in mind when you design

your cell.

Figure 68 Overdrive Level-Shifter Cell

library(level_shifter_cell_library_example) {

voltage_map(VDD1, 1.2);

voltage_map(VDD, 0.8);

voltage_map(VSS, 0.0);

operating_conditions(XYZ) {

process : 1.0;

voltage : 3.0;

temperature : 25.0;

}

default_operating_conditions : XYZ;

cell(Buffer_Type_HL_Level_shifter) {

is_level_shifter : true;

level_shifter_type : HL ;

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

Liberty User Guide Volume 1

R-2020.09

435

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

std_cell_main_rail : true;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

leakage_power() {

when : "!A";

value : 1.5;

related_pg_pin : VDD;

}

pin(A) {

direction : input;

/* Defining the input_signal_level attribute identifies an Overdrive

Level Shifter cell */

input_signal_level : VDD1;

related_power_pin : VDD;

related_ground_pin : VSS;

input_voltage_range ( 1.1 , 1.3);

}

pin(Z) {

direction : output;

related_power_pin : VDD;

related_ground_pin : VSS;

function : "A";

power_down_function : "!VDD + VSS";

output_voltage_range (0.6 , 0.9);

timing() {

related_pin : A;

cell_rise(template) {

...

}

cell_fall(template) {

...

}

rise_transition(template) {

...

}

fall_transition(template) {

...

}

internal_power() {

related_pin : A;

related_pg_pin : VDD;

...

}

} /* end pin group*/

...

} /*end cell group*/

Liberty User Guide Volume 1

R-2020.09

436

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

...

} /*end library group */

Level-Shifter Cell With Virtual Bias Pins

This section provides an example of a level-shifter cell with virtual bias pins and two n-well

regular wells for substrate-bias modeling.

library (example_multi_rail_with_bias_pins) {

…

cell ( level_shifter ) {

pg_pin ( vdd1 ) {

pg_type : primary_power ;

…

}

pg_pin ( vdd2 ) {

pg_type : primary_power ;

…

}

pg_pin ( vss ) {

pg_type : primary_ground ;

…

}

pg_pin ( vpw ) {

pg_type : pwell ;

…

}

pg_pin ( vnw1 ) {

pg_type : nwell ;

…

}

pg_pin ( vnw2 ) {

pg_type : nwell ;

…

}

pin ( I ) {

direction : input;

related_power_pin : vdd1

related_ground_pin : vss

related_bias_pin : "vnw1 vpw"

…

}

pin ( Z ) {

direction : output;

function : "I";

related_power_pin : "vdd2" ;

related_ground_pin : "vss" ;

related_ bias_pin : "vnw2 vpw";

power_down_function : "!vdd1 + !vdd2 + vss + !vnw1 + !vnw2 + vpw";

…

}

} /* End of cell group */

}/* End of library group */

Liberty User Guide Volume 1

R-2020.09

437

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

Simple Enable Level-Shifter Cell

Figure 69 shows the schematic of a basic enable level-shifter cell. The A signal pin is

linked to the VDD1 and VSS power and ground pin pair, and the EN signal pin and the Y

signal pin are linked to the VDD2 and VSS power and ground pin pair. The enable pin is

linked to VDD2.

The example that follows the figure shows a library containing an enable level-shifter cell.

Figure 69 Enable Level-Shifter Cell Schematic

library(enable_level_shifter_library_example) {

voltage_map(VDD1, 0.8);

voltage_map(VDD2, 1.2);

voltage_map(VSS, 0.0);

operating_conditions(XYZ) {

voltage : 3.0;

...

}

default_operating_conditions : XYZ;

cell(Enable_Level_Shifter) {

is_level_shifter : true;

level_shifter_type : LH ;

pg_pin(VDD1) {

voltage_name : VDD1;

pg_type : primary_power;

std_cell_main_rail : true;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

pg_pin(VDD2) {

voltage_name : VDD2;

Liberty User Guide Volume 1

R-2020.09

438

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

pg_type : primary_power;

}

leakage_power() {

when : "!A";

value : 1.5;

related_pg_pin : VDD1;

}

leakage_power() {

when : "!A";

value : 1.5;

related_pg_pin : VDD2;

}

pin(A) {

direction : input;

related_power_pin : VDD1;

related_ground_pin : VSS;

input_voltage_range ( 0.7 , 0.9);

level_shifter_data_pin : true;

}

pin(EN) {

direction : input;

related_power_pin : VDD2;

related_ground_pin : VSS;

input_voltage_range ( 1.1 , 1.3);

level_shifter_enable_pin : true;

}

pin(Y) {

direction : output;

related_power_pin : VDD2;

related_ground_pin : VSS;

function : "A * EN";

power_down_function : "!VDD2 + VSS";

output_voltage_range ( 1.1 , 1.3);

timing() {

related_pin : "A EN";

cell_rise(template) {

...

}

cell_fall(template) {

...

}

rise_transition(template) {

...

}

fall_transition(template) {

...

}

Liberty User Guide Volume 1

R-2020.09

439

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

internal_power() {

related_pin : "A EN";

related_pg_pin : VDD1;

...

}

internal_power() {

related_pin : "A EN";

related_pg_pin : VDD2;

...

}

}/* end pin group*/

...

}/*end cell group*/

...

}/*end library group*/

Enable Level-Shifter With Isolation

Figure 70 shows the schematic of a NOR-type enable level-shifter cell with isolation

capabilities. The example that follows the figure is a Liberty description of the cell. At the

cell level, the Liberty model has both the is_isolation_cell and the is_level_shifter

attributes set to true.

At the pin level, only the isolation_cell_enable_pin and the

isolation_cell_data_pin isolation attributes (and not the level-shifter attributes) are

specified. For more information about isolation attributes, see Isolation Cell Modeling on

page 446.

During compilation, the tool automatically derives the corresponding pin-based level-shifter

attributes. Therefore, the .db file includes the following derived attributes:

•

level_shifter_data_pin set to true on pin D

•

level_shifter_enable_pin set to true on pin EN

Liberty User Guide Volume 1

R-2020.09

440

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

Figure 70 NOR-Type Enable Level-Shifter Cell With Isolation

cell (ELS) {

is_level_shifter : true;

is_isolation_cell : true;

pg_pin (VDD1) {

voltage_name : "VDD1";

pg_type : "primary_power";

std_cell_main_rail : true;

permit_power_down : true;

}

pg_pin (VDD2) {

voltage_name : “VDD2";

pg_type : “primary_power";

}

pg_pin (VSS) {

voltage_name : "VSS";

pg_type : "primary_ground";

}

pin (D) {

related_power_pin : "VDD1";

related_ground_pin : “VSS";

isolation_cell_data_pin : true;

direction : “input";

…

}

pin (EN) {

related_power_pin : "VDD1";

related_ground_pin : “VSS";

isolation_cell_enable_pin : true;

alive_during_partial_power_down : true;

direction : “input";

}

pin (Y) {

related_power_pin : "VDD2";

related_ground_pin : “VSS";

direction : "output";

Liberty User Guide Volume 1

R-2020.09

441

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

alive_during_partial_power_down : true;

power_down_function : “(!VDD1*!EN)+!VDD2+VSS";

function : “!(D + EN)";

}

} /* end cell */

Clamping in Latch-Based Enable Level-Shifter Cell

Table 28 shows the truth table for a latch-based enable level-shifter cell with two enable

pins, EN1 and EN2. The example that follows the table shows the enable level-shifter cell

modeled with the clamp function attributes.

Table 28 Truth Table for a Latch-Based Enable Level-Shifter Cell With

Two Enable Pins

A EN1 EN2 Y Function

1/0 1 0 1/0 Level shifter

- 0 1 1 Clamp to 1

- 0 0 Qn-1 Latch

- 1 1 ? Forbidden

cell(clamp_1_latch_ELS) {

is_level_shifter : true ;

...

pg_pin(VDD1) {

pg_type : primary_power;

...

}

pg_pin(VSS1) {

pg_type : primary_ground;

...

}

pg_pin(VDD2) {

pg_type : primary_power;

std_cell_main_rail : true;

...

}

pg_pin(VSS2) {

pg_type : primary_ground;

...

}

latch (IQ, IQN) {

data_in : A;

enable : EN1;

preset : EN2;

}

Liberty User Guide Volume 1

R-2020.09

442

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

pin (A) {

related_power_pin : VDD1;

related_ground_pin : VSS1;

direction : input;

level_shifter_data_pin : true ;

...

}

pin (EN1) {

related_power_pin : VDD2;

related_ground_pin : VSS2;

direction : input;

level_shifter_enable_pin : true ;

...

}

pin (EN2) {

related_power_pin : VDD2;

related_ground_pin : VSS2;

direction : input;

level_shifter_enable_pin : true ;

...

}

pin (Y) {

related_power_pin : VDD2;

related_ground_pin : VSS2;

direction : output;

clamp_1_function: "!EN1 * EN2";

clamp_latch_function: "!EN1 * !EN2";

illegal_clamp_function: "EN1 * EN2";

function : "IQ";

...

}

...

}

Differential Level-Shifter Cell

Figure 71 shows a schematic of a low-to-high differential level-shifter cell with the

complementary input pins, A and AN, and an enable pin, EN. The differential level-shifter

cell connects the VDD1 and VDD2 power domains. The differential level-shifter cell uses

the supply voltage, VDD2. The supply voltage, VDD1, drives the inputs on the pins, A and

AN. The example that follows the figure shows a typical model of the differential level-

shifter cell.

Liberty User Guide Volume 1

R-2020.09

443

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

Figure 71 Differential Level-Shifter Schematic

cell(DLS) {

is_level_shifter : true ;

pin_opposite ("A", "AN");

contention_condition : "!(A^AN)*EN";

...

pg_pin (VDD2) {

pg_type : primary_power;

std_cell_main-rail : true;

...

}

pg_pin (GND) {

pg_type : primary_ground;

...

}

pin (A) {

related_power_pin : VDD2 ;

related_ground_pin : GND ;

direction : input;

level_shifter_data_pin : true ;

input_signal_level : VDD1 ;

...

}

pin (AN) {

related_power_pin : VDD2 ;

related_ground_pin : GND ;

Liberty User Guide Volume 1

R-2020.09

444

Chapter 9: Advanced Low-Power Modeling

Level-Shifter Cells in a Multivoltage Design

direction : input;

level_shifter_data_pin : true ;

input_signal_level : VDD2;

timing(){

related_pin : "A";

timing_type : non_seq_setup_rising ;

rise_constraint(DLS_temp) {

...

}

fall_constraint(template_name) {

...

}

timing(){

related_pin : "A";

timing_type : non_seq_setup_falling ;

rise_constraint(DLS_temp) {

...

}

fall_constraint(template_name) {

...

}

timing(){

related_pin : "A";

timing_type : non_seq_hold_rising ;

rise_constraint(DLS_temp) {

...

}

fall_constraint(template_name) {

...

}

timing(){

related_pin : "A";

timing_type : non_seq_hold_falling ;

rise_constraint(DLS_temp) {

...

}

fall_constraint(template_name) {

...

}

pin (EN) {

related_power_pin : VDD2;

related_ground_pin : GND;

direction : input;

Liberty User Guide Volume 1

R-2020.09

445

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

level_shifter_enable_pin : true ;

...

}

pin (Y) {

related_power_pin : VDD2;

related_ground_pin : GND;

direction : output;

function : "(A*!AN)*EN";

...

}

...

}

Isolation Cell Modeling

In partition-based designs with multiple power supplies and voltages, the outputs from a

shut-down partition to an active partition must be maintained at predictable signal levels.

An isolation cell isolates the shut-down partition from the active partition. The isolation

logic ensures that all the inputs to the active partition are clamped to a fixed value.

Example 99 shows the syntax for modeling the isolation cell, and its pins.

Example 99 Isolation Cell Modeling Syntax

cell(isolation_cell) {

is_isolation_cell : true ;

...

pg_pin(pg_pin_name_P) {

pg_type : primary_power ;

permit_power_down : true ;

...

}

pg_pin(pg_pin_name_G) {

pg_type : primary_ground;

...

}

pin (data) {

direction : input;

isolation_cell_data_pin : true ;

...

}

pin (enable) {

direction : input;

isolation_cell_enable_pin : true ;

alive_during_partial_power_down : true ;

...

}

...

pin (output) {

Liberty User Guide Volume 1

R-2020.09

446

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

direction : output;

alive_during_partial_power_down : true ;

function : “Boolean Expression”;

power_down_function : “Boolean Expression”;

...

}/* End pin group */

}/* End Cell group */

Cell-Level Attribute

This section describes a cell-level attribute of the isolation cells.

is_isolation_cell Attribute

The is_isolation_cell attribute identifies a cell as an isolation cell. The valid values of

this attribute are true or false. If not specified, the default is false, meaning that the cell

is an ordinary standard cell.

Pin-Level Attributes

This section describes the pin-level attributes for the isolation cells.

isolation_cell_data_pin Attribute

The isolation_cell_data_pin attribute identifies the data pin of an isolation cell. The

valid values are true or false. If not specified, all the input pins of the isolation cell are

considered to be data pins.

isolation_cell_enable_pin Attribute

The isolation_cell_enable_pin attribute identifies an enable or control pin of an

isolation cell including a clock isolation cell. The valid values are true or false. The

default is false.

power_down_function Attribute

The power_down_function attribute identifies the Boolean condition to switch off the

output pin of the cell (when the cell is inactive due to the external power-pin states).

permit_power_down Attribute

The permit_power_down attribute indicates that the power pin can be powered down

while in the isolation mode. The valid values are true or false. The default is false.

Liberty User Guide Volume 1

R-2020.09

447

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

alive_during_partial_power_down Attribute

The alive_during_partial_power_down attribute indicates that the pin with this attribute

is active while the isolation cell is partially powered down, and the corresponding power or

the ground rails are not considered as the power reference. The valid values are true and

false. The default is false, and in the default setting, the UPF isolation supply set is the

power reference.

alive_during_power_up Attribute

The optional alive_during_power_up attribute specifies an active data pin that is

the data pin is active while its related power pin is active.

You can specify this attribute only in a pin group where the isolation_cell_data_pin or

the level_shifter_data_pin attribute is set to true.

Attribute Dependencies

The isolation cell attributes have the following dependencies:

•

When the control pin of an isolation cell is activated, the output becomes a constant.

•

The control pin of an isolation cell, that permits partial power down must be included

in the Boolean expression of the power_down_function attribute for the same output.

The control pin blocks the terms that use the powered-down rail, to set to true. To

generate the output in the isolation mode, the active power rail is used.

Therefore, an isolation cell cannot be partially powered down if the power_down_function

expression of its power pin does not include the isolation_cell_enable_pin attribute

set.

Isolation Cell Examples

Unlike level-shifter cells, isolation cells cannot shift voltage levels. All other characteristics

are the same between a level-shifter cell and an isolation cell. The following sections show

Liberty models of isolation cells.

Simple NAND-Type Isolation Cell

Figure 72 shows a schematic and a library description of a simple NAND-type isolation

cell. The library describes only the portion related to the power and ground pin syntax. In

the figure, the A, EN, and Y signal pins are associated to the VDD and VSS power and

ground pin pair. The example shows a library with an isolation cell.

Liberty User Guide Volume 1

R-2020.09

448

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

Figure 72 Simple NAND-Type Isolation Cell

library(isolation_cell_library_example) {

voltage_map(VDD, 1.0);

voltage_map(VSS , 0.0);

operating_conditions(XYZ) {

voltage : 1.0;

...

}

default_operating_conditions : XYZ;

cell(Isolation_Cell) {

is_isolation_cell : true;

dont_touch : true;

dont_use : true;

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

leakage_power() {

when : "!A";

value : 1.5;

related_pg_pin : VDD;

}

pin(A) {

direction : input;

related_power_pin : VDD;

related_ground_pin : VSS;

isolation_cell_data_pin : true;

Liberty User Guide Volume 1

R-2020.09

449

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

}

pin(EN) {

direction : input;

related_power_pin : VDD;

related_ground_pin : VSS;

isolation_cell_enable_pin : true;

}

pin(Y) {

direction : output;

related_power_pin : VDD;

related_ground_pin : VSS;

function : "A * EN";

power_down_function : "!VDD + VSS";

timing() {

related_pin : "A EN";

cell_rise(template) {

...

}

cell_fall(template) {

...

}

rise_transition(template) {

...

}

fall_transition(template) {

...

}

internal_power() {

related_pin : A;

related_pg_pin : VDD;

...

}

}/* end pin group*/

...

}/*end cell group*/

...

}/*end library group*/

Simple NOR-Type Isolation Cell

Figure 73 shows a schematic of a simple NOR-type isolation cell with data input, D, and

enable input, E. The example that follows the figure is a library description of the cell.

Liberty User Guide Volume 1

R-2020.09

450

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

Figure 73 Simple NOR-Type Isolation Cell

cell (NOR_cellA) {

is_isolation_cell : true;

pg_pin (VDD) {

voltage_name : "VDD";

pg_type : "primary_power";

permit_power_down : true;

}

pg_pin (VSS) {

voltage_name : "VSS";

pg_type : "primary_ground";

}

pin (D) {

related_power_pin : "VDD";

related_ground_pin : “VSS";

isolation_cell_data_pin : true;

direction : “input";

…

}

pin (E) {

related_power_pin : "VDD";

related_ground_pin : “VSS";

isolation_cell_enable_pin : true;

alive_during_partial_power_down : true;

direction : “input";

…

}

pin (Z) {

related_power_pin : "VDD";

related_ground_pin : “VSS";

alive_during_partial_power_down : true;

direction : "output";

power_down_function : “(!VDD*!E) + VSS";

function : “!(D + E)";

…

}

} /* end cell */

NOR-Type Isolation Cell With Inverted Input

Figure 74 shows a schematic of a NOR-type isolation cell with an inverter at the data

input, D. For the isolation cell to function correctly, the high signal voltage on D must be

greater than or equal to the cell supply voltage, VDD. The example that follows the figure

is a library description of the isolation cell.

Liberty User Guide Volume 1

R-2020.09

451

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

Figure 74 NOR-Type Isolation Cell With Inverted Input

cell (NOR_cellB) {

is_isolation_cell : true;

pg_pin (VDD) {

voltage_name : "VDD";

pg_type : "primary_power";

permit_power_down : true;

}

pg_pin (VSS) {

voltage_name : "VSS";

pg_type : "primary_ground";

}

pin (D) {

related_power_pin : "VDD";

related_ground_pin : “VSS";

isolation_cell_data_pin : true;

alive_during_power_up : true;

/* ISO data pin must stay alive when its RPP is alive

1. default value is false

2. alive_during_power_up is only valid

when "isolation_cell_data_pin : true" */

direction : "input";

…

}

pin (E) {

related_power_pin : "VDD";

related_ground_pin : "VSS";

isolation_cell_enable_pin : true;

alive_during_partial_power_down : true;

direction : "input";

…

}

pin (Z) {

related_power_pin : "VDD";

related_ground_pin : "VSS";

alive_during_partial_power_down : true;

direction : "output";

power_down_function : "(!VDD *!E) + VSS";

function : "!(!D + E)";

…

}

Liberty User Guide Volume 1

R-2020.09

452

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

} /* end cell */

NOR-Type Isolation Cell With Inverted Output

Figure 75 shows a schematic of a NOR-type isolation cell with an inverter at the output, Z.

For the isolation cell to function correctly, the high signal voltage on D must be less than

or equal to the cell supply voltage, VDD. The example that follows the figure is a library

description of the cell.

Figure 75 NOR-Type Isolation Cell With Inverted Output

cell (NOR_cellC) {

is_isolation_cell : true;

pg_pin (VDD) {

voltage_name : "VDD";

pg_type : "primary_power";

}

pg_pin (VSS) {

voltage_name : "VSS";

pg_type : "primary_ground";

}

pin (D) {

related_power_pin : "VDD“;

related_ground_pin : “VSS";

isolation_cell_data_pin : true;

direction : “input";

…

}

pin (E) {

related_power_pin : "VDD";

related_ground_pin : “VSS";

isolation_cell_enable_pin : true;

direction : “input";

…

}

pin (Z) {

related_power_pin : "VDD";

related_ground_pin : “VSS";

direction : "output";

power_down_function : “!VDD + VSS";

function : “(D + E)";

…

}

} /* end cell */

Liberty User Guide Volume 1

R-2020.09

453

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

Isolation Cell Without Enable Pin

A single-bit isolation cell without an enable pin has one data input and one output pin. An

N-bit multibit isolation cell without enable pins, has N data input and N output pins.

The output pin Liberty model of such cells must have a clamp function attribute. During

compilation, the tool automatically sets the cell-level is_no_enable attribute to true for

such cells.

Table 29 shows the truth table for an isolation cell without any enable pin. D and Z are the

input and output pins, respectively. VDD is the related power pin of the input, and VDDO

is the related power pin of the output. The output clamps to latch condition when the input

circuit is powered off and the output circuit remains powered on. The example that follows

the table shows the Liberty model of the isolation cell.

Table 29 Truth Table for a No-Enable-Pin Isolation Cell

A (Input) VDD VDDO Z (Output)

Any ON ON D

Any OFF ON Latch

Any OFF OFF X

Any ON OFF X

library (mylib) {

…

voltage_map(VDD, 0.80);

voltage_map(VDDO, 1.20);

…

cell(No_Enable_Iso) {

is_isolation_cell : true;

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin(VDDO) {

voltage_name : VDDO;

pg_type : backup_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

pin(D) {

direction : input;

related_power_pin : VDD;

related_ground_pin : VSS;

Liberty User Guide Volume 1

R-2020.09

454

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

isolation_cell_data_pin : true;

}

pin(Z) {

direction : output;

related_power_pin : VDDO;

related_ground_pin : VSS;

function : "D";

clamp_latch_function : "!VDD";

power_down_function : "!VDDO + VSS";

timing() {

related_pin : "D";

…

} /* end timing group */

}/* end pin group*/

}/*end cell group*/

}/*end library group*/

Multibit Isolation Cell

Figure 76 shows a multibit isolation cell with four data input pins, four enable pins for

each of the data input pins, and four data output pins. Each of the data outputs is a linear

function of the respective data input. The example following the figure is a model of the

isolation cell.

Liberty User Guide Volume 1

R-2020.09

455

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

Figure 76 4-bit Isolation Cell

cell (4_bit_iso) {

is_isolation_cell : true;

pg_pin (VDD) {

pg_type : primary_power;

voltage_name : VDD;

}

pg_pin (VSS) {

pg_type : primary_ground;

voltage_name : VSS;

}

...

pin (a1) {

isolation_cell_data_pin : true;

related_power_pin : VDD;

related_ground_pin : VSS;

...

}

pin (a2) {

isolation_cell_data_pin : true;

related_power_pin : VDD;

related_ground_pin : VSS;

...

Liberty User Guide Volume 1

R-2020.09

456

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

}

pin (a3) {

isolation_cell_data_pin : true;

related_power_pin : VDD;

related_ground_pin : VSS;

...

}

pin (a4) {

isolation_cell_data_pin : true;

related_power_pin : VDD;

related_ground_pin : VSS;

...

}

pin (e1) {

isolation_cell_enable_pin : true;

related_power_pin : VDD;

related_ground_pin : VSS;

...

}

pin (e2) {

isolation_cell_enable_pin : true;

related_power_pin : VDD;

related_ground_pin : VSS;

...

}

pin (e3) {

isolation_cell_enable_pin : true;

related_power_pin : VDD;

related_ground_pin : VSS;

...

}

pin (e4) {

isolation_cell_enable_pin : true;

related_power_pin : VDD;

related_ground_pin : VSS;

...

}

pin (z1) {

related_power_pin : VDD;

related_ground_pin : VSS;

power_down_function : !VDD + VSS;

function : a1 * e1;

clam_0_function : !e1;

...

}

pin (z2) {

related_power_pin : VDD;

related_ground_pin : VSS;

power_down_function : !VDD + VSS;

function : a2 * e2;

clam_0_function : !e2;

Liberty User Guide Volume 1

R-2020.09

457

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

...

}

pin (z3) {

related_power_pin : VDD;

related_ground_pin : VSS;

power_down_function : !VDD + VSS;

function : a3 * e3;

clam_0_function : !e3;

...

}

pin (z4) {

related_power_pin : VDD;

related_ground_pin : VSS;

power_down_function : !VDD + VSS;

function : a4 * e4;

clam_0_function : !e4;

...

}

Clock-Isolation Cell Modeling

Using combinational isolation cells to isolate clock signals might result in phase-clipped

outputs. Figure 77 shows an AND isolation cell. The phase of the output clock signal,

CK_OUT, becomes clipped, depending on the arrival time of the isolation-enable signal,

ISO_EN, with respect to the input clock signal, CK.

Figure 77 Clock Isolation With AND Isolation Cell

To avoid phase-clipping, use clock-isolation cells for clock isolation. Figure 78 shows a

schematic and a typical output of a clock-isolation cell.

Liberty User Guide Volume 1

R-2020.09

458

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

Figure 78 Clock Isolation Cell Schematic

Note:

The phase of the output clock signal, CK_OUT, is not clipped.

The modeling syntax of the clock-isolation cell and its pins is as follows:

cell (cell_name) {

is_clock_isolation_cell : true;

pin(input pin) {

clock_isolation_cell_clock_pin : true;

direction : input;

...

}

pin(input_pin) {

isolation_cell_enable_pin : true;

direction : input;

...

}

pin(output_pin_name) {

direction : output;

...

}

...

}

Cell-Level Attribute

This section describes the cell-level attribute of clock-isolation cells.

is_clock_isolation_cell Attribute

The is_clock_isolation_cell attribute identifies a cell as a clock-isolation cell. The

default is false, meaning that the cell is a standard cell.

Pin-Level Attributes

This section describes the pin-level attributes for clock-isolation cells.

Liberty User Guide Volume 1

R-2020.09

459

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

isolation_cell_enable_pin Attribute

The isolation_cell_enable_pin attribute identifies an enable or control pin of a clock-

isolation cell. The default is false.

clock_isolation_cell_clock_pin Attribute

The clock_isolation_cell_clock_pin attribute identifies an input clock pin of a clock-

isolation cell. The default is false.

Clock Isolation Cell Examples

Example 100 shows a library description of the clock-isolation cell in Figure 78 on

page 459.

Example 100 Library Description of the Clock-Isolation Cell

library (my_lib) {

...

cell(ck_iso_cell) {

is_clock_isolation_cell : true;

...

pg_pin (VDD) {

pg_type : primary_power;

voltage_name : VDD;

}

pg_pin (VSS) {

pg_type : primary_ground;

voltage_name : VSS;

}

statetable(" CK ISO_EN ", "Q ") {

table : " L L : - : L ,\

L H : - : H ,\

H - : - : N ";

}

pin(CK) {

clock_isolation_cell_clock_pin : true;

direction : input;

related_ground_pin : VSS;

related_power_pin : VDD;

...

}

pin(ISO_EN) {

isolation_cell_enable_pin : true;

direction : input;

related_ground_pin : VSS;

related_power_pin : VDD;

...

}

pin(CK_OUT) {

direction : output;

power_down_function : "!VDD + VSS";

related_ground_pin : VSS;

Liberty User Guide Volume 1

R-2020.09

460

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

related_power_pin : VDD;

state_function : "CK * Q";

timing() {

related_pin : "CK";

timing_sense : "positive_unate";

...

}

...

}

Example 101 shows the clock-isolation cell also modeled as a clock-gating cell. To model

a cell as both a clock-isolation cell and a clock-gating cell, use both the clock-isolation and

clock-gating attributes.

Example 101 Example of a Cell Modeled as Both Clock-Isolation and Clock-Gating Cell

cell(ICG_CK_ISO_CELL) {

is_clock_isolation_cell : true;

clock_gating_integrated_cell : "latch_posedge";

...

pg_pin (VDD) {

pg_type : primary_power;

voltage_name : VDD;

}

pg_pin (VSS) {

pg_type : primary_ground;

voltage_name : VSS;

}

statetable(" CK EN ", "Q ") {

table : " L L : - : L ,\

L H : - : H ,\

H - : - : N ";

}

pin(CK) {

clock_isolation_cell_clock_pin : true;

clock_gate_clock_pin : true;

direction : input;

related_ground_pin : VSS;

related_power_pin : VDD;

...

}

pin(EN) {

isolation_cell_enable_pin : true;

clock_gate_enable_pin : true;

direction : input;

related_ground_pin : VSS;

related_power_pin : VDD;

...

}

pin(CK_OUT) {

Liberty User Guide Volume 1

R-2020.09

461

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

direction : output;

clock_gate_output_pin : true;

power_down_function : "!VDD + VSS";

related_ground_pin : VSS;

related_power_pin : VDD;

state_function : "CK * Q";

timing() {

related_pin : "CK";

timing_sense : "positive_unate";

...

}

...

}

Clamping Isolation Cell Output Pins

In isolation cells with multiple enable pins, clamping the outputs might be required to

maintain them at particular logic levels, such as 0,1, z, or a previously-latched value.

The clamp function modeling syntax for the isolation cell and its pins is as follows:

cell (cell_name) {

is_isolation_cell : true;

...

pin(input_pin) {

direction : input;

isolation_cell_data_pin : true;

...

}

pin(input_pin) {

direction : input;

isolation_cell_enable_pin : true;

...

}

pin(input_pin) {

direction : input;

isolation_cell_enable_pin : true;

...

}

pin(output_pin_name) {

direction : output;

clamp_0_function : "Boolean expression" ;

clamp_1_function : "Boolean expression" ;

clamp_z_function : "Boolean expression" ;

clamp_latch_function : "Boolean expression" ;

illegal_clamp_condition : "Boolean expression" ;

...

}

...

}

Liberty User Guide Volume 1

R-2020.09

462

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

Pin-Level Attributes

This section describes the pin-level clamp function attributes to clamp the isolation cell

output pins.

clamp_0_function Attribute

The clamp_0_function attribute specifies the input condition for the enable pins of an

isolation cell when the output clamps to 0.

clamp_1_function Attribute

The clamp_1_function attribute specifies the input condition for the enable pins of an

isolation cell when the output clamps to 1.

clamp_z_function Attribute

The clamp_z_function attribute specifies the input condition for the enable pins of an

isolation cell when the output clamps to z.

clamp_latch_function Attribute

The clamp_latch_function attribute specifies the input condition for the enable pins of

an isolation cell when the output clamps to the previously latched value.

illegal_clamp_condition Attribute

The illegal_clamp_condition attribute specifies the invalid condition for the enable

pins of an isolation cell. If the illegal_clamp_condition attribute is not specified, the

invalid condition does not exist.

Note:

All the input pins used in the Boolean expressions of the clamp_0_function,

clamp_1_function, clamp_z_function, and clamp_latch_function

attributes must be enable pins with the isolation_cell_enable_pin

attribute set to true. The Boolean expressions of the clamp_0_function,

clamp_1_function, clamp_z_function, clamp_latch_function, and

illegal_clamp_condition attributes must be mutually exclusive.

Example of Clamping in Isolation Cell

The table in Clamping in Latch-Based Enable Level-Shifter Cell shows the truth table for

an isolation cell with two enable pins, EN1 and EN2. Example 102 shows the isolation cell

modeled with a clamp function attribute.

Liberty User Guide Volume 1

R-2020.09

463

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

Table 30 Truth Table for an Isolation Cell With Two Enable Pins

A EN1 EN2 Y Function

0/1 1 1 0/1 AND

- 0 1 0 Clamp to 0

- 1 0 0 Clamp to 0

- 0 0 0 Clamp to 0

Example 102 Using a Clamp Function Attribute to Model an Isolation Cell

cell(ISO_clamp_0) {

is_isolation_cell : true;

...

pin(A) {

direction : input;

capacitance : 1.0;

isolation_cell_data_pin : true;

...

}

pin(EN1) {

direction : input;

capacitance : 1.0;

isolation_cell_enable_pin : true;

...

}

pin(EN2) {

direction : input;

capacitance : 1.0;

isolation_cell_enable_pin : true;

...

}

pin(Y) {

direction : output;

function : "A*EN1*EN2";

clamp_0_function : "!(EN1*EN2)";

...

}

Isolation Cells With Multiple Control Pins

In partition-based designs, output pins of an isolation-cell need to be maintained at

predefined levels for a significant period of time. In such designs, using isolation cells with

multiple control or enable pins reduces the leakage current. Multiple control pins allow

Liberty User Guide Volume 1

R-2020.09

464

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

an isolation cell to be partially powered down. For example, in an isolation cell with two

control pins, one control pin controls the output level. The other control pin is used to

partially power-down the isolation cell while the output level is maintained.

Figure 79 shows the gate-level diagrams of isolation cells with multiple control pins. In

each of the three diagrams, the dotted-line arrow traces the path from the isolation-control

pin to the output pin.

Figure 79 Gate-Level Diagrams of Isolation Cells With Multiple Control Pins

The isolation control pins permit the power pins (not shown in Figure 79) to power

down. The alive_during_partial_power_down attribute on the isolation-control pins

indicate that these pins remain active even when the corresponding power pins are

powered down. Example 103 shows the partially powered down model of the cell, ISO1,

depicted in Figure 79. Table 31 shows the Boolean expressions for the function and

power_down_function attributes of the isolation cells depicted in Figure 79.

Liberty User Guide Volume 1

R-2020.09

465

Chapter 9: Advanced Low-Power Modeling

Isolation Cell Modeling

Example 103 Partially Powered Down Model of the ISO1 Cell

cell ( ISO1 ) {

is_isolation_cell : true;

pg_pin ( VDD ) {

pg_type : primary_power;

permit_power_down : true

}

pg_pin ( VSS ) {

pg_type : primary_ground ;

}

pin ( D ) {

isolation_cell_data_pin : true ;

}

pin ( EN) {

direction : input

isolation_cell_enable_pin : true ;

alive_during_partial_power_down : true ;

}

pin ( Y ) {

direction : output ;

alive_during_partial_power_down : true ;

function : D * !EN ;

power_down_function : (!VDD * !EN) + VSS ;

}

Note:

By default, the related_power_pin and related_ground_pin attributes

are mapped to VDD and VSS, respectively. The related_power_pin and

related_ground_pin attributes are not specified for the input and output pins

in Example 103.

Table 31 Boolean Expressions for the function and

power_down_function Attributes of the Isolation Cells in Figure 79

Cell function (Output Y) power_down_function (Output

ISO1 D * !EN ( !VDD * !EN ) + VSS

ISO2 D * EN1 * !EN2 ( !VDD * !EN2 ) + VSS

ISO3 D + !EN1 + EN2 !VDD + ( VSS + EN1 )

Pins with the alive_during_partial_power_down attribute do not require the power

pins to be active. For example, for the cell ISO2, the isolation-control pin, EN2, does not

require VDD to be active. This pin controls the power-down of VDD through the Boolean

expression of the power_down_function attribute as shown in Table 31. The other

Liberty User Guide Volume 1

R-2020.09

466

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

control pin, EN1, without the alive_during_partial_power_down attribute requires

both VDD and VSS to be active, and is not included in the Boolean expression of the

power_down_function attribute.

In each of the isolation cells in Figure 79, the permit_power_down attribute is set on a

power pin when there is at least one pin with the isolation_cell_enable_pin attribute.

For example, for the cell ISO2, the permit_power_pin attribute is set on the power pin,

VDD, given the isolation_cell_enable_pin attribute is set on the pin, EN2.

Switch Cell Modeling

Switch cells, also known as multithreshold complementary metal oxide semiconductor

cells (power-switch cells), are used to reduce power. They are divided into the following

two classes:

•

Coarse grain

There are two types of coarse-grain switch cells, header switch cells, and footer switch

cells. The header switch cells control the power nets based on a PMOS transistor,

and the footer switch cells control the ground nets based on an NMOS transistor. The

coarse grain cell is a switch that drives the power to other logic cells. It is used as a

big switch to the supply rails and to turn off design partitions when the relative logic is

inactive. Therefore, coarse-grain switch cells can reduce the leakage of the inactive

logic.

In addition, coarse-grain switch cells can also have the properties of a fine-grain switch

cell. For example, they can act as a switch and have output pins that might or might not

be shut off by the internal switch pins.

•

Fine grain

To reduce the leakage power, the fine-grain switch cell includes an embedded switch

pin that is used to turn off the cell when it is inactive.

The syntax supports fine-grain switch cells only for macro cells.

Coarse-Grain Switch Cells

Coarse-grain switch cells must have the following properties:

•

They must be able to model the condition under which the cell turns off the controlled

design partition or the cells connected in the output power pin’s fanout logical cone.

This is modeled with a switching function based on special switch signal pins as well as

a separate but related power-down function based on power pin inputs.

•

They must be able to model the “acknowledge” output pins (output pins whose

signal is used to propagate the switch signal to the next-switch cell or to a power

Liberty User Guide Volume 1

R-2020.09

467

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

controller input's logic cloud). Timing is also propagated from the input switch pin to the

acknowledge output pins.

•

They must have at least one virtual output power and ground pin (virtual VDD or virtual

VSS), one regular input power and ground pin (VDD or VSS), and one switch input pin.

There is no limit on the number of pins a coarse-grain cell can have.

The following describes a simple coarse-grain switch header cell and a simple coarse-

grain switch footer cell:

◦

Header cell: one switch input pin, one VDD (power) input power and ground pin,

and one virtual VDD (internal power) output power and ground pin

◦

Footer cell: one switch input pin, one virtual VSS (internal ground) output power and

ground pin, and one VSS (ground) input power and ground pin

•

They can have multiple switch pins and multiple acknowledge output pins.

•

They must have the steady state current (I/V) information to determine the resistance

value when the switch is on.

•

The timing information can be specified for coarse-grain switch cells on the output pins,

and it can be state dependent for switch pins.

The power output pins in a coarse-grain switch cell can have the following two states:

•

Awake or On

In this state, the input power level is transmitted through the cell to either a 1 or 0 on

the output power pin, depending on other prior switch cells in series settings.

•

Off

In this state, the sleep pin deactivates the pass-through function, and the output power

pin is set to X.

Coarse-Grain Switch Cell Syntax

The following syntax is a portion of the coarse-grain switch cell syntax:

library(coarse_grain_library_name) {

...

lu_table _template (template_name)

variable_1 : input_voltage;

variable_2 : output_voltage;

index_1 ( float, … );

index_2 ( float, … );

}

...

cell(cell_name) {

switch_cell_type : coarse_grain;

Liberty User Guide Volume 1

R-2020.09

468

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

...

pg_pin (VDD/VSS pin name) {

pg_type : primary_power | primary_ground;

direction : input ;

...

}

/* Virtual power and ground pins use "switch_function" to describe the

logic to shut off the attached design partition */

pg_pin (virtual VDD/VSS pin name) {

pg_type : internal_power | internal_ground;

direction: output;

...

switch_function : "function_string";

pg_function : "function_string";

}

dc_current (dc_current_name) {

related_switch_pin : input_pin_name;

related_pg_pin : VDD pin name;

related_internal_pg_pin : Virtual VDD;

values("float, ...");

}

pin (input_pin_name) {

direction : input;

switch_pin : true;

…

}

…

/* The acknowledge output pin uses "function" to represent the

propagated

switching

signal

pin(acknowledge_output_pin_name) {

…

function : "function_string";

power_down_function : "function_string";

direction : output;

…

} /* end pin group */

} /* end cell group */

You can use the following syntax for intrinsic parasitic models.

switch_cell_type : coarse_grain;

dc_current (template_name) {

related_switch_pin : pin_name;

related_pg_pin : pg_pin_name;

related_internal_pg_pin : pg_pin_name;

index_1 ( "float, ..." );

Liberty User Guide Volume 1

R-2020.09

469

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

index_2 ( "float, ..." );

values ( "float, ..." );

}

Library-Level Group

The following attribute is a library-level attribute for switch cells.

lu_table_template Group

The library-level lu_table_template group models the templates for the steady state

current information that is used within the dc_current group. The input_voltage value

specifies input voltage values for the switch pin. The output_voltage value specifies the

output voltage values of the switch pin. The input_voltage and output_voltage values

are the absolute gate voltage and absolute drain voltage, respectively, when a CMOS

transistor is used to model a power-switch cell.

The dc_current group, which is used for steady state current modeling, must be defined

at the cell level. It is defined by two indexes: index_1 and index_2. The index_1 attribute

represents a string that includes a comma-separated set of N values, where N represents

the table rows. The values define the voltage levels measured at either the input voltage

or the output voltage. When referring to the input voltage, the voltage level is measured at

the related switch pin, and the set of N values must have at least two values for N. When

referring to the output voltage, the voltage level is measured at the related internal PG pin,

and the set of N values must have at least three values for N. This voltage level is related

to a common reference ground for the cell. The set of N index_1 values must increase

monotonically.

The index_2 attribute represents a string that includes a comma-separated set of M

values, where M represents the table columns. The values define the voltage levels that

are specified at either the input voltage or the output voltage. When referring to the input

voltage, the voltage level is measured at the related switch pin, and the set of M values

must have at least two values for M. When referring to the output voltage, the voltage level

is measured at the related internal PG pin, and the set of M values must have at least

three values for M. This voltage level is related to a common reference ground for the cell.

The set of M index_2 values must increase monotonically.

Cell-Level Attribute and Group

The following cell-level attribute and group apply to coarse-grain switch cells.

switch_cell_type Attribute

The switch_cell_type attribute specifies the switch cell type so that it is not indirectly

derived from the cell modeling description. Valid values are coarse_grain and

fine_grain.

Liberty User Guide Volume 1

R-2020.09

470

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

dc_current Group

The cell-level dc_current group models the steady state current information, similar to

the lu_table_template group. The table is used to specify the DC current through the

cell’s output pin (generally the related_internal_pg_pin) in the current units specified

at the library level using the current_unit attribute.

The dc_current group includes the related_switch_pin, related_pg_pin, and

related_internal_pg_pin attributes, which are described in the following sections.

related_switch_pin Attribute

The related_switch_pin string attribute specifies the name of the related switch pin for

the coarse-grain switch cell.

related_pg_pin Attribute

The related_pg_pin string attribute is used to specify the name of the power and ground

pin that represents the VDD or VSS power source.

related_internal_pg_pin Attribute

The related_internal_pg_pin string attribute is used to specify the name of the power

and ground pin that represents the virtual VDD or virtual VSS power source.

Pin-Level Attributes

The following attributes are pin-level attributes for coarse-grain switch cells.

switch_function Attribute

The switch_function string attribute identifies the condition when the attached design

partition is turned off by the input switch_pin.

For a coarse-grain switch cell, the switch_function attribute can be defined at both

controlled power and ground pins (virtual VDD and virtual VSS for pg_pin) and the output

pins. It identifies the signal pins that can turn the power pin on.

When the switch_function attribute is defined in the controlled power and ground pin, it

is used to specify the Boolean condition under which the cell switches off (or drives an X

to) the controlled design partitions, including the traditional signal input pins only with no

related power pins to this output.

switch_pin Attribute

The switch_pin attribute is a pin-level Boolean attribute. When it is set to true, it is used

to identify the pin as the switch pin of a coarse-grain switch cell.

Liberty User Guide Volume 1

R-2020.09

471

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

function Attribute

The function attribute in a pin group defines the value of an output pin or inout pin

in terms of the input pins or inout pins in the cell group or model group. The function

attribute describes the Boolean function of only nonsleep input signal pins.

pg_function Attribute

The pg_function attribute models the logical function of a virtual or derived power and

ground (PG) pin as a Boolean expression involving the cells input signal pins, internal

signal pins, and PG pins. The Boolean expression attribute is checked during library

compile to ensure that only one pg_pin is always active at this virtual or derived PG pin. If

more than one pg_pin is found to be active at the virtual or the derived pg_pin output, the

read_lib command generates an error.

pg_pin (VOUT) {

voltage_name : “VOUT";

pg_type : "internal_power";

direction : "output";

pg_function : “VDD1 * !(en1 & en2 & sleep) + VDD2 * (en1 & en2 &

sleep)”;

}

power_down_function Attribute

The power_down_function string attribute is used to identify the condition under which

the cell's signal output pin is switched off (when the cell is in off mode due to the external

power pin states).

pg_pin Group

The cell-level pg_pin group is used to model the VDD and VSS pins and virtual VDD and

VSS pins of a coarse-grain switch cell. The syntax is based on the Y-2006.06 power and

ground pin syntax.

Fine-Grained Switch Support for Macro Cells

A macro cell with a fine-grained switch is a cell that contains a special switch transistor

with a control pin that can turn off the power supply of the cell when it is idle. This

significantly lowers the power consumption of a design.

With the growing popularity of low-power designs, macro cells with fine-grained switches

play an important role. The syntax identifies a cell as a macro cell and specifies the correct

power pin that supplies power to each signal pin.

Macro Cell With Fine-Grained Switch Syntax

cell(cell_name) {

is_macro_cell : true;

switch_cell_type : coarse_grain | fine_grain;

Liberty User Guide Volume 1

R-2020.09

472

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

pg_pin (power/ground pin name) {

pg_type : primary_power | primary_ground | backup_power |

backup_ground;

direction: input | inout | output;

...

}

/* This is a special pg pin that uses "switch_function" to describe the

logic to shut

off the attached design partition */

pg_pin (internal power/ground pin name) {

direction: internal | input | output | inout;

pg_type : internal_power | internal_ground;

switch_function : "function_string";

pg_function : "function_string";

…

}

pin (input_pin_name) {

direction : input | inout;

switch_pin : true | false;

…

}

...

pin(output_pin_name) {

direction : output | inout;

power_down_function : "function_string";

...

} /* end pin group */

} /* end cell group */

Cell-Level Attributes

The following attributes are cell-level attributes for macro cells with fine-grained switches.

is_macro_cell Attribute

The is_macro_cell simple Boolean attribute identifies whether a cell is a macro cell.

If the attribute is set to true, the cell is a macro cell. If it is set to false, the cell is not a

macro cell.

switch_cell_type Attribute

The switch_cell_type attribute is enhanced to support macro cells with internal

switches. The valid enumerated values for this attribute are coarse_grain and

fine_grain.

pg_pin Group

The following attribute can be specified under the pg_pin group for macro cells with fine-

grained switches.

Liberty User Guide Volume 1

R-2020.09

473

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

direction Attribute

The direction attribute supports internal as a valid value for macros when the internal

power and ground is not visible or accessible at the cell boundary.

Switch-Cell Modeling Examples

The following sections provide examples for a simple coarse-grain header switch cell and

a complex coarse-grain header switch cell.

Simple Coarse-Grain Header Switch Cell

Figure 80 and the example that follows it show a simple coarse-grain header switch cell.

Figure 80 Simple Coarse-Grain Header Switch Cell

library (simple_coarse_grain_lib) {

...

current_unit : 1mA;

...

voltage_map(VDD, 1.0);

voltage_map(VVDD, 0.8);

voltage_map(VSS, 0.0);

operating_conditions(XYZ) {

process : 1.0;

voltage : 1.0;

temperature : 25.0;

}

default_operating_conditions : XYZ;

Liberty User Guide Volume 1

R-2020.09

474

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

lu_table_template ( ivt1 ) {

variable_1 : input_voltage;

variable_2 : output_voltage;

index_1 ( "0.1, 0.2, 0.4, 0.8, 1.0" );

index_2 ( "0.1, 0.2, 0.4, 0.8, 1.0" );

}

...

cell ( Simple_CG_Switch ) {

...

switch_cell_type : coarse_grain;

pg_pin ( VDD ) {

pg_type : primary_power;

direction : input;

voltage_name : VDD;

}

pg_pin ( VVDD ) {

pg_type : internal_power;

voltage_name : VVDD;

direction : output ;

switch_function : "SLEEP" ;

pg_function : "VDD" ;

}

pg_pin ( VSS ) {

pg_type : primary_ground;

direction : input;

voltage_name : VSS;

}

/* I/V curve information */

dc_current ( ivt1 ) {

related_switch_pin : SLEEP; /* control pin */

related_pg_pin : VDD; /* source */

related_internal_pg_pin : VVDD; /* drain */

values( "0.010, 0.020, 0.030, 0.030, 0.030", \

"0.011, 0.021, 0.031, 0.041, 0.051", \

"0.012, 0.022, 0.032, 0.042, 0.052", \

"0.013, 0.023, 0.033, 0.043, 0.053", \

"0.014, 0.024, 0.034, 0.044, 0.054");

}

...

}

pin ( SLEEP ) {

switch_pin : true;

capacitance: 1.0;

related_power_pin : VDD;

related_ground_pin : VSS;

} /* end pin */

} /* end cell */

} /* end library */

Liberty User Guide Volume 1

R-2020.09

475

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

Complex Coarse-Grain Header Switch Cell

Figure 81 and the example that follows it show a complex coarse-grain header switch cell.

Figure 81 Complex Coarse-Grain Header Switch Cell

library (complex_coarse_grain_lib) {

...

current_unit : 1mA;

...

voltage_map(VDD, 1.0);

voltage_map(VVDD, 0.8);

voltage_map(VSS, 0.0);

operating_conditions(XYZ) {

process : 1.0;

voltage : 1.0;

temperature : 25.0;

}

default_operating_conditions : XYZ;

lu_table_template ( ivt1 ) {

variable_1 : input_voltage;

variable_2 : output_voltage;

index_1 ( "0.1, 0.2, 0.4, 0.8, 1.0" );

index_2 ( "0.1, 0.2, 0.4, 0.8, 1.0" );

}

...

Liberty User Guide Volume 1

R-2020.09

476

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

cell ( Complex_CG_Switch ) {

...

switch_cell_type : coarse_grain;

pg_pin ( VDD ) {

pg_type : primary_power;

voltage_name : VDD;

direction: input ;

}

pg_pin ( VVDD ) {

pg_type : internal_power;

direction : output ;

voltage_name : VVDD;

switch_function : "SLEEP";

pg_function : "VDD" ;

}

pg_pin ( VSS ) {

pg_type : primary_ground;

voltage_name : VSS;

direction : input ;

}

/* I/V curve information */

dc_current ( ivt1 ) {

related_switch_pin : SLEEP; /* control pin */

related_pg_pin : VDD; /* source power pin */

related_internal_pg_pin : VVDD; /* drain internal power pin*/

values( "0.010, 0.020, 0.030, 0.040, 0.050", \

"0.011, 0.021, 0.031, 0.041, 0.051", \

"0.012, 0.022, 0.032, 0.042, 0.052", \

"0.013, 0.023, 0.033, 0.043, 0.053", \

"0.014, 0.024, 0.034, 0.044, 0.054");

}

pin ( SLEEP ) {

direction : input;

switch_pin : true;

capacitance: 1.0;

related_power_pin : VDD;

related_ground_pin : VSS;

...

}

...

pin (Y) {

direction : output;

function : "SLEEP";

related_power_pin : VDD;

related_ground_pin : VSS;

power_down_function : "!VDD + VSS";

timing() {

related_pin : SLEEP;

...

}

} /* end pin group */

Liberty User Guide Volume 1

R-2020.09

477

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

} /* end cell group*/

} /* end library group*/

Complex Coarse-Grain Switch Cell With an Internal Switch Pin

Figure 82 and the example that follows it show a complex coarse-grain switch cell with an

internal switch pin.

Figure 82 Complex Coarse-Grain Switch Cell With an Internal Switch Pin

library (Complex_CG_lib) {

...

current_unit : 1mA;

...

voltage_map(VDD, 1.0);

voltage_map(VVDD, 0.8);

voltage_map(VSS, 0.0);

operating_conditions(XYZ) {

process : 1.0;

voltage : 1.0;

temperature : 25.0;

}

default_operating_conditions : XYZ;

lu_table_template ( ivt1 ) {

variable_1 : input_voltage;

variable_2 : output_voltage;

Liberty User Guide Volume 1

R-2020.09

478

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

index_1 ( "0.1, 0.2, 0.4, 0.8, 1.0" );

index_2 ( "0.1, 0.2, 0.4, 0.8, 1.0" );

}

...

cell (COMPLEX_HEADER_WITH_INTERNAL_SWITCH_PIN) {

cell_footprint : complex_mtpmos;

area : 1.0;

switch_cell_type : coarse_grain;

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

direction : input;

}

pg_pin(VVDD) {

voltage_name : VVDD;

pg_type : internal_power;

direction : output;

switch_function : "SLEEP" ;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

direction : input;

}

dc_current(ivt1) {

related_switch_pin : internal;

related_pg_pin : VDD;

related_internal_pg_pin : VVDD;

values( "0.010, 0.020, 0.030, 0.040, 0.050", \

"0.011, 0.021, 0.031, 0.041, 0.051", \

"0.012, 0.022, 0.032, 0.042, 0.052", \

"0.013, 0.023, 0.033, 0.043, 0.053", \

"0.014, 0.024, 0.034, 0.044, 0.054");

}

pin(SLEEP) {

switch_pin : true;

direction : input;

capacitance : 1.0;

related_power_pin : VDD;

related_ground_pin : VSS;

...

}

pin(Y) {

direction : output;

function : "SLEEP";

related_power_pin : VDD;

related_ground_pin : VSS;

power_down_function : "!VDD + VSS";

Liberty User Guide Volume 1

R-2020.09

479

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

timing() {

related_pin : "SLEEP"

...

}

} /* end pin group */

pin(internal) {

direction : internal;

timing() {

related_pin : "SLEEP"

...

}

} /* end pin group */

} /* end cell group */

} /* end library group */

Complex Coarse-Grain Switch Cell With Parallel Switches

Figure 83 and the example that follows it show a complex coarse-grain switch cell with two

parallel switches.

Figure 83 Complex Coarse-Grain Switch Cell With Two Parallel Switches

library (Complex_CG_lib) {

...

current_unit : 1mA;

...

voltage_map(VDD, 1.0);

Liberty User Guide Volume 1

R-2020.09

480

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

voltage_map(VVDD, 0.8);

voltage_map(VSS, 0.0);

operating_conditions(XYZ) {

process : 1.0;

voltage : 1.0;

temperature : 25.0;

}

default_operating_conditions : XYZ;

lu_table_template ( ivt1 ) {

variable_1 : input_voltage;

variable_2 : output_voltage;

index_1 ( "0.1, 0.2, 0.4, 0.8, 1.0" );

index_2 ( "0.1, 0.2, 0.4, 0.8, 1.0" );

}

...

cell (COMPLEX_HEADER_WITH_TWO_PARALLEL_SWITCHES) {

cell_footprint : complex_mtpmos;

area : 1.0;

switch_cell_type : coarse_grain;

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

direction : input;

}

pg_pin(VVDD) {

voltage_name : VVDD;

pg_type : internal_power;

direction : output;

switch_function : "CTL1 & CTL2" ;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

direction : input;

}

dc_current(ivt1) {

related_switch_pin : CTL1;

related_pg_pin : VDD;

related_internal_pg_pin : VVDD;

values( "0.010, 0.020, 0.030, 0.040, 0.050", \

"0.011, 0.021, 0.031, 0.041, 0.051", \

"0.012, 0.022, 0.032, 0.042, 0.052", \

"0.013, 0.023, 0.033, 0.043, 0.053", \

"0.014, 0.024, 0.034, 0.044, 0.054");

}

dc_current(ivt1) {

related_switch_pin : CTL2;

Liberty User Guide Volume 1

R-2020.09

481

Chapter 9: Advanced Low-Power Modeling

Switch Cell Modeling

related_pg_pin : VDD;

related_internal_pg_pin : VVDD;

values( "0.010, 0.020, 0.030, 0.040, 0.050", \

"0.011, 0.021, 0.031, 0.041, 0.051", \

"0.012, 0.022, 0.032, 0.042, 0.052", \

"0.013, 0.023, 0.033, 0.043, 0.053", \

"0.014, 0.024, 0.034, 0.044, 0.054");

}

pin(CTL1) {

switch_pin : true;

direction : input;

capacitance : 1.0;

related_power_pin : VDD;

related_ground_pin : VSS;

...

}

pin(CTL2) {

switch_pin : true;

direction : input;

capacitance : 1.0;

related_power_pin : VDD;

related_ground_pin : VSS;

...

}

pin(CTL1OUT) {

direction : output;

function : "CTL1";

related_power_pin : VDD;

related_ground_pin : VSS;

power_down_function : "!VDD + VSS";

timing() {

related_pin : "CTL1"

...

}

} /* end pin group */

pin(CTL2OUT) {

direction : output;

function : "CTL1";

related_power_pin : VDD;

related_ground_pin : VSS;

power_down_function : "!VDD + VSS";

timing() {

related_pin : "CTL2"

...

}

} /( end pin group */

} /* end cell group */

} /* end library group */

Liberty User Guide Volume 1

R-2020.09

482

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

Some elements of an electronic design can store the logic state of the design. This is

required for the design to wake up in the same state in which it was shut down. The

retention cell is one such design element.

Retention cells are sequential cells that hold their state when the power supply is shut

down and restore this state when the power is brought up again. The retention cell or

supply. The power supply to the shadow register is always powered on to maintain the

memory of the state. Therefore, the shadow register has high threshold-voltage transistors

to reduce the leakage power. The main register has low threshold-voltage transistors for

performance during the normal operation of the retention cell.

Retention cells are broadly classified into the store-in-place and balloon structures.

Figure 84 shows the two main retention cell structures. The store-in-place structure

includes a master-slave latch where either the slave or the master latch stores the state of

the cell when the master-slave latch is shut down. In this structure, the master-slave latch

implements the main register while the latch that stores the state of the cell implements

the shadow register. The balloon structure includes a flip-flop or master-slave latch and

a balloon latch with a control logic that stores the state of the cell when the master-slave

latch is shut down. In this structure, the master-slave latch implements the main register

and the balloon latch implements the shadow register. The control logic includes signals,

such as save and restore signals that control the data storage in the shadow register and

the data transfer between the shadow register and the main register.

Liberty User Guide Volume 1

R-2020.09

483

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

Figure 84 Retention Cell Structures

Liberty User Guide Volume 1

R-2020.09

484

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

Modes of Operation

A retention cell has two modes of operation: normal mode and retention mode. The

retention mode has three stages: save event, sleep mode, and restore event. For

example, for the balloon structure, the master-slave latch operates in normal mode and

the balloon latch operates in retention mode. The master-slave latch is considered to be

edge-triggered. The normal and retention modes are described as follows:

•

normal mode

In this mode, the retention cell is fully powered on and the master-slave latch operates

normally. The balloon latch does not add to the load at the output of the retention cell.

•

retention mode

◦ save event

During this event, the current state of the master-slave latch is saved before

the power to the latch is shut down. The balloon latch is considered to be edge-

triggered during the save event. The trailing edge of the save control signal is the

triggering edge.

◦

sleep mode

In this mode, the master-slave latch is shut down.

◦

restore event

During the restore event, a wake-up signal activates the master-slave latch and

the data stored in the balloon latch is fed back to the master-slave latch. The state

of the master-slave latch is restored just after the power is restored and before

the retention cell operation returns to normal mode. The balloon latch is also

considered to be edge-triggered during the restore event. The two methods to

restore the state are:

▪

The leading edge of the restore signal is the triggering edge for the balloon latch.

The master-slave latch becomes transparent, that is, it does not latch the data.

However, it outputs the same state that was saved in the balloon latch.

▪

The trailing edge is the triggering edge for the balloon latch. The data is fully

restored from the balloon latch and the flip-flop starts operating normally. In this

method, the restored data is available for a shorter time.

Retention Cell Modeling Syntax

The following syntax shows the modeling of retention cells. The reference_input

attribute defines the connectivity information for the input pins based on the

reference_pin_names variable. The reference_pin_names variable specifies the

Liberty User Guide Volume 1

R-2020.09

485

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

internal reference input nodes used within the ff, latch, ff_bank, and latch_bank

groups.

The sequential components of a retention cell are defined by using the flip-flop and latch

syntax. The syntax to model the scan retention cells is identical to the syntax to model the

scan sequential components. All scan retention cell functional models have a regular cell

function that includes the scan pins as part of the function, while the test_cell group

models the nonscan functionality of the retention cells with the scan pins that have been

specified with the signal_type attributes.

cell(cell_name) {

retention_cell : retention_cell_style;

pg_pin (primary_power_name) {

voltage_name : primary_power_name;

pg_type : primary_power;

}

pg_pin (primary_ground_name) {

voltage_name : primary_ground_name;

pg_type : primary_ground;

}

pg_pin (backup_power_name) {

voltage_name : backup_power_name;

pg_type : backup_power;

}

pg_pin (backup_ground_name) {

voltage_name : backup_ground_name;

pg_type : backup_ground;

}

pin(pin_name) {

retention_pin(pin_class, disable_value);

related_ground_pin : backup_ground;

related_power_pin : backup_power;

save_action : L|H|R|F;

restore_action : L|H|R|F;

restore_edge_type : edge_trigger | leading | trailing;

...

}

...

retention_condition() {

power_down_function: "Boolean_function";

required_condition: "Boolean_function";

}

clock_condition() {

clocked_on : "Boolean_expression";

required_condition : "Boolean_expression";

hold_state : L|H|N ;

clocked_on_also : "Boolean_expression";

required_condition_also : "Boolean_expression";

hold_state_also : L|H|N;

}

preset_condition() {

Liberty User Guide Volume 1

R-2020.09

486

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

input : "Boolean_expression";

required_condition : "Boolean_expression" ;

}

clear_condition() {

input : "Boolean_expression" ;

required_condition : "Boolean_expression" ;

}

pin(pin_name) {

direction : inout | output | internal;

function : Boolean_equation_with_internal_node_name;

reference_input : pin_names;

...

}

bus(bus_name) {

bus_type : bus_type_name;

direction : inout | output | internal;

function : Boolean_equation_with_internal_node_name;

reference_input : pin_names;

...

}

ff (["reference_pin_names",] variable1, variable2 ) {

power_down_function : "Boolean_expression" ;

...

}

latch (["reference_pin_names",] variable1, variable2 ) {

power_down_function : "Boolean_expression";

...

}

ff_bank (["reference_pin_names",] variable1, variable2, bits) {

power_down_function : "Boolean_expression";

...

}

latch_bank (["reference_pin_names",] variable1, variable2, bits) {

power_down_function : "Boolean_expression";

...

}

...

statetable (...) {

power_down_function : "Boolean_expression";

...

}

...

}

Liberty User Guide Volume 1

R-2020.09

487

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

Cell-Level Attributes, Groups, and Variables

This section describes the cell-level attributes, groups, and variables for retention cell

modeling.

retention_cell Simple Attribute

The retention_cell attribute identifies the type of the retention cell or register. For

a given cell, there can be multiple types of retention cells that have the same function

in normal mode but different sleep signals, wake signals, or clocking schemes. For

example, if a D flip-flop supports two retention strategies, such as type1 (where the data is

transferred when the clock is low) and type2 (where the data is transferred when the clock

is high), the values of the retention_cell attribute are different, such as DFF_type1 and

DFF_type2.

ff, latch, ff_bank, and latch_bank Groups

The ff, latch, ff_bank, and latch_bank groups define sequential blocks. Define these

groups at the cell level. You can specify one or more of these groups within a cell group.

retention_condition Group

The retention_condition group is a group of attributes that specify the conditions for

the retention cell to hold its state during the retention mode. The retention_condition

group includes the power_down_function and required_condition attributes.

power_down_function Attribute

The power_down_function attribute specifies the Boolean condition for the retention

cell to be powered down—that is, the primary power to the cell is shut down. When this

Boolean condition evaluates to true, it triggers the evaluation of the control input conditions

specified by the required_condition attribute.

required_condition Attribute

The required_condition attribute specifies the control input conditions during the

retention mode. For example, in the figure in Retention Cell With Multiple latch Groups,

the retention signal, RET, is low during the retention mode. These conditions are checked

when the Boolean condition specified by the power_down_function attribute evaluates to

true. If these conditions are not met, the cell is considered to be in an illegal state.

Note:

Within the retention_condition group, the power_down_function attribute

by itself does not specify the retention mode of the cell. The conditions specified

by the required_condition attribute ensure that the retention control pin is in

the correct state when the primary power to the cell is shut down.

Liberty User Guide Volume 1

R-2020.09

488

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

clock_condition Group

The clock_condition group is a group of attributes that specify the conditions for correct

signal during clock-based events. The clock_condition group includes two classes of

attributes: attributes without the _also suffix and attributes with the _also suffix. These

are similar to the clocked_on and clocked_on_also attributes of the ff group.

clocked_on and clocked_on_also Attributes

The clocked_on and clocked_on_also attributes specify the active edge of the clock

signal. The Boolean expression of the clocked_on attribute must be identical to the one

specified in the clocked_on attribute of the corresponding ff or ff_bank group.

For example, for a master-slave latch, use the clocked_on attribute on the clock to the

master latch and the clocked_on_also attribute on the clock to the slave latch.

Note:

A single-stage flip-flop or latch does not use the clocked_on_also attribute.

required_condition and required_condition_also Attributes

The required_condition and required_condition_also attributes specify the input

conditions during the active edge of the clock signal. These conditions are checked,

respectively, at the values specified by the clocked_on and clocked_on_also attributes.

If any one of the conditions are not met, the cell is considered to be in an illegal state.

For example, when the required_condition attribute is checked at the rising edge of

the clock signal specified by the clocked_on attribute, the required_condition_also

attribute is also checked at the rising edge of the clock signal specified by the

clocked_on_also attribute. If the clocked_on_also attribute is not specified, the

required_condition_also attribute is checked at the falling edge of the clock signal

specified by the clocked_on attribute. This condition is checked when the slave latch is in

the hold state.

hold_state and hold_state_also Attributes

The hold_state and hold_state_also attributes specify the values for the Boolean

expressions of the clocked_on and clocked_on_also attributes during the retention

mode. The valid values are L (low), H (high), or N (no change).

If the data is restored to both the master and slave latches, the value of the hold_state

attribute is N. If the data is restored to the slave latch, the value of the hold_state

attribute is L.

preset_condition and clear_condition Groups

The preset_condition and clear_condition groups contain attributes that specify

the conditions, respectively, for the present and clear signals in the normal mode of the

retention cell.

Liberty User Guide Volume 1

R-2020.09

489

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

The asynchronous control signals, preset and clear, have higher priority over the clock

signal. However, these signals do not control the balloon latch. Therefore, if the preset or

clear signals are asserted during the restore event, these signals need to be active for a

time longer than the restore event so that the master-slave latch content is successfully

overwritten, as shown in Figure 85. Therefore, the preset and clear signals must be

checked at the trailing edge.

Figure 85 Preset and Clear Signal Overlaps With Restore

input Attribute

The input attribute specifies how the preset or clear control signal is asserted. The

Boolean expression of the input attribute must be identical to one specified in the input

attribute of the ff group.

required_condition Attribute

The required_condition attribute specifies the input condition during the active edge

of the preset or clear signal. The required_condition attribute is checked at the trailing

edge of the preset or clear signal. When the input condition is not met, the cell is in an

illegal state.

reference_pin_names Variable

The reference_pin_names variable specifies the input nodes that are used for internal

reference within the ff, latch, ff_bank, or latch_bank groups. If you do not specify

the reference_pin_names variable, the node names in the ff, latch, ff_bank, or

latch_bank groups are considered to be the actual pin or bus names of the cell.

Liberty User Guide Volume 1

R-2020.09

490

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

variable1 and variable2 Variables

The variable1 and variable2 variables define the output nodes for internal reference.

The values of the variable1 and variable2 variables in the ff, latch, ff_bank, or

latch_bank groups must be unique for a cell.

bits Variable

The bits variable defines the width of the ff_bank and latch_bank component.

Pin-Level Attributes

This section describes the pin-level attributes for retention cell modeling.

retention_pin Complex Attribute

The retention_pin attribute identifies the retention pins of a retention cell. In the normal

mode, the retention pins are disabled.

The retention_pin attribute has the following arguments:

•

Pin class

The values are

◦

restore

Restores the state of the cell.

◦

save

Saves the state of the cell.

◦

save_restore

Saves and restores the state of the cell. When a single pin in a retention cell

performs both the save and restore operations, specify the retention_pin attribute

with the save_restore value. The retention pin is in save mode when it saves the

data. The retention pin is in restore mode when it restores the data.

function Attribute

The function attribute maps an output, inout, or internal pin to a corresponding internal

node or a value of the variable1 or variable2 variable in a ff, latch, ff_bank, or

latch_bank group. The function attribute also accepts a Boolean equation containing

the variable1 or variable2 variable and other input, inout, or internal pins. Define the

function attribute in a pin or bus group.

Liberty User Guide Volume 1

R-2020.09

491

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

reference_input Attribute

The reference_input attribute specifies the input pins that map to the reference pin

names of the corresponding ff, latch, ff_bank, or latch_bank group. For each inout,

output, or internal pin, the variable1 or variable2 value specified in the function

statement determines the corresponding ff, latch, ff_bank, or latch_bank group. You

can define the reference_input attribute in a pin or bus group.

save_action and restore_action Attributes

The save_action and restore_action attributes specify where the save and restore

events occur with respect to the save and restore control signals, respectively. Valid values

are L (low), H (high), R (rise), and F (fall). The L or H values indicate that the data is actually

stored in the balloon latch at the trailing edge of the save signal. The R or F values indicate

that this edge of the restore signal specifies when the data stored in the balloon latch is

available at the output of the master-slave latch.

restore_edge_type Attribute

The restore_edge_type attribute specifies the type of the edge of the restore signal

where the output of the master-slave latch is restored. The restore_edge_type attribute

supports the following edge types: edge_trigger, leading, and trailing. The default

edge type is leading. This is because the other control signals, such as clock, preset, and

clear are of leading edge type, that is, they make the data available at the output of the

master-slave latch when the latch is transparent.

The edge_trigger type indicates that the output of the master-slave latch is restored

at the edge of the restore signal. The master-slave latch resumes normal operation

immediately thereafter.

The leading edge type indicates that the output of the master-slave latch is restored at

the leading edge of the restore signal. The master-slave latch resumes normal operation

after the trailing edge of the restore signal.

The trailing edge type indicates that the output of the master-slave latch is restored at

the trailing edge of the restore signal. The master-slave latch resumes normal operation

after the trailing edge of the restore signal.

Figure 86 shows the valid data windows when the restore_edge_type attribute is set to

the leading and trailing edge types.

Liberty User Guide Volume 1

R-2020.09

492

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

Figure 86 Valid Data Window for leading and trailing Values of the restore_edge_type

Attribute

save_condition and restore_condition Attributes

The save_condition and restore_condition attributes specify the input conditions

during the save and restore events respectively. These conditions are respectively

checked at the values of the save_action and restore_action attributes. If any one of

the conditions are not met, the cell is considered to be in an illegal state.

Retention Cell Model Examples

Retention Cell With Balloon Latch

Figure 87 shows a retention cell structure that is defined using the ff or latch group. The

cell has a balloon latch structure to store the data when the main flip-flop is shut down.

The data is transferred to the output of the retention cell at the rising edge of the clock

signal, CK. The SAVE and RESTORE pins save and restore the data.

Liberty User Guide Volume 1

R-2020.09

493

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

Figure 87 Retention Cell Model Schematic With Balloon Latch

Example 104 Retention Cell With Balloon Latch

library (BALLOON_RET_FLOP) {

delay_model : table_lookup;

input_threshold_pct_rise : 50 ;

input_threshold_pct_fall : 50 ;

output_threshold_pct_rise : 50 ;

output_threshold_pct_fall : 50 ;

slew_lower_threshold_pct_fall : 30.0 ;

slew_lower_threshold_pct_rise : 30.0 ;

slew_upper_threshold_pct_fall : 70.0 ;

slew_upper_threshold_pct_rise : 70.0 ;

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1uA";

pulling_resistance_unit : "1kohm";

capacitive_load_unit (0.1,ff);

voltage_map (VDD, 1.0);

voltage_map (VDDB, 0.9);

voltage_map (VSS, 0.0);

Liberty User Guide Volume 1

R-2020.09

494

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

nom_process : 1.0;

nom_temperature : 25.0;

nom_voltage : 1.1;

operating_conditions(typ) {

process : 1.0 ;

temperature : 25 ;

voltage : 1.1 ;

tree_type : "balanced_tree" ;

}

default_operating_conditions : typ;

wire_load("05*05") {

resistance : 1.0 ;

capacitance : 25 ;

area : 1.1 ;

slope : "balanced_tree" ;

fanout_length(1,0.39);

}

cell (balloon_ret_cell) {

retention_cell : retdiff;

area : 1.0 ;

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

pg_pin(VDDB) {

voltage_name : VDDB;

pg_type : backup_power;

}

ff ( Q1, QN1 ) {

clocked_on : " CK ";

next_state : " D ";

clear : " RESTORE * !Q2 ";

preset : " RESTORE * Q2 ";

clear_preset_var1 : "L";

clear_preset_var2 : "H";

power_down_function : "!VDD+VSS";

/* Latch 1 is powered by primary power supply */

}

latch("Q2", "QN2") {

enable : " SAVE ";

data_in : "Q";

power_down_function : "!VDDB+VSS";

/* Latch 2 is powered by backup power supply */

Liberty User Guide Volume 1

R-2020.09

495

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

}

clock_condition() {

clocked_on : "CK";

required_condition : "RESTORE";

hold_state : L;

}

pin(RESTORE) {

direction : input;

capacitance : 0.1;

related_power_pin : VDDB;

related_ground_pin : VSS;

retention_pin(restore, "0");

restore_action : "H";

restore_condition : "!CK";

restore_edge_type : "leading";

}

pin(SAVE) {

direction : input;

capacitance : 0.1;

related_power_pin : VDDB;

related_ground_pin : VSS;

retention_pin(save, "0");

save_action : "H";

save_condition : "!CK";

}

pin(D) {

direction : input;

capacitance : 0.1;

related_power_pin : VDD;

related_ground_pin : VSS;

}

pin(CK) {

direction : input;

clock : true;

capacitance : 0.1;

related_power_pin : VDD;

related_ground_pin : VSS;

}

pin(Q) {

direction : output;

function : "Q1";

related_power_pin : VDD;

related_ground_pin : VSS;

timing() {

related_pin : "CK";

timing_type : rising_edge;

cell_rise(scalar) { values ( "0.1");}

rise_transition(scalar) { values ( "0.1");}

cell_fall(scalar) { values ( "0.1");}

fall_transition(scalar) { values ( "0.1");}

}

Liberty User Guide Volume 1

R-2020.09

496

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

retention_condition() {

power_down_function : "!VDD+VSS";

required_condition: "!SAVE";

}

pin(q1) {

direction : internal;

function : "Q2";

}

} /* End cell group */

} /* End Library group */

Retention Cell With Multiple latch Groups

Figure 88 shows a schematic of a basic retention cell. The state of the cell is stored inside

the slave latch that is powered by the backup power VDDB. Figure 89 shows the valid

values of the input control signals when the cell is in retention mode.

In the figure, and in Example 105, the reference cells are defined by using the

latch group syntax. The connectivity information for the input pins is specified in

the reference_input attribute that is mapped to the reference pin names of the

corresponding latch group.

Figure 88 Simple Retention Cell Model Schematic

Liberty User Guide Volume 1

R-2020.09

497

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

Figure 89 Valid RET and CK Signal Values in the Retention Mode

Note:

To retain the stored data, the retention signal, RET, must be low during the

retention mode. This condition is specified by the required_condition

attribute of the retention_condition group.

Example 105 Retention Cell Model Example Using Multiple Latch Group

library (RET_FLOP) {

delay_model : table_lookup;

input_threshold_pct_rise : 50 ;

input_threshold_pct_fall : 50 ;

output_threshold_pct_rise : 50 ;

output_threshold_pct_fall : 50 ;

slew_lower_threshold_pct_fall : 30.0 ;

slew_lower_threshold_pct_rise : 30.0 ;

slew_upper_threshold_pct_fall : 70.0 ;

slew_upper_threshold_pct_rise : 70.0 ;

time_unit : "1ns";

voltage_unit : "1V";

Liberty User Guide Volume 1

R-2020.09

498

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

current_unit : "1uA";

pulling_resistance_unit : "1kohm";

capacitive_load_unit (0.1,ff);

voltage_map (VDD, 1.0);

voltage_map (VDDB, 0.9);

voltage_map (VSS, 0.0);

nom_process : 1.0;

nom_temperature : 25.0;

nom_voltage : 1.1;

operating_conditions(xyz) {

process : 1.0 ;

temperature : 25 ;

voltage : 1.1 ;

tree_type : "balanced_tree" ;

}

default_operating_conditions : xyz;

... /* Other library level attributes and groups */

cell (retention_flip_flop) {

retention_cell : retdiff;

area : 1.0;

pg_pin (VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin (VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

pg_pin (VDDB) {

voltage_name : VDDB;

pg_type : backup_power;

}

latch ( Q1, QN1 ) {

enable : "(RET * CK)'";

data_in : "D";

power_down_function : "!VDD+VSS";

/* Latch1 is powered by primary power supply */

}

latch("Q2", "QN2") {

enable : "RET * CK";

data_in : "Q1";

power_down_function : "!VDDB+VSS";

/* Latch2 is powered by backup power supply */

}

clock_condition() {

clocked_on : "CK";

required_condition : "RET";

Liberty User Guide Volume 1

R-2020.09

499

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

hold_state : "L";

pin (RET) {

direction : input;

capacitance : 0.1;

related_power_pin : VDDB;

related_ground_pin : VSS;

retention_pin(save_restore, "1");

save_action : "L";

restore_action : "H";

save_condition : "!CK";

restore_condition : "!CK";

restore_edge_type : "leading";

}

pin(D) {

direction : input;

capacitance : 0.1;

related_power_pin : VDD;

related_ground_pin : VSS;

}

pin(CK) {

direction : input;

clock : true;

capacitance : 0.1;

related_power_pin : VDD;

related_ground_pin : VSS;

}

pin (Q) {

direction : output;

function : "Q2";

related_power_pin : VDD;

related_ground_pin : VSS;

timing() {

related_pin : "CK";

timing_type : rising_edge;

cell_rise(scalar) { values ( "0.1");}

rise_transition(scalar) { values ( "0.1");}

cell_fall(scalar) { values ( "0.1");}

fall_transition(scalar) { values ( "0.1");}

}

retention_condition() {

power_down_function : "!VDD+VSS";

required_condition: "!RET";

}

} /* End Cell group */

} /* End Library group */

Liberty User Guide Volume 1

R-2020.09

500

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

Retention Cell With Multiple latch_bank Groups

Figure 90 and Example 106 show a retention cell structure that is defined using the

latch_bank group that has multibit parallel inputs and output buses in the datapath and

the clock path.

Figure 90 Multibit (2-bit) Retention Cell Model Schematic

Example 106 Retention Cell Model Example Using Multiple latch_bank Groups

library (RET_FLOP_BANK) {

input_threshold_pct_rise : 50 ;

input_threshold_pct_fall : 50 ;

output_threshold_pct_rise : 50 ;

output_threshold_pct_fall : 50 ;

slew_lower_threshold_pct_fall : 30.0 ;

slew_lower_threshold_pct_rise : 30.0 ;

slew_upper_threshold_pct_fall : 70.0 ;

slew_upper_threshold_pct_rise : 70.0 ;

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1uA";

pulling_resistance_unit : "1kohm";

capacitive_load_unit (0.1,ff);

voltage_map (VDD, 1.0);

voltage_map (VDDB, 0.9);

voltage_map (VSS, 0.0);

nom_process : 1.0;

nom_temperature : 25.0;

Liberty User Guide Volume 1

R-2020.09

501

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

nom_voltage : 1.1;

operating_conditions(xyz) {

process : 1.0 ;

temperature : 25 ;

voltage : 1.1 ;

tree_type : "balanced_tree" ;

}

default_operating_conditions : xyz;

type (bus2) {

base_type : array;

data_type : bit;

bit_width : 2;

bit_from : 0;

bit_to : 1;

downto : false;

}

cell (retention_flip_bank) {

retention_cell : retdiff_bank;

area : 1.0;

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

pg_pin(VDDB) {

voltage_name : VDDB;

pg_type : backup_power;

}

latch_bank ("Q1", "QN1", 2) {

enable : "(RET * CK)'";

data_in : "SE'*D + SE*SI";

power_down_function : "!VDD+VSS";

}

latch_bank ("Q2", "QN2", 2) {

enable : " RET * CK ";

data_in : " q1 ";

power_down_function : "!VDDB+VSS";

}

clock_condition() {

clocked_on : " CK ";

required_condition : " RET ";

hold-state : " L ";

}

Liberty User Guide Volume 1

R-2020.09

502

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

bus(D) {

bus_type : bus2;

direction : input;

capacitance : 0.1;

related_power_pin : VDD;

related_ground_pin : VSS;

bus(q1) {

bus_type : bus2;

direction : internal;

function : "Q1";

related_power_pin : VDD;

related_ground_pin : VSS;

}

bus(Q) {

bus_type : bus2;

direction : output;

function : "Q2";

related_power_pin : VDD;

related_ground_pin : VSS;

}

pin(RET) {

direction : input;

capacitance : 0.1;

related_power_pin : VDDB;

related_ground_pin : VSS;

retention_pin("restore", 1);

save_action : "L";

restore_action : "H";

save_condition : "!CK";

restore_condition : "!CK";

restore_edge_type : "leading";

}

pin(CK) {

direction : input;

clock : true;

capacitance : 0.1;

related_power_pin : VDD;

related_ground_pin : VSS;

}

retention_condition() {

power_down_function : "!VDD+VSS";

required_condition: "!RET";

}

bus(SI) {

bus_type : bus2;

direction : input;

clock : true;

capacitance : 0.1;

related_power_pin : VDD;

related_ground_pin : VSS;

}

Liberty User Guide Volume 1

R-2020.09

503

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

bus(SE) {

bus_type : bus2;

direction : input;

clock : true;

capacitance : 0.1;

related_power_pin : VDD;

related_ground_pin : VSS;

}

cell_leakage_power : 1.000000;

} /* End Cell group */

} /* End Library group */

Retention Cell With Edge-Triggered Balloon Logic

Figure 91 shows a retention cell structure with two ff groups. The cell has a balloon latch

or flip-flop to store the data when the main flip-flop is shut down. The data is transferred to

the output of the main flip-flop, Flop1, on the rising edge of the clock signal, CK, when the

asynchronous preset, SN, and clear, RN, are inactive. In retention mode, the retention pin,

RET, saves the data into the balloon flip-flop and restores the data from the balloon flip-

flop to the output pin of the retention cell. At the rising edge of the RET signal, the data is

saved inside the balloon flip-flop, Flop2, and Flop1 is shut down. When the power to Flop1

is brought up and the retention pin, RET, becomes inactive, the data from Flop2 is restored

to Flop1 at the falling edge of the RET signal.

Liberty User Guide Volume 1

R-2020.09

504

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

Figure 91 Edge-Triggered Retention Cell Model Schematic

Example 107 Retention Cell With Edge-Triggered Balloon Logic

library(edge_triggered_retention) {

delay_model : table_lookup;

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1uA";

capacitive_load_unit (0.1,ff);

default_fanout_load : 1.0;

default_inout_pin_cap : 1.0;

default_input_pin_cap : 1.0;

default_output_pin_cap : 1.0;

input_threshold_pct_rise : 50 ;

input_threshold_pct_fall : 50 ;

output_threshold_pct_rise : 50 ;

output_threshold_pct_fall : 50 ;

slew_lower_threshold_pct_fall : 30.0 ;

slew_lower_threshold_pct_rise : 30.0 ;

slew_upper_threshold_pct_fall : 70.0 ;

slew_upper_threshold_pct_rise : 70.0 ;

Liberty User Guide Volume 1

R-2020.09

505

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

voltage_map(VDD, 1.0);

voltage_map(VDDB, 1.0);

voltage_map(VSS, 0.0);

nom_process : 1.0;

nom_temperature : 25.0;

nom_voltage : 1.1;

operating_conditions(xyz) {

process : 1.0 ;

temperature : 25 ;

voltage : 1.1 ;

tree_type : "balanced_tree" ;

}

default_operating_conditions : xyz;

cell (edge_trigger) {

retention_cell : "edge_trigger";

... /* Other cell-level attributes and groups */

pg_pin (VDD) {

voltage_name : "VDD";

pg_type : "primary_power";

}

pg_pin (VDDB) {

voltage_name : "VDDB";

pg_type : "backup_power";

}

pg_pin (VSS) {

voltage_name : "VSS";

pg_type : "primary_ground";

}

ff ("IQ1" , "IQN1") {

next_state : "D";

clocked_on : "CK";

clear : "RN + (RET * q1')";

preset : "SN + (RET * q1)";

clear_preset_var1 : L;

clear_preset_var1 : H;

power_down_function : "!VDD + VSS"; /* Flip-Flop “Flop1” is powered

by Primary power supply */

}

ff ("IQ2" , "IQN2") {

next_state : "Q";

clocked_on : "RET";

power_down_function : "!VDDS + VSS"; /* Flip-Flop “Flop2” is powered

by Primary power supply */

}

clock_condition() {

clocked_on : "CK"; /* clock must be Low to go into retention mode */

hold_state : "N"; /* when clock switches (either direction), RET

must

be High */

condition : "RET";

}

clear_condition() {

Liberty User Guide Volume 1

R-2020.09

506

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

input : "!RN"; /* When clear de-asserts, RET must be high to allow

Low value to be transferred to Flop1 */

required_condition : "RET";

}

preset_condition() {

input : "!SN"; /* When clear de-asserts, RET must be high to allow

High value to be transferred to Flop1 */

required_condition : "RET";

}

retention_condition() {

power_down_function : "!VDD+VSS";

required_condition: "!RET";

}

pin (q1) {

direction : "internal";

function : "IQ2";

related_power_pin : "VDD";

related_ground_pin : "VSS";

... /* Other pin-level attributes and groups */

}

pin (CK) {

direction : "input";

clock : true;

capacitance : 1.0;

related_power_pin : "VDD";

related_ground_pin : "VSS";

... /* Other pin-level attributes and groups */

}

pin (RET) {

related_power_pin : "VDDB";

related_ground_pin : "VSS";

capacitance : 1.0;

direction : "input";

retention_pin("save_restore",0);

save_action : "R";

restore_action : "R";

save_condition : "!CK";

restore_condition : "!CK";

restore_edge_type : "leading";

... /* Other pin-level attributes and groups */

}

pin (D) {

direction : "input";

related_power_pin : "VDD";

related_ground_pin : "VSS";

capacitance : 1.0;

... /* Other pin-level attributes and groups */

}

pin (RN) {

direction : "input";

related_power_pin : "VDD";

Liberty User Guide Volume 1

R-2020.09

507

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

related_ground_pin : "VSS";

capacitance : 1.0;

... /* Other pin-level attributes and groups */

}

pin (SN) {

direction : "input";

related_power_pin : "VDD";

related_ground_pin : "VSS";

capacitance : 1.0;

... /* Other pin-level attributes and groups */

}

pin (Q) {

direction : "output";

function : "IQ1";

related_power_pin : "VDD";

related_ground_pin : "VSS";

... /* Other pin-level attributes and groups */

} /* End Pin group */

} /* End Cell group */

} /* End Library group */

MUX-Scan Retention Cell

Figure 92 and Example 108 show a scan retention cell structure that is defined using the

latch group. The cell is the scan version of the retention cell modeled in the example in

Retention Cell With Multiple latch Groups. The test_cell group includes only the function

of the nonscan version of the retention cell.

Figure 92 MUX-Scan Retention Cell Model Schematic

Liberty User Guide Volume 1

R-2020.09

508

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

Example 108 MUX-Scan Retention Cell Model

library (Retention_cell_Example) {

delay_model : table_lookup;

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1uA";

capacitive_load_unit (0.1,ff);

default_fanout_load : 1.0;

default_inout_pin_cap : 1.0;

default_input_pin_cap : 1.0;

default_output_pin_cap : 1.0;

input_threshold_pct_rise : 50 ;

input_threshold_pct_fall : 50 ;

output_threshold_pct_rise : 50 ;

output_threshold_pct_fall : 50 ;

slew_lower_threshold_pct_fall : 30.0 ;

slew_lower_threshold_pct_rise : 30.0 ;

slew_upper_threshold_pct_fall : 70.0 ;

slew_upper_threshold_pct_rise : 70.0 ;

voltage_map (VDD, 1.0);

voltage_map (VDDB, 0.9);

voltage_map (VSS, 0.0);

nom_process : 1.0;

nom_temperature : 25.0;

nom_voltage : 1.1;

operating_conditions(xyz) {

process : 1.0 ;

temperature : 25 ;

voltage : 1.1 ;

tree_type : "balanced_tree" ;

}

default_operating_conditions : xyz;

… /* Other library-level attributes */

cell (scan_retention_cell) {

retention_cell : my_scan_ret_cell;

… /* Other cell-level attributes and groups */

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

pg_pin(VDDB) {

voltage_name : VDDB;

pg_type : backup_power;

}

pin(RET) {

Liberty User Guide Volume 1

R-2020.09

509

Chapter 9: Advanced Low-Power Modeling

Retention Cell Modeling

direction : input;

capacitance : 0.1;

related_power_pin : VDDB;

related_ground_pin : VSS;

retention_pin(save_restore, "1");

… /* Other pin-level attributes and groups */

}

pin(D) {

direction : input;

capacitance : 0.1;

related_power_pin : VDD;

related_ground_pin : VSS;

… /* Other pin-level attributes and groups */

}

pin(CK) {

direction : input;

clock : true;

capacitance : 0.1;

related_power_pin : VDD;

related_ground_pin : VSS;

… /* Other pin-level attributes and groups */

}

pin(Q) {

direction : output;

function : "Q2";

related_power_pin : VDD;

related_ground_pin : VSS;

reference_input : "RET CK q1";

… /* Other pin-level attributes and groups */

}

pin(q1) {

direction : internal;

function : "Q1";

related_power_pin : VDD;

related_ground_pin : VSS;

reference_input : "RET CK SE D SI";

… /* Other pin-level attributes and groups */

}

retention_condition() {

power_down_function : "!VDD+VSS";

required_condition: "!RET";

}

latch ("p1 p2,p3,p4,p5", "Q1", "QN1") {

enable : " p1' + p2' ";

data_in : " p3'*p4 + p3*p5 ";

power_down_function : "!VDD+VSS"; /* Latch 1 is powered by Primary

power supply */

}

latch ("p1 p2 p3", "Q2", "QN2") {

enable : " p1 * p2 ";

data_in : " p3 ";

power_down_function : "!VDDB+VSS"; /* Latch 2 is powered by Backup

Liberty User Guide Volume 1

R-2020.09

510

Chapter 9: Advanced Low-Power Modeling

Always-On Cell Modeling

power supply */

}

test_cell() {

pin(SI) {

direction : input;

signal_type : "test_scan_in";

}

pin(RET) {

direction : input;

}

pin(D) {

direction : input;

}

pin(SE) {

direction : input;

signal_type : "test_scan_enable";

}

pin(CK) {

direction : input;

}

latch (“Q1”, “QN1” ) {

enable : " RET’ + CK' ";

data_in : " D ";

}

latch ("Q2", "QN2”) {

enable : " RET * CK ";

data_in : " q1 ";

}

pin (q1) {

direction : internal;

function : "Q1";

}

pin(Q) {

direction : output;

signal_type : "test_scan_out";

function : "Q2";

} /* End Pin group */

} /* End test_cell group */

} /* End cell group */

} /* End Library group */

Always-On Cell Modeling

In complex low-power designs, some signals need to be routed through blocks that

have been shut down. As a result, a variety of cell categories require “always-on” signal

pins. Always-on cells remain powered on by a backup power supply in the region where

they are placed even when the main power supply is switched off. The cells also have a

secondary backup power pin that supplies the current that is necessary when the main

supply is not available.

Liberty User Guide Volume 1

R-2020.09

511

Chapter 9: Advanced Low-Power Modeling

Always-On Cell Modeling

For tools to recognize always-on cells in the reference library and use them during

special always-on synthesis, library models need an attribute that can identify them. The

always_on attribute identifies always-on cells and pins.

When you run the read_lib command, the always_on attribute is automatically added to

buffer or inverter cells that have input and output pins that are linked to backup power or

backup ground PG pins. The following buffers and inverters are automatically identified as

always-on cells:

•

Cells with one primary power pin, one primary ground pin, and one backup ground

pin, if both the input and output signal pins are linked to the primary power and backup

ground pins.

•

Cells with one primary power pin, one backup power pin, and one primary ground pin,

if both the input and output signal pins are linked to the backup power and primary

ground pins.

•

Cells with one primary power pin, one backup power pin, one primary ground pin, and

one backup ground pin if

◦

Both the input and output signal pins are linked to the backup power pin and the

backup ground pin.

◦

Both the input and output signal pins are linked to the primary power pin and the

backup ground pin.

◦

Both the input and output signal pins are linked to the backup power pin and the

primary ground pin.

The always_on attribute also identifies always-on input pins so that tools can trace all

always-on nets crossing domains that are shut down. Always-on pins are automatically

created for the following cells:

•

Save and restore pins on retention cells

•

Control pins on switch cells

•

Enable pins on isolation cells and enable level-shifter cells

The cell library does not require that you specify these cells as always-on cells. If you have

other cells that need to be specified as always-on, you can add them to the library cell

model.

Always-On Cell Syntax

library (library_name) {

...

cell (cell_name) {

always_on : true;

Liberty User Guide Volume 1

R-2020.09

512

Chapter 9: Advanced Low-Power Modeling

Always-On Cell Modeling

...

pin (pin_name) {

always_on : true;

... }

always_on Simple Attribute

The always_on simple attribute models always-on cells and signal pins. During

compilation, the always_on attribute is automatically added to buffer or inverter cells that

have input and output pins that are linked to backup power or backup ground PG pins. The

always_on attribute is supported at the cell level and at the pin level.

Note:

Some macro cell input pins require that you specify the always_on attribute for

always-on pins.

Always-On Simple Buffer Example

Figure 93 and the example that follows it show a simple always-on cell buffer. In the

figure, the A signal pin and the Y signal pin are linked to the VDDBAK and VSS power and

ground pin pair.

Figure 93 Simple Always-On Cell Buffer

library (my_library) {

…

voltage_map (VDD, 1.0);

voltage_map (VDDBAK, 1.0);

voltage_map (VSS, 0.0);

...

cell(buffer_type_AO) {

always_on : true;

/* The always-on attribute is not required at the cell

Liberty User Guide Volume 1

R-2020.09

513

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

level if the cell is an always-on cell*/

/* Other cell level information */

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin(VDDBAK) {

voltage_name : VDDBAK;

pg_type : backup_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

…

pin (A) {

/* The always-on attribute is not required at the pin

level if the cell is an always-on cell*/

related_power_pin : VDDBAK;

related_ground_pin : VSS;

/* Other pin level information */

}

pin (Y) {

/* The always-on attribute is not required at the pin

level if the cell is an always-on cell*/

function : "A";

related_power_pin : VDDBAK;

related_ground_pin : VSS;

power_down_function : "!VDDBAK + VSS";

/* Other pin level information */

} /* End Pin group */

} /* End Cell group */

…

} /* End Library group */

Macro Cell Modeling

Macro cells do not contain internal logic information. At the cell-level, macro cells

are modeled using the is_macro_cell attribute. To model macro cells for power

management, use the power management pin-level attributes described in the following

sections.

Liberty User Guide Volume 1

R-2020.09

514

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

Macro Cell Isolation Modeling

To indicate that a macro cell is internally isolated and does not require external isolation,

set the is_isolated attribute. Figure 94 shows a macro cell with the is_isolated

attribute. The macro cell is connected to a power-switching circuit. The macro cell pin,

In1 is internally isolated, and In2 is connected to an external isolation cell. When the

is_isolated attribute is set on the pin, In1, the pin is considered to be internally isolated.

Figure 94 Macro Cell With the is_isolated Attribute

Example 109 shows the modeling syntax of an internally isolated macro cell.

Example 109 Macro Cell Isolation Modeling Syntax

cell (cell_name) {

...

is_macro_cell : true;

pin (pin_name) {

direction : input | inout | output;

is_isolated : true | false;

isolation_enable_condition : Boolean_expression;

...

}

bus (bus_name) {

direction : input | inout | output;

is_isolated : true | false;

Liberty User Guide Volume 1

R-2020.09

515

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

isolation_enable_condition : Boolean_expression;

...

}

bundle (bundle_name) {

direction : input | inout | output;

is_isolated : true | false;

isolation_enable_condition : Boolean_expression;

...

}

...

}

Example 110 shows a typical model of an internally isolated macro cell.

Example 110 Modeling an Internally Isolated Macro Cell by Using the is_isolated and

isolation_enable_condition Attributes

library (internal_isolated_pin_example) {

...

type ( bus_type_name ) {

base_type : array;

data_type : bit

bit_width : 2;

bit_from : 1;

bit_to : 0;

}

cell ( macro ) {

is_macro_cell : true;

pg_pin(GND) {

voltage_name : VSS;

pg_type : primary_ground;

}

pg_pin(VDDI) {

voltage_name : VDDH;

pg_type : primary_power;

}

......

pin (en) {

direction : input;

...

}

pin (in_bus) {

bus_type : bus_type_name;

direction : input;

...

}

pin (sp) {

direction : input|inout;

is_isolated : true;

isolation_enable_condition : "en’";

related_power_pin : VDDI;

related_ground_pin : GND;

......

Liberty User Guide Volume 1

R-2020.09

516

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

}

pin (out) {

direction : output;

is_isolated : true;

isolation_enable_condition : "en’";

related_power_pin : VDDI;

related_ground_pin : GND;

......

}

bus (bus_a) {

bus_type : bus_type_name;

is_isolated : true;

isolation_enable_condition : "en’ * in_bus * in_bundle";

related_power_pin : VDDI;

related_ground_pin : GND;

...

}

...

}

Pin-Level Attributes

This section describes the pin-level attributes of isolated macro cells.

is_isolated Attribute

The is_isolated attribute indicates that a pin, bus, or bundle of a macro cell is internally

isolated and does not require the insertion of an external isolation cell. The default is

false.

Note:

The is_isolated attribute also supports the internal isolation of pad-cell pins.

isolation_enable_condition Attribute

The isolation_enable_condition attribute specifies the condition of isolation for

internally isolated pins, buses, or bundles of a macro cell. When this attribute is defined

in a pin group, the corresponding Boolean expression can include only input and inout

pins. Do not include the output pins of an internally isolated macro cell in the Boolean

expression.

When the isolation_enable_condition attribute is defined in a bus or bundle group,

the corresponding Boolean expression can include pins, and buses and bundles of the

same bit-width. For example, when the Boolean expression includes a bus and a bundle,

both of them must have the same bit-width.

All the pins, buses, and bundles specified in the Boolean expression of the

isolation_enable_condition attribute must have the always_on attribute.

Liberty User Guide Volume 1

R-2020.09

517

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

Note:

The isolation_enable_condition attribute also supports the internal

isolation of pad-cell pins.

Modeling Macro Cells With Internal PG Pins

This capability is useful for modeling macro cells containing internal voltage converters

that supply power to the internal subcells.

Figure 95 shows the schematic of a macro cell with internal voltage converters, VC1 and

VC2. VC1 and VC2 convert the external supply voltages, VDD and VCC, into internal

supply voltages, IN1 and IN2, respectively. The pins, IN1 and IN2, are internal PG pins of

the macro cell and are used to power the logic connected to the input ports, A1 and A2.

Figure 95 Macro Cell With Internal PG Pins

Liberty User Guide Volume 1

R-2020.09

518

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

Example 111 shows a typical model of the macro cell. The pg_type attribute is set to

internal_power, the direction attribute is set to internal, and the pg_function

attribute is set to VDD and VCC, on the PG pins, IN1 and IN2, respectively.

Example 111 Macro Cell Model With Internal PG Pins

voltage_map (VDD, 1.4);

voltage_map (VCC, 2.8);

voltage_map (VDD, 1.4);

voltage_map (VCC, 2.8);

voltage_map (VSS, 0.0);

voltage_map (IN1, 0.7);

voltage_map (IN2, 6.5);

cell(new_macro_cell) {

...

is_macro_cell : true;

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin(VCC) {

voltage_name : VCC;

pg_type : primary_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

pg_pin(IN1) {

voltage_name : IN1;

pg_type : internal_power;

direction : internal ;

pg_function : VDD;

}

pg_pin(IN2) {

voltage_name : IN2;

pg_type : internal_power;

direction : internal ;

pg_function : VCC;

}

...

pin(CK) {

related_power_pin : VDD ;

related_ground_pin : VSS ;

direction : input ;

...

}

pin(A1) {

related_power_pin : IN1 ;

related_ground_pin : VSS ;

direction : input ;

...

Liberty User Guide Volume 1

R-2020.09

519

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

}

pin(A2) {

related_power_pin : IN2 ;

related_ground_pin : VSS ;

direction : input ;

}

...

}

Note:

You do not need to specify the switch_cell_type and switch_function

attributes for this macro cell because it does not include any built-in switches.

Macro Cell With Built-in Multiplexer

The figure in Macro Cell With Fine-Grained Internal Power Switches and the example that

follows show a macro cell with fine-grained internal power switches and a built-in power

multiplexer with input PG pin rails, VDD1 and VDD2.

Some of the signal pins are related to the primary PG pins. For the signal pins, INPUT and

OUTPUT, the related power pin is VDD1. However for the SWITCH2 signal pin, the related

power pin is VVDD_int.

Liberty User Guide Volume 1

R-2020.09

520

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

Figure 96 Macro Cell With Built-in Multiplexer

In the following Liberty model, the internal PG pin, VVDD_int, does not have the

switch_function attribute. The Boolean expression of the VVDD_int pg_function

attribute includes the signal pin, SIG_EN.

library(mylib) {

.../* unit attributes */

voltage_map(VDD1, 0.80); /* primary power */

voltage_map(VDD2, 1.20); /* secondary power */

voltage_map(VVDD1, 0.80); /* internal power */

voltage_map(VVDD_int, 0.80); /* internal power */

voltage_map(VVDD2, 0.80); /* internal power */

voltage_map(VSS, 0.0); /* primary ground */

... /* nominal PVT definitions */

... /* operation conditions */

... /* threshold definitions */

.../* default attributes */

... /* table templates */

cell(PG_MUX_macro) {

area : 1.0;

switch_cell_type : fine_grain;

is_macro_cell : true;

pin(SIG_EN) {

Liberty User Guide Volume 1

R-2020.09

521

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

direction : input;

capacitance : 1.00;

related_power_pin : VDD1;

related_ground_pin : VSS;

switch_pin : true;

internal_power() {

...

}

pin(SWITCH1) {

direction : input;

capacitance : 1.00;

related_power_pin : VDD1;

related_ground_pin : VSS;

switch_pin : true;

internal_power() {

...

}

pin(SWITCH2) {

direction : input;

capacitance : 1.00;

related_power_pin : VVDD_int;

related_ground_pin : VSS;

switch_pin : true;

internal_power() {

...

}

pg_pin(VDD1) {

pg_type : primary_power;

direction : input ;

voltage_name : VDD1;

}

pg_pin(VDD2) {

pg_type : primary_power;

direction : input ;

voltage_name : VDD2;

}

pg_pin (VVDD1) {

pg_type : internal_power;

voltage_name : VVDD1;

direction : internal ;

switch_function : "(SWITCH1)";

pg_function : "VDD1";

}

pg_pin (VVDD_int) {

pg_type : internal_power;

voltage_name : VVDD_int;

direction : internal ;

pg_function : "(VDD1 * !SIG_EN + VDD2 * SIG_EN)";

}

pg_pin (VVDD2) {

Liberty User Guide Volume 1

R-2020.09

522

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

pg_type : internal_power;

voltage_name : VVDD2;

direction : internal ;

switch_function : "(SWITCH2)";

pg_function : "(VVDD_int)";

}

pg_pin ( VSS ) {

pg_type : primary_ground;

voltage_name : VSS;

direction : inout ;

}

pin(SWITCHOUT1) {

direction : output;

related_power_pin : VDD1;

related_ground_pin : VSS;

function : "SWITCH1";

power_down_function : "!VDD1 + VSS";

timing() {

related_pin : "SWITCH1";

...

}

pin(SWITCHOUT2) {

direction : output;

related_power_pin : VVDD_int;

related_ground_pin : VSS;

function : "SWITCH2";

power_down_function : "!VVDD_int + VSS";

timing() {

related_pin : "SWITCH1";

...

}

pin(INPUT) {

direction : input;

related_power_pin : VVDD2;

related_ground_pin : VSS;

}

pin(OUTPUT) {

direction : output;

related_power_pin : VVDD2;

related_ground_pin : VSS;

power_down_function : "!VVDD2 + VSS";

timing() {

related_pin : "INPUT";

...

}

} /*end library group*/

Liberty User Guide Volume 1

R-2020.09

523

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

Macro Cell With Fine-Grained Internal Power Switches

Figure 97 and the example that follows it show a macro cell with fine-grained internal

power switches. In the figure, the CTRL signal pin is linked to the PVDD and PVSS power

and ground pin pair, and the MA signal pin and the A signal pin are linked to the PVVDD

and PVSS power and ground pin pair.

Figure 97 Macro Cell With Fine-Grained Power Switch Schematics

library (macro_switch) {

...

Voltage_map (PVDD, 1.0);

Voltage_map (PVVDD, 1.0);

Voltage_map (PVSS, 0.0);

operating_conditions(XYZ) {

process : 1.0;

voltage : 1.0;

temperature : 25.0;

}

default_operating_conditions : XYZ;

cell(MACRO) {

is_macro_cell : true;

switch_cell_type : fine_grain;

...

pg_pin(PVDD) {

voltage_name : PVDD;

pg_type : primary_power;

direction : input;

Liberty User Guide Volume 1

R-2020.09

524

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

}

pg_pin(PVSS) {

voltage_name : PVSS;

pg_type : primary_ground;

direction : input;

}

pg_pin(PVVDD) {

voltage_name : PVVDD;

pg_type : internal_power;

direction : internal;

switch_function : "CTRL";

pg_function : "PVDD";

}

pin(CTRL) {

direction : input;

switch_pin : true;

related_power_pin : PVDD;

related_ground_pin : PVSS;

...

}

pin(A) {

direction : input;

related_power_pin : PVVDD;

related_ground_pin : PVSS;

...

}

pin(MA) {

direction : input;

power_down_function : "!PVDD + PVSS";

related_power_pin : PVVDD;

related_ground_pin : PVSS;

...

}

Macro Cell With an Always-On Pin Example

Figure 98 and the example that follows it show a macro cell with one always-on pin. In the

figure, the A signal pin and Y1 signal pin are linked to the VDDBAK and VSS power and

ground pin pair. The B, C, and Y2 signal pins are linked to the VDD and VSS power and

ground pin pair.

Liberty User Guide Volume 1

R-2020.09

525

Chapter 9: Advanced Low-Power Modeling

Macro Cell Modeling

Figure 98 Macro Cell With an Always-On Pin

library (my_library) {

...

voltage_map (VDD, 2.0) ;

voltage_map (VSS, 0.1) ;

voltage_map (VDDBAK, 1.0) ;

...

cell(Macro_cell_with_AO_pins) {

/* other cell level information */

pg_pin(VDD) {

voltage_name : VDD;

pg_type : primary_power;

}

pg_pin(VSS) {

voltage_name : VSS;

pg_type : primary_ground;

}

pg_pin(VDDBAK) {

voltage_name : VDDBAK;

pg_type : backup_power;

}

...

pin (A) {

always_on : true;

related_power_pin : VDDBAK;

related_ground_pin : VSS;

/* Other pin level information */

}

pin (B C) {

related_power_pin : VDD;

related_ground_pin : VSS;

Liberty User Guide Volume 1

R-2020.09

526

Chapter 9: Advanced Low-Power Modeling

Modeling Antenna Diodes

/* Other pin level information */

}

pin (Y1) {

always_on : true;

function : "A";

related_power_pin : VDDBAK;

related_ground_pin : VSS;

power_down_function : "!VDD + !VDDBAK + VSS";

/* Other pin specific information */

} /* End Pin group */

pin (Y2) {

function : "A";

related_power_pin : VDD;

related_ground_pin : VSS;

power_down_function : "!VDD + !VDDBAK + VSS";

/* Other pin specific information */

} /* End Pin group */

...

} /* End Cell group */

...

} /* End Library group */

Modeling Antenna Diodes

Modeling antenna diodes includes modeling antenna-diode cells and cells with built-in

antenna-diode ports.

Antenna-Diode Cell Modeling

An antenna-diode cell has only one input to a diode that discharges electrical charges.

The cell is typically inserted at the boundary between two power domains and can be

placed in any one of the power domains. Figure 99 shows the three types of antenna-

diode cells.

Liberty User Guide Volume 1

R-2020.09

527

Chapter 9: Advanced Low-Power Modeling

Modeling Antenna Diodes

Figure 99 Types of Antenna-Diode Cells

In multivoltage designs, the power type antenna-diode cell is connected to VDD of a power

domain where VSS is shut down. The ground type antenna-diode cell is connected to VSS

of a power domain where VDD is shut down. The power-and-ground type antenna-diode

cell is connected to both VDD and VSS. To eliminate leakage paths that can result in chip

failure, the correct type of antenna-diode cell must be inserted.

The modeling syntax of the antenna-diode cell is as follows:

cell (cell name) {

antenna_diode_type : power | ground | power_and_ground;

pin (pin name) {

antenna_diode_related_power_pins : power pin name;

antenna_diode_related_ground_pins : ground pin name;

...

}

...

}

In a library, a cell that has a single pin with the direction attribute set to input or inout

is considered to be an antenna-diode cell.

Cell-Level Attribute

antenna_diode_type Attribute

The antenna_diode_type attribute specifies the type of antenna-diode cell. Valid values

are power, ground, and power_and_ground.

Liberty User Guide Volume 1

R-2020.09

528

Chapter 9: Advanced Low-Power Modeling

Modeling Antenna Diodes

Pin-Level Attributes

antenna_diode_related_power_pins Attribute

The antenna_diode_related_power_pins attribute specifies the related power pin of the

antenna-diode cell. Apply the antenna_diode_related_power_pins attribute to the input

pin of the cell.

antenna_diode_related_ground_pins Attribute

The antenna_diode_related_ground_pins attribute specifies the related ground pin of

the antenna-diode cell. Apply the antenna_diode_related_ground_pins attribute to the

input pin of the cell.

Antenna-Diode Cell Modeling Example

Example 112 shows a typical model of the antenna-diode cell.

Example 112 Antenna-Diode Cell Model

library (antenna_library)

...

cell (power_diode_cell) {

antenna_diode_type : "power";

pg_pin (VDD) {

voltage_name : "VDD";

pg_type : "primary_power";

}

pin (INP) {

antenna_diode_related_power_pins : "VDD";

direction : "input";

}

cell (ground_diode_cell) {

antenna_diode_type : "ground";

pg_pin (VSS) {

voltage_name : "VSS";

pg_type : "primary_ground";

}

pin (INP) {

antenna_diode_related_ground_pins : "VSS";

direction : "input";

}

cell (pg_diode_cell) {

antenna_diode_type : "power_and_ground";

pg_pin (VDD) {

voltage_name : "VDD";

pg_type : "primary_power";

}

pg_pin (VSS) {

Liberty User Guide Volume 1

R-2020.09

529

Chapter 9: Advanced Low-Power Modeling

Modeling Antenna Diodes

voltage_name : "VSS";

pg_type : "primary_ground";

}

pin (INP) {

antenna_diode_related_power_pins : "VDD";

antenna_diode_related_ground_pins : "VSS";

direction : "input";

}

Modeling Cells With Built-In Antenna-Diode Ports

To model a cell with a built-in antenna-diode pin, specify the antenna_diode_type

attribute on the pin.

The modeling syntax of the cell with a built-in antenna-diode pin is as follows:

cell (cell name) {

...

pin (pin name) {

antenna_diode_type : power | ground | power_and_ground;

antenna_diode_related_power_pins : "power_pin1 power_pin2";

antenna_diode_related_ground_pins : "ground_pin1 ground_pin2";

...

}

pin (pin name) {

...

}

...

}

Pin-Level Attributes

antenna_diode_type Attribute

The antenna_diode_type attribute specifies the type of antenna-diode pin. Valid values

are power, ground, and power_and_ground.

antenna_diode_related_power_pins Attribute

The antenna_diode_related_power_pins attribute specifies the related power pins for

the antenna-diode pin. Apply the antenna_diode_related_power_pins attribute to the

antenna-diode pin.

antenna_diode_related_ground_pins Attribute

The antenna_diode_related_ground_pins attribute specifies the related ground pins for

the antenna-diode pin. Apply the antenna_diode_related_ground_pins attribute to the

antenna-diode pin.

Liberty User Guide Volume 1

R-2020.09

530

Chapter 9: Advanced Low-Power Modeling

Modeling Antenna Diodes

Antenna-Diode Pin Modeling Example

Example 113 shows a typical model of a cell with a built-in antenna-diode pin.

Example 113 A Cell Model With Built-In power_and_ground Antenna-Diode Pin Port

cell (cell_with_internal_diode_port)

area : "1.0";

pg_pin (VDD) {

voltage_name : "VDD";

pg_type : "primary_power";

}

pg_pin (VDD1) {

voltage_name : "VDD1";

pg_type : "primary_power";

}

pg_pin (VSS) {

voltage_name : "VSS";

pg_type : "primary_ground";

}

pg_pin (VSS1) {

voltage_name : "VSS1";

pg_type : "primary_ground";

}

pin (antenna_diode) {

antenna_diode_type: power_and_ground;

antenna_diode_related_power_pins : "VDD VDD1";

antenna_diode_related_power_pins : "VSS VSS1";

direction : "input";

capacitance : "1.0";

}

pin (INP1) {

direction : "input";

capacitance : "1.0";

}

pin (INP2) {

direction : "input";

capacitance : "1.0";

}

pin (OUT1) {

related_power_pin : "VDD";

related_ground_pin : "VSS";

direction : "output";

}

pin (OUT1) {

related_power_pin : "VDD";

related_ground_pin : "VSS";

direction : "output";

}

Liberty User Guide Volume 1

R-2020.09

531

Composite Current Source Modeling

This chapter provides an overview of composite current source modeling (CCS).

It covers the syntax for CCS modeling in the following sections:

• Modeling Cells With Composite Current Source Information

• Representing Composite Current Source Driver Information

• Representing Composite Current Source Receiver Information

• Comparison Between Two-Segment and Multisegment Receiver Models

• Two-Segment Receiver Capacitance Model

• Multisegment Receiver Capacitance Model

• CCS Retain Arc Support

• Composite Current Source Driver and Receiver Model Example

Modeling Cells With Composite Current Source Information

Composite current source (CCS) models include driver and receiver models. A driver

model can be used with or without the receiver model.

Nanometer transistor geometries with nonlinear waveforms, nonlinear interconnect delays,

and high circuit speeds require accurate delay calculation. CCS models support driver

complexity by using a time- and voltage- dependent current source with an infinite drive

resistance. The driver model maps the arbitrary transistor behavior for lumped loads to

that for an arbitrary detailed parasitic network, which results in high accuracy.

In the receiver model, the input capacitance of a receiver is dynamically adjusted during

the voltage transitions.

Representing Composite Current Source Driver Information

Specify the nonlinear delay information based on input slew and output load at the pin

level by defining a current lookup table in a timing group.

Liberty User Guide Volume 1

R-2020.09

532

Chapter 10: Composite Current Source Modeling

Representing Composite Current Source Driver Information

Composite Current Source Lookup Tables

To define the lookup tables, use the following groups and attributes:

•

output_current_template group in the library group

•

output_current_rise and output_current_fall groups in the timing group

Defining the output_current_template Group

Use this library-level group to create templates of common information that multiple

current vectors can use. A table template specifies the composite current source driver

model and the breakpoints for the axis. Specifying index_1, index_2, and index_3 values

at the library level is optional.

output_current_template Syntax

library(name

) {

...

output_current_template(template_name

) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

variable_3: time;

...

}

...

}

Template Variables for CCS Driver Models

The table template specifying composite current source driver models can have three

variables: variable_1, variable_2, and variable_3. The valid values for variable_1

and variable_2 are input_net_transition and total_output_net_capacitance. The

only valid value for variable_3 is time.

output_current_template Example

library (new_lib) {

...

output_current_template (CCT) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

variable_3: time;

...

}

...

}

Liberty User Guide Volume 1

R-2020.09

533

Chapter 10: Composite Current Source Modeling

Representing Composite Current Source Driver Information

Defining the Lookup Table Output Current Groups

To specify the output current for the nonlinear table model, use the output_current_rise

and output_current_fall groups within the timing group.

Note:

The output_current_rise group can include negative current values and the

output_current_fall group can include positive current values.

output_current_rise Syntax

timing() {

output_current_rise () {

vector (template_name

){

reference_time : float;

index_1 (float);

index_2 (float);

index_3 ("float,..., float");

values("float,..., float");

}

vector Group

Define the vector group in the output_current_rise or output_current_fall group.

This group stores current information for a particular input slew and output load.

reference_time Simple Attribute

Define the reference_time simple attribute in the vector group. The reference_time

attribute represents the time at which the input waveform crosses the rising or falling input

delay threshold.

Template Variables for CCS Driver Models

The table template specifying composite current source driver models can have three

variables: variable_1, variable_2, and variable_3. The valid values for variable_1

and variable_2 are input_net_transition and total_output_net_capacitance. The

only valid value for variable_3 is time.

The index value for input_net_transition or total_output_net_capacitance is a

single floating-point number. The index values for time are a list of floating-point numbers.

The values attribute defines a list of floating-point numbers that represent the current

values of the driver model.

Liberty User Guide Volume 1

R-2020.09

534

Chapter 10: Composite Current Source Modeling

Representing Composite Current Source Receiver Information

vector Group Example

library (new_lib) {

...

output_current_template (CCT) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

variable_3: time;

}

...

timing() {

output_current_rise() {

vector(CCT) {

reference_time : 0.05;

index_1(0.1);

index_2(2.1);

index_3("1.0, 1.5, 2.0, 2.5, 3.0");

values("1.1, 1.2, 1.4, 1.3, 1.5");

...

}

output_current_fall() {

vector(CCT) {

reference_time : 0.05;

index_1(0.1);

index_2(2.1);

index_3("1.0, 1.5, 2.0, 2.5, 3.0");

values("1.1, 1.2, 1.4, 1.3, 1.5");

...

}

Representing Composite Current Source Receiver Information

Switching transistors have nonlinear capacitance. At an input or inout node, the collective

capacitance of all the transistors connected to that node is modeled as the receiver

capacitance. The Miller effect due to the output switching in the opposite direction adds to

the nonlinearity. The capacitances are dependent on the input slew and output load.

CCS receiver models are of two types:

•

Two-segment receiver capacitance model

The voltage rise or fall at an input or inout node is divided into two segments and

the corresponding capacitance values are stored as receiver_capacitance1 and

receiver_capacitance2 lookup tables.

•

Multisegment capacitance model

Liberty User Guide Volume 1

R-2020.09

535

Chapter 10: Composite Current Source Modeling

Comparison Between Two-Segment and Multisegment Receiver Models

The voltage rise or fall at an input or inout node is divided into multiple segments and

the corresponding capacitance values are stored as lookup tables. The number of

segments is represented by the letter N. This model better represents the nonlinearity

of the net receiver capacitance.

Comparison Between Two-Segment and Multisegment Receiver

Models

You might achieve different results with the two-segment and the multisegment receiver

capacitance models.

This is because the number of segments are different. Also, the multisegment model uses

the input slew value of the library-level slew_derate_from_library attribute, shown

with the solid red line in Figure 100. This slew is used for the input_net_transition

(index_1) values of all the N segments, regardless of the local waveform slopes.

The two-segment model uses the local slope of the two segments (s1 and s2 in

Figure 100), shown with the solid blue lines. So even at N = 2, the multisegment and two-

segment model values might not match.

Liberty User Guide Volume 1

R-2020.09

536

Chapter 10: Composite Current Source Modeling

Two-Segment Receiver Capacitance Model

Figure 100 Slope Calculation in Multisegment and Two-Segment Receiver Models

Two-Segment Receiver Capacitance Model

Define the CCS receiver model

• At the pin level using the receiver_capacitance group.

Specify the receiver_capacitance1_rise, receiver_capacitance1_fall,

receiver_capacitance2_rise, receiver_capacitance2_fall groups in the

receiver_capacitance group.

The pin-level definition is not a function of the output capacitance and is useful when

there are no forward timing arcs.

•

At the timing level by specifying the receiver_capacitance1_rise,

receiver_capacitance1_fall, receiver_capacitance2_rise,

receiver_capacitance2_fall groups in the timing group.

Syntax

The following is the Liberty syntax of CCS timing receiver models.

Liberty User Guide Volume 1

R-2020.09

537

Chapter 10: Composite Current Source Modeling

Two-Segment Receiver Capacitance Model

cell(cell_name) {

mode_definition (mode_name) {

mode_value(name_string) {

when : "Boolean_expression";

sdf_cond : "Boolean_expression";

} ...

pin(pin_name) {

direction : input; /* or "inout" */

receiver_capacitance() {

when : "Boolean_expression";

char_when : "Boolean_expression";

mode (mode_name, mode_value);

receiver_capacitance1_rise (lu_template_name) {

index_1("float, ..., float");

index_2("float, ..., float");

values("float, ..., float");

}

receiver_capacitance1_fall (lu_template_name) { ... }

receiver_capacitance2_rise (lu_template_name) { ... }

receiver_capacitance2_fall (lu_template_name) { ... }

}

pin(pin_name) {

direction : output; /* or "inout" */

timing() {

when : "Boolean_expression";

mode (mode_name, mode_value);

...

receiver_capacitance() {

receiver_capacitance1_rise (lu_template_name) {

index_1("float, ..., float");

index_2("float, ..., float");

values("float, ..., float");

}

receiver_capacitance1_fall (lu_template_name) { ... }

receiver_capacitance2_rise (lu_template_name) { ... }

receiver_capacitance2_fall (lu_template_name) { ... }

}

} ...

}

Defining the receiver_capacitance Group at the Pin Level

To model the CCS receiver capacitance at the pin level, define the

receiver_capacitance group in the pin group. In the receiver_capacitance

group, specify the receiver_capacitance1_rise, receiver_capacitance1_fall,

receiver_capacitance2_rise, and receiver_capacitance2_fall groups. Each

Liberty User Guide Volume 1

R-2020.09

538

Chapter 10: Composite Current Source Modeling

Two-Segment Receiver Capacitance Model

of these groups specify a lookup table. The lookup table can be one-dimensional, two-

dimensional, or scalar.

The index values in the index_1 and index_1 attributes are a list of ascending floating-

point numbers. The values attribute defines a list of floating-point numbers that represent

the capacitances of the receiver model.

Define the template of the lookup table in the library-level lu_table_template group.

To use the template, specify the name of the lu_table_template group as the receiver

capacitance group name.

Defining the lu_table_template Group

The lu_table_template group defines the template for the following groups specified in

the receiver_capacitance group:

•

receiver_capacitance1_rise

•

receiver_capacitance1_fall

• receiver_capacitance2_rise

•

receiver_capacitance2_fall

The template definition includes the variable_1, variable_2, index_1, and index_2

attributes. The variable_1 and variable_2 attributes specify the index variables of the

lookup tables of the receiver capacitance groups. The index_1 and index_2 attributes

specify the numerical values of these variables.

The values of the variable_1 and variable_2 attributes are input_net_transition

and total_output_net_capacitance.

You can specify the following types of lookup tables in receiver capacitance groups:

•

One-dimensional tables with a single index, such as input_net_transition

• Two-dimensional tables with the indexes, input_net_transition and

total_output_net_capacitance

•

A scalar that has a single variation value irrespective of the input_net_transition

and total_output_net_capacitance values

lu_table_template Group Syntax

library(name) {

...

lu_table_template(template_name) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

index_1 ("float,..., float");

index_2 ("float,..., float");

Liberty User Guide Volume 1

R-2020.09

539

Chapter 10: Composite Current Source Modeling

Two-Segment Receiver Capacitance Model

...

}

...

}

Conditional Data Modeling

Use the following attributes in the receiver_capacitance group for conditional data

modeling in CCS receiver models.

when Attribute

The when attribute specifies the Boolean condition for the input state of the receiver

capacitance timing arc.

char_when Attribute

The char_when attribute specifies the input state at which the receiver capacitance timing

arc was characterized.

char_when_rise Attribute

The char_when_rise attribute specifies the rising input state at which the receiver

capacitance timing arc was characterized.

char_when_fall Attribute

The char_when_fall attribute specifies the falling input state at which the receiver

capacitance timing arc was characterized.

mode Attribute

The complex mode attribute specifies the current mode of the cell. When defined in the

receiver_capacitance group, the mode attribute specifies the receiver capacitance for

the given mode. If you specify the mode attribute, you must define the mode_definition

group at the cell level.

Examples

Example 114 shows a receiver capacitance model with conditional data, that is, the when

and mode attributes.

Example 114 Modeling Receiver Capacitance With when and mode Attributes

library(new_lib) {

...

output_current_template(CCT) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

variable_3: time;

index_1("0.1, 0.2");

index_2("1, 2");

index_3("1, 2, 3, 4, 5");

}

Liberty User Guide Volume 1

R-2020.09

540

Chapter 10: Composite Current Source Modeling

Two-Segment Receiver Capacitance Model

lu_table_template(LTT1) {

variable_1: input_net_transition;

index_1("0.1, 0.2, 0.3, 0.4");

}

lu_table_template(LTT2) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

index_1("0.1, 0.2");

index_2("1, 2");

}

...

cell(my_cell) {

...

mode_definition(rw) {

mode_value(read) {

when : "I";

sdf_cond : "I == 1";

}

mode_value(write) {

when : "!I";

sdf_cond : "I == 0";

}

pin(I) { /* pin-based receiver model defined for pin 'A' */

direction : input;

/* receiver capacitance for condition 1 */

receiver_capacitance() {

when : "I"; /* or using mode as next commented line */

/* mode (rw, read); */

receiver_capacitance1_rise(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance1_fall(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance2_rise(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance2_fall(LTT1) {

values("1, 2, 3, 4");

}

/* receiver capacitance for condition 2 */

receiver_capacitance() {

when : "!I"; /* or using mode as next commented line */

/* mode (rw, write); */

receiver_capacitance1_rise(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance1_fall(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance2_rise(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance2_fall(LTT1) {

values("1, 2, 3, 4");

}

pin (ZN) {

Liberty User Guide Volume 1

R-2020.09

541

Chapter 10: Composite Current Source Modeling

Two-Segment Receiver Capacitance Model

direction : input;

capacitance : 1.2;

…

timing() {

…

}

…

} /* end cell */

…

} /* end library */

Example 115 shows the use of the char_when attribute in the pin-level receiver

capacitance model.

Example 115 Receiver Capacitance Model With the char_when Attribute

library (mylib) {

/* library unit, slew, OC and other library level information */

/* receiver model template */

lu_table_template ("template_8x1") {

variable_1 : "input_net_transition";

index_1("0, 1, 2, 3, 4, 5, 6, 7");

}

...

cell (mycell) {

pin (Y) {

direction : "output";

function : "A1 * A2 * A3";

...

/* timing-based ccs receiver model and driver model */

timing () {

related_pin : "A1";

...

}

timing () {

related_pin : "A2";

...

}

timing () {

related_pin : "A3";

...

}

...

} /* end pin Y */

pin (A1) {

direction : "input";

...

/* pin-based ccs receiver model */

receiver_capacitance () {

/* default condition */

/* characterization input-state */

Liberty User Guide Volume 1

R-2020.09

542

Chapter 10: Composite Current Source Modeling

Two-Segment Receiver Capacitance Model

char_when : "!A2 * !A3";

receiver_capacitance1_rise ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance2_rise ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance1_fall ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance2_fall ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

...

} /* end pin A1 */

pin (A2) {

direction : "input";

...

/* pin-based ccs receiver model */

...

} /* end pin A2 */

pin (A3) {

direction : "input";

...

/* pin-based CCS receiver model */

/* enumerate all conditions */

receiver_capacitance () {

when : "!A1 * A2";

receiver_capacitance1_rise ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance2_rise ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance1_fall ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance2_fall ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

Liberty User Guide Volume 1

R-2020.09

543

Chapter 10: Composite Current Source Modeling

Two-Segment Receiver Capacitance Model

}

receiver_capacitance () {

when : "A1 * !A2";

receiver_capacitance1_rise ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance2_rise ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance1_fall ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance2_fall ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance () {

when : "!A1 * !A2";

receiver_capacitance1_rise ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance2_rise ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance1_fall ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

receiver_capacitance2_fall ("template_8x1") {

values("0.11111, 0.22222, 0.33333, 0.44444, 0.55555, \

0.66666, 0.77777, 0.88888");

}

...

} /* end pin A3 */

} /* end cell mycell */

} /* end library mylib */

Example 116 shows the use of the char_when_rise and char_when_fall attributes in the

pin-level receiver capacitance model.

Example 116 char_when_rise and char_when_fall Attributes in receiver_capacitance Group

library (mylib) {

...

cell (mycell) {

pin (Y) {

Liberty User Guide Volume 1

R-2020.09

544

Chapter 10: Composite Current Source Modeling

Two-Segment Receiver Capacitance Model

direction : "output";

function : "A1 * A2 * A3";

...

} /* end pin Y */

pin (A1) {

direction : "input";

/* pin-based ccs receiver model */

receiver_capacitance () {

char_when_rise : "!A2 * !A3";

char_when_fall : "!A2 * A3";

...

}

...

} /* end pin A1 */

...

} /* end cell mycell */

} /* end library mylib */

Defining the Receiver Capacitance Groups at the Timing Level

At the timing level, you do not need to define the receiver_capacitance group. Define

the receiver capacitance for the timing arcs by using the receiver_capacitance1_rise,

receiver_capacitance1_fall, receiver_capacitance2_rise, and

receiver_capacitance2_fall groups in the timing group.

Conditional Data Modeling

Use the mode and when attributes in timing arcs for conditional timing arcs and constraints.

Defining the lu_table_template Group

Use this library-level group to create templates of common information that multiple lookup

tables can use. A table template specifies the table parameters and the breakpoints for

each axis. Assign each template a name so that lookup tables can refer to it.

lu_table_template Group

Define your lookup table templates in the library group.

lu_table_template Group Syntax

Define your lookup table templates in the library group.

library(name

) {

...

lu_table_template(template_name

) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

index_1 ("float,..., float");

index_2 ("float,..., float");

...

Liberty User Guide Volume 1

R-2020.09

545

Chapter 10: Composite Current Source Modeling

Two-Segment Receiver Capacitance Model

}

...

}

Template Variables for CCS Receiver Models

The table template specifying composite current source receiver models can have only

two variables: variable_1 and variable_2. The parameters are the input transition time

and the total output capacitance of a constrained pin.

The index values in the index_1 and index_2 attributes are a list of ascending floating-

point numbers.

In the timing level, the table template specifying composite current source receiver models

can have two variables: variable_1 and variable_2. The valid values for either variable

are input_net_transition and total_output_net_capacitance.

The index values in the index_1 and index_2 attributes are a list of ascending floating-

point numbers.

The values attribute defines a list of floating-point numbers that represent the capacitance

for the receiver model.

lu_table_template Example

...

lu_table_template(LTT2) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

index_1("0.1, 0.2, 0.4, 0.3");

index_2("1.0, 2.0");

}

Timing-Level receiver_capacitance Example

timing() { /* timing arc-based receiver model*/

...

related_pin : "B"

receiver_capacitance1_rise(LTT2) {

values("1.1, 4., 2.0, 3.2");

}

receiver_capacitance1_fall(LTT2) {

values("1.0, 3.2, 4.0, 2.1");

}

receiver_capacitance2_rise(LTT2) {

values("1.1, 4., 2.0, 3.2");

}

receiver_capacitance2_fall(LTT2) {

values("1.0, 3.2, 4.0, 2.1");

}

...

}

Liberty User Guide Volume 1

R-2020.09

546

Chapter 10: Composite Current Source Modeling

Multisegment Receiver Capacitance Model

In the multisegment receiver capacitance model, the rise or fall voltage at an input

or inout node is divided into N segments, where N is an integer greater than 2.

For each segment, the capacitance values are stored in a lookup table using the

receiver_capacitance_rise or receiver_capacitance_fall groups.

The modeling syntax is:

library (library_name) {

receiver_capacitance_rise_threshold_pct ("float,...");

receiver_capacitance_fall_threshold_pct ("float,...");

...

cell(cell_name) {

...

/* The receiver_capacitance group can be under a pin or timing group. */

pin (pin_name) {

direction : input;

...

/* pin based receiver model */

receiver_capacitance () {

when : boolean expression;

mode (mode_name, mode_value);

receiver_capacitance_rise (lu_template_name) {

segment : "integer";

...

}

receiver_capacitance_fall (lu_template_name) {

segment : "integer";

...

}

} /* end receiver_capacitance group */

pin (pin_name) {

direction : output;

...

timing() {

...

when : boolean_expression;

mode (mode_name, mode_value);

receiver_capacitance_rise (lu_template_name) {

segment : "integer";

...

}

receiver_capacitance_fall (lu_template_name) {

segment : "integer";

...

}

} /* end timing group */

} /* end pin group */

} /* end cell group */

Liberty User Guide Volume 1

R-2020.09

547

Chapter 10: Composite Current Source Modeling

Multisegment Receiver Capacitance Model

} /* end library group */

Library-Level Groups and Attributes

This section describes the library-level groups and attributes for multisegment receiver

capacitance modeling.

lu_table_template Group

The lu_table_template group defines the template for the

receiver_capacitance_rise and receiver_capacitance_fall groups specified in the

receiver_capacitance and timing groups:

The template definition includes the variable_1, variable_2, index_1, and index_2

attributes. The variable_1 and variable_2 attributes specify the index variables for the

lookup tables (LUTs) in these groups. The index_1 and index_2 attributes specify the

numerical values of the variables.

The values of variable_1 and variable_2 attributes are input_net_transition and

total_output_net_capacitance.

You can specify the following types of lookup tables within these groups:

•

One-dimensional tables with a single index, such as input_net_transition

•

Two-dimensional tables with the indexes, input_net_transition and

total_output_net_capacitance

• A scalar that has a single variation value irrespective of the input_net_transition

and total_output_net_capacitance values

receiver_capacitance_rise_threshold_pct and

receiver_capacitance_fall_threshold_pct Attributes

The receiver_capacitance_rise_threshold_pct and

receiver_capacitance_fall_threshold_pct attributes specify the points that separate

the voltage rise and fall segments. Specify each point as a percentage of the rail voltage

between 0.0 and 100.0.

Specify monotonically increasing values with the

receiver_capacitance_rise_threshold_pct attribute, and monotonically decreasing

values with the receiver_capacitance_fall_threshold_pct attribute. For example,

receiver_capacitance_rise_threshold_pct ("0, 50, 60, 70, 80, 90, 100") ;

receiver_capacitance_fall_threshold_pct ("100, 50, 40, 30, 20, 10, 0") ;

The number of segments, N, is one less than the number of points. So, N is 6. The

following figure shows the segments for a voltage rise waveform.

Liberty User Guide Volume 1

R-2020.09

548

Chapter 10: Composite Current Source Modeling

Multisegment Receiver Capacitance Model

Figure 101 Segments in a Multisegment Receiver Capacitance Model

Pin and Timing Level Groups

This section describes the pin and timing level groups and attributes for multisegment

receiver capacitance modeling.

receiver_capacitance Group

At the pin level, define the receiver_capacitance_rise and

receiver_capacitance_fall groups in the receiver_capacitance group.

Each of these groups specify a lookup table. Define the template of the lookup table in the

library-level lu_table_template group. To use the template, specify the template name

as the receiver_capacitance_rise or receiver_capacitance_fall group name.

Note:

At the timing level, define the receiver_capacitance_rise and

receiver_capacitance_fall groups in the timing group.

receiver_capacitance_rise and receiver_capacitance_fall Groups

The receiver_capacitance_rise and receiver_capacitance_fall groups specify

the receiver capacitance values of each of the N rise and fall voltage segments, in lookup

tables. Specify N receiver_capacitance_rise groups, each for a unique segment. The

receiver_capacitance_fall group has the same requirement.

Liberty User Guide Volume 1

R-2020.09

549

Chapter 10: Composite Current Source Modeling

Multisegment Receiver Capacitance Model

The receiver_capacitance_rise and receiver_capacitance_fall

groups are structurally similar to the receiver_capacitance1_rise,

receiver_capacitance2_rise, receiver_capacitance1_fall, and

receiver_capacitance2_fall groups and include all of their attributes and subgroups.

segment Attribute

The segment attribute specifies the segment that the receiver_capacitance_rise or the

receiver_capacitance_fall group represents. The values vary from 1 to N.

Conditional Data Modeling

You can use the mode and when attributes in both the receiver_capacitance and timing

groups.

when Attribute

The when attribute specifies the Boolean condition for the input state of the receiver

capacitance timing arc.

mode Attribute

The complex mode attribute specifies the current mode of the cell. When defined in the

receiver_capacitance group, the mode attribute specifies the receiver capacitance for

the given mode. If you specify the mode attribute, you must define the mode_definition

group at the cell level.

Example

The following example shows a typical multisegment receiver capacitance model.

library (mylib) {

receiver_capacitance_rise_threshold_pct ("0, 50, 60, 70, 80, 90,

100");

receiver_capacitance_fall_threshold_pct ("100, 50, 40, 30, 20, 10, 0");

/* receiver model template */

lu_table_template ("delay_template_8x1") {

variable_1 : "input_net_transition";

index_1("0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8");

}

lu_table_template ("delay_template_8x8") {

variable_1 : "input_net_transition";

variable_2 : "total_output_net_capacitance";

index_1("0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8");

index_2("0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8");

}

...

cell (flop) {

pin (D) {

direction : input;

/* pin-based CCS receiver model */

Liberty User Guide Volume 1

R-2020.09

550

Chapter 10: Composite Current Source Modeling

Multisegment Receiver Capacitance Model

receiver_capacitance () {

/* default condition */

/* The old model groups are shown for comparison

receiver_capacitance1_rise(lu_template_name) {...}

receiver_capacitance2_rise(lu_template_name) {...}

receiver_capacitance1_fall(lu_template_name) {...}

receiver_capacitance2_fall(lu_template_name) {...}

receiver_capacitance_rise ("delay_template_8x1") {

segment : 1;

values("0.11111, 0.22222, 0.33333, 0.44444, \

0.55555, 0.66666, 0.77777, 0.88888");

}

...

receiver_capacitance_rise ("delay_template_8x1") {

segment : 6;

values("0.1111, 0.2222, 0.3333, 0.4444, \

0.5555, 0.6666, 0.77777, 0.88888");

}

receiver_capacitance_fall ("delay_template_8x1") {

segment : 1;

values("0.11111, 0.22222, 0.33333, 0.44444,\

0.55555, 0.66666, 0.77777, 0.88888");

}

...

receiver_capacitance_fall ("delay_template_8x1") {

segment : 6;

values("0.1111, 0.2222, 0.3333, 0.4444, \

0.5555, 0.6666, 0.7777, 0.8888");

}

} /* end receiver_capacitance group */

} /* end pin D group */

pin (CLK) {

direction : input;

...

}

pin (Y) {

direction : output;

function : "IQ";

...

timing () {

related_pin : "CLK";

...

/* arc-based ccs receiver model */

receiver_capacitance_rise ("delay_template_8x8") {

segment : 1;

values("0.11111, 0.22222, 0.33333, 0.44444, \

0.55555, 0.66666, 0.77777, 0.88888, ...");

}

...

receiver_capacitance_rise ("delay_template_8x8") {

segment : 6;

values("0.11111, 0.22222, 0.33333, 0.44444, \

Liberty User Guide Volume 1

R-2020.09

551

Chapter 10: Composite Current Source Modeling

CCS Retain Arc Support

0.55555, 0.66666, 0.77777, 0.88888, ...");

}

receiver_capacitance_fall ("delay_template_8x8") {

segment : 1;

values("0.11111, 0.22222, 0.33333, 0.44444, \

0.55555, 0.66666, 0.77777, 0.88888,...");

}

...

receiver_capacitance_fall ("delay_template_8x8") {

segment : 6;

values("0.11111, 0.22222, 0.33333, 0.44444, \

0.55555, 0.66666, 0.77777, 0.88888, ...");

}

} /* end timing group */

} /* end pin Y group*/

} /* end cell flop group*/

} /* end library mylib */

CCS Retain Arc Support

A retain delay is the shortest delay among all parallel arcs, from the input port to the

output port. Access time is the longest delay from the input port to the output port. The

output value is uncertain and unstable in the time interval between the retain delay and

the access time. A retain arc, as shown in Figure 102, ensures that the output does not

change during this time interval.

Figure 102 Retain Arc Example

Retain arcs:

•

Guarantee that the output does not change for a certain time interval.

• Are usually defined for memory cells.

•

Are not inferred as a timing check but are inferred as a delay arc.

Liberty syntax supports retain arcs in nonlinear delay models by providing the following

timing groups:

•

retaining_rise

Liberty User Guide Volume 1

R-2020.09

552

Chapter 10: Composite Current Source Modeling

CCS Retain Arc Support

• retaining_fall

• retain_rise_slew

• retain_fall_slew

CCS Retain Arc Syntax

The following syntax supports CCS timing models including the expanded and compact

CCS timing models. Because retain arcs have no relation to CCS receiver models, only

syntax for CCS driver models is described as follows:

Syntax

library (library_name) {

delay_model : table_lookup;

...

output_current_template(template_name) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

variable_3: time;

index_1("float, ..., float"); /* optional at library level */

index_2("float, ..., float"); /* optional at library level*/

index_3("float, ..., float"); /* optional at library level*/

}

cell(name) {

pin (name) {

timing() {

ccs_retain_rise() {

vector(template_name) {

reference_time : float;

index_1("float");

index_2("float");

index_3("float, ..., float");

values("float, ..., float");

}

vector(template_name) { . . . } …

}

ccs_retain_fall() {

vector(template_name) {

reference_time : float;

index_1("float");

index_2("float");

index_3("float, ..., float");

values("float, ..., float");

}

vector(template_name) { . . . } …

}

output_current_rise() { … }

output_current_fall() { … }

Liberty User Guide Volume 1

R-2020.09

553

Chapter 10: Composite Current Source Modeling

CCS Retain Arc Support

}

. . .

}

The format of the expanded CCS retain arc group is the same as the general CCS timing

arcs that are defined by using the output_current_rise and output_current_fall

groups.

ccs_retain_rise and ccs_retain_fall Groups

The ccs_retain_rise and ccs_retain_fall groups are provided in the timing group for

expanded CCS retain arcs.

vector Group

The current vector group in the ccs_retain_rise and ccs_retain_fall groups uses

the lookup table template defined by output_current_template. The vector group has

the following parameters:

•

input_net_transition

•

total_output_net_capacitance

• time

For every value pair (such as input_net_transition and

total_output_net_capacitance), there is a specified current(time) vector.

reference_time Attribute

The reference_time simple attribute specifies the time that the input signal waveform

crosses the rising or falling input delay threshold.

Compact CCS Retain Arc Syntax

The compact CCS retain arc format is the same as a general compact CCS timing arc.

The following retain arc syntax supports compact CCS timing.

Syntax

library(my_lib) {

...

base_curves (base_curves_name) {

base_curve_type: enum (ccs_timing_half_curve);

curve_x ("float…, float");

curve_y (integer, "float…, float");

...

Liberty User Guide Volume 1

R-2020.09

554

Chapter 10: Composite Current Source Modeling

CCS Retain Arc Support

}

compact_lut_template(template_name) {

base_curves_group: base_curves_name;

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

variable_3 : curve_parameters;

index_1 ("float…, float");

index_2 ("float…, float");

index_3 ("string…, string");

}

…

cell(cell_name) {

...

pin(pin_name) {

direction : string;

capacitance : float;

timing() {

compact_ccs_retain_rise (template_name) {

base_curves_group : "base_curves_name";

index_1 ("float…, float");

index_2 ("float…, float");

index_3 ("string…, string");

values ("…"…)

}

compact_ccs_retain_fall (template_name) {

base_curves_group : "base_curves_name";

index_1 ("float…, float");

index_2 ("float…, float");

index_3 ("string…, string");

values ("…"…)

}

compact_ccs_rise(template_name) { … }

compact_ccs_fall(template_name) { … }

. . .

}/*end of timing */

}/*end of pin */

}/*end of cell */

…

}/* end of library*/

compact_ccs_retain_rise and compact_ccs_retain_fall Groups

The compact_ccs_retain_rise and compact_ccs_retain_fall groups are provided in

the timing group for compact CCS retain arcs.

base_curves_group Attribute

The base_curves_group attribute is optional. The attribute is required when

base_curves_name is different from that defined in the compact_lut_template template

name.

Liberty User Guide Volume 1

R-2020.09

555

Chapter 10: Composite Current Source Modeling

Composite Current Source Driver and Receiver Model Example

index_1, index_2, and index_3 Attributes

The values for the index_1 and index_2 attributes are input_net_transition and

total_output_net_capacitance.

The values for the index_3 attribute must contain the following base curve parameters:

•

init_current

•

peak_current

• peak_voltage

•

peak_time

•

left_id

• right_id

values Attribute

The values attribute provides the compact CCS retain arc data values. The left_id and

right_id values for compact CCS timing base curves should be integers, and they must

be predefined in the base_curves group.

Composite Current Source Driver and Receiver Model Example

Example 117 is an example of composite current source driver and receiver model syntax.

Example 117 Composite Current Source Driver and Receiver Model

library(new_lib) {

. . .

output_current_template(CCT) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

variable_3: time;

}

lu_table_template(LTT1) {

variable_1: input_net_transition;

index_1("0.1, 0.2, 0.3, 0.4");

}

lu_table_template(LTT2) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

index_1("1.1, 2.2");

index_2("1.0, 2.0");

}

. . .

cell(DFF) {

pin(D) { /* pin-based receiver model*/

Liberty User Guide Volume 1

R-2020.09

556

Chapter 10: Composite Current Source Modeling

Composite Current Source Driver and Receiver Model Example

direction : input;

receiver_capacitance() {

receiver_capacitance1_rise(LTT1) {

values("1.1, 0.2, 1.3, 0.4");

}

receiver_capacitance1_fall(LTT1) {

values("1.0, 2.1, 1.3, 1.2");

}

receiver_capacitance2_rise(LTT1) {

values("0.1, 1.2, 0.4, 1.3");

}

receiver_capacitance2_fall(LTT1) {

values("1.4, 2.3, 1.2, 1.1");

}

}/*end of pin (D)*/

} /*end of cell (DFF)*/

...

cell() {

...

pin (Y) {

direction : output;

capacitance : 1.2;

timing() { /* CCS and arc-based receiver model*/

. . .

related_pin : "B";

receiver_capacitance1_rise(LTT2) {

values("0.1, 1.2" \

"3.0, 2.3");

}

receiver_capacitance1_fall(LTT2) {

values("1.1, 2.3" \

"1.3, 0.4");

}

receiver_capacitance2_rise(LTT2) {

values("1.3, 0.2" \

"1.3, 0.4");

}

receiver_capacitance2_fall(LTT2) {

values("1.3, 2.1" \

"0.4, 1.3");

}

output_current_rise() {

vector(CCT) {

reference_time : 0.05;

index_1(0.1);

index_2(1.0);

index_3("1.0, 1.5, 2.0, 2.5, 3.0");

values("1.1, 1.2, 1.5, 1.3, 0.5");

}

vector(CCT) {

reference_time : 0.05;

Liberty User Guide Volume 1

R-2020.09

557

Chapter 10: Composite Current Source Modeling

Composite Current Source Driver and Receiver Model Example

index_1(0.1);

index_2(2.0);

index_3("1.2, 2.2, 3.2, 4.2, 5.2");

values("1.11, 1.31, 1.51, 1.41, 0.51");

}

vector(CCT) {

reference_time : 0.06;

index_1(0.2);

index_2(1.0);

index_3("1.2, 2.1, 3.2, 4.2, 5.2");

values("1.0, 1.5, 2.0, 1.2, 0.4");

}

vector(CCT) {

reference_time : 0.06;

index_1(0.2);

index_2(2.0);

index_3("1.2, 2.2, 3.2, 4.2, 5.2");

values("1.11, 1.21, 1.51, 1.41, 0.31");

}

output_current_fall() {

vector(CCT) {

reference_time : 0.05;

index_1(0.1);

index_2(1.0);

index_3("0.1, 2.3, 3.3, 4.4, 5.0");

values("-1.1, -1.3, -1.6, -1.4, -0.5");

}

vector(CCT) {

reference_time : 0.05;

index_1(0.1);

index_2(2.0);

index_3("1.2, 2.2, 3.2, 4.2, 5.2");

values("1.11, -1.21, -1.41, -1.31, -0.51");

}

vector(CCT) {

reference_time : 0.13;

index_1(0.2);

index_2(1.0);

index_3("0.1, 1.3, 2.3, 3.4, 5.0");

values("-1.1, -1.3, -1.8, -1.4, -0.5");

}

vector(CCT) {

reference_time : 0.13;

index_1(0.2);

index_2(2.0);

index_3("1.2, 2.2, 3.2, 4.2, 5.2");

values("-1.11, -1.31, -1.81, -1.51, -0.41");

}

}/*end of timing*/

. . .

} /* end of pin (Y) */

. . .

Liberty User Guide Volume 1

R-2020.09

558

Chapter 10: Composite Current Source Modeling

Composite Current Source Driver and Receiver Model Example

} /* end of cell */

. . .

} /* end of library */

Liberty User Guide Volume 1

R-2020.09

559

Advanced Composite Current Source Modeling

This chapter provides an overview of advanced composite current source (CCS) modeling

to support nanometer and very deep submicron IC development.

The following composite current source modeling topics are covered:

• Modeling Cells With Advanced Composite Current Source Information

• Compact CCS Timing Model

• Variation-Aware Timing Modeling Support

Modeling Cells With Advanced Composite Current Source

Information

Composite current source modeling supports additional driver model complexity by using

a time- and voltage- dependent current source with essentially an infinite drive resistance.

To achieve high accuracy, this driver model maps the transistor behavior for lumped loads

to that for parasitic network instead of modeling the transistor behavior.

The composite current source model has better receiver model accuracy because the

input capacitance of a receiver is dynamically adjusted during the transition by using two

capacitance values. You can use the driver model with or without the receiver model.

Compact CCS Timing Model

Conventional CCS timing driver models require you to describe each CCS driver switching

current waveform by sampling data points. As the number of timing arcs increase in a

standard cell library, the CCS timing library size can become very large.

This section describes the syntax of a compact model that uses indirectly shared base

curves to model the shape of switching curves. By allowing each base curve to model

multiple switching curves with similar shapes, the modeling efficiency is improved and the

library size is compressed.

The topics in the following sections include:

•

Describing CCS timing base curves.

Liberty User Guide Volume 1

R-2020.09

560

Chapter 11: Advanced Composite Current Source Modeling

Compact CCS Timing Model

• Describing the syntax of base curves and the compact CCS driver modeling format.

Modeling With CCS Timing Base Curves

CCS driver switching curves in the I-V domain are smoother than those in the I(t) and V(t)

domains. The I-V switching curves are usually convex, and they have no inflection point in

the middle, a feature that facilitates compact modeling.

In Figure 103, the CCS segmentation process samples nine data points from the I(t)

curve based on the tolerance. 18 floating-point numbers, that is, nine time points and nine

current points are stored in the CCS library.

Figure 103 I(t), V(t), and I-V Curves for Inverter Cell Rise Transition With Existing CCS

Format

In Figure 104, the I-V curve is split into two halves at the peak, and an eleven point

normalized base curve in the base curve database is selected to exactly match each half

curve.

Liberty User Guide Volume 1

R-2020.09

561

Chapter 11: Advanced Composite Current Source Modeling

Compact CCS Timing Model

Only six parameters are required to model this inverter switching curve, reducing the

storage cost. The six parameters are as follows:

Iinit

Switching current value at the starting point.

Ipeak

Peak switching current value.

Vpeak

Voltage value when current reaches peak value.

Tpeak

Time when current reaches peak value.

Left id

Reference id of the base curve that matches the left half.

Right id

Reference id of the base curve that matches the right half.

Liberty User Guide Volume 1

R-2020.09

562

Chapter 11: Advanced Composite Current Source Modeling

Compact CCS Timing Model

Figure 104 Using Base Curves to Simplify I-V Curve Modeling

Compact CCS Timing Model Syntax

In the figure (in Modeling With CCS Timing Base Curves), each switching I-V curve can

be modeled by normalized base curves using the following parameters: init_current,

peak_current, peak_voltage, peak_time, left_id, and right_id.

The init_current, peak_current, peak_voltage, and peak_time parameters are the

critical characteristics of the curve. The left_id and right_id describe the two base

curves that represent the two halves of the I-V curve.

The syntax for compact CCS timing model is as follows:

library(my_compact_ccs_lib) {

…

base_curves (base_curves_name) {

base_curve_type: enum (ccs_timing_half_curve);

curve_x ("float…, float");

curve_y (curve_id, "float..., float");

...

curve_y (curve_id, "float..., float");

Liberty User Guide Volume 1

R-2020.09

563

Chapter 11: Advanced Composite Current Source Modeling

Compact CCS Timing Model

}

compact_lut_template(template_name) {

base_curves_group: base_curves_name;

variable_1 : input_net_transition |

total_output_net_capacitance;

variable_2 : input_net_transition |

total_output_net_capacitance;

variable_3 : curve_parameters;

index_1 ("float..., float");

index_2 ("float..., float");

index_3 ("string..., string");

}

…

cell(cell_name) {

…

pin(pin_name) {

direction : string;

capacitance : float;

timing() {

/*Compact CCS arc-based driver model*/

compact_ccs_rise (template_name) {

base_curves_group : "base_curves_name";

values ("..."..., "..." \

"..."..., "..." \

"..."..., "...")

}/*end of compact_ccs_rise() */

compact_ccs_fall(template_name) {

...

}/*end of compact_ccs_fall() */

...

} /*end of timing */

} /*end of pin */

} /*end of cell */

...

} /* end of library*/

The groups described in the following sections support compact CCS timing models.

base_curves Group

The base_curves library-level group contains the detailed description of normalized base

curves. The base_curves group has the following attributes:

base_curve_type Complex Attribute

The base_curve_type attribute specifies the type of base curve. The only valid value for

this attribute is ccs_timing_half_curve.

Liberty User Guide Volume 1

R-2020.09

564

Chapter 11: Advanced Composite Current Source Modeling

Compact CCS Timing Model

curve_x complex Attribute

The data array contains the x-axis values of the normalized base curve. Only one curve_x

value is allowed for each base_curves group. See the figure (in Modeling With CCS

Timing Base Curves), for more details.

For a ccs_timing_half_curve type base curve, the curve_x value must be between 0

and 1 and increase monotonically.

curve_y complex Attribute

Each base curve (as illustrated in the figure in Modeling With CCS Timing Base Curves) is

composed of one curve_x and one curve_y. You should define the curve_x base curve

before curve_y for better clarity and easier implementation.

There are two data sections in the curve_y complex attribute:

•

curve_id is the identifier of the base curve.

•

Data array is the y-axis values of the normalized base curve.

compact_lut_template Group

The compact_lut_template group is used for compact CCS timing modeling. (The

lu_table_template group is used for other timing models.) The compact_lut_template

group has the following attributes:

base_curves_group Attribute

This is a required attribute in the compact_lut_template group. Its value should be a

predefined base_curves group name. The base_curve_type of base_curves group

determines the values in index_3. It also determines where you can use this template.

variable_1 and variable_2 Attributes

Only input_net_transition and total_output_net_capacitance are valid values for

variable_1 and variable_2.

variable_3 Attribute

Only curve_parameters is a string value for this variable.

index_1 and index_2 Attributes

These are required attributes. They define the input_net_transition or

total_output_net_capacitance values using the float notation.

index_3 Attribute

String values in index_3 are determined by the base_curve_type in base_curves group.

When the base_curve_type is a ccs_timing_half_curve, at least six string parameters

Liberty User Guide Volume 1

R-2020.09

565

Chapter 11: Advanced Composite Current Source Modeling

Compact CCS Timing Model

should be defined. They are init_current, peak_current, peak_voltage, peak_time,

left_id, and right_id. If any of these six parameters are missing, a compilation error is

issued.

compact_ccs_{rise|fall} Group

This is the compact CCS timing data in timing arc group, which has the following

attributes:

base_curves_group Attribute

Defining this attribute is optional when the base_curves_name is same as that defined in

the compact_lut_template group. This group is referenced by the compact_ccs_{rise|

fall} group.

values Attribute

Values of compact CCS timing data depend on how you define index_3 values.

For compact CCS timing, base curves data left_id and right_id values can only be

integers.

Compact CCS Timing Library Example

library(my_lib) {

...

/* normal lu table template for timing arcs */

lu_table_template (LTT2) {

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

index_1 ("0.1, 0.2");

index_2 ("1.0, 2.0");

}

base_curves (ctbct1){

base_curve_type : ccs_timing_half_curve;

curve_x("0.2, 0.5, 0.8");

curve_y(1, "0.8, 0.5, 0.2");

curve_y(2, "0.75, 0.5, 0.35");

...

curve_y(100, "0.85, 0.5, 0.15");

}

...

/* New lu table template for compact CCS timing model*/

compact_lut_template(LTT3) {

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

variable_3 : curve_parameters;

index_1 ("0.1, 0.2");

index_2 ("1.0, 2.0");

Liberty User Guide Volume 1

R-2020.09

566

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

index_3 ("init_current, peak_current, peak_voltage, peak_time,

left_id,

right_id");

base_curves_group: "ctbct1";

}

…

cell(cell_name) {

...

pin(Y) {

direction : output;

capacitance : 1.2;

timing() {

/*compact CCS and arc-based receiver model*/

compact_ccs_rise(LTT3) {

base_curves_group : "ctbct1"; /* optional*/

values("0.1, 0.5, 0.6, 0.8, 1, 3", \

"0.15, 0.55, 0.65, 0.85, 2, 4", \

"0.2, 0.6, 0.7, 0.9, 3, 2", \

"0.25, 0.65, 0.75, 0.95, 4, 1")

}/*end of compact_ccs_rise() */

compact_ccs_fall(LTT3) {

. . .

}/*end of compact_ccs_fall() */

. . .

}/*end of timing */

}/*end of pin(Y) */

}/*end of cell */

...

}/* end of library*/

Variation-Aware Timing Modeling Support

As process technologies scale to nanometer geometries, it is crucial to build variation-

based cell models to solve uncertainties attributed to the variability in the device and

interconnect. The CCS timing approach addresses the effects of nanometer processes by

enabling advanced driver and receiver modeling.

This modeling capability supports variation parameters and is an extension of compact

CCS timing driver modeling. You can even apply variation parameter models to CCS

timing models.

These timing models employ a single current-based behavior that enables the concurrent

analysis and optimization of timing issues. The result is a complete open-source current

based modeling solution that reduces design margins and speeds design closure.

Process variation is modeled in static timing analysis tools to improve parametric yield and

to control the design for corner-based analysis. This section describes the extension for

variation-aware timing modeling using the existing CCS syntax.

Liberty User Guide Volume 1

R-2020.09

567

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

The following sections include information about

• Variation-aware modeling for compact CCS timing driver models

•

Variation-aware modeling for CCS timing receivers

• Variation-aware modeling for regular or interdependent timing constraints

•

Conditional data modeling for variation-aware timing receiver models

The amount of data can be reduced by using the compact CCS timing syntax. Without

compacting, variation parameter models require more library data storage. You should be

familiar with the compact CCS syntax before reading this section.

Variation-Aware Compact CCS Timing Driver Model

This format supports variation parameters. It is an extension of a compact CCS timing

driver modeling. The timing_based_variation groups specified in the timing group can

represent variation-aware CCS driver information in a compact format. The syntax is as

follows:

library (library_name) {

...

base_curves (base_curves_name) {

base_curve_type: enum (ccs_timing_half_curve);

curve_x ("float,...");

curve_y (integer, "float, ...");

...

}

compact_lut_template(template_name) {

base_curves_group : base_curves_name;

variable_1 : input_net_transition |

total_output_net_capacitance;

variable_2 : input_net_transition |

total_output_net_capacitance;

variable_3 : curve_parameters;

...

}

va_parameters(string, ...);

...

timing() {

compact_ccs_rise(template_name) {...}

compact_ccs_fall(template_name) {...}

timing_based_variation() {

va_parameters(string, ...);

nominal_va_values(float, ...);

va_compact_ccs_rise(template_name) {

va_values(float, ...);

values("..., float, ..., integer, ...", ...);

...}

...

Liberty User Guide Volume 1

R-2020.09

568

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

va_compact_ccs_fall(template_name) { ... }

...} /* end of timing based variation */

...} /* end of timing group */

...

} /* end of library group */

timing_based_variation Group

This group specifies rising and falling output transitions for variation parameters.

The rising and falling output transitions are specified in va_compact_ccs_rise and

va_compact_ccs_fall respectively.

•

The va_compact_ccs_rise group is required only if a compact_ccs_rise group exists

within a timing group.

•

The va_compact_ccs_fall group is required only if a compact_ccs_fall group exists

within a timing group.

va_parameters Attribute

The va_parameters attribute specifies a list of variation parameters with the following

rules:

•

One or more variation parameters are allowed.

•

Variation parameters are represented by a string.

• Values in va_parameters must be unique.

•

The va_parameters must be defined before being referenced by nominal_va_values

and va_values.

The va_parameters attribute can be specified within a variation group or within a

library level. timing_based_variation can be specified within a timing group only, and

pin_based_variation can be specified within a pin group only. None of these can be

specified within a library group.

•

If the va_parameters attribute is specified at the library level, all cells under the library

default to the same variation parameters.

•

If the va_parameters attribute is defined in the variation group, all va_values and

nominal_va_values under the same variation group refers to this va_parameters.

The attribute values can be user-defined or predefined parameters. For more information,

see the examples in Variation-Aware Syntax Examples.

The parameters defined in default_operating_conditions are process, temperature,

and voltage. The voltage names are defined by using the voltage_map complex attribute.

For more information see “voltage_map Complex Attribute.

Liberty User Guide Volume 1

R-2020.09

569

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

You can use the following predefined parameters:

• For the parameters defined in operating_conditions, if voltage_map is defined,

and you specify these attributes as values of va_parameters, these attributes are

considered as user-defined variables.

•

For the parameters defined in operating_conditions, if there is no voltage_map

attribute at library level, and you specify these attributes as values of va_parameters,

these attributes are taken as predefined parameters.

nominal_va_values Attribute

This attribute characterizes nominal values of all variation parameters.

•

It is required for every timing_based_variation group.

•

The value of this attribute has a one-to-one mapping to the corresponding

va_parameters.

• If a nominal compact CCS driver model group and a variation-aware compact CCS

driver model group are defined under the same timing group, the nominal values are

applied to the nominal compact CCS driver model group.

va_compact_ccs_rise and va_compact_ccs_fall Groups

The va_compact_ccs_rise and va_compact_ccs_fall groups specify characterization

corners with variation value parameters.

•

These groups can be specified under different timing_based_variation groups if

they cannot share the same va_parameters.

•

You should characterize two corners at each side of the nominal value of all variation

parameters as specified in va_parameters. When corners are characterized for one

of the parameters, all other variations are assumed to be nominal values. Therefore,

a timing_based_variation group with N variation parameters requires exactly 2N

characterization corners. For an example, see examples in Variation-Aware Syntax

Examples.

•

All variation-aware compact CCS driver model groups inside the

timing_based_variation share the same va_parameters.

va_values Attribute

The va_values attribute specifies values of each variation parameter for all corners

characterized in the variation-aware compact CCS driver model groups.

•

Required for the variation-aware compact CCS driver model groups.

•

The value of this attribute has a one-to-one mapping to the corresponding

va_parameters.

Liberty User Guide Volume 1

R-2020.09

570

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

For an example that shows how to specify va_values with three variation parameters,

see examples in Variation-Aware Syntax Examples. In the example, the first variation

parameter has a nominal value of 0.50, the second parameter has a nominal value of 1.0,

and the third parameter has a nominal value of 2.0. All parameters have a variation range

of -10% to +10%.

values Attribute

The values attribute follows the same rules as the nominal compact CCS driver model

groups with the following exceptions:

•

The left_id and right_id are optional.

•

The left_id and right_id values must be used together. They can either be omitted

or defined together in the compact_lut_template.

• If left_id and right_id are not defined in the variation-aware compact CCS driver

model group, they default to the values defined in the nominal compact CCS driver

model group.

timing_based_variation and pin_based_variation Groups

These groups represent variation-aware receiver capacitance information under the timing

and pin groups.

•

If receiver_capacitance group exists in pin group, variation-aware CCS receiver

model groups are required in pin_based_variation.

•

If nominal CCS receiver model groups exist in the timing group, variation-aware CCS

receiver model groups are required in timing_based_variation.

va_parameters Attribute

The va_parameters attribute specifies a list of variation parameters within a

timing_based_variation or pin_based_variation group. See va_parameters Attribute

on page 569 for details.

nominal_va_values Attribute

The nominal_va_values attribute characterizes nominal values for all variation

parameters. The following list describes the nominal_va_values attribute.

•

The attribute is required in the timing_based_variation and pin_based_variation

groups.

•

The value of this attribute has one-to-one mapping to the corresponding

va_parameters attribute.

•

In pin-based models, if nominal CCS receiver model and variation-aware CCS receiver

model groups are defined under the same pin, the nominal values are applied to the

Liberty User Guide Volume 1

R-2020.09

571

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

nominal CCS receiver model groups. For an example, see examples in Variation-

Aware Syntax Examples.

•

In timing-based models, if the nominal compact CCS driver model group and variation-

aware CCS receiver model groups are defined under the same timing group, the

nominal values are applied to the nominal compact CCS driver model groups.

va_receiver_capacitance1_rise, va_receiver_capacitance1_fall,

va_receiver_capacitance2_rise, va_receiver_capacitance2_fall Groups

These groups specify characterization corners with variation values in

timing_based_variation and pin_based_variation groups.

•

You should characterize two corners at each side of the nominal value of all variation

parameters specified in va_parameters.

When corners are characterized for one of parameters, all other variations are

assumed to be nominal value. Therefore, for a timing_based_variation group with

N variation parameters, exactly 2N characterization corner groups are required. This

same rule applies to pin_based_variation.

•

All variation-aware CCS receiver model groups in timing_based_variation or

pin_based_variation group share the same va_parameters.

va_values Attribute

Specifies values of each variation parameter for all corners characterized in variation-

aware CCS receiver model groups.

•

The attribute is required for variation-aware CCS receiver model groups.

•

The value of this attribute has one-to-one mapping to the corresponding

va_parameters attribute.

Variation-Aware CCS Timing Receiver Model

The variation-aware CCS receiver model is expected to be used together with

variation-aware compact CCS driver model. The timing_based_variation and

pin_based_variation groups specify timing and pin groups respectively. In both groups,

the variation-aware CCS receiver model groups are used to represent variation-aware

CCS receiver information. They are defined in the following syntax and sections.

library() {

...

lu_table_template(timing_based_template_name) {

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

...

}

lu_table_template(pin_based_template_name) {

Liberty User Guide Volume 1

R-2020.09

572

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

variable_1 : input_net_transition;

...

}

va_parameters(string , ...);

...

pin(pin_name) {

receiver_capacitance() {

receiver_capacitance1_rise(template_name) {...}

receiver_capacitance2_rise(template_name) {...}

receiver_capacitance1_fall(template_name) {...}

receiver_capacitance2_fall(template_name) {...}

}

pin_based_variation() {

va_parameters(string, ... );

nominal_va_values(float,...);

va_receiver_capacitance1_rise(pin_based_template_name) {

va_values(float, ...);

values("float, ...", ...);

...

}

va_receiver_capacitance2_rise(pin_based_template_name) {...}

va_receiver_capacitance1_fall(pin_based_template_name) {...}

va_receiver_capacitance2_fall(pin_based_template_name) {...}

...

} /* end of pin_based_variation */

...} /* end of pin */

...

pin(pin_name) {

...

timing() {

receiver_capacitance1_rise(template_name) {...}

receiver_capacitance2_rise(template_name) {...}

receiver_capacitance1_fall(template_name) {...}

receiver_capacitance2_fall(template_name) {...}

timing_based_variation() {

va_parameters(string, ... );

nominal_va_values(float, ...);

va_receiver_capacitance1_rise(timing_based_template_name) {

va_values(float, ...);

values("float, ...", ...);

...

}

va_receiver_capacitance2_rise(timing_based_template_name) {

va_receiver_capacitance1_fall(timing_based_template_name) {

va_receiver_capacitance2_fall(timing_based_template_name) {

...

} /* end of timing_based_variation */

...

} /* end of timing */

...

} /* end of pin */

...

Liberty User Guide Volume 1

R-2020.09

573

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

timing_based_variation and pin_based_variation Groups

These groups represent variation-aware receiver capacitance information under the pin or

timing group level.

•

If the receiver_capacitance group exists in the pin group, variation-aware CCS

receiver model groups are required in the pin_based_variation group.

•

If nominal CCS receiver model groups exist in the timing group, variation-aware CCS

receiver model groups are required in the timing_based_variation group.

va_parameters Complex Attribute

This attribute specifies a list of variation parameters within the timing_based_variation

or pin_based_variation groups. See va_parameters Attribute on page 569 for more

details.

nominal_va_values Complex Attribute

This complex attribute specifies the nominal values of all variation parameters.

•

The attribute is required for the timing_based_variation and pin_based_variation

groups.

•

The value of this attribute has one-to-one mapping to the corresponding

va_parameters attribute.

•

In a pin-based model, if nominal CCS receiver model and variation-aware CCS

receiver model groups are defined under the same pin, the nominal values are applied

to nominal CCS receiver model groups. For an example, see the examples in Variation-

Aware Syntax Examples.

•

In a timing-based model, if nominal CCS receiver model and variation-aware CCS

receiver model groups are defined under the same timing group, the nominal values

are applied to nominal CCS receiver model groups.

va_receiver_capacitance1_rise, va_receiver_capacitance1_fall,

va_receiver_capacitance2_rise, and

va_receiver_capacitance2_fall Groups

These groups specify characterization corners with variation values in the

timing_based_variation and pin_based_variation groups.

•

You should characterize two corners at each side of the nominal value of all variation

parameters specified in va_parameters attribute.

When corners are characterized for one of the parameters, all other variations are

assuming to be nominal value. Therefore, for a timing_based_variation group with

Liberty User Guide Volume 1

R-2020.09

574

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

N variation parameters, exactly 2N characterization corner groups are required. This

rule also applies to pin_based_variation.

•

All variation-aware CCS receiver model groups in timing_based_variation or

pin_based_variation group share the same va_parameters.

va_values Attribute

Specifies values of each variation parameter for all corners characterized in variation-

aware CCS receiver model groups.

•

Required for variation-aware CCS receiver model groups.

•

The value of this attribute has one-to-one mapping to the corresponding

va_parameters attribute.

Variation-Aware Timing Constraint Modeling

This syntax supports variation parameters. It is an extension of the timing

constraint modeling. It also applies to interdependent setup and hold. The

timing_based_variation groups specified in the timing group represent variation-aware

timing constraint sensitive information, which is defined in the following syntax:

library() {

...

lu_table_template(template_name) {

variable_1 : variables;

variable_2 : variables;

variable_3 : variables;

...

}

va_parameters(string, ...);

...

timing () {

...

interdependence_id : integer;

rise_constraint(template_name) { ... }

fall_constraint(template_name) { ... }

timing_based_variation() {

va_parameters(string, ...);

nominal_va_values(float, ...);

va_rise_constraint(template_name) {

va_values(float, ...);

values("float, ...");

...

}

va_fall_constraint(template_name) { ... }

...

} /* end of timing_based_variation */

...

Liberty User Guide Volume 1

R-2020.09

575

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

} /* end of timing */

...

} /* end of pin */

...

} /* end of library */

timing_based_variation Group

The timing_based_variation group specifies the rise and fall timing constraints

for variation parameters within a timing group. The rise and fall timing constraints are

specified in the va_rise_constraint and va_fall_constraint groups respectively.

•

The va_rise_constraint group is required only if rise_constraint group exists

within a timing group.

•

The va_fall_constraint group is required only if fall_constraint group exists

within a timing group.

va_parameters Complex Attribute

This complex attribute specifies a list of variation parameters within

timing_based_variation or pin_based_variation. See va_parameters Attribute on

page 569 for details.

nominal_va_values Complex Attribute

This complex attribute is used to specify nominal values of all variation parameters. See

nominal_va_values Attribute on page 570 for more information.

va_rise_constraint and va_fall_constraint Groups

The va_rise_constraint and va_fall_constraint groups specify characterization

corners with variation values in timing_based_variation.

•

The template name refers to the lu_table_template group.

•

Both groups can be specified under different timing_based_variation groups if they

cannot share the same va_parameters attribute.

• You are expected to characterize two corners at each side of the nominal value of all

variation parameters as specified in va_parameters attribute.

When corners are characterized for one parameter, all other variations are assumed to

be of nominal value. Therefore, for a timing_based_variation group with N variation

parameters, exactly 2N characterization corners are required.

•

All the va_rise_constraint and va_fall_constraint groups in the

timing_based_variation group share the same va_parameters attribute.

Liberty User Guide Volume 1

R-2020.09

576

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

va_values Attribute

Specifies values of each variation parameter for all corners characterized in the

va_rise_constraint and va_fall_constraint groups.

•

Required for the va_rise_constraint and va_fall_constraint groups.

•

The value of this attribute has a one-to-one mapping to the corresponding

va_parameters attribute.

Conditional Data Modeling for Variation-Aware Timing Receiver

Models

Liberty provides the following syntax to support conditional data modeling for pin-based

variation-aware timing receiver models:

library(library_name) {

...

lu_table_template(timing_based_template_name) {

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

...

}

lu_table_template(pin_based_template_name) {

variable_1 : input_net_transition;

...

}

va_parameters(string, ...);

…

cell(cell_name) {

mode_definition (mode_name) {

mode_value(namestring) {

when : "boolean expression";

sdf_cond : "boolean expression";

} …

pin(pin_name) {

direction : input; /* or "inout" */

receiver_capacitance() {

when : "boolean expression";

mode (mode_name, mode_value);

receiver_capacitance1_rise (template_name) { ... }

receiver_capacitance1_fall (template_name) { ... }

receiver_capacitance2_rise (template_name) { ... }

receiver_capacitance2_fall (template_name) { ... }

}

pin_based_variation() {

/* The "when" and "mode" attributes should be exactly the same as

defined in the

receiver_capacitance group above */

Liberty User Guide Volume 1

R-2020.09

577

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

when : "boolean expression";

mode (mode_name, mode_value);

va_parameters(string, ...);

nominal_va_values(float, ...);

va_receiver_capacitance1_rise (pin_based_template_name) { ... }

va_receiver_capacitance1_fall (pin_based_template_name) { ... }

va_receiver_capacitance2_rise (pin_based_template_name) { ... }

va_receiver_capacitance2_fall (pin_based_template_name) { ... }

...

}/* end of pin_based_variation */

...

}/* end of pin group */

pin(pin_name) {

direction : output; /* or "inout" */

timing() {

when : "boolean expression";

mode (mode_name, mode_value);

...

receiver_capacitance() {

receiver_capacitance1_rise (template_name) { ... }

receiver_capacitance1_fall (template_name) { ... }

receiver_capacitance2_rise (template_name) { ... }

receiver_capacitance2_fall (template_name) { ... }

}

timing_based_variation() {

va_parameters(string, ...);

nominal_va_values(float, ...);

va_receiver_capacitance1_rise (timing_based_template_name) {...}

va_receiver_capacitance1_fall (timing_based_template_name) {...}

va_receiver_capacitance2_rise (timing_based_template_name) {...}

va_receiver_capacitance2_fall (timing_based_template_name) {...}

...

} /* end of timing_based_variation */

}

...

} /* end of pin group */

} /* end of cell group */

...

} /*end of library */

when Attribute

The when string attribute is provided in the pin_based_variation group to support

conditional data modeling.

mode Attribute

The mode complex attribute is provided in the pin_based_variation group to support

conditional data modeling. If the mode attribute is specified, mode_name and mode_value

must be predefined in the mode_definition group at the cell level.

Liberty User Guide Volume 1

R-2020.09

578

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

The following example shows conditional data modeling for pin-based variation-aware

timing receiver models:

library(new_lib) {

...

output_current_template(CCT) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

variable_3: time;

index_1("0.1, 0.2");

index_2("1, 2");

index_3("1, 2, 3, 4, 5");

}

lu_table_template(LTT1) {

variable_1: input_net_transition;

index_1("0.1, 0.2, 0.3, 0.4");

}

lu_table_template(LTT2) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

index_1("0.1, 0.2");

index_2("1, 2");

}

...

cell(my_cell) {

...

mode_definition(rw) {

mode_value(read) {

when : "I";

sdf_cond : "I == 1";

}

mode_value(write) {

when : "!I";

sdf_cond : "I == 0";

}

pin(I) { /* pin-based receiver model defined for pin 'A' */

direction : input;

/* receiver capacitance for condition 1 */

receiver_capacitance() {

when : "I"; /* or using mode as next commented line */

/* mode (rw, read); */

receiver_capacitance1_rise(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance1_fall(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance2_rise(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance2_fall(LTT1) {

values("1, 2, 3, 4");

Liberty User Guide Volume 1

R-2020.09

579

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

}

pin_based_variation ( ) {

when : "I"; /* or using mode as next commented line */

/* mode (rw, read); */

va_parameters(channel_length, threshold_voltage);

nominal_va_values(0.5, 0.5) ;

va_receiver_capacitance1_rise (LTT1) {

va_values(0.50, 0.45);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_rise (LTT1) {

va_values(0.50, 0.55);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_rise (LTT1) {

va_values(0.45, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_rise (LTT1) {

va_values(0.55, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_rise (LTT1) {

va_values(0.50, 0.45);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_rise (LTT1) {

va_values(0.50, 0.55);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_rise (LTT1) {

va_values(0.45, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_rise (LTT1) {

va_values(0.55, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_fall (LTT1) {

va_values(0.50, 0.45);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_fall (LTT1) {

va_values(0.50, 0.55);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_fall (LTT1) {

va_values(0.45, 0.5);

Liberty User Guide Volume 1

R-2020.09

580

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

values("1, 2, 3, 4");

}

va_receiver_capacitance1_fall (LTT1) {

va_values(0.55, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_fall (LTT1) {

va_values(0.50, 0.45);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_fall (LTT1) {

va_values(0.50, 0.55);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_fall (LTT1) {

va_values(0.45, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_fall (LTT1) {

va_values(0.55, 0.5);

values("1, 2, 3, 4");

}

/* receiver capacitance for condition 2 */

receiver_capacitance() {

when : "!I"; /* or using mode as next commented line */

/* mode (rw, write); */

receiver_capacitance1_rise(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance1_fall(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance2_rise(LTT1) {

values("1, 2, 3, 4");

}

receiver_capacitance2_fall(LTT1) {

values("1, 2, 3, 4");

}

pin_based_variation ( ) {

when : "!I"; /* or using mode as next commented line */

/* mode (rw, write); */

va_parameters(channel_length, threshold_voltage);

nominal_va_values(0.5, 0.5) ;

va_receiver_capacitance1_rise (LTT1) {

va_values(0.50, 0.45);

values("1, 2, 3, 4");

Liberty User Guide Volume 1

R-2020.09

581

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

}

va_receiver_capacitance1_rise (LTT1) {

va_values(0.50, 0.55);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_rise (LTT1) {

va_values(0.45, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_rise (LTT1) {

va_values(0.55, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_rise (LTT1) {

va_values(0.50, 0.45);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_rise (LTT1) {

va_values(0.50, 0.55);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_rise (LTT1) {

va_values(0.45, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_rise (LTT1) {

va_values(0.55, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_fall (LTT1) {

va_values(0.50, 0.45);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_fall (LTT1) {

va_values(0.50, 0.55);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_fall (LTT1) {

va_values(0.45, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance1_fall (LTT1) {

va_values(0.55, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_fall (LTT1) {

va_values(0.50, 0.45);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_fall (LTT1) {

Liberty User Guide Volume 1

R-2020.09

582

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

va_values(0.50, 0.55);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_fall (LTT1) {

va_values(0.45, 0.5);

values("1, 2, 3, 4");

}

va_receiver_capacitance2_fall (LTT1) {

va_values(0.55, 0.5);

values("1, 2, 3, 4");

}

pin (ZN) {

direction : input;

capacitance : 1.2;

...

timing() {

...

}

...

} /* end cell */

...

} /* end library */

Variation-Aware Compact CCS Retain Arcs

Variation-aware timing models include:

•

Timing-based modeling for compact CCS timing drivers.

•

Timing-based and pin-based modeling for CCS timing receivers.

• Timing-based modeling for regular or interdependent timing constraints.

Liberty provides the following syntax in the timing_based_variation group to support

retain arcs for compact CCS driver models:

library (library_name) {

...

base_curves (base_curves_name) {

base_curve_type: enum (ccs_timing_half_curve);

curve_x ("float, ...");

curve_y (integer, "float...");

...

}

compact_lut_template(template_name) {

base_curves_group : base_curves_name;

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

variable_3 : curve_parameters;

Liberty User Guide Volume 1

R-2020.09

583

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

...

}

va_parameters(string , ...);

...

cell(cell_name) {

...

pin(pin_name) {

direction : string;

capacitance : float;

timing() {

compact_ccs_rise(template_name) { ... }

compact_ccs_fall(template_name) { ... }

timing_based_variation() {

va_parameters(string , ... );

nominal_va_values(float, ...);

va_compact_ccs_retain_rise(template_name) {

va_values(float, ...);

values ("..., float, ..., integer, ...", ...);

}

...

va_compact_ccs_retain_fall(template_name) {

va_values(float, ...);

values ("..., float, ..., integer, ...", ...);

}

...

va_compact_ccs_rise(template_name) { ... } ...

va_compact_ccs_fall(template_name) { ... } ...

} /* end of timing_based_variation group */

...

} /* end of pin group */

...

} /* end of cell group */

...

} /* end of library group*/

The format of variation-aware compact CCS retain arcs is the same as general variation-

aware compact CCS timing arcs.

va_compact_ccs_retain_rise and va_compact_ccs_retain_fall

Groups

The va_compact_ccs_retain_rise and va_compact_ccs_retain_fall groups in the

timing_based_variation group specify characterization corners with variation value

parameters for retain arcs.

va_values Attribute

The va_values attribute defines the values of each variation parameter for all corners

characterized in variation-aware compact CCS retain arcs. The value of this attribute is

mapped one-to-one to the corresponding va_parameters.

Liberty User Guide Volume 1

R-2020.09

584

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

values Attribute

The values attribute follows the same rules as general variation-aware compact CCS

timing models.

Variation-Aware Syntax Examples

va_parameters in Advanced CCS Modeling Usage

Example 118 va_parameters in Advanced CCS Modeling Usage

library (example) {

...

operating_conditions (typical) {

process : 1.5 ;

temperature : 70 ;

voltage : 2.75 ;

...

}

default_operating_conditions: typical;

…

/* " temperature", "voltage" and "process" are predefined

parameters, and "Vthr" is an user-defined parameter. */

va_parameters(temperature, voltage, process, Vthr, …);

...

}

library (example) {

...

operating_conditions (typical) {

process : 1.5 ;

temperature : 70 ;

voltage : 2.75 ;

...

}

voltage_map(VDD1, 2.75);

voltage_map(GND2, 0.2);

default_operating_conditions: typical;

...

/* "VDD1" and "GND2" are predefined parameters, and

"voltage" is taken as an user-defined parameter. */

va_parameters(VDD1, GND2, voltage,...);

For information about va_parameters, see va_parameters Attribute on page 569.

Example 119 va_parameters in Advanced CCS Modeling Usage

library (example) {

...

Liberty User Guide Volume 1

R-2020.09

585

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

operating_conditions (typical) {

process : 1.5 ;

temperature : 70 ;

voltage : 2.75 ;

...

}

default_operating_conditions: typical;

…

/* " temperature", "voltage" and "process" are predefined

parameters, and "Vthr" is an user-defined parameter. */

va_parameters(temperature, voltage, process, Vthr, …);

...

}

library (example) {

...

operating_conditions (typical) {

process : 1.5 ;

temperature : 70 ;

voltage : 2.75 ;

...

}

voltage_map(VDD1, 2.75);

voltage_map(GND2, 0.2);

default_operating_conditions: typical;

...

/* "VDD1" and "GND2" are predefined parameters, and

"voltage" is taken as an user-defined parameter. */

va_parameters(VDD1, GND2, voltage,...);

For information about va_parameters, see va_parameters Complex Attribute.

va_compact_ccs_rise and va_compact_ccs_fall Groups

Example 120 va_compact_ccs_rise and va_compact_ccs_fall Groups

...

timing() {

...

compact_ccs_rise(temp) { /* nominal I-V waveform */

...

}

timing_based_variation() {

va_parameters(string, ... ); /* N variation parameters */

...

va_compact_ccs_rise(temp) { /* 1st corner */

...

}

...

va_compact_ccs_rise(temp) { /* last corner : total (2 * N) corners

*/ ...

}

} /* end of timing_based_variation */

Liberty User Guide Volume 1

R-2020.09

586

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

...

} /* end of timing */

...

For information about va_compact_ccs_rise and va_compact_ccs_fall, see

va_compact_ccs_rise and va_compact_ccs_fall Groups.

va_values With Three Variation Parameters

Example 121 va_values With Three Variation Parameters

...

timing_based_variation ( ) {

va_parameters(var1, var2, var3); /* assumed that three variation

parameters are var1, var2 and var3 */

nominal_va_values(0.5, 1.0, 2.0);

va_compact_ccs_rise ( ) {

va_values(0.50, 1.0, 1.8);

...

}

va_compact_ccs_rise ( ) {

va_values(0.50, 1.0, 2.2);

...

}

va_compact_ccs_rise ( ) {

va_values(0.50, 0.9, 2.0);

...

}

va_compact_ccs_rise ( ) {

va_values(0.50, 1.1, 2.0);

...

}

va_compact_ccs_rise ( ) {

va_values(0.45, 1.0, 2.0);

...

}

va_compact_ccs_rise ( ) {

va_values(0.55, 1.0, 2.0);

...

}

...

For information about using va_values with the va_compact_ccs_rise and

va_compact_ccs_fall groups, see va_compact_ccs_rise and va_compact_ccs_fall

Groups on page 570.

Liberty User Guide Volume 1

R-2020.09

587

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

peak_voltage in Values Attribute

Example 122 peak_voltage in Values Attribute

...

library(va_ccs) {

compact_lut_template(clt) {

index_3 ("init_current, peak_current, peak_voltage, peak_time,\

left_id, right_id");

...

}

voltage_map(VDD1, 3.0);

voltage_map(VDD2, 3.5);

voltage_map(GND1, 0.5);

voltage_map(GND2, 0.2);

...

cell(test) {

pg_pin(v1) {

voltage_name : VDD1;

...

}

pg_pin(v2) {

voltage_name : VDD2;

...

}

pg_pin(g1) {

voltage_name : GND1;

...

}

pg_pin(g2) {

voltage_name : GND2;

...

}

...

timing() {

timing_based_variation ( ) {

va_parameters(Vthr);

nominal_va_values(0.23);

va_compact_ccs_rise (clt ) {

/* error : There are two power pins (v1 and v2)

and two ground pins (g1 and g2) in the cell "test".

The peak_voltage cannot be greater than the largest power

voltage, which is 3.5, and less than the smallest ground

voltage,

which is 0.2. The value 4.0 is greater than 3.5 and 0.1

is less than 0.2. Both of them are wrong. */

va_values(0.25);

values("0.21, 0.54, 4.0, 0.36, 1, 2",\

"0.15, 0.55, 0.1, 0.85, 2, 4", ...);

...

Liberty User Guide Volume 1

R-2020.09

588

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

}

...

timing_based_variation ( ) {

va_parameters(Vthr, VDD2, GND2);

nominal_va_values(0.23, 3.5, 0.2);

va_compact_ccs_rise ( clt) {

/* In this group, the variation value of VDD2 is 4.1,

and GND2 is 0.0, so the largest power voltage is 4.1 and

the smallest ground voltage is 0.0. The peak_voltage 4.0. */

va_values(0.18, 4.1, 0.0);

values("0.21, 0.54, 4.0, 0.36, 1, 2",\

"0.15, 0.55, 0.1, 0.85, 2, 4", ...);

...

}

...

For information about peak_voltage in values attribute see va_compact_ccs_rise and

va_compact_ccs_fall Groups on page 570.

pin_based_variation Group

Example 123 pin_based_variation Group

...

pin(pin_name) {

receiver_capacitance() {

receiver_capacitance1_rise(template_name) {

/* nominal input capacitance table */

...

}

pin_based_variation() {

nominal_va_values(2.0, 4.54, 0.23);

/* These nominal values apply to nominal input capacitance tables.

va_receiver_capacitance1_rise(template_name) {

/* variational input capacitance table */

...

}

...

}

...

} /* end of pin */

...

For information about peak_voltage in values attribute see timing_based_variation and

pin_based_variation Groups on page 574.

Liberty User Guide Volume 1

R-2020.09

589

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

Pin-based Model With nominal CCS receiver model and Variation-

Aware CCS Receiver Model Groups

Example 124 pin-based Model With nominal CCS receiver model and Variation-aware CCS

Receiver Model Groups

/* Assume that there is no va_parameters defined */

library(lib_name) {

...

timing() {

timing_based_variation() {

va_compact_ccs_rise(cltdf) {

base_curves_group : base_name;

va_values(2.4)

/* error : can't find a corresponding va_parameters */ …}

...

} /* end of timing_based_variation */

...

} /* end of library */

/* Assume that va_parameters is defined at the end of

timing_based_variation

group and no default va_parameters is defined at library level */

...

timing_based_variation() {

nominal_va_values(2.0);

/* error : can't find a corresponding va_parameters */

...

va_parameters(Vthr);

/* within a timing_based_variation, this is defined before

all nominal_va_values and va_values attributes */

} /* end of timing_based_variation */

...

/* Assume that va_parameters is defined only at library level */

...

library(lib_name) {

...

timing_based_variation() {

nominal_va_values(2.0);

/* error : can't find a corresponding va_parameters */

...

}

...

va_parameters(Vthr);

/* within a library, this is defined before all

cell groups (or all nominal_va_values and va_values

attributes) */

} /* end of library */

Liberty User Guide Volume 1

R-2020.09

590

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

For information about peak_voltage in values attribute see timing_based_variation Group

on page 569.

nominal_va_values in Advanced CCS Modeling Usage

Example 125 nominal_va_values in Advanced CCS Modeling Usage

/* ASSUME that there is no voltage_map defined in library */

library (example) {

operating_conditions (typical) {

process : 1.5 ;

temperature : 70 ;

voltage : 2.75 ;

...

}

default_operating_conditions: typical;

...

timing_based_variation() {

va_parameters(voltage, temperature, process);

nominal_va_values(2.00, 70, 1.5);

/* error : The nominal voltage defined in

default_operating_conditions is 2.75. The value 2.00 is wrong. */

/* There is voltage_map defined at library level. */

library (example) {

operating_conditions (typical) {

process : 1.5 ;

temperature : 70 ;

voltage : 2.75 ;

...

}

voltage_map(VDD1, 2.75);

default_operating_conditions: typical;

...

timing_based_variation() {

va_parameters(voltage);

nominal_va_values(2.00);

/* Note: "voltage" is an user-defined parameter. */

...

Variational Values in Advanced CCS Modeling Usage

Example 126 Variational Values in Advanced CCS Modeling Usage

/* When var2 has a nominal value (1.0), var1 has three variational

values

(0.45, 0.55 and 0.50). However, only two values are allowed.

When var1 has a nominal value (0.50), var2 has two variational values

(0.8 and 1,0). The value 0.8 is less than the nominal value (1.0).

However, the value 1.0 is not greater than the nominal value,

Liberty User Guide Volume 1

R-2020.09

591

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

and this is incorrect. */

...

timing_based_variation ( ) {

va_parameters(var1, var2);

nominal_va_values(0.50, 1.0);

va_receiver_capacitance2_rise (temp_1) {

va_values(0.45, 1.0);

...

}

va_receiver_capacitance2_rise (temp_1) {

va_values(0.55, 1.0);

...

}

va_receiver_capacitance2_rise (temp_1) {

va_values(0.50, 0.8);

...

}

va_receiver_capacitance2_rise (temp_1) {

va_values(0.50, 1.0);

...

}

...

Variation-Aware CCS Driver or Receiver with Timing Constraints

Example 127 Variation-Aware CCS Driver or Receiver with Timing Constraints

library(my_lib) {

...

base_curves (ctbct1){

base_curve_type : ccs_timing_half_curve;

curve_x("0.2, 0.5, 0.8");

curve_y(1, "0.8, 0.5, 0.2");

curve_y(2, "0.75, 0.5, 0.35") ;

curve_y(3, "0.7, 0.5, 0.45") ;

...

curve_y(37, "0.23, 1.4, 6.23") ;

}

compact_lut_template(LUT4x4) {

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

variable_3 : curve_parameters;

index_1("0.1, 0.2, 0.3, 0.4");

index_2("1.0, 2.0, 3.0, 4.0");

index_3 ("init_current, peak_current, peak_voltage, peak_time,\

left_id, right_id");

base_curves_group: "ctbct1";

}

lu_table_template(LUT3) {

Liberty User Guide Volume 1

R-2020.09

592

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

variable_1: input_net_transition;

index_1("0.1, 0.3, 0.5");

}

lu_table_template(LUT3x3) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

index_1("0.1, 0.3, 0.5");

index_2("1.0, 3.0, 5.0");

}

lu_table_template(LUT5x5) {

variable_1: constrained_pin_transition;

variable_2: related_pin_transition;

index_1("0.01, 0.05, 0.1, 0.5, 1");

index_2("0.01, 0.05, 0.1, 0.5, 1");

}

...

cell(INV1) {

...

pin (A) {

direction: input;

capacitance: 0.3;

receiver_capacitance ( ) {

...

}

pin_based_variation ( ) {

va_parameters(channel_length, threshold_voltage);

nominal_va_values(0.5, 0.5) ;

va_receiver_capacitance1_rise (LUT3) {

va_values(0.50, 0.45);

values("0.29, 0.30, 0.31");

}

va_receiver_capacitance1_rise (LUT3) {

va_values(0.50, 0.55);

...

}

va_receiver_capacitance1_rise (LUT3) {

va_values(0.45, 0.50);

...

}

va_receiver_capacitance1_rise (LUT3) {

va_values(0.55, 0.50);

...

}

va_receiver_capacitance2_rise (LUT3) {

va_values(0.50, 0.45);

values("0.19, 8.60, 5.41");

}

va_receiver_capacitance2_rise (LUT3) {

va_values(0.50, 0.55);

...

}

va_receiver_capacitance2_rise (LUT3) {

va_values(0.45, 0.50);

Liberty User Guide Volume 1

R-2020.09

593

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

...

}

va_receiver_capacitance2_rise (LUT3) {

va_values(0.55, 0.50);

...

}

va_receiver_capacitance1_fall (LUT3) {

va_values(0.50, 0.45);

values("0.53, 2.16, 9.18");

}

va_receiver_capacitance1_fall (LUT3) {

va_values(0.50, 0.55);

...

}

va_receiver_capacitance1_fall (LUT3) {

va_values(0.45, 0.50);

...

}

va_receiver_capacitance1_fall (LUT3) {

va_values(0.55, 0.50);

...

}

va_receiver_capacitance2_fall (LUT3) {

va_values(0.50, 0.45);

values("0.39, 0.98, 5.15");

}

va_receiver_capacitance2_fall (LUT3) {

va_values(0.50, 0.55);

...

}

va_receiver_capacitance2_fall (LUT3) {

va_values(0.45, 0.50);

...

}

va_receiver_capacitance2_fall (LUT3) {

va_values(0.55, 0.50);

...

}

} /* end of pin */

pin (Y) {

direction: output;

timing ( ) {

related_pin: "A";

compact_ccs_rise(LUT4x4) {

...

}

compact_ccs_fall(LUT4x4) {

...

}

timing_based_variation() {

va_parameters(channel_length, threshold_voltage);

Liberty User Guide Volume 1

R-2020.09

594

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

nominal_va_values(0.50, 0.50);

va_compact_ccs_rise (LUT4x4 ) { /* without optional fields */

va_values(0.50, 0.45);

values("0.1, 0.5, 0.6, 0.8, 1, 3", \

"0.15, 0.55, 0.65, 0.85, 2, 4", \

"0.2, 0.6, 0.7, 0.9, 3, 2", \

"0.1, 0.2, 0.3, 0.4, 1,3", \

"0.2, 0.3, 0.4, 0.5, 4,5", \

"0.3, 0.4, 0.5, 0.6, 2,4", \

"0.4, 0.5, 0.6, 0.7, 7,8", \

"0.5, 0.6, 0.7, 0.8, 10,4", \

"0.5, 0.6, 0.8, 0.9, 11, 2", \

"0.25, 0.55, 1.65, 1.85, 3, 4", \

"1.2, 1.6, 1.7, 1.9, 5, 2", \

"1.1, 2.2, 2.3, 0.4, 1,30", \

"1.2, 2.3, 1.4, 0.5, 17,5", \

"1.3, 2.4, 1.5, 0.6, 22,24", \

"1.4, 2.5, 1.6, 1.7, 17,18", \

"1.5, 2.6, 0.7, 0.8, 10,33");

}

va_compact_ccs_rise (LUT4x4 ) {

va_values(0.50, 0.55);

...

}

va_compact_ccs_rise (LUT4x4 ) {

va_values(0.45, 0.50);

...

}

va_compact_ccs_rise (LUT4x4 ) {

va_values(0.55, 0.50);

...

}

va_compact_ccs_fall (LUT4x4 ) { /* without optional fields */

...

}

...

} /* end of timing_based_variation */

...

} /* end of timing */

...

} /* end of pin */

...

} /* end of cell */

...

cell(INV4) {

...

pin (Y) {

direction: output;

timing ( ) {

related_pin: "A";

receiver_capacitance1_rise (LUT3x3) {

...

Liberty User Guide Volume 1

R-2020.09

595

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

}

receiver_capacitance2_rise (LUT3x3) {

...

}

receiver_capacitance1_fall (LUT3x3) {

...

}

receiver_capacitance2_fall (LUT3x3) {

...

}

rise_constraint(LUT5x5) {

...

}

fall_constraint(LUT5x5) {

...

}

timing_based_variation ( ) {

va_parameters(channel_length,threshold_voltage);

nominal_va_values(0.50, 0.50) ;

va_receiver_capacitance1_rise (LUT3x3) {

va_values(0.50, 0.45);

values( "1.10, 1.20, 1.30", \

"1.11, 1.21, 1.31", \

"1.12, 1.22, 1.32");

}

va_receiver_capacitance2_rise (LUT3x3) {

va_values(0.50, 0.45);

values("1.20, 1.30, 1.40", \

"1.21, 1.31, 1.41", \

"1.22, 1.32, 1.42");

}

va_receiver_capacitance1_fall (LUT3x3) {

va_values(0.50, 0.45);

values("1.10, 1.20, 1.30", \

"1.11, 1.21, 1.31", \

"1.12, 1.22, 1.32");

}

va_receiver_capacitance2_fall (LUT3x3) {

va_values(0.50, 0.45);

values("1.20, 1.30, 1.40", \

"1.21, 1.31, 1.41", \

"1.22, 1.32, 1.42");

}

va_receiver_capacitance1_rise (LUT3x3) {

va_values(0.50, 0.55);

...

}

...

va_receiver_capacitance1_rise (LUT3x3) {

va_values(0.45, 0.50);

...

}

…

Liberty User Guide Volume 1

R-2020.09

596

Chapter 11: Advanced Composite Current Source Modeling

Variation-Aware Timing Modeling Support

va_receiver_capacitance1_rise (LUT3x3) {

va_values(0.55, 0.50);

...

}

...

va_rise_constraint(LUT5x5) {

va_values(0.50, 0.45);

values( "-0.1452, -0.1452, -0.1452, -0.1452, 0.3329", \

"-0.1452, -0.1452, -0.1452, -0.1452, 0.3952", \

"-0.1245, -0.1452, -0.1452, -0.1358, 0.5142", \

" 0.05829, 0.0216, 0.01068, 0.06927, 0.723", \

" 1.263, 1.227, 1.223, 1.283, 1.963");

}

va_rise_constraint(LUT5x5) {

va_values(0.50, 0.55);

...

}

va_rise_constraint(LUT5x5) {

va_values(0.55, 0.50);

...

}

va_rise_constraint(LUT5x5) {

va_values(0.45, 0.50);

...

}

va_fall_constraint(LUT5x5) {

va_values(0.50, 0.55);

...

}

va_fall_constraint(LUT5x5) {

va_values(0.55, 0.50);

...

}

va_fall_constraint(LUT5x5) {

va_values(0.45, 0.50);

...

}

va_fall_constraint(LUT5x5) {

va_values(0.50, 0.45);

...

}

} /* end of timing_based_variation */

...

} /* end of timing */

...

} /* end of pin */

...

} /* end of cell */

...

} /* end of library */

Liberty User Guide Volume 1

R-2020.09

597

Nonlinear Signal Integrity Modeling

This chapter provides an overview of modeling noise to support gate-level static noise

analysis.

It covers various topics on modeling noise for calculation, detection, and propagation, in

the following sections:

• Modeling Noise Terminology

• Modeling Cells for Noise

• Representing Noise Calculation Information

• Representing Noise Immunity Information

• Representing Propagated Noise Information

• Examples of Modeling Noise

Modeling Noise Terminology

A net can be either an aggressor or a victim:

• An aggressor net is a net that injects noise onto a victim net.

•

A victim net is a net onto which noise is injected by one or more neighboring nets

through the cross-coupling capacitors between the nets.

Noise effect can be categorized in two ways:

• Delay noise

•

Functional noise

Delay noise occurs when victim and aggressor nets switch simultaneously. This activity

alters the delay and slew of the victim net.

Functional noise occurs when a victim net is intended to be at a stable value and the noise

injected onto this net causes it to glitch. The glitch might propagate to a state element,

such as a latch, altering the circuit state and causing a functional failure.

Liberty User Guide Volume 1

R-2020.09

598

Chapter 12: Nonlinear Signal Integrity Modeling

Modeling Cells for Noise

To compute and detect any delay or functional noise failure, the following are calculated:

• Noise calculation

•

Noise immunity

• Noise propagation

Noise Calculation

Coupled noise is the noise voltage induced at the output of nonswitching gates when

coupled adjacent drivers to the output (aggressor drivers) are switching.

Noise Immunity

The main concept of noise immunity is that for most cells, a glitch on the input pin has

to be greater than a certain fixed voltage to cause a failure. However, a glitch with a

tall height might still not cause any failure if the glitch width is very small. This is mainly

because noise failure is related to input noise glitch energy and this energy is proportional

to the area under the glitch waveform.

For example, if a large voltage glitch in terms of height and width occurs on the clock pin

of a flip-flop, the glitch can cause a change in the data and therefore the flip-flop output

might change.

Noise Propagation

Propagated noise is the noise waveform created at the output of nonswitching gates due

to the propagation of noise from the inputs of the same gate.

Modeling Cells for Noise

Library information for noise can be characterized in the following ways:

• I-V Characteristics and Drive Resistance

•

Noise Immunity

• Noise Propagation

Liberty User Guide Volume 1

R-2020.09

599

Chapter 12: Nonlinear Signal Integrity Modeling

Modeling Cells for Noise

I-V Characteristics and Drive Resistance

To calculate the coupled noise glitch on a victim net, you need to know the effective

steady-state drive resistance of the net. Figure 105 on page 601 shows the four different

types of noise glitch:

•

Vh+: Input is high, and the noise is over the high voltage rail.

•

Vh-: Input is high, and the noise is less than the high voltage rail.

• Vl+: Input is low, and the noise is over the low voltage rail.

•

Vl-: Input is low, and the noise is less than the low voltage rail.

Because the current is a nonlinear function of the voltage, you need to characterize

the steady-state I-V characteristics curve, which provides a more accurate view of the

behavior of a cell in its steady state. This information is specified for every timing arc of the

cell that can propagate a transition. If an I-V curve cannot be obtained for a specific arc,

the steady-state drive resistance single value can be used, but it is less accurate than the

I-V curve.

Liberty User Guide Volume 1

R-2020.09

600

Chapter 12: Nonlinear Signal Integrity Modeling

Modeling Cells for Noise

Figure 105 Noise Glitch and Steady-State Drive Resistance

Figure 106 on page 602 is an example of two I-V curves and the steady-state resistance

value.

Liberty User Guide Volume 1

R-2020.09

601

Chapter 12: Nonlinear Signal Integrity Modeling

Modeling Cells for Noise

Figure 106 I-V Characteristics and Steady-State Drive Resistance

Noise Immunity

Circuits can tolerate large glitches at their inputs and still work correctly if the glitches

deliver only a small energy. Given this concept, each cell input can be characterized by

application of a wide range of coupling voltage waveform stimuli on it. Figure 107 shows a

glitch noise model.

Liberty User Guide Volume 1

R-2020.09

602

Chapter 12: Nonlinear Signal Integrity Modeling

Modeling Cells for Noise

Figure 107 Glitch Noise Modeling

One method of modeling the noise immunity curve involves applying coupling voltage

waveform stimuli with various heights (in library voltage units) and widths (in library time

units) to the cell input, and then observing the output voltage waveform. The exact set of

input stimuli (in terms of height and width) that produces an output noise voltage height

equal to a predefined voltage is on the noise immunity curve. This predefined voltage is

known as the cell failure voltage. Any input stimulus that has a height and width above

the noise immunity curve causes a noise voltage higher than the cell failure voltage at the

output and produces a functional failure in the cell.

Figure 108 shows an example of a noise immunity curve.

Figure 108 Noise Immunity Curve

As shown in Figure 108, any noise width and height combination that falls above the noise

rejection curve causes functional failure. The selection of cell failure voltage is important

for noise immunity curve characterization.

Liberty User Guide Volume 1

R-2020.09

603

Chapter 12: Nonlinear Signal Integrity Modeling

Modeling Cells for Noise

There are many ways to select a failure voltage for a cell that produces usable noise

immunity curves, including the following:

•

failure

equal to the output DC noise margin

•

failure

equal to the next cell’s V

or (V

– V

)

• V

failure

corresponding to the point on the DC transfer curve where dV

out

/dV

is 1.0 or –

1.0

•

failure

corresponding to the point on the DC transfer curve where V

out

is less than

1.0 or –1.0

•

failure

corresponding to the point on the DC transfer curve where V

out

is 1.0 or –1.0

Figure 109 Different Failure Voltage Criteria for Noise Immunity Curve

The noise immunity curve can also be a function of output loads, where cells with

larger output loads can tolerate greater input noise.

The noise immunity curve is also state-dependent. For example, the noise on the A-

to-Z arc of an XOR gate when B = 0 might be different from the B-to-Z arc when B = 1,

because the arcs might go through different sets of transistors.

Liberty User Guide Volume 1

R-2020.09

604

Chapter 12: Nonlinear Signal Integrity Modeling

Modeling Cells for Noise

Using the Hyperbolic Model

The noise immunity curve resembles a hyperbola, because the area of different noise

along the hyperbola is constant. Therefore noise immunity can be defined as a hyperbolic

function with only three coefficients for every input on an I/O library pin. The formula for the

height based on these three coefficients is as follows:

height = height_coefficient + area_coefficient / (width – width_coefficient);

Your tool gets these coefficients from the library and applies the calculated height and

width to determine whether the noise can cause functional failure. Any point above the

hyperbolic curve signifies a functional failure.

Noise Propagation

Propagated noise from the input to the output of a cell is modeled by

•

Output glitch height

•

Output glitch width

• Output glitch peak time ratio

•

Output load

Figure 110 illustrates basic noise characteristics.

Figure 110 Basic Noise Characteristics

The output noise width, height, and peak-time ratio depend on the input noise width,

height, and peak-time ratio as well as on the output load. However, in some cases, the

dependency on peak-time ratio can be negligible; therefore, to reduce the amount of data,

the lookup table does not have a peak-time-ratio dependency.

Liberty User Guide Volume 1

R-2020.09

605

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Calculation Information

Table 32 shows a summary of the syntax used to model cases when the cell is not

switching.

Table 32 Summary of Library Requirements for Noise Model

Category Model type Description

Noise detection Voltage ranges (DC

noise margin)

Lookup table and

polynomial

input_voltage or output_voltage

defined for all library pins

Hyperbolic noise

immunity curves

Lookup table and

polynomial

Four hyperbolic curves; each has

three coefficients, defined for input or

bidirectional library pins

Noise immunity tables Lookup table Four tables indexed by noise width and

output load defined for timing arcs

Noise immunity

polynomials

Polynomial Four polynomials as a function of noise

width and output load defined for timing

arcs

Noise calculation Steady-state

resistances

Lookup table and

polynomial

Four floating-point values defined for

timing arcs

I-V characteristics

tables

Lookup table Two tables indexed by output

steady-state voltage for non-three-state

arcs and one table for three-state arcs

I-V characteristics

polynomials

Polynomial Two polynomials as a function of output

steady-state voltage for non-three-state

arcs and one table for three-state arcs

Noise propagation Noise propagation

tables

Lookup table Four pairs of noise width and height

tables, each indexed by noise width,

height, and load

Noise propagation

polynomials

Polynomial Four sets of three polynomials (width,

height, and peak-time ratio), each a

function of width, height, peak-time

ratio, and load

Representing Noise Calculation Information

You can represent coupled noise information with an I-V characteristics lookup table model

or polynomial model at the timing level or four simple attributes defined at the timing level:

•

steady_state_resistance_above_high

•

steady_state_resistance_below_low

• steady_state_resistance_high

Liberty User Guide Volume 1

R-2020.09

606

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Calculation Information

• steady_state_resistance_low

I-V Characteristics Lookup Table Model

You can describe I-V characteristics in your libraries by using lookup tables. To define your

lookup tables, use the following groups and attributes:

•

The iv_lut_template group in the library group

•

The steady_state_current_high, steady_state_current_low, and

steady_state_current_tristate groups in the timing group

iv_lut_template Group

Use this library-level group to create templates of common information that multiple

lookup tables can use. A table template specifies the I-V output voltage and the

breakpoints for the axis. Assign each template a name. Make the template name the

group name of a steady_state_current_low, steady_state_current_high, or

steady_state_current_tristate group.

Syntax

library(name

string

) {

...

iv_lut_template(template_name

string

) {

variable_1: iv_output_voltage ;

index_1 ("float,..., float");

}

...

}

Template Variables

To specify I-V characteristics, define the following variable and index:

variable_1

The only valid value is iv_output_voltage, which specifies the I-V voltage of

the output pin specified in the pin group. The voltage is measured from the pin

to the ground.

index_1

The index values are a list of floating-point numbers that can be negative or

positive. The values in the list must be in increasing order. The number of

floating-point numbers in the index_1 variable determines the dimension.

Example

iv_lut_template(my_current_low) {

variable_1: iv_output_voltage;

Liberty User Guide Volume 1

R-2020.09

607

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Calculation Information

index_1 ("-1, -0.1, 0, 0.1 0.8, 1.6, 2");

}

iv_lut_template(my_current_high) {

variable_1 : iv_output_voltage;

index_1("-1, 0, 0.3, 0.5, 0.8, 1.5, 1.6, 1.7, 2");

}

Defining the Lookup Table Steady-State Current Groups

To specify the I-V characteristics curve for the nonlinear table model, use

the steady_state_current_high, steady_state_current_low, or

steady_state_current_tristate groups within the timing group.

Syntax for Table Model

timing() { /* for non-three-state arcs */

steady_state_current_high(template_name

string

) {

values("float,..., float");

}

steady_state_current_low(template_name

string

) {

values("float,..., float");

}

...

}

timing() { /* for three-state arcs */

steady_state_current_tristate(template_name

string

) {

values("float,..., float);

}

...

}

float

The values are floating-point numbers indicating values for current.

The following rules apply to lookup table groups:

•

Each table must have an associated name for the iv_lut_template it uses.

The name of the template must be identical to the name defined in a library

iv_lut_template group.

•

You can overwrite index_1 in a lookup table, but the overwrite must come before the

definition of values.

• The current values of the table are stored in a values attribute. The values can be

negative.

Example

timing() {

Liberty User Guide Volume 1

R-2020.09

608

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Calculation Information

...

steady_state_current_low(my_current_low) {

values("-0.1, -0.05, 0, 0.1, 0.25, 1, 1.8");

}

steady_state_current_high(my_current_high) {

values("-2, -1.8, -1.7, -1.4, -1, -0.5, 0, 0.1, 0.8");

}

I-V Characteristics Curve Polynomial Model

As with the lookup table model, you can describe an I-V characteristics curve in your

libraries by using the polynomial representation. To define your polynomial, use the

following groups and attributes:

•

The poly_template group in the library group

•

The steady_state_current_high, steady_state_current_low, and

steady_state_current_tristate groups within the timing group

poly_template Group

You can define a poly_template group at the library level to specify the equation

variables, the variable ranges, the voltages mapping, and the piecewise data. The valid

values for the variables are extended to include iv_output_voltage, voltage, voltagei,

and temperature.

Syntax

library(name

string

) {

...

poly_template(template_name

string

) {

variables(variable_1

enum

,..., variable_n

enum

);

variable_i_range: (float, float);

...

variable_n_range: (float, float);

mapping(voltage

enum

, power_rail

);

domain(domain_name

string

) {

variable_i_range: (float, float);

...

variable_n_range: (float, float);

}

...

}

...

}

The syntax of the poly_template group is the same as that used for the delay model,

except that the variables used in the format are

•

iv_output_voltage for the output voltage of the pin

Liberty User Guide Volume 1

R-2020.09

609

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Calculation Information

• voltage, voltagei, temperature

The piecewise model through the domain group is also supported.

Example

poly_template ( my_current_low ) {

variables ( iv_output_voltage, voltage,

voltage1,temperature );

mapping(voltage1, VDD2);

variable_1_range (-1, 2);

variable_2_range (1.4, 1.8);

variable_3_range (1.1, 1.5);

variable_4_range (-40, 125);

}

Defining Polynomial Steady-State Current Groups

To specify the I-V characteristics curve to define the polynomial, use

the steady_state_current_high, steady_state_current_low, and

steady_state_current_tristate groups within the timing group.

Syntax for Polynomial Model

timing { /* for non-three-state arcs */

steady_state_current_high(template_name

string

) {

orders("integer,..., integer");

coefs("float,..., float");

domain(domain_name

string

) {

orders("integer,..., integer");

coefs("float,..., float");

}

...

}

steady_state_current_low(template_name

string

) {

...

}

timing() { /* for three-state arcs */

steady_state_current_tristate(template_name

string

) {

...

}

...

}

The orders, coefs, and variable_range attributes represent the polynomial for the

current for high, low, and three-state.

The output voltage, temperature, and any power rail of the cell are allowed as variables for

steady_state_current groups.

Liberty User Guide Volume 1

R-2020.09

610

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Calculation Information

Example

timing() {

steady_state_current_low(my_current_low) {

orders ("3, 3, 0, 0");

coefs ("8.4165, 0.3198, -0.0004, 0.0000, \

1133.8274, 8.7287, -0.0054, 0.0000, \

139.8645, -60.3898, 0.0589, -0.0000, \

-167.4473, 95.7112, -0.1018, 0.0000");

}

steady_state_current_high(my_current_high) {

orders ("3, 3, 0, 0");

coefs ("10.9165, 0.2198, -0.0003, 0.0000, \

1433.8274, 8.7287, -0.0054, 0.0000, \

128.8645, -60.3898, 0.0589, -0.0000, \

-167.4473, 95.7112, -0.1018, 0.0000");

}

...

}

Using Steady-State Resistance Simple Attributes

To represent steady-state drive resistance values, use the following attributes to define the

four regions:

•

steady_state_resistance_above_high

•

steady_state_resistance_below_low

• steady_state_resistance_high

•

steady_state_resistance_low

These attributes are defined within the timing group to represent the steady-state drive

resistance. If one of these attributes is missing, the model becomes inaccurate.

Syntax

pin(name) {

...

timing() {

...

steady_state_resistance_above_high : float;

steady_state_resistance_below_low : float;

steady_state_resistance_high : float;

steady_state_resistance_low : float;

...

}

Liberty User Guide Volume 1

R-2020.09

611

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Calculation Information

float

The value of steady-state resistance for the four different noise regions in the I-V

curve.

Example

steady_state_resistance_above_high : 200.0;

steady_state_resistance_below_low : 100.0;

steady_state_resistance_high : 100.0;

steady_state_resistance_low : 1100.0

Using I-V Curves and Steady-State Resistance for tied_off Cells

In tied-off cells, the output pins are tied to either high or low and there is no need to define

timing information for related pins. The tied-off cells have been enhanced to accept I-V

curve and steady-state resistance in the timing group. To specify only the noise data (I-V

curves and steady-state resistance) in the timing group, you must specify a new Boolean

attribute, tied_off, and set it to true.

Defining tied_off Attribute Usage

You can specify the I-V characteristics and steady-state drive resistance values on tied-off

cells by using the tied_off attribute in the timing group.

Syntax

pin(name) {

...

timing() {

...

tied_off : boolean;

/* timing type is not defined */

/* steady-state resistance */

The following rules apply to tied_off cells:

•

Steady-state resistance and I-V curves can coexist in the same timing arc of a

tied_off output pin.

•

If the output pin is tied to low (function : "0") and its timing arc specifies the

steady_state_current_high group, an error is generated. Similarly if

the output pin is tied to high (function : "1") and its timing arc specifies the

steady_state_current_low group, an error is generated.

•

If noise immunity and noise propagation are specified in the timing arcs of a tied_off

pin, an error is generated.

Liberty User Guide Volume 1

R-2020.09

612

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Immunity Information

• If the related_pin attribute is specified on a tied_off output pin, an error is

generated.

Example

pin (high) {

direction : output;

capacitance : 0;

function : "1";

/* noise information */

timing() {

tied_off : true;

steady_state_resistance_high : 1.22;

steady_state_resistance_above_high : 1.00;

steady_state_current_high(iv1x5){

index_1("0.3,0.75,1.0,1.2,2");

values("-513.2,-447.9,-359.3,-245.7,497.3");

}

Representing Noise Immunity Information

In the Liberty syntax, you can represent noise immunity information with a

• Lookup table or a polynomial model at the timing level

•

Input noise width range at the pin level

• Hyperbolic model at the pin level

Noise Immunity Lookup Table Model

You can represent noise immunity in your libraries by using lookup tables. To define your

lookup tables, use the following groups and attributes:

•

noise_lut_template group in the library group

•

noise_immunity_above_high, noise_immunity_above_low,

noise_immunity_below_low, and noise_immunity_high groups in the timing group

noise_lut_template Group

Use this library-level group to create templates of common information that multiple noise

immunity lookup tables can use.

Liberty User Guide Volume 1

R-2020.09

613

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Immunity Information

A table template specifies the input noise width, the output load, and their corresponding

breakpoints for the axis. Assign each template a name, and make the name the group

name of a noise immunity group.

Syntax

library(name

string

) {

...

noise_lut_template(template_name

string

) {

variable_1: value;

variable_2: value;

index_1 ("float,..., float");

index_2 ("float,..., float");

}

...

}

Template Variables

The library-level table template specifying noise immunity can have two variables

(variable_1 and variable_2). The variables indicate the parameters used to

index the lookup table along the first and second table axes. The parameters are

input_noise_width and total_output_net_capacitance.

The index values in index_1 and index_2 are a list of positive floating-point numbers. The

values in the list must be in increasing order.

The unit for the input noise width is the library time unit.

Example

noise_lut_template(my_noise_reject) {

variable_1 : input_noise_width;

variable_2 : total_output_net_capacitance;

index_1("0, 0.1, 0.3, 1, 2");

index_2("1, 2, 3, 4, 5");

}

Defining the Noise Immunity Table Groups

To represent noise immunity, use the noise_immunity_above_high,

noise_immunity_below_low, noise_immunity_high, and noise_immunity_low groups

within the timing group.

Syntax for Noise Immunity Table Model

timing() {

noise_immunity_above_high(template_name

string

) {

index_1 ("float,..., float"):

index_2 ("float,..., float"):

values("float,...,float"..."float,...,float");

Liberty User Guide Volume 1

R-2020.09

614

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Immunity Information

}

noise_immunity_below_low(template_name

string

) {

...

}

noise_immunity_high(template_name

string

) {

...

}

noise_immunity_low(template_name

string

) {

...

}

The following rules apply to the noise immunity groups:

•

These tables are optional, and each of them can exist separately on the library timing

arcs.

•

Each noise immunity table has an associated name for the noise_lut_template

it uses. The name of the table must be identical to the name defined in a library

noise_lut_template group.

•

Each table is two-dimensional. The indexes are input_noise_width and

total_output_net_capacitance. The values in the table are the noise heights (that

is, height as a function of width and output load).

•

You can overwrite any or both indexes in a noise template. However, the overwrite

must occur before the actual definition of the values.

• The height values of the table are stored in the values attribute. Each height value is

the absolute difference of the noise bump height voltage and the related rail voltage

and is, therefore, a positive number. Any point over this curve describes a height and

width combination that causes functional failure.

•

The unit for the height is the library voltage unit.

•

For points outside table ranges, extrapolation can be used.

Example

pin ( Y ) {

....

timing () {

noise_immunity_below_low (my_noise1) {

values ("1, 0.8, 0.5", \

"1, 0.8, 0.5", \

"1, 0.8, 0.5");

}

noise_immunity_above_high (my_noise1){

values ("1, 0.8, 0.5", \

"1, 0.8, 0.5", \

"1, 0.8, 0.5");

}

Liberty User Guide Volume 1

R-2020.09

615

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Immunity Information

}

Noise Immunity Polynomial Model

As with the lookup table model, you can represent noise immunity in your libraries by

using the polynomial representation. To define your polynomial, use the following groups

and attributes:

•

The poly_template group in the library group

•

The noise_immunity_above_high, noise_immunity_below_low,

noise_immunity_high, and noise_immunity_low groups in the timing group

poly_template Group

You can define a poly_template group at the library level to specify the polynomial

equation variables, the variable ranges, the voltage mapping, and the piecewise

data. The valid values for the variables include total_output_net_capacitance,

input_noise_width, voltage, voltagei, and temperature.

Syntax

library(name

string

) {

...

poly_template(template_name

string

) {

variables(variable_

ienum

,..., variable_

nenum

);

variable_i_range: (float, float);

...

variable_n_range: (float, float);

mapping(voltage

enum

, power_rail

);

domain(domain_name

string

); {

variable_i_range: (float, float);

...

variable_n_range: (float, float);

}

...

}

Template Variables

The syntax of the poly_template group is the same as that used for the delay model,

except that the variables used in the format are

•

input_noise_width

•

total_output_net_capacitance

• voltage, voltagei, temperature

Liberty User Guide Volume 1

R-2020.09

616

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Immunity Information

The piecewise model through the domain group is also supported.

Example

poly_template (my_noise_reject) { /* existing syntax */

variables (input_noise_width,voltage,voltage1, temperature, \

total_output_net_capacitance);

mapping(voltage1, VDD2);

variable_1_range (0, 2);

variable_2_range (1.4, 1.8);

variable_3_range (1.1, 1.5);

variable_4_range (-40, 125);

variable_5_range (0.01, 1.0);

domain (typ) {

variables (input_noise_width,voltage,voltage1, \

temperature,total_output_net_capacitance);

variable_1_range (0, 2);

}

Defining the Noise Immunity Polynomial Groups

To represent noise immunity, use the noise_immunity_above_high,

noise_immunity_below_low, noise_immunity_high, and noise_immunity_low groups

within the timing group.

Syntax

...

timing() {

noise_immunity_above_high(template_name

string

) {

orders("integer,..., integer");

coefs("float,..., float");

...

domain(domain_name

string

) {

orders("integer,..., integer");

coefs("float,...,float");

}

...

}

noise_immunity_below_low(template_name

string

) {

...

}

noise_immunity_high(template_name

string

) {

...

}

noise_immunity_low(template_name

string

) {

...

}

...

}

Liberty User Guide Volume 1

R-2020.09

617

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Immunity Information

Because the polynomial model is a superset of the lookup table model, all syntax

supported in the lookup table is also supported in the polynomial model. For example, you

can have a polynomial noise_immunity_high and a table noise_immunity_low defined

in the same group in a scalable polynomial delay model library.

Example

noise_immunity_low (my_noise_reject) {

domain (typ) {

orders ("1, 1, 1, 1, 1")

coefs ("1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 0.0, 1.0, 1.0, 1.0, \

1.0, 1.0, 1.0, 1.0, 0.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, \

1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0" );

domain (min) {

orders("1 3 1 1");

coefs("-0.01, 0.02, 1.41, -0.54, \

1.85, 1.83, -5.58, -2.96, -0.0001, \

0.0001, -0.002, -0.0019, 0.002, \

0.0012, -0.010, -0.0061, 0.034, \

0.015, 2.08, -0.22, 4.13, 2.44, \

-14.02, -7.83, 7.09e-05, -1.98e-05, \

-0.0019, 0.0009, 0.0065, -0.0004, \

-0.027, -0.016");

}

Input Noise Width Ranges at the Pin Level

To specify whether a noise immunity or propagation table is referenced within the noise

range indexes, the Liberty syntax allows you to specify the minimum and maximum values

of the input noise width.

Defining the input_noise_width Range Limits

You can specify two float attributes, min_input_noise_width and

max_input_noise_width, at the pin level. These attributes are optional and specify the

minimum and maximum values of the input noise width.

Syntax

pin(name

string

) {

...

/* used for noise immunity or propagation */

min_input_noise_width : float;

max_input_noise_width: float;

...

}

Liberty User Guide Volume 1

R-2020.09

618

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Immunity Information

float

The values of min_input_noise_width and max_input_noise_width are the

minimum and maximum input noise width, in library time units.

The following rules apply to input_noise_width range limits:

•

The min_input_noise_width and max_input_noise_width attributes can be defined

only on input or inout pins.

• The min_input_noise_width and max_input_noise_width attributes must both be

defined.

• min_input_noise_width <= max_input_noise_width

Example

pin ( O) {

direction : output ; /* existing syntax */

capacitance : 1 ; /* existing syntax */

fanout_load : 1 ; /* existing syntax */

/* Noise range */

min_input_noise_width : 0.0;

max_input_noise_width : 2.0;

/* Timing group defines what is acceptable noise on input pins. */

timing () {

/* Noise immunity.

* Defines maximum allowed noise height for given pulse width.

* Pulse height is absolute value from the signal level.

* Any of the following four tables are optional. */

noise_immunity_low (my_noise_reject) {

values ("1.5, 0.9, 0.8, 0.65, 0.6");

}

noise_immunity_high (my_noise_reject) {

values ("1.3, 0.8, 0.7, 0.6, 0.55");

}

noise_immunity_below_low (my_noise_reject_outside_rail) {

values ("1, 0.8, 0.5");

}

noise_immunity_above_high (my_noise_reject_outside_rail) {

values ("1, 0.8, 0.5");

}

} /* end of timing group */

} /* end of pin group */

Liberty User Guide Volume 1

R-2020.09

619

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Noise Immunity Information

Defining the Hyperbolic Noise Groups

To specify hyperbolic noise immunity information, use the

hyperbolic_noise_above_high, hyperbolic_noise_below_low,

hyperbolic_noise_high, and hyperbolic_noise_low groups within the pin group.

Syntax

pin(name

string

) {

...

hyperbolic_noise_above_high() {

height_coefficient : float;

area_coefficient : float;

width_coefficient : float;

}

hyperbolic_noise_below_low() {

...

}

hyperbolic_noise_high() {

...

}

hyperbolic_noise_low() {

...

}

...

}

float

The coefficient values for height, width, and area must be 0 or a positive

number.

The following rules apply to noise immunity groups:

•

The hyperbolic noise groups are optional, and each can be defined separately from the

other three.

•

For the same region (above-high, below-low, high, or low), the hyperbolic noise groups

can coexist with normal noise immunity tables.

• For different regions (above-high, below-low, high, or low), a combination of tables and

hyperbolic functions is allowed. For example, you might have a hyperbolic function for

below and above the rails and have tables for high and low tables on the same pin.

•

When no table or hyperbolic function is defined for a given pin, the application checks

other measures for noise immunity, such as DC noise margins.

•

The unit for height and height_coefficient is the library unit of voltage. The

unit for width and width_coefficient is the library unit of time. The unit for

area_coefficient is the library unit of voltage multiplied by the library unit of time.

Liberty User Guide Volume 1

R-2020.09

620

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Propagated Noise Information

Example

hyperbolic_noise_low() {

height_coefficient : 0.4;

area_coefficient : 1.1;

width_coefficient : 0.1;

}

hyperbolic_noise_high() {

height_coefficient : 0.3;

area_coefficient : 0.9;

width_coefficient : 0.1;

}

Representing Propagated Noise Information

You can represent propagated noise information at the timing level by using a

• Propagated Noise Lookup Table Model

•

Propagated Noise Polynomial Model

Propagated Noise Lookup Table Model

You can represent propagated noise in your libraries by using lookup tables. To define

your lookup tables, use the propagation_lut_template group in the library group. In

the timing group, use the following groups:

•

propagated_noise_height_above_high

•

propagated_noise_height_below_low

• propagated_noise_height_high

•

propagated_noise_height_low

•

propagated_noise_width_above_high

• propagated_noise_width_below_low

•

propagated_noise_width_high

•

propagated_noise_width_low

propagation_lut_template Group

Use this library-level group to create templates of common information that multiple

propagation lookup tables can use.

Liberty User Guide Volume 1

R-2020.09

621

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Propagated Noise Information

A table template specifies the propagated noise width, height, and output load and their

corresponding breakpoints for the axis. Assign each template a name. Make the template

name the group name of a propagated noise group.

Syntax

library(name

string

) {

...

propagation_lut_template(template_namesstring) {

variable_1: value;

variable_2: value;

variable_3: value;

index_1 ("float,..., float");

index_2 ("float,..., float");

index_3 ("float,..., float");

}

...

}

Template Variables

The table template specifying propagated noise can have three variables (variable_1,

variable_2, and variable_3). The variables indicate the parameters used to index

the lookup table along the first, second, and third table axes. The parameters are

input_noise_width, input_noise_height, and total_output_net_capacitance.

The index values in the index_1, index_2, and index_3 attributes are a list of positive

floating-point numbers. The values in the list must be in increasing order.

The unit for input_noise_width and input_noise_height is the library time unit.

Example

propagation_lut_template(my_propagated_noise) {

variable_1 : input_noise_width;

variable_2 : input_noise_height;

variable_3 : total_output_net_capacitance;

index_1("0.01, 0.2, 2");

index_2("0.2, 0.8");

index_3("0, 2");

}

Liberty User Guide Volume 1

R-2020.09

622

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Propagated Noise Information

Defining the Propagated Noise Table Groups

To represent propagated noise, use the following groups within the timing group:

propagated_noise_height_above_high, propagated_noise_height_below_low,

propagated_noise_height_high, propagated_noise_height_low, and

propagated_noise_width_above_high.

Syntax for Table Model

timing() {

...

propagated_noise_height_above_high (temp_name

string

) {

index_1 ("float,..., float");

index_2 ("float,..., float");

index_3 ("float,..., float");

values("float,..., float,"..."float,..., float");

}

propagated_noise_height_below_low (temp_name

string

) {

...

}

propagated_noise_width_above_high (temp_name

string

) {

...

}

propagated_noise_width_below_low (temp_name

string

) {

...

}

propagated_noise_height_high(template_name

string

) {

...

}

propagated_noise_height_low(template_name

string

) {

...

}

propagated_noise_width_high(template_name

string

) {

...

}

propagated_noise_width_low(template_name

string

) {

...

}

...

}

Propagation Noise Group Rules

The following rules apply to the propagation noise groups:

• Each of the three pairs of tables is optional; the assumption is that if one pair is

missing, the corresponding region does not propagate any noise.

•

If a pair of tables for a particular region (high, low, above-high, or below-low) is

specified, both width and height must be specified.

Liberty User Guide Volume 1

R-2020.09

623

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Propagated Noise Information

• Each propagated noise table has an associated name for the

propagation_lut_template it uses. The name of the table must be identical to the

name defined in a library propagated_noise_template group.

• Each table can be two-dimensional or three-dimensional. The indexes are input--

_noise_width, input_noise_height, and total_output_net_capacitance. The

values are coefficients of height and width. The coefficient values for height and width

must be 0 or a positive number.

•

You can overwrite any or all indexes in a propagated noise template. However, the

overwrite must occur before the actual definition of the values.

•

The width and height values of the table are stored in the values attribute. Each height

value is the absolute difference of the noise bump height voltage and the related rail

voltage and is, therefore, a positive number. Any point over this curve describes a

height/width combination that causes functional failure.

• The unit for all propagated height is the library voltage unit. The unit for all propagated

width is the library unit of time.

•

For points outside table ranges, extrapolation can be used.

Example

propagated_noise_width_high(my_propagated_noise) {

values ("0.01, 0.10, 0.15", "0.04, 0.14, 0.18",\

"0.05, 0.15, 0.24","0.07, 0.17, 0.32");

}

propagated_noise_height_high(my_propagated_noise) {

values ("0.01, 0.20, 0.25", "0.04, 0.24, 0.28",\

"0.05, 0.25, 0.28","0.07, 0.27, 0.35");

}

Propagated Noise Polynomial Model

As with the lookup table model, you can describe propagated noise in your libraries by

using polynomial representation. To define your polynomial, use the poly_template group

in the library group.

In the timing group, use the following groups:

•

propagated_noise_height_above_high

•

propagated_noise_height_below_low

• propagated_noise_height_high

•

propagated_noise_height_low

•

propagated_noise_width_above_high

Liberty User Guide Volume 1

R-2020.09

624

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Propagated Noise Information

• propagated_noise_width_below_low

• propagated_noise_width_high

• propagated_noise_width_low

•

propagated_noise_peak_time_ratio_above_high

•

propagated_noise_peak_time_ratio_below_low

• propagated_noise_peak_time_ratio_high

•

propagated_noise_peak_time_ratio_low

poly_template Group

You can define a poly_template group at the library level to specify the equation

variables, the variable ranges, the voltage mapping, and the piecewise data.

The valid values for the variables are extended to include input_noise_width,

input_noise_height, input_peak_time_ratio, total_output_net_capacitance,

temperature, and the related rail voltages.

Syntax

library(name

string

) {

...

poly_template(template_name

string

) {

variables(variable_i

enum

,..., variable_n

enum

);

variable_i_range: (float, float);

...

variable_n_range: (float, float);

mapping(voltage

enum

, power_rail

);

domain(domain_name

string

) {

variable_i_range: (float, float);

...

variable_n_range: (float, float);

}

...

}

Template Variables

The syntax of the poly_template group is the same as that of the delay model, except

that the variables used in the format are

•

input_noise_width, input_noise_height, input_peak_time_ratio

•

total_output_net_capacitance

Liberty User Guide Volume 1

R-2020.09

625

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Propagated Noise Information

• voltage, voltagei, temperature

The piecewise model through the domain group is also supported.

The input_peak_time_ratio is always specified as a ratio of width, so it is a value

between 0.0 and 1.0.

Example

poly_template(my_propagated_noise) {

variables (input_noise_width, input_noise_height,

input_peak_time_ratio, total_output_net_capacitance);

variable_1_range (0.01, 2);

variable_2_range (0, 0.8);

variable_3_range (0.0, 1.0);

variable_4_range (0, 2);

} /* poly_template(propagated_noise) */

Defining Propagated Noise Groups for Polynomial Representation

To specify polynomial representation, use the propagated_noise_height_above_high,

propagated_noise_height_below_low, propagated_noise_height_high,

propagated_noise_height_low, propagated_noise_width_above_high,

propagated_noise_width_below_low, propagated_noise_width_high,

propagated_noise_width_low, propagated_noise_peak_time_ratio_above_high,

propagated_noise_peak_time_ratio_below_low,

propagated_noise_peak_time_ratio_high, and

propagated_noise_peak_time_ratio_low groups within the timing group to define the

polynomial.

The peak_time_ratio groups are supported only in the polynomial model.

Syntax for Polynomial

timing() {

...

propagated_noise_height_above_high (temp_name

string

) {

variable_i_range: (float, float);

orders("integer,..., integer");

coefs("float,..., float");

domain(domain_name

string

) {

variable_i_range: (float, float);

orders("integer,..., integer");

coefs("float,..., float");

}

...

}

propagated_noise_width_above_high (temp_name

string

) {

...

}

propagated_noise_height_below_low (temp_name

string

) {

...

Liberty User Guide Volume 1

R-2020.09

626

Chapter 12: Nonlinear Signal Integrity Modeling

Representing Propagated Noise Information

}

propagated_noise_width_below_low (temp_name

string

) {

...

}

propagated_noise_height_high(temp_name

string

) {

...

}

propagated_noise_width_high(temp_name

string

) {

...

}

propagated_noise_height_low(temp_name

string

) {

...

}

propagated_noise_width_low(temp_name

string

) {

...

}

propagated_noise_peak_time_ratio_above_high (temp_name

string

) {

...

}

propagated_noise_peak_time_ratio_below_low( temp_name

string

) {

...

}

propagated_noise_peak_time_ratio_high (temp_name

string

) {

...

}

propagated_noise_peak_time_ratio_low (temp_name

string

) {

...

}

...

}

Because the polynomial model is a superset of the lookup table model, all syntax

supported in the lookup table is also supported in the polynomial model. For

example, you can have a propagated_noise_width_high polynomial and a

propagated_noise_width_low table defined in the same group in a scalable

polynomial delay model library.

Example

propagated_noise_width_high(my_propagated_noise) {

orders("1, 1, 1, 1 ");

coefs("1, 2, 3, 4 ,\

1, 2, 3, 4 ,\

1, 2, 3, 4 ");

}

propagated_noise_height_high(my_propagated_noise) {

orders("1, 1, 1, 1 ");

coefs("1, 2, 3, 4 ,\

1, 2, 3, 4 ,\

1, 2, 3, 4 ");

Liberty User Guide Volume 1

R-2020.09

627

Chapter 12: Nonlinear Signal Integrity Modeling

Examples of Modeling Noise

}

Examples of Modeling Noise

The examples in this section model libraries for noise extension for scalable polynomials

and nonlinear lookup table model libraries.

Scalable Polynomial Model Noise Example

A scalable polynomial delay library allows you to describe how noise parameters vary with

rail voltage and temperature.

library (my_noise_lib) {

delay_model : "polynomial";

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1mA";

capacitive_load_unit (1,pf);

pulling_resistance_unit : 1kohm;

power_supply() {

default_power_rail : VDD1;

power_rail(VDD1, 1.6);

power_rail(VDD2, 1.3);

}

nom_voltage : 1.0;

nom_temperature : 40;

nom_process : 1.0;

/* Templates of DC noise margins and output levels */

input_voltage(MY_CMOS_IN) {

vil : 0.3;

vih : 1.1;

vimin : -0.3;

vimax : VDD + 0.3;

}

output_voltage(MY_CMOS_OUT) {

vol : 0.1;

voh : 1.4;

vomin : -0.3;

vomax : VDD + 0.3;

}

/* Template definitions for noise immunity. Variable:

* input_noise_width */

poly_template ( my_noise_reject ) {

temperature,total_output_net_capacitance);

variables ( input_noise_width, voltage, voltage1, \

temperature,total_output_net_capacitance);

mapping(voltage, VDD1);

mapping(voltage1, VDD2);

variable_1_range (0, 2);

variable_2_range (1.4, 1.8);

variable_3_range (1.1, 1.5);

variable_4_range (-40, 125);

variable_5_range (0.0, 1.0);

domain (typ) {

variables ( input_noise_width, voltage, voltage1,\

temperature, total_output_net_capacitance);

Liberty User Guide Volume 1

R-2020.09

628

Chapter 12: Nonlinear Signal Integrity Modeling

Examples of Modeling Noise

variable_1_range (0, 2);

variable_2_range (1.5, 1.7);

variable_3_range (1.2, 1.4);

variable_4_range (25, 25);

variable_5_range (0.0, 1.0);

mapping(voltage, VDD1);

mapping(voltage1, VDD2);

}

domain (min) {

variables ( input_noise_width, voltage, voltage1, \

temperature );

variable_1_range (0, 2);

variable_2_range (1.7, 1.8);

variable_3_range (1.4, 1.5);

variable_4_range (-40, -40);

mapping(voltage, VDD1);

mapping(voltage1, VDD2);

}

domain (max) {

variables ( input_noise_width, voltage, voltage1, \

temperature );

variable_1_range (0, 2);

variable_2_range (1.6, 1.7);

variable_3_range (1.1, 1.2);

variable_4_range (125, 125);

mapping(voltage, VDD1);

mapping(voltage1, VDD2);

}

} /* end poly_template (my_noise_reject) */

poly_template ( my_noise_reject_outside_rail ) {

variables ( input_noise_width, voltage, voltage1, \

temperature );

mapping(voltage, VDD1);

mapping(voltage1, VDD2);

variable_1_range (0, 2);

variable_2_range (1.4, 1.8);

variable_3_range (1.1, 1.5);

variable_4_range (-40, 125);

} /* end poly_template ( my_noise_reject_outside_rail ) */

/* Template definitions for I-V characteristics. Variable:

* iv_output_voltage */

poly_template ( my_current_low ) {

variables ( iv_output_voltage, voltage, voltage1, \

temperature );

mapping(voltage, VDD1);

mapping(voltage1, VDD2);

variable_1_range (-1, 2);

variable_2_range (1.4, 1.8);

variable_3_range (1.1, 1.5);

variable_4_range (-40, 125);

} /* end poly_template ( my_current_low ) */

poly_template ( my_current_high ) {

variables ( iv_output_voltage, voltage, voltage1, \

temperature );

mapping(voltage, VDD1);

mapping(voltage1, VDD2);

variable_1_range (-1, 2);

variable_2_range (1.4, 1.8);

variable_3_range (1.1, 1.5);

variable_4_range (-40, 125);

} /* end poly_template ( my_current_high ) */

Liberty User Guide Volume 1

R-2020.09

629

Chapter 12: Nonlinear Signal Integrity Modeling

Examples of Modeling Noise

/* Template definitions for propagated noise. Variables:

* input_noise_width

* input_noise_height

* input_peak_time_ratio

* total_output_net_capacitance */

poly_template(my_propagated_noise) {

variables ( input_noise_width, input_noise_height, \

input_peak_time_ratio \

total_output_net_capacitance, voltage, \

voltage1, temperature );

mapping(voltage, VDD1);

mapping(voltage1, VDD2);

variable_1_range (0.01, 2);

variable_2_range (0, 0.8);

variable_3_range (0.0, 1.0);

variable_4_range (0, 2);

variable_5_range (1.4, 1.8);

variable_6_range (1.1, 1.5);

variable_7_range (-40, 125);

} /* end poly_template (my_propagated_noise) */

/* INVERTER */

cell ( INV ) {

area : 1 ;

pin ( A ) {

direction : input ;

capacitance : 1 ;

fanout_load : 1 ;

/* DC noise margins.

* These are used for compatibility of level shifters.

* In noise analysis, they are the least accurate way

* to define noise margins.

* Compatible: can coexist in the pin group with any

* other noise margin definition. */

input_voltage : MY_CMOS_IN ;

/* Noise group defines what is acceptable noise on input

* pins. */

/* Hyperbolic noise immunity.

* Another way to specify noise immunity.

* Mutually exclusive: noise_immunity_low cannot be

* together with

*hyperbolic_noise_immunity_low, and so on.

* Defines pulse_height = height_coefficient +

* area_coefficient / (width - width_coefficient)

* Characterization recommendation: Use

* hyperbolic_noise_immunity_*

* if it can fit the curve, otherwise use

* table noise_immunity_* */

hyperbolic_noise_low() {

height_coefficient : 0.4;

area_coefficient : 1.1;

width_coefficient : 0.1;

}

hyperbolic_noise_high() {

height_coefficient : 0.3;

area_coefficient : 0.9;

width_coefficient : 0.1;

}

hyperbolic_noise_below_low() {

height_coefficient : 0.1;

area_coefficient : 0.3;

width_coefficient : 0.01;

Liberty User Guide Volume 1

R-2020.09

630

Chapter 12: Nonlinear Signal Integrity Modeling

Examples of Modeling Noise

}

hyperbolic_noise_above_high() {

height_coefficient : 0.1;

area_coefficient : 0.3;

width_coefficient : 0.01;

}

} /* end pin (A) */

pin ( Y ) {

direction : output ;

max_fanout : 10 ;

function : " !A ";

output_voltage : MY_CMOS_OUT ;

timing () {

related_pin : A ;

/* Steady state drive resistance */

steady_state_resistance_high : 1500;

steady_state_resistance_low : 1100;

steady_state_resistance_above_high : 200;

steady_state_resistance_below_low : 100;

/* I-V curve.

* Describes how much current the pin can deliver in a given state for

* a given voltage on the pin.

* Voltage is measured from the pin to ground, current is measured

* flowing into the cell (both can be either positive or negative). */

steady_state_current_low(my_current_low) {

orders ("3, 3, 0, 0");

coefs ("8.4165, 0.3198, -0.0004, 0.0000, \

1133.8274, 8.7287, -0.0054, 0.0000, \

139.8645, -60.3898, 0.0589, -0.0000, \

-167.4473, 95.7112, -0.1018, 0.0000");

}

steady_state_current_high(my_current_high) {

orders ("3, 3, 0, 0");

coefs ("10.9165, 0.2198, -0.0003, 0.0000, \

1433.8274, 8.7287, -0.0054, 0.0000, \

128.8645, -60.3898, 0.0589, -0.0000, \

-167.4473, 95.7112, -0.1018, 0.0000");

}

/* Noise immunity.

* Defines maximum allowed noise height for given pulse width.

* Pulse height is absolute value from the signal level.

* Any of the 4 tables below are optional. */

noise_immunity_low (my_noise_reject) {

domain (typ) {

orders ("3, 3, 0, 0, 0");

coefs ("11.4165, 0.2198, -0.0003, 0.0000, \

1353.8274, 8.7287, -0.0054, 0.0000, \

149.8645, -60.3898, 0.0589, -0.0000, \

-167.4473, 95.7112, -0.1018, 0.0000");

}

domain (min) {

orders ("3, 3, 0, 0");

coefs ("6.964065, 0.134078, -0.000183, 0.0000, \

825.834714, 5.324507, -0.003294, 0.0000, \

91.417345, -36.837778, .035929, -0.0000, \

-102.142853, 58.383832, -.062098, 0.0000");

}

domain (max) {

orders ("3, 3, 0, 0");

coefs ("19.065555, 0.367066, -0.000501, 0.0000, \

2260.891758, 14.576929, -0.009018, 0.0000, \

Liberty User Guide Volume 1

R-2020.09

631

Chapter 12: Nonlinear Signal Integrity Modeling

Examples of Modeling Noise

250.273715, -100.850966, 0.098363, -0.0000, \

-279.636991, 159.837704, -0.170006, 0.0000");

}

noise_immunity_high (my_noise_reject) {

domain (typ) {

orders ("3, 3, 0, 0, 0");

coefs ("12.4165, 0.2198, -0.0003, 0.0000, \

1353.8274, 8.7287, -0.0054, 0.0000, \

129.8645, -60.3898, 0.0589, -0.0000, \

-147.4473, 95.7112, -0.1018, 0.0000");

}

domain (min) {

orders ("3, 3, 0, 0");

coefs ("6.364065, 0.134078, -0.000183, 0.0000, \

845.834714, 5.324507, -0.003294, 0.0000, \

91.417345, -36.837778, .035929, -0.0000, \

-103.142853, 58.383832, -.062098, 0.0000");

}

domain (max) {

orders ("3, 3, 0, 0");

coefs ("19.265555, 0.367066, -0.000601, 0.0000, \

2460.891758, 14.576929, -0.009018, 0.0000, \

250.273715, -130.850966, 0.098363, -0.0000, \

-279.636991, 159.837704, -0.170006, 0.0000");

}

noise_immunity_below_low (my_noise_reject_outside_rail) {

orders ("3, 3, 0, 0");

coefs ("10.4165, 0.1198, -0.0003, 0.0000, \

1333.8274, 8.7287, -0.0054, 0.0000, \

149.8645, -60.3898, 0.0589, -0.0000, \

-167.4473, 95.7112, -0.1018, 0.0000");

}

noise_immunity_above_high (my_noise_reject_outside_rail) {

orders ("3, 3, 0, 0");

coefs ("12.4165, 0.2298, -0.0003, 0.0000, \

1253.8274, 8.7287, -0.0054, 0.0000, \

149.8645, -60.3898, 0.0589, -0.0000, \

-167.4473, 95.7112, -0.1018, 0.0000");

}

/* Propagated noise.

* It is a function of input noise width and height and output

* capacitance. Width and height are in separate tables. */

propagated_noise_width_high(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("8.4165, 0.3198, -0.0004, 0.2000, \

1.8645, -6.3898, 0.0589, -0.03000, \

-1.4473, 9.7112, -0.1018, 0.3500, ");

}

propagated_noise_height_high(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("0.4165, 0.3198, -0.0014, 0.2000, \

0.8645, -6.3898, 0.0589, -0.03000, \

-0.4473, 0.7112, -0.1018, 0.3500, ");

}

propagated_noise_peak_time_ratio_high(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("0.4165, 0.3198, 0.0014, 0.2000, \

0.8645, 0.3898, 0.0589, 0.03000, \

0.4473, 0.7112, 0.1018, 0.3500, ");

Liberty User Guide Volume 1

R-2020.09

632

Chapter 12: Nonlinear Signal Integrity Modeling

Examples of Modeling Noise

}

propagated_noise_width_low(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("8.4165, 0.3198, -0.0004, 0.2000, \

1.8645, -6.3898, 0.0589, -0.03000, \

-1.4473, 9.7112, -0.1018, 0.3500, ");

}

propagated_noise_height_low(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("0.4165, 0.3198, -0.0014, 0.2000, \

0.8645, -6.3898, 0.0589, -0.03000, \

-0.4473, 0.7112, -0.1018, 0.3500, ");

}

propagated_noise_peak_time_ratio_low(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("0.4165, 0.3198, 0.0014, 0.2000, \

0.8645, 0.3898, 0.0589, 0.03000, \

0.4473, 0.7112, 0.1018, 0.3500, ");

}

propagated_noise_width_above_high(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("8.4165, 0.3198, -0.0004, 0.2000, \

1.8645, -6.3898, 0.0589, -0.03000, \

-1.4473, 9.7112, -0.1018, 0.3500, ");

}

propagated_noise_height_above_high(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("0.4165, 0.3198, -0.0014, 0.2000, \

0.8645, -6.3898, 0.0589, -0.03000, \

-0.4473, 0.7112, -0.1018, 0.3500, ");

}

propagated_noise_peak_time_ratio_above_high(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("0.4165, 0.3198, 0.0014, 0.2000, \

0.8645, 0.3898, 0.0589, 0.03000, \

0.4473, 0.7112, 0.1018, 0.3500, ");

}

propagated_noise_width_below_low(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("8.4165, 0.3198, -0.0004, 0.2000, \

1.8645, -6.3898, 0.0589, -0.03000, \

-1.4473, 9.7112, -0.1018, 0.3500, ");

}

propagated_noise_height_below_low(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("0.4165, 0.3198, -0.0014, 0.2000, \

0.8645, -6.3898, 0.0589, -0.03000, \

-0.4473, 0.7112, -0.1018, 0.3500, ");

}

propagated_noise_peak_time_ratio_below_low(my_propagated_noise) {

orders ("1, 2, 1, 0, 0, 0, 0");

coefs ("0.4165, 0.3198, 0.0014, 0.2000, \

0.8645, 0.3898, 0.0589, 0.03000, \

0.4473, 0.7112, 0.1018, 0.3500, ");

}

cell_rise(scalar) { values("0");}

rise_transition(scalar) { values("0");}

cell_fall(scalar) { values("0");}

fall_transition(scalar) { values("0");}

} /* end of timing group */

} /* end of pin (Y) */

Liberty User Guide Volume 1

R-2020.09

633

Chapter 12: Nonlinear Signal Integrity Modeling

Examples of Modeling Noise

} /* end of cell (INV) */

} /* end of library (my_noise_lib)

Nonlinear Delay Model Library With Noise Information

A nonlinear delay model noise library is limited to a fixed voltage.

library (my_noise_lib) {

delay_model : "table_lookup";

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1mA";

capacitive_load_unit (1,pf);

pulling_resistance_unit : 1kohm;

nom_voltage : 1.6;

nom_temperature : 40.0;

nom_process : 1.0;

/* Templates of input and output levels (used for DC noise margin) */

input_voltage(MY_CMOS_IN) {

vil : 0.3;

vih : 1.1;

vimin : -0.3;

vimax : VDD + 0.3;

}

output_voltage(MY_CMOS_OUT) {

vol : 0.1;

voh : 1.4;

vomin : -0.3;

vomax : VDD + 0.3;

}

/* Template definitions for noise immunity. Variable:

* input_noise_width */

noise_lut_template(my_noise_reject) {

variable_1 : input_noise_width;

variable_2 : total_output_net_capacitance;

index_1("0, 0.1, 0.3, 1, 2");

index_2("0, 0.1, 0.3, 1, 2");

}

noise_lut_template(my_noise_reject_outside_rail) {

variable_1 : input_noise_width;

variable_2 : total_output_net_capacitance;

index_1("0, 0.1, 2");

index_2("0, 0.1, 2");

}

/* Template definitions for I-V characteristics. Variable:

* iv_output_voltage */

iv_lut_template(my_current_low) {

variable_1 : iv_output_voltage

index_1("-1, -0.1, 0, 0.1 0.8, 1.6, 2");

}

iv_lut_template(my_current_high) {

variable_1 : iv_output_voltage

index_1("-1, 0, 0.3, 0.5, 0.8, 1.5, 1.6, 1.7, 2");

}

/* Template definitions for propagated noise. Variables:

* input_noise_width

* input_noise_height

* total_output_net_capacitance */

propagation_lut_template(my_propagated_noise) {

Liberty User Guide Volume 1

R-2020.09

634

Chapter 12: Nonlinear Signal Integrity Modeling

Examples of Modeling Noise

variable_1 : input_noise_width;

variable_2 : input_noise_height;

variable_3 : total_output_net_capacitance;

index_1("0.01, 0.2, 2");

index_2("0.2, 0.8");

index_3("0, 2");

}

cell (tieoff_30_esd) {

pin (high) {

direction : output;

capacitance : 0;

function : "1";

/* noise information */

timing() {

tied_off : true;

steady_state_resistance_high : 1.22;

steady_state_resistance_above_high : 1.00;

steady_state_current_high(iv1x5){

index_1("0.3,0.75,1.0,1.2,2");

values("-513.2,-447.9,-359.3,-245.7,497.3");

}

pin (low) {

direction : output;

capacitance : 0;

function : "0";

/* noise information */

timing() {

tied_off : true;

steady_state_resistance_low : 0.1;

steady_state_resistance_below_low : 0.4;

steady_state_current_low(iv1x5){

index_1("-0.25,0.3,0.5,1.0,1.8");

values("-595.4,555.4,690.5,774.75,822.5");

}

/* INVERTER */

cell ( INV ) {

area : 1 ;

pin ( A ) {

direction : input ;

capacitance : 1 ;

fanout_load : 1 ;

/* DC noise margins.

* These are used for compatibility of level shifters. In noise

* analysis they are the least accurate way to define noise margins.

* Compatible: can coexist in the pin group with any other noise margin

* definition. */

input_voltage : MY_CMOS_IN ;

/* Timing group defines what is acceptable noise on input pins. */

/* Hyperbolic noise immunity.

* Another way to specify noise immunity.

* Mutually exclusive: noise_immunity_low cannot be together with

* hyperbolic_noise_immunity_low, etc.

* Defines pulse_height = height_coefficient +

* area_coefficient / (width - width_coefficient)

* Characterization recommendation: use hyperbolic_noise_immunity_*

Liberty User Guide Volume 1

R-2020.09

635

Chapter 12: Nonlinear Signal Integrity Modeling

Examples of Modeling Noise

* if can fit the curve, otherwise table noise_immunity_* */

hyperbolic_noise_low() {

height_coefficient : 0.4;

area_coefficient : 1.1;

width_coefficient : 0.1;

}

hyperbolic_noise_high() {

height_coefficient : 0.3;

area_coefficient : 0.9;

width_coefficient : 0.1;

}

hyperbolic_noise_below_low() {

height_coefficient : 0.1;

area_coefficient : 0.3;

width_coefficient : 0.01;

}

hyperbolic_noise_above_high() {

height_coefficient : 0.1;

area_coefficient : 0.3;

width_coefficient : 0.01;

}

} /* end of pin A */

pin ( Y ) {

direction : output ;

max_fanout : 10 ;

function : " !A ";

output_voltage : MY_CMOS_OUT

min_input_noise_width : 0.0;

max_input_noise_width : 2.0;

timing () {

related_pin : A ;

/* Steady-state drive resistance */

steady_state_resistance_high : 1500;

steady_state_resistance_low : 1100;

steady_state_resistance_above_high : 200;

steady_state_resistance_below_low : 100;

/* I-V curve.

* Describes how much current the pin can deliver in a given state for

* a given voltage on the pin. The steady_state_resistance*_max is the

* highest resistance in the I-V curve, the

* steady_state_resistance*_min is the lowest.

* Mutually exclusive: If steady_state_resistance_low* or

* steady_state_resistance_max or steady_state_resistance_min is

* specified, the I-V curve cannot be specified.

* Characterization recommendation: Use steady_state_resistance* if

* an I-V curve cannot be generated.

* Voltage is measured from the pin to ground, current measured

* flowing into the cell (both can be either positive or negative). */

steady_state_current_low(my_current_low) {

values("0.1, 0.05, 0, -0.1, -0.25, -1, -1.8");

}

steady_state_current_high(my_current_high) {

values("2, 1.8, 1.7, 1.4, 1, 0.5, 0, -0.1, -0.8");

}

cell_rise(scalar) { values("0");}

rise_transition(scalar) { values("0");}

cell_fall(scalar) { values("0");}

fall_transition(scalar) { values("0");}

/* Noise immunity.

* Defines the maximum allowed noise height for given pulse width.

* Pulse height is the absolute value from the signal level.

Liberty User Guide Volume 1

R-2020.09

636

Chapter 12: Nonlinear Signal Integrity Modeling

Examples of Modeling Noise

* Any of the following four tables are optional. */

noise_immunity_low (my_noise_reject) {

values ("1.5, 0.9, 0.8, 0.65, 0.6", \

"1.5, 0.9, 0.8, 0.65, 0.6", \

"1.5, 0.9, 0.8, 0.65, 0.6");

}

noise_immunity_high (my_noise_reject) {

values ("1.3, 0.8, 0.7, 0.6, 0.55", \

"1.5, 0.9, 0.8, 0.65, 0.6", \

"1.5, 0.9, 0.8, 0.65, 0.6");

}

noise_immunity_below_low (my_noise_reject_outside_rail) {

values ("1, 0.8, 0.5", \

"1, 0.8, 0.5", \

"1, 0.8, 0.5");

}

noise_immunity_above_high (my_noise_reject_outside_rail) {

values ("1, 0.8, 0.5", \

"1, 0.8, 0.5", \

"1, 0.8, 0.5");

}

/* Propagated noise.

* A function of input noise width, height, and output

* capacitance. Width and height are in separate tables. */

propagated_noise_width_high(my_propagated_noise) {

values ("0.01, 0.10", "0.15, 0.04", "0.14, 0.18", \

"0.05, 0.15", "0.24, 0.07", "0.17, 0.32");

}

propagated_noise_height_high(my_propagated_noise) {

values ("0.01, 0.10", "0.15, 0.04", "0.14, 0.18", \

"0.05, 0.15", "0.24, 0.07", "0.17, 0.32");

}

propagated_noise_width_low(my_propagated_noise) {

values ("0.01, 0.10", "0.15, 0.04", "0.14, 0.18", \

"0.05, 0.15", "0.24, 0.07", "0.17, 0.32");

}

propagated_noise_height_low(my_propagated_noise) {

values ("0.01, 0.10", "0.15, 0.04", "0.14, 0.18", \

"0.05, 0.15", "0.24, 0.07", "0.17, 0.32");

}

propagated_noise_width_above_high(my_propagated_noise) {

values ("0.01, 0.10", "0.15, 0.04", "0.14, 0.18", \

"0.05, 0.15", "0.24, 0.07", "0.17, 0.32");

}

propagated_noise_height_above_high(my_propagated_noise) {

values ("0.01, 0.10", "0.15, 0.04", "0.14, 0.18", \

"0.05, 0.15", "0.24, 0.07", "0.17, 0.32");

}

propagated_noise_width_below_low(my_propagated_noise) {

values ("0.01, 0.10", "0.15, 0.04", "0.14, 0.18", \

"0.05, 0.15", "0.24, 0.07", "0.17, 0.32");

}

propagated_noise_height_below_low(my_propagated_noise) {

values ("0.01, 0.10", "0.15, 0.04", "0.14, 0.18", \

"0.05, 0.15", "0.24, 0.07", "0.17, 0.32");

} /*end propagated noise groups */

} /* end of timing group */

Liberty User Guide Volume 1

R-2020.09

637

Chapter 12: Nonlinear Signal Integrity Modeling

Examples of Modeling Noise

} /* end of pin (Y)( */

} /* end of cell (INV) */

} /* end of library (my_noise_lib)

Liberty User Guide Volume 1

R-2020.09

638

Composite Current Source Signal Integrity

Modeling

This chapter provides an overview of composite current source (CCS) modeling to support

noise (signal integrity) modeling for advanced technologies.

This chapter includes the following sections:

• CCS Signal Integrity Modeling Overview

• CCS Noise Modeling for Unbuffered Cells With a Pass Gate

• CCS Noise Modeling for Multivoltage Designs

• Referenced CCS Noise Modeling

CCS Signal Integrity Modeling Overview

CCS noise modeling can capture essential noise properties of digital circuits using a

compact library representation. It enables fast and accurate gate-level noise analysis

while maintaining a relatively simple library characterization. CCS noise modeling supports

noise combination and driver weakening.

CCS noise is characterization data that provides information for noise failure detection on

cell inputs, calculation of noise bumps on cell outputs, and noise propagation through the

cell. For the best accuracy, you must add CCS timing data to the library in addition to the

CCS noise data. The CCS noise data includes the following:

•

Channel-connected block parameters

•

DC current tables

• Timing tables for rising and falling transitions

•

Timing tables for low and high propagated noise

CCS Signal Integrity Modeling Syntax

library (name) {

...

Liberty User Guide Volume 1

R-2020.09

639

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

lu_table_template(dc_template_name) {

variable_1 : input_voltage;

variable_2 : output_voltage;

}

lu_table_template(output_voltage_template_name) {

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

variable_3 : time;

}

lu_table_template(propagated_noise_template_name) {

variable_1 : input_noise_height;

variable_2 : input_noise_width;

variable_3 : total_output_net_capacitance;

variable_4 : time;

}

cell (name) {

pin (name) {

...

ccsn_first_stage () {

is_needed : true | false;

is_inverting : Boolean;

stage_type : stage_type_value;

miller_cap_rise : float;

miller_cap_fall : float;

output_signal_level : power_supply_name;

related_ccb_node : spice_node_name;

dc_current (dc_current_template) {

index_1("float, ...");

index_2("float, ...");

values("float, ...");

}

output_voltage_rise ( )

vector (output_voltage_template_name) {

index_1(float);

index_2(float);

index_3("float, ...");

values("float, ...");

}

...

}

output_voltage_fall ( ) {

vector (output_voltage_template_name) {

index_1(float);

index_2(float);

index_3("float, ...");

values("float, ...");

}

...

}

propagated_noise_low ( ) {

vector (propagated_noise_template_name) {

index_1(float);

Liberty User Guide Volume 1

R-2020.09

640

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

index_2(float);

index_3(float);

index_4("float, ...");

values("float, ...");

}

...

}

propagated_noise_high ( ) {

vector (propagated_noise_template_name) {

index_1(float);

index_2(float);

index_3(float);

index_4("float, ...");

values("float, ...");

}

...

}

when : "Boolean expression";

} /* ccsn_first_stage */

ccsn_last_stage () {

is_needed : true | false;

is_inverting : Boolean;

stage_type : stage_type_value;

miller_cap_rise : float;

miller_cap_fall : float;

input_signal_level : power_supply_name;

related_ccb_node : spice_node_name;

dc_current (dc_current_template) {

index_1("float, ...");

index_2("float, ...");

values("float, ...");

}

output_voltage_rise ( ) {

vector (output_voltage_template_name) {

index_1(float);

index_2(float);

index_3("float, ...");

values("float, ...");

}

...

}

output_voltage_fall ( ) {

vector (output_voltage_template_name) {

index_1(float);

index_2(float);

index_3("float, ...");

values("float, ...");

}

...

}

propagated_noise_low ( ) {

vector (propagated_noise_template_name) {

index_1(float);

Liberty User Guide Volume 1

R-2020.09

641

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

index_2(float);

index_3(float);

index_4("float, ...");

values("float, ...");

}

...

}

propagated_noise_high ( ) {

vector (propagated_noise_template_name) {

index_1(float);

index_2(float);

index_3(float);

index_4("float, ...");

values("float, ...");

}

...

}

when : "Boolean expression";

} /* ccsn_last_stage */

...

timing() {

...

ccsn_first_stage () {

is_needed : true | false;

is_inverting : Boolean;

stage_type : stage_type_value;

miller_cap_rise : float;

miller_cap_fall : float;

output_signal_level : power_supply_name;

related_ccb_node : spice_node_name;

dc_current (dc_current_template) {

index_1("float, ...");

index_2("float, ...");

values("float, ...");

}

output_voltage_rise ( ) {

vector (output_voltage_template_name) {

index_1(float);

index_2(float);

index_3("float, ...");

values("float, ...");

}

...

}

output_voltage_fall ( ) {

vector (output_voltage_template_name) {

index_1(float);

index_2(float);

index_3("float, ...");

values("float, ...");

}

...

Liberty User Guide Volume 1

R-2020.09

642

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

}

propagated_noise_low ( ) {

vector (propagated_noise_template_name) {

index_1(float);

index_2(float);

index_3(float);

index_4("float, ...");

values("float, ...");

}

...

}

propagated_noise_high ( ) {

vector (propagated_noise_template_name) {

index_1(float);

index_2(float);

index_3(float);

index_4("float, ...");

values("float, ...");

}

...

}

when : "Boolean expression";

} /* ccsn_first_stage */

ccsn_last_stage () {

is_needed : true | false;

is_inverting : Boolean;

stage_type : stage_type_value;

miller_cap_rise : float;

miller_cap_fall : float;

input_signal_level : power_supply_name;

related_ccb_node : spice_node_name;

dc_current (dc_current_template)

index_1("float, ...");

index_2("float, ...");

values("float, ...");

}

output_voltage_rise ( )

vector (output_voltage_template_name) {

index_1(float);

index_2(float);

index_3("float, ...");

values("float, ...");

}

...

}

output_voltage_fall ( ) {

vector (output_voltage_template_name) {

index_1(float);

index_2(float);

index_3("float, ...");

values("float, ...");

Liberty User Guide Volume 1

R-2020.09

643

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

}

...

}

propagated_noise_low ( ) {

vector (propagated_noise_template_name) {

index_1(float);

index_2(float);

index_3(float);

index_4("float, ...");

values("float, ...");

}

...

}

propagated_noise_high ( ) {

vector (propagated_noise_template_name) {

index_1(float);

index_2(float);

index_3(float);

index_4("float, ...");

values("float, ...");

}

...

}

when : "Boolean expression";

} /* ccsn_last_stage */

} /* end timing/pin/cell/library group */

Library-Level Groups and Attributes

This section describes the library-level groups and attributes used for CCS noise

modeling.

lu_table_template Group

The lu_table_template group creates the lookup-table template for the dc_current

group and vectors for the output_voltage_rise, output_voltage_fall,

propagated_noise_high, and propagated_noise_low groups.

variable_1, variable_2, variable_3, and variable_4 Attributes

Set the variable_1, variable_2, variable_3, and variable_4 attributes inside the

lu_table_template group.

Liberty User Guide Volume 1

R-2020.09

644

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

You can specify the template used for the following tables and vectors by using a

combination of these attributes:

•

The output_current_rise and output_current_fall group vectors

Valid values for variable_1, variable_2, and variable_3 are

input_net_transition, total_output_net_capacitance, and time, respectively.

•

The propagated_noise_low and propagated_noise_high group vectors

Valid values for variable_1, variable_2, variable_3, and variable_4 are

input_noise_height, input_noise_width, total_output_net_capacitance, and

time, respectively.

•

The template used for the dc_current tables

Valid values for variable_1 and variable_2 are input_voltage and

output_voltage, respectively.

Pin-Level Groups and Attributes

This section describes the pin-level groups and attributes used for CCS noise modeling.

ccsn_first_stage and ccsn_last_stage Groups

The ccsn_first_stage and ccsn_last_stage groups specify CCS noise data for the

first stage or the last stage of channel-connected blocks. The ccsn_first_stage and

ccsn_last_stage groups can be defined inside timing or pin groups.

The ccsn_first_stage and ccsn_last_stage groups contain the following:

•

The is_needed, is_inverting, stage_type, miller_cap_rise and

miller_cap_fall, output_signal_level or input_signal_level, and the optional

related_ccb_node channel-connected block attributes

•

The dc_current group, which contains a two-dimensional DC current table

• The output_current_rise and output_current_fall groups, which contain two

timing tables for rising and falling transitions.

•

The propagated_noise_low and propagated_noise_high groups, which contain two

noise tables for low and high propagated noise.

Note:

At the pin level, the ccsn_last_stage group can be defined only in an output

pin or inout pin.

Liberty User Guide Volume 1

R-2020.09

645

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

is_needed Attribute

The is_needed Boolean attribute determines whether the dc_current,

output_current_rise, output_current_fall, propagated_noise_low, and

propagated_noise_high channel-connected block attributes should be specified

to include CCS noise data for a cell. The is_needed attribute is defined inside the

ccsn_first_stage and ccsn_last_stage groups.

By default, the is_needed attribute is set to true, which means that CCS noise data

is included in the ccsn_first_stage and ccsn_last_stage groups for the cell. The

is_needed attribute should be set to false for cells that do not need a current-based

driver model, such as diodes, antennas, and cload cells. When the attribute is set to

false, CCS noise data, enabled by the channel-connected block attributes, is not included

in the ccsn_first_stage and ccsn_last_stage groups.

is_inverting Attribute

The is_inverting attribute specifies whether the channel-connected block is inverting.

If the channel-connected block is inverting, set the is_inverting attribute to true.

Otherwise, set the attribute to false. This attribute is mandatory if the is_needed attribute

is set to true. Note that the is_inverting attribute is different from the “invertness”

or timing_sense of the timing arc, which might consist of multiple channel-connected

blocks.

stage_type Attribute

The stage_type attribute specifies the channel-connected block’s output voltage stage

type. The valid values are pull_up,which causes the channel-connected block’s output

voltage to be pulled up or to rise; pull_down, which causes the channel-connected block’s

output voltage to be pulled down or to fall; and both, which causes the channel-connected

block’s output voltage to be pulled up or down.

miller_cap_rise and miller_cap_fall Attributes

The miller_cap_rise and miller_cap_fall float attributes specify the Miller

capacitance value for a rising and falling channel-connected block output transition.

The value must be greater than or equal to zero. The attributes are defined inside the

ccsn_first_stage and ccsn_last_stage groups.

output_signal_level and input_signal_level Attributes

The output_signal_level and input_signal_level attributes specify the power

supply voltage names for a channel-connected block output and input, respectively. The

output_signal_level attribute is defined inside the ccsn_first_stage group and the

input_signal_level attribute is defined inside the ccsn_last_stage group.

Liberty User Guide Volume 1

R-2020.09

646

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

Note:

The output_signal_level and input_signal_level attribute specifications

within the ccsn_first_stage and ccsn_last_stage groups override the

output_signal_level and input_signal_level attribute specifications at the

pin level.

For a timing arc, the output_signal_level attribute specification within the

ccsn_first_stage group overrides the output_signal_level attribute

specification for the related pin (defined by the related_pin attribute).

related_ccb_node Attribute

The optional related_ccb_node attribute specifies the SPICE node in the subcircuit

netlist that is used for the dc_current table characterization and waveform

measurements.

dc_current Group

The dc_current group specifies the input and output voltage values of a two-dimensional

current table for a channel-connected block. Use the index_1 and index_2 attributes,

respectively, to list the input and output voltage values in library voltage units. Specify the

values attribute in the dc_current group to list the relative channel-connected block DC

current values, in library current units, that are measured at the channel-connected block

output node.

output_voltage_rise and output_voltage_fall Groups

The output_voltage_rise and output_voltage_fall groups specify vector groups

that describe three-dimensional output_voltage tables for a channel-connected block

whose output node’s voltage values are rising or falling. The groups are defined inside the

ccsn_first_stage and ccsn_last_stage groups.

Specify the following attributes in the vector group: The index_1 attribute lists the

input_net_transition (slew) values in library time units. The index_2 attribute lists the

total_output_net_capacitance (load) values in library capacitance units. The index_3

attribute lists the sampling time values in library time units. The values attribute lists the

voltage values, in library voltage units, that are measured at the channel-connected block

output node.

propagated_noise_high and propagated_noise_low Groups

The propagated_noise_low and propagated_noise_high groups use vector groups

to specify the three-dimensional output_voltage tables of the channel-connected block

whose output node’s voltage values are rising or falling. The groups are defined inside the

ccsn_first_stage and ccsn_last_stage groups.

Liberty User Guide Volume 1

R-2020.09

647

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

Specify the following attributes in the vector group: The index_1 attribute lists the

input_noise_height values in library voltage units. The index_2 attribute lists

the input_noise_width values in library time units. The index_3 attribute lists the

total_output_net_capacitance values in library capacitance units. The index_4

attribute lists the sampling time values in library time units. The values attribute lists the

voltage values, in library voltage units, that are measured at the channel-connected block

output node.

when Attribute

The when attribute specifies the condition under which the channel-connected block data is

applied. The attribute is defined in the ccsn_first_stage and ccsn_last_stage groups

both at the pin level and the timing level.

CCS Noise Library Examples

Example 128 CCS Noise Library Example

library (CCS_noise) {

technology ( cmos ) ;

delay_model : table_lookup;

time_unit : "1ps" ;

leakage_power_unit : "1pW" ;

voltage_unit : "1V" ;

current_unit : "1uA" ;

pulling_resistance_unit : "1kohm" ;

capacitive_load_unit(1000.000,ff) ;

nom_voltage : 1.200;

nom_temperature : 25.000;

nom_process : 1.000;

operating_conditions("OC1") {

process : 1.000;

temperature : 25.000;

voltage : 1.200;

tree_type : "balanced_tree";

}

default_operating_conditions:OC1;

lu_table_template(del_0_5_7_t) {

variable_1 : input_net_transition;

index_1("10.000, 175.000, 455.000, 980.000, 2100.000");

variable_2 : total_output_net_capacitance;

index_2("0.000000, 0.004000, 0.007000, 0.019000, 0.040000, 0.075000,\

0.175000");

}

lu_table_template(ccsn_dc_29x29) {

variable_1 : input_voltage;

variable_2 : output_voltage;

}

lu_table_template(ccsn_timing_lut_5) {

Liberty User Guide Volume 1

R-2020.09

648

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

variable_3 : time;

}

lu_table_template(ccsn_prop_lut_5) {

variable_1 : input_noise_height;

variable_2 : input_noise_width;

variable_3 : total_output_net_capacitance;

variable_4 : time;

}

lu_table_template(lu_table_template7x9) {

variable_1 : input_net_transition;

variable_2 : voltage;

}

cell(inv) {

area : 0.75;

pin(I) {

direction : input;

max_transition : 2100.0;

capacitance : 0.002000;

fanout_load : 1;

}

pin(Z) {

direction : output;

max_capacitance : 0.175000;

max_fanout : 58;

max_transition : 1400.0;

function : "(I)’";

timing() {

related_pin : "I";

timing_sense : negative_unate;

...

ccsn_first_stage ( ) {

is_needed : true;

is_inverting : true;

stage_type : both;

miller_cap_rise : 0.00055;

miller_cap_fall : 0.00084;

dc_current (ccsn_dc_29x29) {

index_1 ("-1.200, -0.600, -0.240, -0.120, 0.000, 0.060, 0.120,

0.180, \

0.240, 0.300, 0.360, 0.420, 0.480, 0.540, 0.600, 0.660,

0.720, 0.780, 0.840, 0.900, 0.960, 1.020, 1.080, 1.140,

1.200, 1.320, 1.440, 1.800, 2.400");

index_2 ("-1.200, -0.600, -0.240, -0.120, 0.000, 0.060, 0.120,

0.180, \

0.240, 0.300, 0.360, 0.420, 0.480, 0.540, 0.600, 0.660,

0.720, 0.780, 0.840, 0.900, 0.960, 1.020, 1.080, 1.140,

1.200, 1.320, 1.440, 1.800, 2.400");

values ("619.332000, 0.548416, 0.510134, 0.491965, 0.470368, \

...

-0.390604, -0.394495, -0.403571, -579.968000");

}

output_voltage_rise ( ) {

Liberty User Guide Volume 1

R-2020.09

649

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

vector (ccsn_timing_lut_5) {

index_1(175.000);

index_2(0.004000);

index_3 ("104.222, 127.996, 144.729, 159.367, 176.983");

values ("1.080, 0.840, 0.600, 0.360, 0.120");

}

...

}

output_voltage_fall ( ) {

vector (ccsn_timing_lut_5) {

index_1(175.000);

index_2(0.004000);

index_3 ("104.222, 127.996, 144.729, 159.367, 176.983");

values ("1.080, 0.840, 0.600, 0.360, 0.120");

}

...

}

propagated_noise_low ( ) {

vector (ccsn_prop_lut_5) {

index_1(0.6000);

index_2(1365.00);

index_3(0.004000);

index_4 ("640.90, 679.55, 711.76, 755.45, 793.68");

values ("0.0553, 0.0884, 0.1105, 0.0884, 0.0553");

}

...

vector (ccsn_prop_lut_5) {

index_1(0.6500);

index_2(2730.00);

index_3(0.019000);

index_4 ("1298.73, 1379.15, 1484.78, 1599.75, 1687.38");

values ("0.0927, 0.1483, 0.1854, 0.1483, 0.0927");

}

propagated_noise_high ( ) {

vector (ccsn_prop_lut_5) {

index_1(0.6000);

index_2(1365.00);

index_3(0.004000);

index_4 ("648.77, 688.99, 741.96, 793.08, 833.85");

values ("1.0592, 0.9748, 0.9184, 0.9748, 1.0592");

}

...

vector (ccsn_prop_lut_5) {

index_1(0.6500);

index_2(2730.00);

index_3(0.019000);

index_4 ("1307.15, 1404.92, 1561.13, 1709.43, 1814.30");

values ("1.0028, 0.8844, 0.8055, 0.8844, 1.0028");

}

} /* ccsn_first_stage */

} /* timing I -> Z */

} /* Z */

} /* cell(inv) */

Liberty User Guide Volume 1

R-2020.09

650

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

} /* library *

The following Liberty snippet shows the use of the optional related_ccb_node attribute in

pin-based ccsn_first_stage and ccsn_last_stage groups.

Example 129 Using related_ccb_node Attribute in Pin-Based CCS Noise Models

cell("A") {

...

pin(CK) {

direction : "input" ;

...

ccsn_first_stage() {

related_ccb_node : "ckn:711" ;

...

}

pin(EN) {

direction : "input" ;

...

ccsn_first_stage() {

...

}

pin(Q) {

direction : "output" ;

...

ccsn_last_stage() {

related_ccb_node : "i3:1623" ;

...

}

...

}

In the following Liberty snippet of a 2-input AND gate, the related_ccb_node attribute of

the ccsn_first_stage and ccsn_last_stage groups are specified for the A→Y timing

arc.

Example 130 Using related_ccb_node Attribute in Timing Arcs

cell (AND2) {

...

pin (A) {

...

}

pin (B) {

...

}

pin (Y) {

...

timing () {

...

related_pin :A;

ccsn_first_stage() {

related_ccb_node : "net1:15";

...

}

ccsn_last_stage() {

Liberty User Guide Volume 1

R-2020.09

651

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

related_ccb_node : "net1:15";

...

}

...

}

Conditional Data Modeling in CCS Noise Models

The following attributes support conditional data modeling in pin-based CCS noise models:

•

The when attribute in the ccsn_first_stage and ccsn_last_stage groups.

•

The mode attribute.

The following syntax shows the when and mode support for pin-based CCS noise models:

cell(cell_name) {

mode_definition (mode_name) {

mode_value(namestring) {

when : "Boolean expression";

sdf_cond : "Boolean expression";

} ...

pin(pin_name) {

direction : input;

/* The following syntax supports pin-based ccs noise */

/* ccs noise first stage for Condition 1 */

ccsn_first_stage() {

is_needed :true | false;

when : "Boolean expression";

mode (mode_name, mode_value);

...

}

...

/* ccs noise first stage for Condition n */

ccsn_first_stage() {

is_needed :true | false;

when : "Boolean expression";

mode (mode_name, mode_value);

...

}

pin(pin_name) {

direction : output;

/* ccs noise last stage for Condition 1 */

ccsn_last_stage() {

is_needed : true | false;

when : "Boolean expression";

mode (mode_name, mode_value);

...

}

...

Liberty User Guide Volume 1

R-2020.09

652

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

/* ccs noise last stage for Condition n */

ccsn_last_stage() {

is_needed : true | false;

when : "Boolean expression";

mode (mode_name, mode_value);

...

}

timing() {

...

/* following are arc-based ccs noise */

ccsn_first_stage() {

is_needed : true | false;

...

}

...

ccsn_last_stage() {

is_needed : true | false;

...

}

when Attribute

The when attribute is a conditional attribute that is supported in pin-based CCS noise

models in the ccsn_first_stage and ccsn_last_stage groups.

mode Attribute

The pin-based mode attribute is provided in the ccsn_first_stage and ccsn_last_stage

groups for conditional data modeling. If the mode attribute is specified, mode_name and

mode_value must be predefined in the mode_definition group at the cell level.

Example

library (csm13os120_typ) {

technology ( cmos ) ;

delay_model : table_lookup;

lu_table_template(ccsn_dc_29x29) {

variable_1 : input_voltage;

variable_2 : output_voltage;

}

cell(inv0d0) {

area : 0.75;

mode_definition(rw) {

mode_value(read) {

when : "I";

sdf_cond : "I == 1";

}

mode_value(write) {

when : "!I";

Liberty User Guide Volume 1

R-2020.09

653

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Signal Integrity Modeling Overview

sdf_cond : "I == 0";

}

pin(I) {

direction : input;

max_transition : 2100.0;

capacitance : 0.002000;

fanout_load : 1;

...

}

pin(ZN) {

direction : output;

max_capacitance : 0.175000;

max_fanout : 58;

max_transition : 1400.0;

function : "(I)";

/* pin-based CCS noise first stage for Condition 1 */

ccsn_first_stage () {

...

when : "I"; /* or using mode as next commented line */

/* mode(rw, read); */

dc_current (ccsn_dc_29x29) { ... }

output_voltage_rise ( ) { ... }

output_voltage_fall ( ) { ... }

propagated_noise_low ( ) { ... }

propagated_noise_high ( ) { ... }

} /* ccsn_last_stage */

/* pin-based CCS noise last stage for Condition 2 */

ccsn_last_stage () {

…

when : "!I"; /* or using mode as next commented line */

/* mode(rw, read); */

dc_current (ccsn_dc_29x29) { ... }

output_voltage_rise ( ) { ... }

output_voltage_fall ( ) { ... }

propagated_noise_low ( ) { ... }

propagated_noise_high ( ) { ... }

} /* ccsn_last_stage */

timing() {

related_pin : "I";

timing_sense : negative_unate;

...

} /* timing I -> Z */

} /* Z */

} /* cell(inv0d0) */

} /* library */

Liberty User Guide Volume 1

R-2020.09

654

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Noise Modeling for Unbuffered Cells With a Pass Gate

Unbuffered input and output latches are a special type of cell that has an internal memory

node connected to an input or output pin. To increase the speed of the design and lower

power consumption, these cells do not use inverters.

The major difference between an unbuffered output cell and an unbuffered input cell is as

follows:

•

Unbuffered Output Cell

An unbuffered output cell has the feedback, or back-driving path, from the unbuffered

output pin to an internal node. In Figure 111, Q is connected to internal node D_1

through the IR inverter.

Figure 111 Unbuffered Output Latch

•

Unbuffered Input Cell

The input pin of an unbuffered cell is not buffered and can be connected through a

pass gate to the internal node. (A pass gate is a special gate that has an input and an

output and a control input. If the control is set to true, the output is driven by the input.

Otherwise, it is a floating output.) For example, in Figure 112, D is connected to internal

node D_1 through a pass gate.

Liberty User Guide Volume 1

R-2020.09

655

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Noise Modeling for Unbuffered Cells With a Pass Gate

Figure 112 Unbuffered Input Latch

To correctly model this category of cells, you must determine:

•

If a pin is buffered or unbuffered.

• If a pin is implemented with a pass gate.

•

If the ccsn_*_stage information models a pass gate.

Syntax for Unbuffered Output Latches

/* unbuffered output pin */

pin (pin_name) {

direction : inout | output;

is_unbuffered : true | false ;

has_pass_gate : true | false ;

ccsn_first_stage () {

is_pass_gate : true | false;

...

}

...

ccsn_last_stage () {

is_pass_gate : true | false;

...

}

...

timing() {

ccsn_first_stage () {

is_pass_gate : true | false;

...

}

...

ccsn_last_stage () {

is_pass_gate : true | false;

...

}

...

}

Liberty User Guide Volume 1

R-2020.09

656

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Noise Modeling for Unbuffered Cells With a Pass Gate

}

pin (pin_name) {

direction : input | inout;

is_unbuffered : true | false ;

has_pass_gate : true | false ;

ccsn_first_stage () {

is_pass_gate : true | false;

...

}

...

ccsn_last_stage () {

is_pass_gate : true | false;

...

}

...

timing() {

ccsn_first_stage () {

is_pass_gate : true | false;

...

}

...

ccsn_last_stage () {

is_pass_gate : true | false;

...

}

...

}

Pin-Level Attributes

The following attributes are pin-level attributes for unbuffered output latches.

is_unbuffered Attribute

The is_unbuffered simple Boolean attribute indicates that a pin is unbuffered. This

optional attribute can be specified on the pins of any library cell. The default is false.

has_pass_gate Attribute

The has_pass_gate simple Boolean attribute can be defined in a pin group to indicate

whether the pin is internally connected to at least one pass gate.

ccsn_first_stage Group

The ccsn_first_stage group specifies CCS noise for the first stage of the channel-

connected block (CCB). When the ccsn_first_stage group is defined at the pin level, it

can only be defined in an input pin or an inout pin.

Liberty User Guide Volume 1

R-2020.09

657

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Noise Modeling for Multivoltage Designs

The ccsn_first_stage group syntax models back-driving CCS noise propagation

information from the output pin to the internal node.

is_pass_gate Attribute

The is_pass_gate Boolean attribute is defined in a ccsn_*_stage group (such as

ccsn_first_stage) to indicate whether the ccsn_*_stage information is modeled for a

pass gate. The attribute is optional and its default is false.

CCS Noise Modeling for Multivoltage Designs

In multivoltage designs, a complex macro cell can have multiple power domains with

different power supplies internal to the cell. The internal power supplies that provide

power to some of the inputs and outputs of the channel-connected blocks (CCBs), cannot

be modeled at the pin level. Therefore, pin-level attributes do not correctly describe the

operation of the CCS noise stages for these channel-connected blocks. To correctly model

the CCS noise stages, specify the internal power supplies in the ccsn_first_stage and

ccsn_last_stage groups that are specified within the pin or timing groups.

Figure 113 shows a macro cell with three power domains, PD1, PD2, and PD3. The input

pin, IN, is connected to the channel-connected blocks (not shown in the figure) for two

CCS noise stages in PD1 and PD2. The outputs of the channel-connected blocks go to

PD3. The CCS noise stage for the output pin, Y, is in PD1 and is driven by an internal

stage in PD3. The example in Figure 113 shows that the channel-connected block inputs

or outputs for the CCS stages do not always map to a pin.

Figure 113 A Complex Macro Cell With Multiple Power Domains

Liberty User Guide Volume 1

R-2020.09

658

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Noise Modeling for Multivoltage Designs

To model such CCS noise stages, use the output_signal_level and the

input_signal_level attributes respectively within the ccsn_first_stage and

ccsn_last_stage groups, as shown in Example 131.

Example 131 Pin and Timing Based CCS Noise Model of Low-to-High Level-Shifter Cells

library (test) {

technology(cmos);

nom_voltage : 1.080000;

voltage_unit : "1V";

voltage_map(VDD1,1.080000);

voltage_map(GND1,0.000000);

voltage_map(VDD2,0.900000);

...

cell (LVL_SHIFT_L2H_1) {

is_level_shifter : true;

level_shifter_type : LH;

input_voltage_range(0.900000,1.320000);

output_voltage_range(0.900000,1.320000);

pg_pin (VDD) {

voltage_name : VDD1;

...

}

pg_in (VDDL) {

voltage_name : VDD2;

...

}

pin (I) {

direction : input;

level_shifter_data_pin : true;

related_ground_pin : VSS;

related_power_pin : VDDL;

ccsn_first_stage () {/* pin-based model */

is_needed : true;

stage_type : both;

...

output_signal_level : VDD1;

/* Specifies that the power supply to the ccsn_first_stage output

is VDD1. The power supply to the ccsn_first_stage input is

specified at the pin level by the related_power_pin attribute

as VDDL. */

dc_current (ccsn_dc)...

}

pin (Z) {

direction : output;

power_down_function : "!VDD + !VDDL + VSS";

function : "I";

related_ground_pin : VSS;

related_power_pin : VDD;

...

ccsn_last_stage () { /* pin-based model */

Liberty User Guide Volume 1

R-2020.09

659

Chapter 13: Composite Current Source Signal Integrity Modeling

CCS Noise Modeling for Multivoltage Designs

is_needed : "true";

stage_type : "both";

...

input_signal_level : VDD2;

/* Specifies that the power supply to the ccsn_last_stage input

is VDD2. The power supply to the ccsn_last_stage output is

specified at the pin level by the related_power_pin attribute

as VDD. */

dc_current (ccsn_dc)...

}

...

}

cell (LVL_SHIFT_L2H_2) {

is_level_shifter : true;

level_shifter_type : LH;

input_voltage_range(0.900000,1.320000);

output_voltage_range(0.900000,1.320000);

pg_pin (VDD) {

voltage_name : VDD1;

...

}

pg_in (VDDL) {

voltage_name : VDD2;

...

}

pin (I) {

direction : input;

level_shifter_data_pin : true;

related_ground_pin : VSS;

related_power_pin : VDDL;

}

pin (Z) {

direction : output;

power_down_function : "!VDD + !VDDL + VSS";

function : "I";

related_ground_pin : VSS;

related_power_pin : VDD;

...

timing() {

related_pin : I;

...

ccsn_first_stage () {/* arc-based model */

is_needed : true;

stage_type : both;

...

output_signal_level : VDD1;

dc_current (ccsn_dc)...

}

ccsn_last_stage () {/* arc-based model */

is_needed : "true";

stage_type : "both";

...

Liberty User Guide Volume 1

R-2020.09

660

Chapter 13: Composite Current Source Signal Integrity Modeling

Referenced CCS Noise Modeling

input_signal_level : VDD1;

dc_current (ccsn_dc)...

}

...

}

...

}

...

}

Referenced CCS Noise Modeling

For CCS noise characterization, a circuit is partitioned into channel-connected blocks

(CCBs). An input pin might simultaneously drive multiple channel-connected blocks

(CCBs).

For different input states and capacitive loads, you can represent each channel-connected

block using multiple input_ccb and output_ccb groups. The input_ccb and output_ccb

groups have names and are defined in pin groups.

In each timing arc, you can use these names to reference the input_ccb or output_ccb

groups that

•

Contribute to the noise but do not propagate the noise in the timing arc; this also

applies to pin-level receiver_capacitance groups

•

Propagate the noise in the timing arc

Because you define the input_ccb and output_ccb groups only in the pin groups,

this model eliminates multiple definitions of the same channel-connected block noise in

different timing groups, such as for a ccsn_last_stage group representing an inverter in

a conventional two-stage CCS noise model.

To better model noise, the input_ccb and output_ccb groups include the

output_voltage_rise and output_voltage_fall groups. The output_voltage_rise

and output_voltage_fall values are characterized with driver waveforms instead of

ramp waveforms as in the conventional two-stage CCS noise model.

For more information about the conventional two-stage CCS noise model, see CCS Signal

Integrity Modeling Syntax on page 639.

Modeling Syntax

library (library_name) {

cell (cell_name) {

driver_waveform : "waveform_name";

driver_waveform_rise : "waveform_name";

Liberty User Guide Volume 1

R-2020.09

661

Chapter 13: Composite Current Source Signal Integrity Modeling

Referenced CCS Noise Modeling

driver_waveform_fall "waveform_name";

...

pin (pin_name) {

direction : input;

...

input_ccb (input_ccb_name1) {

when : logical_expression;

mode(mode_name, mode_value);

related_ccb_node : "spice_node_name1";

output_voltage_rise {

...

}

...

}

input_ccb (input_ccb_name2) {

when : logical_expression

mode(mode_name, mode_value);

related_ccb_node : "spice_node_name2";

output_voltage_rise {

...

}

...

}

...

receiver_capacitance (lu_template) {

when : logical_expression;

mode(mode_name, mode_value);

active_input_ccb(input_ccb_name1, input_ccb_name2,...]);

} /* end receiver_capacitance group */

} /* end pin a group */

pin (pin_name) {

direction : output;

...

output_ccb(output_ccb_name1) {

when : logical_expression;

mode(mode_name, mode_value);

related_ccb_node : "spice_node_name3";

}

timing() {/* Arc has propagating noise (full arc-based) */

...

active_input_ccb(input_ccb_name1, input_ccb_name2, ...);

propagating_ccb(input_ccb_name2, output_ccb_name);

}

timing() { /* Arc has no propagating noise because it involves

three inverting stages)*/

...

active_input_ccb(input_ccb_name1, input_ccb_name2);

active_output_ccb(output_ccb_name);

}

} /* end pin group */

} /* end cell group */

} /* end library group */

Liberty User Guide Volume 1

R-2020.09

662

Chapter 13: Composite Current Source Signal Integrity Modeling

Referenced CCS Noise Modeling

Cell-Level Attributes

This section describes the optional cell-level attributes specific to the referenced CCS

noise model.

driver_waveform Attribute

The driver_waveform attribute specifies a cell-specific driver waveform. The specified

driver waveform must be a predefined driver_waveform_name attribute value in the

library-level normalized_driver_waveform group table.

driver_waveform_rise and driver_waveform_fall Attributes

The driver_waveform_rise and driver_waveform_fall specify the rise and fall driver

waveforms. These attributes override the driver_waveform attribute.

For more information about driver waveform modeling syntax, see Driver Waveform

Support on page 282.

Pin-Level Groups

This section describes the pin-level groups and attributes specific to the referenced CCS

noise model.

input_ccb and output_ccb Groups

The input_ccb and output_ccb groups include all the attributes and subgroups of the

ccsn_first_stage and ccsn_last_stage groups respectively.

Except for pins where the input_ccb and output_ccb groups are not required, you must

name all these groups so that they can be referenced. For the exceptions, you must set

the is_needed attribute to false in the input_ccb and output_ccb groups.

The name includes the pin identifier and the group identifier. The pin identifier is the

same in all the input_ccb and output_ccb groups of the pin. The pin identifier enables

homogeneous treatment of these groups in buses and bundles.

For example, in the input_ccb("CCB_D1"){...} group, the CCB_D part of the name

indicates that the channel-connected block group belongs to pin D and 1 indicates that this

is the first input_ccb group of pin D.

Note:

The library characterization tools can use an additional cell identifier in the

input_ccb and output_ccb group names.

Liberty User Guide Volume 1

R-2020.09

663

Chapter 13: Composite Current Source Signal Integrity Modeling

Referenced CCS Noise Modeling

Conditional Data Modeling

Use the mode and when attributes in the input_ccb and output_ccb groups for

conditional data modeling.

related_ccb_node Attribute

The optional related_ccb_node attribute specifies the SPICE node in the subcircuit

netlist that is used for the dc_current table characterization. The attribute is defined in the

input_ccb group of an input pin and the output_ccb group of an output pin.

output_voltage_rise and output_voltage_fall Groups

The output_voltage_rise and output_voltage_fall groups have the following

differences from those in the CCS noise stage groups.

•

The output waveform specified by the index_3 and values attributes is

characterized using a driver waveform and not a ramp waveform. So, the index_1

or input_net_transition is a slew value based on slew trip points and library slew

derate and not a rail-to-rail ramp transition time.

•

The index_1 (input_net_transition) values must match one of the index_1 values

of the driver waveform specified at the cell-level.

•

The index_2 (total_output_net_capacitance) values must match one of the

index_2 values of the cell_rise and cell_fall groups.

•

The values at index_1 and index_2 of all the output_voltage_rise or

output_voltage_fall groups in an input_ccb or output_ccb group must form a grid

without duplicated or missing points.

For an input_ccb group that does not directly drive an output pin, the number of

output_voltage_rise groups must be M x 1. For an output_ccb or an input_ccb

that directly drives an output pin, the number of groups must be M x N.

M is the number of index_1 values and N is the number of index_2 values.

Note:

For libraries with 7 x 7 or 8 x 8 nonlinear delay model (NLDM) tables, both M

and N can be 4.

Timing-Level Attributes

This section describes the timing-level attributes specific to the referenced CCS noise

model.

Liberty User Guide Volume 1

R-2020.09

664

Chapter 13: Composite Current Source Signal Integrity Modeling

Referenced CCS Noise Modeling

active_input_ccb Attribute

The active_input_ccb attribute lists the input_ccb groups of the input pin that

are active or switching in the timing arc or the receiver capacitance load but do not

propagate the noise to the output pin. In the timing group, the input pin is specified by the

related_pin attribute.

You can also specify this attribute in the receiver_capacitance group of the input pin.

active_output_ccb Attribute

The active_output_ccb attribute lists the output_ccb groups in the timing arc that drive

the output pin, but do not propagate the noise. You must define both the output_ccb and

timing groups in the same pin group.

propagating_ccb Attribute

The propagating_ccb attribute lists all the channel-connected block groups that

propagate the noise in a particular timing arc, to the output pin.

In the list, the first name is the input_ccb group of the input pin (specified by the

related_pin attribute in the timing group). The second name, if present, is for the

output_ccb group of the output pin.

Note:

You can list at most two names. This attribute does not support timing

arcs with three or more inverting stages. For such cases and complex

circuits with converging paths, reference the input_ccb group name in

the active_input_ccb attribute and the output_ccb group name in the

active_output_ccb attribute.

Examples

The following example shows a simple noise model with two timing arcs sharing the same

output channel-connected block.

cell (AND2) {

...

pin (A) {

...

input_ccb("CCB_A") {

related_ccb_node : "net1:15";

...

}

pin (B) {

...

input_ccb("CCB_B") {

Liberty User Guide Volume 1

R-2020.09

665

Chapter 13: Composite Current Source Signal Integrity Modeling

Referenced CCS Noise Modeling

related_ccb_node : "net1:15";

...

}

input_ccb("CCB_CP2") {

related_ccb_node : "net3:3";

...

}

pin (Y) {

...

output_ccb("CCB_Y") {

related_ccb_node : "net1:15";

...

}

timing () {

related_pin : A;

propagating_ccb("CCB_A", "CCB_Y");

}

timing () {

related_pin : B;

propagating_ccb("CCB_B", "CCB_Y");

}

...

}

The following figure is a schematic with the input, A, driving three logic gates. The relevant

channel-connected blocks are shown.

Liberty User Guide Volume 1

R-2020.09

666

Chapter 13: Composite Current Source Signal Integrity Modeling

Referenced CCS Noise Modeling

Figure 114 A Schematic With Multiple Active Channel-Connected Blocks

The following table shows which of the four active channel-connected blocks propagate

the noise in the A→Z timing arc.

Active channel-connected

block

Propagates noise in

A→Z arc?

A_NOT1 No

A_NOT2 No

A_NAND1 Yes

Z_INV Yes

The following example shows how the blocks are referenced in the timing group.

pin(Z) {

direction : output;

timing () { /* A→Z arc */

related_pin : A;

...

active_input_ccb("A_NOT1", "A_NOT2");

propagating_ccb("A_NAND1", "Z_INV");

} /* end timing */

Liberty User Guide Volume 1

R-2020.09

667

Chapter 13: Composite Current Source Signal Integrity Modeling

Referenced CCS Noise Modeling

}

Liberty User Guide Volume 1

R-2020.09

668

Composite Current Source Power Modeling

This chapter provides an overview of composite current source (CCS) modeling to support

advanced technologies.

It covers the syntax for CCS power modeling in the following sections:

• Composite Current Source Power Modeling

• Compact CCS Power Modeling

• Composite Current Source Dynamic Power Examples

Composite Current Source Power Modeling

The library nonlinear power model format captures leakage power numbers in multiple

input combinations to generate a state-dependent table. It also captures dynamic power

of various input transition times and output load capacitance to create the state-dependent

and path-dependent internal energy data.

The composite current source (CCS) power modeling format extends current library

models to include current-based waveform data to provide a complete solution that

addresses static and dynamic power. It also addresses dynamic IR drop. The following are

features of this approach as compared to the nonlinear power model:

•

Creates a single unified power library format suitable for power optimization, power

analysis, and rail analysis.

•

Captures a supply current waveform for each power or ground pin.

• Provides finer time resolution.

•

Offers full multivoltage support.

•

Captures equivalent parasitic data to perform fast and accurate rail analysis.

• Reduces the characterization runtime.

Liberty User Guide Volume 1

R-2020.09

669

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

Cell Leakage Current

Because CCS power is current-based data, leakage current on the power and ground pins

is captured instead of leakage power as specified in the nonlinear power model format.

For information about gate leakage, see gate_leakage Group on page 671. The leakage

current syntax is as follows:

Example 132 Leakage Current Syntax

cell(cell_name) {

...

leakage_current() {

when : "Boolean expression";

pg_current(pg_pin_name) {

value : float;

}

...

leakage_current() { /* without the when statement */

/* default state */

...

}

Current conservation means that the sum of all current values must be zero. A positive

value means power pin current, and a negative value means ground pin current.

For multiple power and ground pins, you must use the regular format because it provides

pg_current, which allows you to specify the power and ground names. For example, if

you have two power pins, you must specify the value for each pin.

Again, a simplified format is allowed for a cell with a single power and ground pin. For this

case, no pg_current group is required within a leakage_current group.

Example 133 Leakage Current Format Simplified

cell(cell_name) {

...

leakage_current() { /* without pg_current group*/

when : "Boolean expression";

value : float;

}

leakage_current() { /* without the when statement */

/* default state */

...

}

Liberty User Guide Volume 1

R-2020.09

670

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

Gate Leakage Modeling in Leakage Current

The syntax for these power models is described in the following section.

Syntax

cell(cell_name) {

...

leakage_current() {

when : "Boolean expression";

pg_current(pg pin name) {

value : float;

}

...

gate_leakage(input pin name) {

input_low_value : float;

input_high_value : float;

}

...

}

...

leakage_current() {

/* group without when statement */

/* default state */

...

}

gate_leakage Group

This group specifies the cell’s gate leakage current on input or inout pins within the

leakage_current group in a cell. For information about cell leakage, see Cell Leakage

Current on page 670.

The following information pertains to a gate_leakage group:

•

Groups can be placed in any order if there are more than one gate_leakage groups

within a leakage_current group.

•

Leakage current of a cell is characterized with opened outputs, which means outputs

of a modeling cell do not drive any other cells. Outputs are assumed to have zero static

current during the measurement.

•

A missing gate_leakage group is allowed for certain pins.

•

Current conservation is applicable if it can be applied to higher error tolerance.

Liberty User Guide Volume 1

R-2020.09

671

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

input_low_value Attribute

This attribute specifies gate leakage current on an input or inout pin when the pin is in a

low state.

•

A negative float value is required.

•

The gate leakage current is measured from the power pin of the cell to the ground pin

of its driver cell.

• The input pin is pulled low.

•

The input_low_value attribute is not required for a gate_leakage group.

•

Defaults to 0 if no gate_leakage group is specified for certain pins.

• Defaults to 0 if no input_low_value attribute is specified in the gate_leakage group.

input_high_value Attribute

This attribute specifies gate leakage current on an input or inout pin when the pin is in a

high state.

•

A positive float value is required.

•

The gate leakage current is measured from the power pin of its driver cell to the ground

pin of the cell.

• The input pin is pulled high.

•

The input_high_value is not required for a gate_leakage group.

•

Defaults to 0 if no gate_leakage groups is specified for certain pins.

• Defaults to 0 if no input_high_value is specified in the gate_leakage group.

Intrinsic Parasitic Models

The intrinsic parasitic model syntax consists of two parts: intrinsic resistance and intrinsic

capacitance.

cell (cell_name) {

mode_definition (mode_name) {

mode_value(namestring) {

when : "Boolean expression";

sdf_cond : "Boolean expression";

}

...

intrinsic_parasitic() {

mode (mode_name, mode_value);

when : "Boolean expression";

Liberty User Guide Volume 1

R-2020.09

672

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

intrinsic_resistance(pg_pin_name) {

related_output : output_pin_name;

value : float;

}

intrinsic_capacitance(pg_pin_name) {

value : float;

}

intrinsic_parasitic() {

/*without when statement */

/* default state */

}

Example 134 Typical Intrinsic Parasitic Model Using Modes

library (csm13os120_typ) {

technology ( cmos ) ;

delay_model : table_lookup;

lu_table_template(ccsn_dc_29x29) {

variable_1 : input_voltage;

variable_2 : output_voltage;

}

cell(inv0d0) {

area : 0.75;

pg_pin(V1) {

voltage_name : VDD1;

pg_type : primary_power;

}

pg_pin(G1) {

voltage_name : GND1;

pg_type : primary_ground;

}

mode_definition(rw) {

mode_value(read) {

when : "A1";

sdf_cond : "A1 == 1";

}

mode_value(write) {

when : "!A1";

sdf_cond : "A1 == 0";

}

pin(A1) {

direction : input;

capacitance : 0.1 ;

related_power_pin : V1;

related_ground_pin : G1;

}

pin(A2) {

direction : input;

Liberty User Guide Volume 1

R-2020.09

673

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

capacitance : 0.1 ;

related_power_pin : V1;

related_ground_pin : G1;

}

pin(ZN) {

direction : output;

max_capacitance : 0.1;

function : "!A1+A2";

related_power_pin : V1;

related_ground_pin : G1;

timing() {

timing_sense : "negative_unate"

related_pin : "A1”;

...

}

pin(ZN1) {

direction : output;

max_capacitance : 0.1;

function : "!A1";

related_power_pin : V1;

related_ground_pin : G1;

timing() {

timing_sense : "negative_unate"

related_pin : "A1 A2”;

...

}

intrinsic_parasitic() {

mode(rw, read);

intrinsic_resistance(G1) {

related_output : "ZN";

value : 9.0;

}

intrinsic_capacitance(G1) {

value : 8.2;

}

} /* cell(inv0d0) */

} /* library

Voltage-Dependent Intrinsic Parasitic Models

Intrinsic parasitics are conventionally modeled as voltage-independent or steady-state

values. However, intrinsic parasitics are voltage-dependent. To better represent intrinsic

parasitics in a CCS power model, use a lookup table for intrinsic parasitics instead

of a single steady-state value. You can use the steady-state value when your design

requirements are not critical.

The lookup table is one-dimensional and consists of intrinsic parasitic values for different

values of VDD. You can selectively add these values to any intrinsic_resistance or

Liberty User Guide Volume 1

R-2020.09

674

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

intrinsic_capacitance subgroup. Use lookup tables when correct estimation of voltage

drops is critical, such as power-switch designs.

The following are the advantages of using lookup tables.

•

Accurate estimation of peak-inrush current and wake-up time

•

Optimal power-up and power-down sequencing

• Optimal power-switch design, that is, minimum number of used and placed power-

switch cells

Example 135 Syntax of Voltage-Dependent Intrinsic Parasitic Model With Lookup Tables

lu_table_template (template_name) {

variable_1 : pg_voltage | pg_voltage_difference ;

index_1 ( "float, ... float" );

}

cell (cell_name) {

...

intrinsic_parasitic() {

when : "Boolean expression";

intrinsic_resistance (pg_pin_name) {

related_output : output_pin_name;

value : float;

reference_pg_pin : pg_pin_name;

lut_values (template_name) {

index_1 ("float, ... float");

values ("float, ... float");

}

intrinsic_capacitance(pg_pin_name) {

value : float;

reference_pg_pin : pg_pin_name;

lut_values (template_name) {

index_1 ("float, ... float");

values ("float, ... float");

}

...

}

Example 136 Example of Voltage-Dependent Intrinsic Parasitic Model

library(example_library) {

......

lu_table_template ( test_voltage ) {

variable_1 : pg_voltage;

index_1 ( "0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0" );

}

cell (AND3) {

......

Liberty User Guide Volume 1

R-2020.09

675

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

intrinsic_parasitic() {

when : "A1 & A2 & ZN";

intrinsic_resistance(G1) {

related_output : "ZN";

value : 9.0;

reference_pg_pin : G1;

lut_values ( test_voltage ) {

index_1 ( "0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9,

1.0" );

values ( "0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9,

1.0" );

}

intrinsic_capacitance(G2) {

value : 8.2;

reference_pg_pin : G2;

lut_values ( test_voltage ) {

index_1 ( "0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9,

1.0" );

values ( "0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9,

1.0" );

}

intrinsic_resistance(G1) {

related_output : "ZN1";

value : 62.2;

}

intrinsic_parasitic() {

/* default state */

intrinsic_resistance(G1) {

related_output : "ZN";

value : 9.0;

reference_pg_pin : G1;

lut_values ( test_voltage ) {

index_1 ( "0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9,

1.0" );

values ( "0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9,

1.0" );

}

intrinsic_resistance(G1) {

related_output : "ZN1";

value : 9.0;

}

intrinsic_capacitance(G2) {

value : 8.2;

reference_pg_pin : G2;

lut_values ( test_voltage ) {

index_1 ( "0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9,

1.0" );

values ( "0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9,

1.0" );

Liberty User Guide Volume 1

R-2020.09

676

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

}

......

} /* end of cell AND3 */

}

Library-Level Group

The following library-level group models voltage-dependent intrinsic parasitics.

lu_table_template Group

This group defines the template for the lut_values group. The lu_table_template

group includes a one-dimensional variable, variable_1. The valid values of the

variable_1 variable are pg_voltage and pg_voltage_difference. When the

variable_1 variable is set to the pg_voltage value, the values of the intrinsic

capacitance or resistance directly vary with the power supply voltage of the cell. When

the variable_1 variable is set to the pg_voltage_difference value, the values of the

intrinsic capacitance or resistance vary with the difference between the power supply

voltage and the power pin voltage specified by the reference_pg_pin attribute.

Note:

The reference_pg_pin attribute specifies the reference pin for the

intrinsic_resistance and intrinsic_capacitance groups. The reference

pin must be a valid PG pin.

Pin-Level Group

The following pin-level group models voltage-dependency in intrinsic parasitics by using

lookup tables.

lut_values Group

To use the lookup table for intrinsic parasitics, use the lut_values group. You can add

the lut_values group to both the intrinsic_resistance and intrinsic_capacitance

groups. The lut_values group uses the variable_1 variable, which is defined within the

lu_table_template group, at the library level.

Parasitics Modeling in Macro Cells

For macro cells, the total_capacitance group is provided within the

intrinsic_parasitic group.

total_capacitance Group

The total_capacitance group specifies the macro cell’s total capacitance on a power or

ground net within the intrinsic_parasitic group.

Liberty User Guide Volume 1

R-2020.09

677

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

• This group can be placed in any order if there is more than one total_capacitance

group within an intrinsic_parasitic group.

• If the total_capacitance group is not defined for a certain power and ground pin, the

value of capacitance defaults to 0.0.

•

The parasitics modeling of the total capacitance in macros cells is not state dependent.

This means that there is no state condition specified in the intrinsic_parasitic

group.

Parasitics Modeling Syntax

cell (cell_name) {

power_cell_type : enum(stdcell, macro);

...

intrinsic_parasitic() {

total_capacitance(pg pin name) {

value : float;

}

...

}

...

}

Dynamic Power

Because CCS power is current-based data, instantaneous power data on the power or

ground pin is captured instead of internal energy specified in the nonlinear power model

format. The current-based data provides higher accuracy than the existing model.

In the CCS modeling format, instantaneous power data is specified as a table of current

waveforms. The table is dependent on the transition time of a toggling input and the

capacitance of the toggling outputs.

As the number of output pins increases in a cell, the number of waveform tables becomes

large. However, the cell with multiple output pins (more than one output) does not need

to be characterized for all possible output load combinations. Therefore, two types of

methods can be introduced to simplify the captured data.

•

Cross type - Only one output capacitance is swept, while all other output capacitances

are held in a typical value or fixed value.

•

Diagonal type - The capacitance to all the output pins is swept together by an identical

value.

A table that is modeled based on these two types is defined as a sparse table. Otherwise

it is defined as a dense table, meaning that all combinations of the output load variable are

specified in tables.

Liberty User Guide Volume 1

R-2020.09

678

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

Dynamic Power and Ground Current Table Syntax

You can use the following syntax for dynamic current:

pg_current_template(template_name_1) {

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

variable_3 : time;

index_1(float, ); /* optional */

index_2(float, ); /* optional */

index_3(float, ); /* optional */

}

pg_current_template(template_name_2) {

variable_1 : input_net_transition;

variable_2 : total_output_net_capacitance;

variable_3 : total_output_net_capacitance;

variable_4 : time;

index_1(float, ); /* optional */

index_2(float, ); /* optional */

index_3(float, ); /* optional */

index_4(float, ); /* optional */

}

Dynamic Power Modeling in Macro Cells

The extensions to CCS dynamic power format provides more accurate models for macro

cells. The current dynamic power model only supports current waveforms for single-input

events.

The model can also be applied to memory modeling with synchronous events, which are

triggered by toggling either a single read_enable or write_enable.

However, for asynchronous event, the read access can be triggered by more than one bit

of the address bus toggling. To support asynchronous memory access for macro cells, use

min_input_switching_count and max_input_switching_count, in dynamic power as

shown in the next section.

The following syntax for dynamic power format provides more accurate models for macro

cells:

...

cell(cell_name) {

mode_definition (mode_name) {

mode_value(namestring) {

when : "Boolean expression";

sdf_cond : "Boolean expression";

}

...

power_cell_type : enum(stdcell, macro)

dynamic_current() {

mode (mode_name, mode_value);

Liberty User Guide Volume 1

R-2020.09

679

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

when : "Boolean expression";

related_inputs : "input_pin_name";

switching_group() {

min_input_switching_count : integer;

max_input_switching_count : integer;

pg_current(pg_pin_name) {

vector(template_name) {

reference_time : float;

index_1(float);

index_2("float,...");

values("float,...");

} /* end vector group*/

...

} /end pg_current group */

...

} /* end switching_group */

...

} /* end dynamic_current group */

...

} /* end cell group*/

...

The min_input_switching_count and max_input_switching_count attributes

specify the number of bits in the input bus that are switching simultaneously while an

asynchronous event occurs. A single switching bit can be defined by setting the same

value in both attributes.

The following example shows that any three bits specified in related_inputs are

switching simultaneously.

...

min_input_switching_count : 3;

max_input_switching_count : 3;

...

A range of switching bits can be defined by setting the minimum and maximum value.

The following example shows that any 2, 3, 4 or 5 bits specified in related_inputs are

switching simultaneously.

...

min_input_switching_count : 2;

max_input_switching_count : 5;

...

min_input_switching_count Attribute

This attribute specifies the minimum number of bits in an input bus that are switching

simultaneously.

•

The count must be integer.

•

The count must greater than 0 and less than max_input_switching_count.

Liberty User Guide Volume 1

R-2020.09

680

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

max_input_switching_count Attribute

This attribute specifies the maximum number of bits in an input bus that are switching

simultaneously.

•

The count must be integer.

•

The count must greater than min_input_switching_count.

• The count must be less than the total number of bits listed in related_inputs.

Examples for CCS Dynamic Power for Macro Cells

...

pg_current_template ( CCS_power_1 ) {

variable_1 : input_net_transition ;

variable_2 : time;

}

type(bus3) {

base_type : array;

bit_width : 3;

...

}

...

cell ( example ) {

bus(addr_in) {

bus_type : bus3;

direction : input;

...

}

pin(data_in) {

direction : input;

…

}

...

power_cell_type : macro;

dynamic_current() {

when: “!WE”;

related_inputs : "addr_in";

switching_group ( ) {

min_input_switching_count : 1;

max_input_switching_count : 3;

pg_current (VSS) {

vector ( CCS_power_1 ) {

reference_time : 0.01;

index_1 ( "0.01" )

index_2 ( "4.6, 5.9, 6.2, 7.3")

values ( "0.002, 0.009, 0.134, 0.546")

}

...

vector ( CCS_power_1 ) {

reference_time : 0.01;

index_1 ( "0.03" )

Liberty User Guide Volume 1

R-2020.09

681

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

index_2 ( "2.4, 2.6, 2.9, 4.0" )

values ( "0.012, 0.109, 0.534, 0.746")

}

vector ( CCS_power_1 ) {

reference_time : 0.01;

index_1 ( "0.08" )

index_2 ( "1.0, 1.6, 1.8, 1.9" )

values ( "0.102, 0.209, 0.474, 0.992")

}

...

} /* pg_current */

...

} /* switching_group */

...

} /* dynamic_current */

...

intrinsic_parasitic() {

total_capacitance(VDD) {

value : 0.2;

}

...

} /* intrinsic_parasitic */

...

leakage_current() {

when : WE;

gate_leakage(data_in) {

input_low_value : -0.3;

input_high_value : 0.5;

}

...

} /* leakage_current */

...

} /* end of cell */

...

Conditional Data Modeling for Dynamic Current Example

library (csm13os120_typ) {

technology ( cmos ) ;

delay_model : table_lookup;

lu_table_template(ccsn_dc_29x29) {

variable_1 : input_voltage;

variable_2 : output_voltage;

}

cell(inv0d0) {

area : 0.75;

pg_pin(V1) {

voltage_name : VDD1;

pg_type : primary_power;

}

pg_pin(G1) {

Liberty User Guide Volume 1

R-2020.09

682

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

voltage_name : GND1;

pg_type : primary_ground;

}

mode_definition(rw) {

mode_value(read) {

when : "A1";

sdf_cond : "A1 == 1";

}

mode_value(write) {

when : "!A1";

sdf_cond : "A1 == 0";

}

power_cell_type : stdcell;

dynamic_current() { /* dense table */

mode(rw, read);

related_inputs : "A2";

related_outputs : "ZN ZN1";

switching_group() {

output_switching_condition(rise rise);

pg_current(V1) {

vector(test_1) {

reference_time : 23.7;

index_1("0.8");

index_2("0.7");

index_3("10.4");

index_4("8.2 8.5 9.1 9.4 9.8");

values("0.7 34.6 3.78 92.4 100.1");

}

...

}

pin(A1) {

direction : input;

capacitance : 0.1 ;

related_power_pin : V1;

related_ground_pin : G1;

}

pin(A2) {

direction : input;

capacitance : 0.1 ;

related_power_pin : V1;

related_ground_pin : G1;

}

pin(ZN) {

direction : output;

max_capacitance : 0.1;

function : "!A1+A2";

related_power_pin : V1;

related_ground_pin : G1;

timing() {

timing_sense : "negative_unate"

Liberty User Guide Volume 1

R-2020.09

683

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Power Modeling

related_pin : "A1”;

…

}

pin(ZN1) {

direction : output;

max_capacitance : 0.1;

function : "!A1";

related_power_pin : V1;

related_ground_pin : G1;

timing() {

timing_sense : "negative_unate"

related_pin : "A1 A2”;

…

}

} /* cell(inv0d0) */

} /* library

Dynamic Current Syntax

The syntax in Example 137 is used for instantaneous power data, which is captured at the

cell level.

Example 137 Dynamic Current Syntax

cell(cell_name) {

power_cell_type : enum(stdcell, macro)

dynamic_current() {

when : "Boolean expression";

related_inputs : input_pin_name;

related_outputs : output_pin_name;

typical_capacitances(float, );/* applied for cross type;/*

switching_group() {

input_switching_condition(enum(rise, fall));

output_switching_condition(enum(rise, fall));

pg_current(pg_pin_name) {

vector(template_name) {

reference_time : float;

index_output : output_pin_name; /* applied for

cross type;/*

index_1(float);

index_n(float);

index_n+1(float, );

values(float, );

} /* vector */

} /pg_current */

Liberty User Guide Volume 1

R-2020.09

684

Chapter 14: Composite Current Source Power Modeling

Compact CCS Power Modeling

} /* switching_group */

} /* dynamic_current */

} /* cell */

Note:

For the input_switching_condition and input_switching_condition

groups, the rise and fall values can be separated by commas or space.

Compact CCS Power Modeling

CCS power compaction uses base curve technology to significantly reduce the library

size of CCS power libraries. Greater control of the Liberty file size allows you to include

additional data points and more accurately capture CCS power data for dynamic current

waveforms.

Base curve technology was first introduced for compact CCS timing. Each timing current

waveform is split into two segments in the I-V domain, and the shape of each segment

is modeled by a base curve that has a similar shape. This segmentation prevents direct

modeling with the piecewise linear data points.

Compact CCS power modeling differs from compact CCS timing modeling in that power

waveforms can include both positive sections and negative sections. They must be

modeled in an I(t) domain. In addition, the segmentation is more flexible. This is important

because the current waveform shape might contain one or more bumps. The compact

CCS power modeling segmentation points can be selected at:

•

The point where the current waveform crosses zero

•

The peak of a current bump

In Figure 115, the red curve shows an example CCS power waveform in piecewise linear

format with fifteen data points. Thirty float numbers must be stored in the library. This is

an expensive storage cost for a single I(t) waveform because libraries generally include

a large number of I(t) waveforms. In addition, the waveform shape is not smooth, despite

the fifteen data points, due to the inefficiency of the piecewise linear representation. The

current value error is larger than 5% in some regions of the waveform.

Liberty User Guide Volume 1

R-2020.09

685

Chapter 14: Composite Current Source Power Modeling

Compact CCS Power Modeling

Figure 115 Power Current Vector

Segmenting the waveform and using base curve technology for each segment provides

greater accuracy. In Figure 115, the blue dots and blue curve show the waveform using

base curve technology. The blue dots represent five segmentation points that divide the

waveform into four sections. You can save the segmentation points as characteristic points

and model the shape of each segment using a base curve. The blue curve is the third

segment that can be represented by a base curve.

The following example describes the format for each current waveform:

start,

start

, bcid

, t

ip1

, I

ip1,

bcid

, [ t

ip2

, I

ip2,

bcid

, ..., ] t

end

, I

end

;

The arguments are defined as follows:

start

The current start time.

start

The initial current.

The time of an internal segmentation point.

The current value of an internal segmentation point.

end

The time when transition ends and current value becomes stable.

Liberty User Guide Volume 1

R-2020.09

686

Chapter 14: Composite Current Source Power Modeling

Compact CCS Power Modeling

end

The current value at the endpoint.

bcid

The ID of the base curve that models the shape between two neighboring

points.

Compact CCS Power Syntax and Requirements

The expanded, or dynamic, CCS power model syntax provides an important reference and

criteria for compact CCS power modeling. See Dynamic Current Syntax on page 684 for

the dynamic_current syntax and see Dynamic Power and Ground Current Table Syntax

on page 679 for the pg_current_template syntax.

The following requirements must be met in the pg_current_template group:

•

The last variable_* value must be time. The time variable is required.

•

The input_net_transition and total_output_net_capacitance values are

available for all variable_* attributes except the last variable_*. They can be placed

in any order except last.

The following conditions describe the pg_current_template group:

• There can be zero or one input_net_transition variable.

•

There can be zero, one, or two total_output_net_capacitance variables.

•

Each vector group in the pg_current group describes a current waveform that is

compacted into a table in the compact CCS power model.

Similar to the compact CCS timing modeling syntax, compact CCS power modeling

syntax uses the base_curves group to describe normalized base curves and the

compact_lut_template group as the compact current waveform template. However,

the compact_lut_template group attributes are extended from three dimensions to

four dimensions when CCS power models need two total_output_net_capacitance

attributes.

The compact CCS power modeling syntax is as follows:

library (my_library) {

base_curves(bc_name) {

base_curve_type : enum (ccs_half_curve, ccs_timing_half_curve);

curve_x ("float, ..., float");

curve_y ("integer, float, ..., float"); /* base curve #1 */

curve_y ("integer, float, ..., float"); /* base curve #2 */

...

curve_y ("integer, float, ..., float"); /* base curve #n */

}

Liberty User Guide Volume 1

R-2020.09

687

Chapter 14: Composite Current Source Power Modeling

Compact CCS Power Modeling

compact_lut_template (template_name) {

base_curves_group : bc_name;

variable_1 : input_net_transition | total_output_net_capacitance;

variable_2 : input_net_transition | total_output_net_capacitance;

variable_3 : input_net_transition | total_output_net_capacitance;

variable_4 : curve_parameters;

index_1 ("float, ..., float");

index_2 ("float, ..., float");

index_3 ("float, ..., float");

index_4 ("string, ..., string");

}

...

cell(cell_name) {

dynamic_current() {

switching_group() {

pg_current(pg_pin_name) {

compact_ccs_power (template_name) {

base_curves_group : bc_name;

index_output : pin_name;

index_1 ("float, ..., float");

index_2 ("float, ..., float");

index_3 ("float, ..., float");

index_4 ("string, ..., string");

values ("float | integer, ..., float | integer");

} /* end of compact_ccs_power */

...

} /* end of pg_current */

...

} /* end of switching_group */

...

} /* end of dynamic_current */

...

} /* end of cell */

...

} /* end of library*/

Library-Level Groups and Attributes

This section describes library-level groups and attributes used for compact CCS power

modeling.

base_curves Group

The base_curves group contains the detailed description of normalized base curves. The

base_curves group has the following attributes:

base_curve_type Complex Attribute

The base_curve_type attribute specifies the type of base curve. The ccs_half_curve

value allows you to model compact CCS power and compact CCS timing data within

Liberty User Guide Volume 1

R-2020.09

688

Chapter 14: Composite Current Source Power Modeling

Compact CCS Power Modeling

the same base_curves group. You must specify ccs_half_curve before specifying

ccs_timing_half_curve.

curve_x Complex Attribute

The data array contains the x-axis values of the normalized base curve. Only one curve_x

value is allowed for each base_curves group.

For a ccs_timing_half_curve base curve, the curve_x value must be between 0 and 1

and increase monotonically.

curve_y Complex Attribute

Each base curve consists of one curve_x and one curve_y attributes. You should define

the curve_x base curve before curve_y for better clarity and easier implementation. The

valid region for curve_y is [-30, 30] for compact CCS power.

There are two data sections in the curve_y complex attribute:

•

The curve_id integer specifies the identifier of the base curve.

•

The data array specifies the y-axis values of the normalized base curve.

compact_lut_template Group

The compact_lut_template group is a lookup table template used for compact CCS

timing and power modeling.

The following requirements must be met for compact CCS power modeling:

•

The last variable_* value must be curve_parameters.

•

The input_net_transition and total_output_net_capacitance values are

available for all variable_* attributes except the last variable_*. They can be placed

in any order except last.

The following conditions describe the pg_current_template group:

• There can be zero or one input_net_transition variable.

•

There can be zero, one, or two total_output_net_capacitance variables.

•

The element type for all index_* values except the last one is a list of floating-point

numbers.

•

The element type for the last index_* value is a string.

•

The only valid value for index_*, when it is last and when it is specified with

curve_parameters as the last variable_*, is init_time, init_current, bc_id1,

point_time1, point_current1, bc_id2, [point_time2, point_current2, bc_id3,

…], end_time, end_current.

Liberty User Guide Volume 1

R-2020.09

689

Chapter 14: Composite Current Source Power Modeling

Compact CCS Power Modeling

The valid value in the last index is the pattern that all curve parameter series should

follow. It is a pattern rather than a specified series because the table varies in size.

Curve parameters define how to describe a current waveform. There should be at

least two segments. The reference time for each current waveform is always zero. The

negative time values, such as the values with corresponding parameters init_time,

point_time and end_time, are permitted.

Note that this index is only for clarity. It is not used to determine the curve parameters.

Curve parameters can be uniquely determined by the size of the values. A valid size

can be represented as (8+3i), where i is an integer and i>=0. The current waveform

has (i+2) segments.

Cell-Level Groups and Attributes

This section describes cell-level groups and attributes used for compact CCS power

modeling.

compact_ccs_power Group

The compact_ccs_power group contains a detailed description for compact CCS

power data. The compact_ccs_power group includes the following optional attributes:

base_curves_group, index_1, index_2, index_3 and index_4. The description for these

attributes in the compact_ccs_power group is the same as in the compact_lut_template

group. However, the attributes have a higher priority in the compact_ccs_power group.

For more information, see compact_lut_template Group on page 689.

The index_output attribute is also optional. It is used only on cross type tables.

values Attribute

The values attribute is required in the compact_ccs_power group. The data within the

quotation marks (" "), or line, represent the current waveform for one index combination.

Each value is determined by the corresponding curve parameter. In the following line,

"t0, c0, 1, t1, c1, 2, t2, c2, 3, t3, c3, 4, t4, c4"

the size is 14 = 8+3*2. Therefore, the curve parameters are as follows:

"init_time, init_current, bc_id1, point_time1, point_current1, bc_id2, \

point_time2, point_current2, bc_id3, point_time3, point_current3,

bc_id4,\

end_time, end_current"

The elements in the values attribute are floating-point numbers for time and current and

integers for the base curve ID. The number of current waveform segments can be different

Liberty User Guide Volume 1

R-2020.09

690

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Dynamic Power Examples

for each slew and load combination, which means that each line size can be different. As a

result, Liberty syntax supports tables with varying sizes, as shown:

compact_ccs_power (template_name) {

...

index_1("0.1, 0.2"); /* input_net_transition */

index_2("1.0, 2.0"); /* total_output_net_capacitance */

index_3 ("init_time, init_current, bc_id1, point_time1,

point_current1,

bc_id2, [point_time2, point_current2, bc_id3, ...], \

end_time, end_current"); /* curve_parameters */

values

("t0, c0, 1, t1, c1, 2, t2, c2, 3, t3, c3, 4, t4, c4", \ /* segment=4 */

"t0, c0, 1, t1, c1, 2, t2, c2", \ /* segment=2 */

"t0, c0, 1, t1, c1, 2, t2, c2, 3, t3, c3", \ /* segment=3 */

"t0, c0, 1, t1, c1, 2, t2, c2, 3, t3, c3"); /* segment=3 */

}

Composite Current Source Dynamic Power Examples

This section provides the following CCS dynamic power examples:

• Design Cell With a Single Output Example

•

Dense Table With Two Output Pins Example

• Cross Type With More Than One Output Pin Example

•

Diagonal Type With More Than One Output Pin Example

Design Cell With a Single Output Example

pg_current_template ( CCS_power_1 ) {

variable_1 : input_net_transition ;

variable_2 : total_output_net_capacitance ;

variable_3 : time ;

}

cell (example) {

dynamic_current() {

when: D;

related_inputs : CP;

related_outputs : Q;

switching_group ( ) {

input_switching_condition(rise);

output_switching_condition(rise);

pg_current (VDD ) {

vector ( CCS_power_1 ) {

reference_time : 0.01;

Liberty User Guide Volume 1

R-2020.09

691

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Dynamic Power Examples

index_1 ( 0.01 )

index_2 ( 1.0 )

index_3 ( 0.000, 0.0873, 0.135, 0.764)

values ( 0.002, 0.009, 0.134, 0.546)

}

Dense Table With Two Output Pins Example

pg_current_template ( CCS_power_1 ) {

variable_1 : input_net_transition ;

variable_2 : total_output_net_capacitance ;

variable_3 : total_output_net_capacitance ;

variable_4 : time ;

}

cell ( example ) {

dynamic_current() {

related_inputs : "A" ;

related_outputs : "Z" ;

typical_capacitances(0.04);

switching_group() {

input_switching_condition(rise);

output_switching_condition(rise);

pg_current(VDD) {

vector(ccsp_switching_load_time) {

reference_time : 0.0015 ;

index_1("0.0019");

index_2("0.001");

index_3("0, 0.006, 0.03, 0.07, 0.09, 0.1, 0.2, 0.3, 0.4,

0.5");

values("5e-06, 0.001, 0.02, 0.03, 0.05, 0.08, 0.09, 0.04,

0.009, 5.0e-06");

}

Cross Type With More Than One Output Pin Example

pg_current_template ( CCS_power_1 ) {

variable_1 : input_net_transition ;

variable_2 : total_output_net_capacitance ;

variable_3 : time ;

}

Liberty User Guide Volume 1

R-2020.09

692

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Dynamic Power Examples

cell ( example )

dynamic_current() {

when: D;

related_inputs : CP;

related_outputs : Q QN QN1 QN2;

typical_capacitances(10.0 10.0 10.0 10.0);

switching_group ( ) {

input_switching_condition(rise);

output_switching_condition(rise, fall, fall, fall);

pg_current (VSS) {

vector ( CCS_power_1 ) {

index_output : Q;

reference_time : 0.01;

index_1 ( 0.01 )

index_2 ( 5.0)

index_3 ( 0.000, 0.0873, 0.135, 0.764)

values ( 0.002, 0.009, 0.134, 0.546)

}

vector ( CCS_power_1 ) {

index_output : QN;

reference_time : 0.01;

index_1 ( 0.01 )

index_2 ( 1.0 )

index_3 ( 0.000, 0.0873, 0.135, 0.764)

values ( 0.002, 0.009, 0.134, 0.546)

}

vector ( CCS_power_1 ) {

index_output : QN;

reference_time : 0.01;

index_1 ( 0.01 )

index_2 ( 5.0 )

index_3 ( 0.000, 0.0873, 0.135, 0.764)

values ( 0.002, 0.009, 0.134, 0.546)

}

Diagonal Type With More Than One Output Pin Example

pg_current_template ( CCS_power_1 ) {

variable_1 : input_net_transition ;

variable_2 : total_output_net_capacitance ;

variable_3 : time ;

}

cell ( example )

dynamic_current() {

when: D ;

related_inputs : CP;

related_outputs : Q QN QN1 QN2;

switching_group ( ) {

input_switching_condition(rise);

Liberty User Guide Volume 1

R-2020.09

693

Chapter 14: Composite Current Source Power Modeling

Composite Current Source Dynamic Power Examples

output_switching_condition(rise, fall, fall, fall);

}

pg_current (VSS) {

vector ( CCS_power_1 ) {

reference_time : 0.01;

index_1 ( 0.01 )

index_2 ( 1.0 )

index_3 ( 0.000, 0.0873, 0.135, 0.764)

values ( 0.002, 0.009, 0.134, 0.546)

}

Liberty User Guide Volume 1

R-2020.09

694

On-Chip Variation (OCV) Modeling

On-chip variation (OCV) causes variation in the timing performance of each transistor in a

design.

In advanced OCV models, these variations are modeled using derating factors based on

the path depth and path distance.

In parametric OCV models, the variations are modeled using random variation and path

distance of cells.

The OCV model definitions are covered in the following sections:

•

Advanced OCV Modeling

In an advanced OCV model, the derating values are based on the path depth and path

distance.

The modeling syntax is:

library (name) {

ocv_table_template(ocv_template_name) {

variable_1: path_depth|path_distance;

variable_2: path_depth|path_distance;

index_1 ("float…, float");

index_2 ("float…, float");

}

ocv_derate(ocv_derate_group_name) {

ocv_derate_factors(ocv_template_name) {

rf_type: rise|fall|rise_and_fall;

derate_type: early|late;

path_type: clock|data|clock_and_data;

index_1 ("float,..., float");

index_2 ("float,..., float");

values ( "float,..., float", \

..., \

"float,..., float");

}

...

Liberty User Guide Volume 1

R-2020.09

695

Chapter 15: On-Chip Variation (OCV) Modeling

Advanced OCV Modeling

}

default_ocv_derate_group: ocv_derate_group_name;

ocv_arc_depth: float;

...

cell (cell_name) {

ocv_derate_group: ocv_derate_group_name;

ocv_arc_depth: float;

...

ocv_derate(ocv_derate_group_name) {

ocv_derate_factors(ocv_template_name) {

rf_type: rise|fall|rise_and_fall;

derate_type: early|late;

path_type: clock|data|clock_and_data;

index_1 ("float,..., float");

index_2 ("float,..., float");

values ( "float,..., float", \

..., \

"float,..., float");

}

...

}

pin | bus | bundle (name) {

direction: inout | output;

timing() {

ocv_arc_depth: float;

...

} /* end of timing */

} /* end of inout | output pin */

...

} /* end of cell */

...

} /* end of library */

Table 33 Association Between the Liberty Advanced OCV Syntax and

the PrimeTime Advanced OCV File Format

Liberty syntax PrimeTime advanced OCV file format

ocv_derate group_name

ocv_table_template table

path_depth depth

path_distance distance

ocv_derate_factors table

rf_type rf_type

derate_type derate_type

Liberty User Guide Volume 1

R-2020.09

696

Chapter 15: On-Chip Variation (OCV) Modeling

Advanced OCV Modeling

Liberty syntax PrimeTime advanced OCV file format

path_type path_type

ocv_derate_group group_name

default_ocv_derate_group group_name

ocv_arc_depth Not applicable

Library-Level Groups and Attributes

This section describes library-level groups and attributes for advanced OCV modeling that

also apply to cells and timing arcs where specified.

ocv_table_template Group

The ocv_table_template group defines the template for an ocv_derate_factors group

defined within the ocv_derate group.

The template definition includes two one-dimensional variables, variable_1 and

variable_2. These variables are used as indexes in the ocv_derate_factors group.

You must specify variable_1. Specifying variable_2 is optional.

Both variable_1 and variable_2 can have one of the following values:

•

path_depth: The number of cells in a delay path.

•

path_distance: The physical distance spanned by the path. Use the distance_unit

attribute in the library to specify the path distance unit.

You can specify the following types of lookup tables within the ocv_table_template

group:

• One-dimensional tables with the index consisting of path_depth or path_distance for

a table

•

Two-dimensional tables with one index consisting of path_depth, and the other index

consisting of path_distance

This means that for a two-dimensional table, the values of variable_1 and

variable_2 are different.

ocv_derate Group

The ocv_derate group contains a set of ocv_derate_factors groups. The ocv_derate

group specifies a set of lookup tables with OCV derating factors for timing.

You must specify at least one ocv_derate_factors group within an ocv_derate group.

Liberty User Guide Volume 1

R-2020.09

697

Chapter 15: On-Chip Variation (OCV) Modeling

Advanced OCV Modeling

You can specify the ocv_derate group in the library and cell groups. To define multiple

ocv_derate groups in a library, use different group names. If multiple ocv_derate groups

have the same name, the group that is last specified overrides the previous ones.

ocv_derate_factors Group

The ocv_derate_factors group specifies a lookup table of the OCV derating factors. The

lookup table can be one-dimensional, two-dimensional, or scalar. For a one-dimensional

lookup table, the index consists of path_depth or path_distance values. For a two-

dimensional lookup table, the indexes consist of the path_depth and path_distance

values. Use the scalar to specify a single derating factor irrespective of the path depth and

path distance.

Use the following attributes to define specific OCV derating factors in the

ocv_derate_factors lookup table:

•

rf_type

The rf_type attribute defines the type of delay specified in the ocv_derate_factors

lookup table. Valid values are rise, fall, and rise_and_fall.

•

derate_type

The derate_type attribute defines the type of arrival time specified in the

ocv_derate_factors lookup table. The valid values are early and late.

•

path_type

The path_type attribute defines the type of path specified in the ocv_derate_factors

group. The valid values are clock, data, and clock_and_data.

These attributes do not have defaults. You must specify these attributes in the

ocv_derate_factors group.

Applying OCV Derating Factors to Library Cells

To apply the set of derating factors defined within an ocv_derate group to a cell, use the

cell-level ocv_derate_group attribute to specify the name of the ocv_derate group.

To apply the same set of derating factors to multiple cells in a library, specify the

ocv_derate group at the library-level and define the name of the ocv_derate group with

the ocv_derate_group attribute in the corresponding cell groups.

The set of derating factors defined within a cell-level ocv_derate group can be applied

only to the particular cell.

If you do not specify the ocv_derate_group attribute, the default ocv_derate group

defined at the library level applies to the cell.

Liberty User Guide Volume 1

R-2020.09

698

Chapter 15: On-Chip Variation (OCV) Modeling

Advanced OCV Modeling

default_ocv_derate_group Attribute

The default_ocv_derate_group attribute specifies the name of the default ocv_derate

group for a library. The default ocv_derate group applies to the cell groups where the

ocv_derate group name is not defined using the cell-level ocv_derate_group attribute.

ocv_arc_depth Attribute

The optional ocv_arc_depth attribute specifies the effective logic depth of a cell or a

timing arc. The default is 1.0.

The path depth is used to determine the OCV derating factors from the lookup tables in

the ocv_derate_factors group.

You can define the ocv_arc_depth attribute in the library, cell, or timing groups.

If you define this attribute in different groups, the attribute value in the timing group

overrides the value defined in the cell group, and the value defined in the cell group

overrides the value defined in the library group.

Cell-Level Attribute

This section describes a cell-level attribute for advanced OCV modeling.

ocv_derate_group Attribute

The ocv_derate_group attribute specifies the name of the ocv_derate group that applies

to a cell.

Advanced OCV Library Example

Example 138 A Typical Advanced OCV Library

library (OCV_lib) {

ocv_table_template(2D_ocv_template) {

variable_1: path_depth;

variable_2: path_distance;

index_1 ("1,2,3");

index_2 ("1,2,3");

}

ocv_table_template(1D_ocv_template1) {

variable_1: path_depth;

index_1 ("1,2,3");

}

ocv_table_template(1D_ocv_template2) {

variable_1: path_distance;

index_1 ("1,2,3");

}

ocv_derate(advanced_ocv){

Liberty User Guide Volume 1

R-2020.09

699

Chapter 15: On-Chip Variation (OCV) Modeling

Advanced OCV Modeling

ocv_derate_factors(scalar) {

rf_type: rise_and_fall;

derate_type: early;

path_type: clock_and_data;

values ( "0.100");

}

ocv_derate_factors(scalar) {

rf_type: rise_and_fall;

derate_type: late;

path_type: clock_and_data;

values ( "0.200");

}

ocv_arc_depth: 1.0;

default_ocv_derate_group: advanced_ocv;

cell (cell1) {

ocv_arc_depth: 2.0;

ocv_derate_group: aocv1;

ocv_derate(aocv1) {

ocv_derate_factors (2D_ocv_template) {

rf_type: rise_and_fall;

derate_type: early;

path_type: clock_and_data;

index_1 ("1,2,3");

index_2 ("4, 5");

values ( "0.1, 0.2, 0.3", \

"0.2, 0.3, 0.4");

}

ocv_derate_factors (2D_ocv_template) {

rf_type: rise_and_fall;

derate_type: late;

path_type: clock_and_data;

index_1 ("1,2,3");

index_2 ("100, 200");

values ( "0.1, 0.2, 0.3", \

"0.2, 0.3, 0.4");

}

ocv_derate(aocv2){

ocv_derate_factors(scalar) {

rf_type: rise_and_fall;

derate_type: late;

path_type: clock_and_data;

values ( "0.900");

}

ocv_derate_factors(scalar) {

rf_type: rise_and_fall;

derate_type: early;

path_type: clock_and_data;

values ( "0.800");

}

...

Liberty User Guide Volume 1

R-2020.09

700

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

pin | bus | bundle (name) {

direction: inout | output;

timing() {

ocv_arc_depth: 3.0;

...

} /* end of timing */

}

...

} /* end of cell */

cell (cell2) {

ocv_derate_group: advanced_ocv;

...

} /* end of cell */

cell (cell3) {

/* use advanced_ocv as default_ocv_derate_group

defined in library */

...

} /* end of cell */

...

} /* end of library */

LVF Models For Cell Delay, Transition, and Constraint

In a parametric OCV (POCV) model, the random variation is specific to a cell or a timing

arc, unlike an advanced OCV model where a specific derating factor applies to multiple

cells or an entire library. The Liberty variation format (LVF) is used to represent the

parametric OCV (POCV) library data, such as the slew-load table per delay timing arc.

The following Liberty variation format (LVF) syntax consists of groups for sigma variation

cell delay, output transition or slew, and constraint tables that are load and input-slew

dependent. The variation values are used during parametric OCV analysis.

Syntax

The parametric OCV Liberty variation format (LVF) modeling syntax for cell delay,

transition, and constraint is:

library (name) {

lu_table_template(lu_template_name) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

variable_3: related_out_total_output_net_capacitance;

index_1 ("float, ..., float");

index_2 ("float, ..., float");

index_3 ("float, ..., float");

}

lu_table_template(constraint_lu_template_name) {

variable_1: related_pin_transition;

Liberty User Guide Volume 1

R-2020.09

701

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

variable_2: constrained_pin_transition;

variable_3: related_out_total_output_net_capacitance | \

related_out_output_net_length | \

related_out_output_net_wire_cap | \

related_out_output_net_pin_cap;

index_1 ("float, ..., float");

index_2 ("float, ..., float");

index_3 ("float, ..., float");

}

ocv_table_template(ocv_template_name) {

variable_1: path_distance;

index_1 ("float, ..., float");

}

ocv_derate(ocv_derate_group_name) {

ocv_derate_factors(ocv_template_name) {

rf_type: rise | fall | rise_and_fall;

derate_type: early | late;

path_type: clock | data | clock_and_data;

index_1 ("float, ..., float");

values ( "float, ..., float");

}

...

}

default_ocv_derate_distance_group: ocv_derate_group_name;

...

cell (cell_name) {

ocv_derate_distance_group: ocv_derate_group_name;

...

pin | bus | bundle (name) {

direction: inout | output;

timing() {

...

ocv_sigma_cell_rise(lu_template_name){

sigma_type: early | late | early_and_late;

index_1 ("float, ..., float");

index_2 ("float, ..., float");

values ( "float, ..., float", \

..., \

"float, ..., float");

}

ocv_sigma_cell_fall(lu_template_name){

sigma_type: early | late | early_and_late;

index_1 ("float, ..., float");

index_2 ("float, ..., float");

values ( "float, ..., float", \

..., \

"float, ..., float");

}

ocv_sigma_rise_transition(lu_template_name){

sigma_type: early | late | early_and_late;

index_1 ("float, ..., float");

index_2 ("float, ..., float");

index_3 ("float, ..., float");

Liberty User Guide Volume 1

R-2020.09

702

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

values ( "float, ..., float", \

..., \

"float, ..., float");

}

ocv_sigma_fall_transition(lu_template_name){

sigma_type: early | late | early_and_late;

index_1 ("float, ..., float");

index_2 ("float, ..., float");

index_3 ("float, ..., float");

values ( "float, ..., float", \

..., \

"float, ..., float");

}

...

} /* end of timing */

...

} /* end of pin */

...

pin | bus | bundle (name) {

direction: input | inout;

timing() {

...

ocv_sigma_rise_constraint(constraint_lu_template_name){

index_1 ("float, ..., float");

index_2 ("float, ..., float");

values ( "float, ..., float", \

..., \

"float, ..., float");

}

ocv_sigma_fall_constraint(constraint_lu_template_name){

index_1 ("float, ..., float");

index_2 ("float, ..., float");

values ( "float, ..., float", \

..., \

"float, ..., float");

}

...

} /* end of timing */

...

} /* end of pin */

...

} /* end of cell */

...

} /* end of library */

Note:

For input pins, you can specify only the ocv_sigma_rise_constraint and

ocv_sigma_fall_constraint tables in the corresponding timing groups.

Liberty User Guide Volume 1

R-2020.09

703

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

For output pins, you can specify only the ocv_sigma_cell_rise,

ocv_sigma_cell_fall, ocv_sigma_rise_transition, and

ocv_sigma_fall_transition tables in the corresponding timing groups.

For inout pins, you can specify the ocv_sigma_cell_rise,

ocv_sigma_cell_fall, ocv_sigma_rise_transition , and

ocv_sigma_fall_transition, ocv_sigma_rise_constraint, and

ocv_sigma_fall_constraint tables in the corresponding timing groups.

Do not specify the sigma_type attribute in the ocv_sigma_rise_constraint

and ocv_sigma_fall_constraint groups.

Table 34 Association Between the Liberty Parametric OCV Syntax and the

PrimeTime Parametric OCV File Format

Liberty syntax PrimeTime parametric OCV file format

ocv_derate group_name

ocv_table_template table

path_distance distance

ocv_derate_factors table

rf_type rf_type

derate_type derate_type

path_type path_type

ocv_derate_distance_group group_name

default_ocv_derate_distance_group group_name

Library-Level Groups and Attributes

This section describes library-level groups and attributes for parametric OCV modeling

that also apply to cells and timing arcs where specified.

lu_table_template Group

The lu_table_template group defines the template for the following groups specified in

the timing group:

•

ocv_sigma_cell_rise

•

ocv_sigma_cell_fall

Liberty User Guide Volume 1

R-2020.09

704

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

• ocv_sigma_rise_transition

• ocv_sigma_fall_transition

• ocv_sigma_rise_constraint

•

ocv_sigma_fall_constraint

For the ocv_sigma_cell_rise, ocv_sigma_cell_fall, ocv_sigma_rise_transition,

and ocv_sigma_fall_transition groups, the template definition includes the

variable_1, variable_2, variable_3, index_1, index_2, and index_3 attributes. The

variable_1, variable_2 and variable_3 attributes specify the index variables for the

lookup tables (LUTs) in these groups. The index_1, index_2, and index_3 attributes

specify the numerical values of the variables.

The values of variable_1, variable_2, and variable_3 attributes

are input_net_transition, total_output_net_capacitance, and

related_out_total_output_net_capacitance.

You can specify the following types of lookup tables within these groups:

•

One-dimensional tables with a single index, such as input_net_transition

• Two-dimensional tables with the indexes, input_net_transition and

total_output_net_capacitance

•

Three-dimensional tables with the indexes, input_net_transition,

total_output_net_capacitance, and

related_out_total_output_net_capacitance

•

A scalar that has a single variation value irrespective of the

input_net_transition, total_output_net_capacitance, and

related_out_total_output_net_capacitance values

For the ocv_sigma_rise_constraint and ocv_sigma_fall_constraint groups,

the template definition includes the variable_1, variable_2, variable_3,

index_1, index_2, and index_3 attributes. The variable_1, variable_2 and

variable_3 attributes specify the index variables for the lookup tables of the

ocv_sigma_rise_constraint and ocv_sigma_fall_constraint groups. The index_1,

index_2, and index_3 attributes specify the numerical values of these variables.

The values of variable_1 and variable_2 are related_pin_transition and

constrained_pin_transition, respectively. The values of variable_3 can be

related_out_total_output_net_capacitance, related_out_output_net_length,

related_out_net_wire_cap, or related_out_output_net_pin_cap. You can specify

the following types of lookup tables within these groups:

•

One-dimensional tables with a single index, such as related_pin_transition

Liberty User Guide Volume 1

R-2020.09

705

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

• Two-dimensional tables with the indexes, related_pin_transition and

constrained_pin_transition

• Three-dimensional tables with the indexes, related_pin_transition,

constrained_pin_transition, and a valid value of variable_3

•

A scalar that has a single variation value irrespective of the related_pin_transition,

constrained_pin_transition, and variable_3 values

ocv_table_template Group

The ocv_table_template group defines the template for an ocv_derate_factors group

defined within the ocv_derate group.

The template definition includes a one-dimensional variable, variable_1, that is used as

an index in the ocv_derate_factors group. Valid value of variable_1 is path_distance

and represents the physical distance spanned by the path. Use the distance_unit

attribute in the library to specify the path distance unit.

ocv_derate Group

The ocv_derate group contains a set of ocv_derate_factors groups. The ocv_derate

group specifies a set of lookup tables with OCV derating factors for timing.

You must specify at least one ocv_derate_factors group within an ocv_derate group.

You can specify the ocv_derate group in the library and cell groups. To define multiple

ocv_derate groups in a library, use different group names. If multiple ocv_derate groups

have the same name, the group that is last-specified overrides the previous ones.

ocv_derate_factors Group

The ocv_derate_factors group specifies a lookup table of the OCV derating factors. The

lookup table can be one-dimensional or scalar. For a one-dimensional lookup table, the

index consists of path_distance values. Use the scalar to specify a single derating factor

irrespective of the path distance.

Use the following attributes to define specific OCV derating factors in the

ocv_derate_factors lookup table:

•

rf_type

The rf_type attribute defines the type of delay specified in the ocv_derate_factors

lookup table. Valid values are rise, fall, and rise_and_fall.

•

derate_type

The derate_type attribute defines the type of arrival time specified in the

ocv_derate_factors lookup table. The valid values are early and late.

•

path_type

Liberty User Guide Volume 1

R-2020.09

706

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

The path_type attribute defines the type of path specified in the ocv_derate_factors

group. The valid values are clock, data, and clock_and_data.

These attributes do not have defaults. You must specify these attributes in the

ocv_derate_factors group.

Applying Parametric OCV Derating Factors to Library Cells

To apply the set of derating factors defined within an ocv_derate group to a cell, use the

cell-level ocv_derate_distance_group attribute to specify the name of the ocv_derate

group.

To apply the same set of derating factors to multiple cells in a library, specify the

ocv_derate group at the library-level and define the name of the ocv_derate group with

the ocv_derate_distance_group attribute in the corresponding cell groups.

The set of derating factors defined within a cell-level ocv_derate group can be applied

only to the particular cell.

If you do not specify the ocv_derate_distance_group attribute, the default ocv_derate

group defined at the library level applies to the cell.

default_ocv_derate_distance_group Attribute

The default_ocv_derate_group attribute specifies the name of the default ocv_derate

group for a library. The default ocv_derate group applies to the cell groups where the

ocv_derate group name is not defined using the cell-level ocv_derate_distance_group

attribute.

Cell-Level Attribute

This section describes a cell-level attribute for parametric OCV modeling.

ocv_derate_distance_group Attribute

The ocv_derate_distance_group attribute specifies the name of the ocv_derate group

that applies to a cell.

Timing Arc Level Groups and Attributes

This section describes the timing arc-level groups for modeling delay variations. Each

of the groups specify a lookup table. The lookup table can be one-dimensional, two-

dimensional, three-dimensional, or scalar.

Define the template of the lookup table in the library-level lu_table_template group.

To use the template, specify the name of the lu_table_template group as the arc-level

group name.

Liberty User Guide Volume 1

R-2020.09

707

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

ocv_sigma_cell_rise Group

The ocv_sigma_cell_rise group specifies a lookup table for the rise delay variation. In

the lookup table, each absolute rise-delay variation offset from the corresponding nominal

rise delay is specified at one sigma (σ), where sigma is the standard deviation of the rise

delay distribution.

Note:

The nominal rise delay value is specified by the cell_rise group within the

timing group. For more information, see Chapter 7, Timing Arcs”.

During parametric OCV analysis, the delay variation and the nominal rise delay are used

to calculate the rise delay at one sigma (σ):

rise delay

(±s)

= nominal rise delay ± ocv_sigma_cell_rise value

ocv_sigma_cell_fall Group

The ocv_sigma_cell_fall group specifies a lookup table for the fall delay variation. In

the lookup table, each absolute fall-delay variation offset from the corresponding nominal

fall delay is specified at one sigma (σ), where sigma is the standard deviation of the fall

delay distribution.

Note:

The nominal fall delay value is specified by the cell_fall group within the

timing group. For more information, Chapter 7, Timing Arcs”.

During OCV analysis, the delay variation and the nominal fall delay are used to calculate

the fall delay at one sigma (σ):

fall delay

(±s)

= nominal fall delay ± ocv_sigma_cell_fall value

ocv_sigma_rise_transition Group

The ocv_sigma_rise_transition group specifies a lookup table of the rise transition

variation values. In the lookup table, each absolute rise-transition variation offset from the

corresponding nominal rise transition is specified at one sigma (σ), where sigma is the

standard deviation of the rise transition distribution.

Note:

The nominal rise transition value is specified by the rise_transition group

within the timing group. For more information, see Chapter 7, Timing Arcs”.

During parametric OCV analysis, the rise transition variation and the nominal rise

transition are used to calculate the rise transition at one sigma (σ):

rise transition

(±σ)

= nominal rise transition ± ocv_sigma_rise_transition

value

Liberty User Guide Volume 1

R-2020.09

708

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

ocv_sigma_fall_transition Group

The ocv_sigma_fall_transition group specifies a lookup table for the fall transition

variation. In the lookup table, each absolute fall-transition variation offset from the nominal

fall transition is specified at one sigma (σ), where sigma is the standard deviation of the fall

transition distribution.

Note:

The nominal fall transition value is specified by the fall_transition group

within the timing group. For more information, Chapter 7, Timing Arcs”.

During parametric OCV analysis, the transition variation and the nominal fall transition are

used to calculate the fall delay at one sigma (σ):

fall transition

(±σ)

= nominal fall transition ± ocv_sigma_fall_transition

value

sigma_type Attribute

The optional sigma_type attribute defines the type of arrival time specified in the

ocv_sigma_cell_rise, ocv_sigma_cell_fall, ocv_sigma_rise_transition,

and ocv_sigma_fall_transition lookup tables. The values are early, late, and

early_and_late. The default is early_and_late.

During parametric OCV analysis, when you specify the sigma_type attribute in these

groups, the following values at ±σ are calculated as:

rise delay

(+σ)

= nominal cell rise + ocv_sigma_cell_rise

late

rise delay

(−σ)

= nominal cell rise - ocv_sigma_cell_rise

early

fall delay

(+σ)

= nominal cell fall + ocv_sigma_cell_fall

late

fall delay

(−σ)

= nominal cell fall - ocv_sigma_cell_fall

early

rise transition

(+σ)

= nominal rise transition + ocv_sigma_rise_transition

late

rise transition

(−σ)

= nominal rise transition - ocv_sigma_rise_transition

early

fall transition

(+σ)

= nominal fall transition + ocv_sigma_fall_transition

late

fall transition

(−σ)

= nominal fall transition - ocv_sigma_fall_transition

early

ocv_sigma_rise_constraint Group

The ocv_sigma_rise_constraint group specifies a lookup table of the rise constraint

variation values. In the lookup table, each absolute rise-constraint variation offset from

the nominal rise constraint is specified at one sigma (σ), where sigma is the standard

deviation of the rise constraint distribution.

Note:

The nominal rise constraint value is specified by the rise_constraint group

within the timing group. For more information, see Chapter 7, Timing Arcs”.

Liberty User Guide Volume 1

R-2020.09

709

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

During OCV analysis, the rise constraint variation and the nominal rise constraint are used

to calculate the rise constraint at one sigma (σ):

rise constraint

(±σ)

= nominal rise constraint ± ocv_sigma_rise_constraint

value

ocv_sigma_fall_constraint Group

The ocv_sigma_fall_constraint group specifies a lookup table for the fall constraint

variation. In the lookup table, each absolute fall-constraint variation offset from the nominal

fall constraint is specified at one sigma (σ), where sigma is the standard deviation of the

fall constraint distribution.

Note:

The nominal fall constraint value is specified by the fall_constraint group

within the timing group. For more information, Chapter 7, Timing Arcs”.

During parametric OCV (POCV) analysis, the delay variation and the nominal fall delay are

used to calculate the fall delay at one sigma (σ):

fall constraint

(±σ)

= fall_constraint ± ocv_sigma_fall_constraint value

Parametric OCV Library Example

Example 139 A Library Model for OCV Delays, Transitions, and Constraints

library (lib1) {

lu_table_template(2D_lu_template) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

index_1 ("1,2,3");

index_2 ("1,2,3");

}

lu_table_template(3D_lu_template) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

variable_3: related_out_total_output_net_capacitance;

index_1 ("1,2,3");

index_2 ("1,2,3");

index_3 ("1,2,3");

}

lu_table_template(2D_constraint_lu_template) {

variable_1: related_pin_transition;

variable_2: constrained_pin_transition;

index_1 ("1,2,3");

index_2 ("1,2,3");

}

ocv_table_template(1D_ocv_template2) {

variable_1: path_distance;

index_1 ("1,2,3");

Liberty User Guide Volume 1

R-2020.09

710

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

}

ocv_derate(location_based_ocv) {

ocv_derate_factors(1D_ocv_template2) {

rf_type: rise_and_fall;

derate_type: early;

path_type: clock_and_data;

index_1 ("1, 2");

values ( "5.0, 6.0");

}

ocv_derate(locv1) {

ocv_derate_factors(1D_ocv_template2) {

rf_type: rise_and_fall;

derate_type: early;

path_type: clock_and_data;

index_1 ("1, 2");

values ( "5.0, 6.0");

}

default_ocv_derate_distance_group: location_based_ocv;

cell (cell1) {

ocv_derate_distance_group: locv1;

...

pin (pin1) {

direction: output;

timing() {

...

related_pin : "rpin1" ;

timing_type : rising_edge ;

cell_rise( 2D_lu_template ){

index_1 ( "0.1, 0.2, 0.3");

index_2 ( "0.4, 0.5, 0.6");

values ( "0.1, 0.2, 0.3",\

"0.2, 0.3, 0.4",\

"0.3, 0.4, 0.5");

}

cell_fall( scalar ){

values ("0.100");

}

rise_transition( 2D_lu_template ){

index_1 ( "0.1, 0.2, 0.3");

index_2 ( "0.4, 0.4, 0.5");

values ( "0.1, 0.2, 0.3",\

"0.3, 0.4, 0.5",\

"0.5, 0.6, 0.7");

}

fall_transition( scalar ){

values ("0.100");

}

ocv_sigma_cell_rise( 2D_lu_template ){

sigma_type: early;

index_1 ( "0.3, 0.4, 0.5");

index_2 ( "0.1, 0.2, 0.3");

Liberty User Guide Volume 1

R-2020.09

711

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Models For Cell Delay, Transition, and Constraint

values ( "0.1, 0.2, 0.3",\

"0.2, 0.3, 0.4",\

"0.3, 0.4, 0.5");

}

ocv_sigma_cell_rise( 2D_lu_template ){

sigma_type: late;

index_1 ( "0.3, 0.4, 0.5");

index_2 ( "0.1, 0.2, 0.3");

values ( "0.1, 0.2, 0.3",\

"0.2, 0.3, 0.4",\

"0.3, 0.4, 0.5");

}

ocv_sigma_cell_fall( scalar ){

sigma_type: early;

values ("0.1");

}

ocv_sigma_cell_fall( scalar ){

sigma_type: late;

values ("0.1");

}

ocv_sigma_rise_transition( 3D_lu_template ){

sigma_type: early;

index_1 ( "0.1, 0.2, 0.3");

index_2 ( "0.4, 0.5, 0.6");

index_3 ( "0.7, 0.8");

values ("0.1, 0.2, 0.3",\

"0.2, 0.3, 0.4",\

"0.3, 0.4, 0.5",\

"0.4, 0.5, 0.6",\

"0.5, 0.6, 0.7",\

"0.6, 0.7, 0.8");

}

ocv_sigma_rise_transition( 3D_lu_template ){

sigma_type: late;

index_1 ( "0.1, 0.2, 0.3");

index_2 ( "0.4, 0.5, 0.6");

index_3 ( "0.7, 0.8");

values ("0.1, 0.2, 0.3",\

"0.2, 0.3, 0.4",\

"0.3, 0.4, 0.5",\

"0.4, 0.5, 0.6",\

"0.5, 0.6, 0.7",\

"0.6, 0.7, 0.8");

}

ocv_sigma_fall_transition( scalar ){

sigma_type: early_and_late;

values ( "0.200");

}

...

} /* end of timing */

}

...

pin (pin2) {

Liberty User Guide Volume 1

R-2020.09

712

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Retain Arc Models

direction: input | inout;

timing() {

...

ocv_sigma_rise_constraint( 2D_lu_constraint_template ){

index_1 ( "0.3, 0.4, 0.5");

index_2 ( "0.1, 0.2, 0.3");

values ( "0.1, 0.2, 0.3",\

"0.2, 0.3, 0.4",\

"0.3, 0.4, 0.5");

}

ocv_sigma_fall_constraint( 2D_lu_constraint_template ){

index_1 ( "0.3, 0.4, 0.5");

index_2 ( "0.1, 0.2, 0.3");

values ( "0.1, 0.2, 0.3",\

"0.2, 0.3, 0.4",\

"0.3, 0.4, 0.5");

}

...

} /* end of timing */

...

} /* end of pin */

...

} /* end of cell */

cell (cell2) {

/* use location_based_ocv as

default_ocv_derate_distance_group defined in library */

...

} /* end of cell */

...

} /* end of library */

LVF Retain Arc Models

A retain arc models the time during which an output port retains its current logical value

after a voltage rise or fall at a related input port.

For information about the nominal retain arc tables that store the retain arc delay and

transition time, see Chapter 7, Timing Arcs.”

The parametric OCV (POCV) models for retain arcs are stored in the Liberty variation

format (LVF) in library source files.

Syntax

The following is the modeling syntax of LVF retain arc models.

library (name) {

lu_table_template(lu_template_name) {

Liberty User Guide Volume 1

R-2020.09

713

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Retain Arc Models

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

variable_3: related_out_total_output_net_capacitance;

index_1 (float,, float);

index_2 (float,, float);

index_3 (float,, float);

}

cell (name) {

pin|bus|bundle(name) {

direction: inout|output;

timing() {

ocv_sigma_retaining_rise (lu_template_name){

sigma_type: early|late|early_and_late;

index_1 (float,, float);

index_2 (float,, float);

index_3 (float,, float);

values (float,, float, \

, \

float,, float);

}

ocv_sigma_retaining_fall(lu_template_name){

sigma_type: early|late|early_and_late;

index_1 (float,, float);

index_2 (float,, float);

index_3 (float,, float);

values (float,, float, \

, \

float,, float);

}

ocv_sigma_retain_rise_slew (lu_template_name){

sigma_type: early|late|early_and_late;

index_1 (float,, float);

index_2 (float,, float);

index_3 (float,, float);

values (float,, float, \

, \

float,, float);

}

ocv_sigma_retain_fall_slew(lu_template_name){

sigma_type: early|late|early_and_late;

index_1 (float,, float);

index_2 (float,, float);

index_3 (float,, float);

values (float,, float, \

, \

float,, float);

}

} /* end of timing */

} /* end of inout/output pin */

} /* end of cell */

} /* end of library */

Liberty User Guide Volume 1

R-2020.09

714

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Retain Arc Models

Library-Level Groups

This section describes library-level groups to model retain arc timing variation.

lu_table_template Group

The lu_table_template group defines the template for the following timing-level retain

arc groups:

•

ocv_sigma_retaining_rise

•

ocv_sigma_retaining_fall

• ocv_sigma_retain_rise_slew

•

ocv_sigma_retain_fall_slew

The template definition includes the variable_1, variable_2, variable_3, index_1,

index_2, and index_3 attributes. The variable_1, variable_2, and variable_3

attributes specify the variables that are used as indexes in these groups. The index_1,

index_2, and index_3 attributes specify the numerical values of the variables. The

values of variable_1, variable_2, and variable_3 are input_net_transition,

total_output_net_capacitance, and related_out_total_output_net_capacitance

respectively. You can define a scalar, one-dimensional, two-dimensional, or three-

dimensional lookup table using the lu_table_template group.

Timing Arc Level Groups

This section describes timing-level groups to model retain arc timing delay and transition

variation. These groups are lookup tables that can be scalar, one, two, or three-

dimensional.

Define these groups in the timing group together with the nominal retain arc tables.

ocv_sigma_retaining_rise and ocv_sigma_retaining_fall Groups

The ocv_sigma_retaining_rise and ocv_sigma_retaining_fall groups are retain

arc delay lookup tables that specify the absolute variation offset from the nominal retain

arc table values at one sigma (σ), where sigma is the standard deviation of the delay

distribution.

During parametric OCV analysis, the retain arc values at ±σ are calculated using the

nominal and variation values as:

retaining_rise

(±σ)

= retaining_rise ± ocv_sigma_retaining_rise

retaining_fall

(±σ)

= retaining_fall ± ocv_sigma_retaining_fall

Liberty User Guide Volume 1

R-2020.09

715

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Retain Arc Models

For more information about the nominal retain arc delay groups, see Chapter 7, Timing

Arcs”.

ocv_sigma_retain_rise_slew and ocv_sigma_retain_fall_slew

Groups

The ocv_sigma_retain_rise_slew and ocv_sigma_retain_fall_slew groups are

retain arc slew lookup tables that specify the absolute variation offset values from the

nominal retain arc table values at one sigma (σ), where sigma is the standard deviation of

the transition distribution.

During parametric OCV analysis, the retain arc values at ±σ are calculated using the

variation values as:

retain_rise_slew

(±σ)

= retain_rise_slew ±

ocv_sigma_retain_rise_slew

retain_fall_slew

(±σ)

= retain_fall_slew ±

ocv_sigma_retain_fall_slew

For more information about the nominal retain arc slew groups, see Chapter 7, Timing

Arcs”.

sigma_type Attribute

The optional sigma_type attribute defines the type of arrival time specified

in the ocv_sigma_retaining_rise, ocv_sigma_retaining_fall,

ocv_sigma_retain_rise_slew, and ocv_sigma_retain_fall_slew lookup tables. The

values are early, late, and early_and_late. The default is early_and_late.

During OCV analysis, if the sigma_type attribute is specified in these groups, the following

values at ±σ are calculated as:

retaining_rise

(+σ)

= retaining_rise + ocv_sigma_retaining_rise

late

retaining_rise

(−σ)

= retaining_rise - ocv_sigma_retaining_rise

early

retaining_fall

(+σ)

= retaining_fall + ocv_sigma_retaining_fall

late

retaining_fall

(−σ)

= retaining_fall - ocv_sigma_retaining_fall

early

retain_rise_slew

(+σ)

= retain_rise_slew + ocv_sigma_retain_rise_slew

late

retain_rise_slew

(−σ)

= retain_rise_slew - ocv_sigma_retain_rise_slew

early

retain_fall_slew

(+σ)

= retain_fall_slew + ocv_sigma_retain_fall_slew

late

retain_fall_slew

(−σ)

= retain_fall_slew - ocv_sigma_retain_fall_slew

early

Library Example

The following example is a library with LVF retain arc models.

library (lib1) {

lu_table_template(2D_lu_template) {

variable_1: input_net_transition;

Liberty User Guide Volume 1

R-2020.09

716

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Retain Arc Models

variable_2: total_output_net_capacitance;

index_1 (1,2,3);

index_2 (1,2,3);

}

lu_table_template(1D_lu_template) {

variable_1: total_output_net_capacitance;

index_1 (1,2,3);

}

cell (cell1) {

pin(pin1) {

direction: output;

timing() {

related_pin : "CLKIN" ;

timing_type : rising_edge ;

cell_rise( 2D_lu_template ){

...

}

cell_fall( 2D_lu_template ){

...

}

rise_transition( 2D_lu_template ){

...

}

fall_transition( 2D_lu_template ){

...

}

retaining_rise( 2D_lu_template ){

index_1 ( "0.10000, 0.20000, 0.30000");

index_2 ( "0.40000, 0.60000, 0.60000");

values ( "0.10000, 0.20000, 0.30000",\

"0.40000, 0.50000, 0.60000",\

"0.70000, 0.80000, 0.90000");

}

retaining_fall ( 1D_lu_template ){

values ( "0.10000, 0.20000, 0.30000");

}

retain_rise_slew( 2D_lu_template ){

index_1 ( "0.10000, 0.20000, 0.30000");

index_2 ( "0.40000, 0.60000, 0.60000");

values ( "0.10000, 0.20000, 0.30000",\

"0.40000, 0.50000, 0.60000",\

"0.70000, 0.80000, 0.90000");

}

retain_fall_slew( 1D_lu_template ){

values ( "0.10000, 0.20000, 0.30000");

}

ocv_sigma_retaining_rise( 2D_lu_template ){

sigma_type: early;

index_1 ( "0.10000, 0.20000, 0.30000");

index_2 ( "0.40000, 0.50000, 0.60000");

values ( "0.10000, 0.20000, 0.30000",\

Liberty User Guide Volume 1

R-2020.09

717

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

"0.40000, 0.50000, 0.60000",\

"0.70000, 0.80000, 0.90000");

}

ocv_sigma_retaining_rise( 2D_lu_template ){

sigma_type: late;

index_1 ( "0.10000, 0.20000, 0.30000");

index_2 ( "0.40000, 0.50000, 0.60000");

values ( "0.10000, 0.20000, 0.30000",\

"0.40000, 0.50000, 0.60000",\

"0.70000, 0.80000, 0.90000");

}

ocv_sigma_retaining_fall ( 1D_lu_template ){

sigma_type: early;

values ( "0.10000, 0.20000, 0.30000");

}

ocv_sigma_retaining_fall ( 1D_lu_template ){

sigma_type: late;

values ( "0.10000, 0.20000, 0.30000");

}

ocv_sigma_retain_rise_slew( 2D_lu_template ){

sigma_type: early_and_late;

index_1 ( "0.10000, 0.20000, 0.30000");

index_2 ( "0.40000, 0.50000, 0.60000");

values ( "0.10000, 0.20000, 0.30000",\

"0.40000, 0.50000, 0.60000",\

"0.70000, 0.80000, 0.90000");

}

ocv_sigma_retain_fall_slew ( 1D_lu_template ){

values ( "0.10000, 0.20000, 0.30000");

}

} /* end of timing group */

} /* end of pin group */

} /* end of cell group */

} /* end of library group */

LVF Moment-Based Models For Ultra-Low Voltage Designs

Accurate models of ultra-low voltage libraries might require support for asymmetric,

biased, or non-Gaussian distributions of timing variation. To capture the shape of the

biased timing variation distribution, moments-based Liberty variation format (LVF) OCV

models are supported.

Liberty User Guide Volume 1

R-2020.09

718

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

Figure 116 Biased Timing Variation Distribution With Positive Skew and Shifted Mean

As shown in Figure 116, the moment-based LVF syntax is based on the mean, standard

deviation, and skewness of the timing variation distribution.

Mean

Mean is the weighted average of the possible values, using their probabilities as weights

or the continuous analog thereof. The mean of a random variable X is defined, as shown:

E[X] = x

+...+x

where X can take values x

with probability p

, x

with probability p

, up to x

with

probability p

Standard Deviation

Standard deviation is a measure of the variation or dispersion of the distribution. It is

defined as the square root of the variance, as shown:

(E[(X-E[X])

])

1/2

Liberty User Guide Volume 1

R-2020.09

719

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

Skewness

Skewness is a measure of the asymmetry of the distribution of a random variable X about

its mean. The definition follows the Pearson's coefficient of skewness. It is defined, as

shown:

(E[(X-E[X])

])

1/3

The following sections describe the moment-based LVF OCV models of random variation

in cell delay, transition, and constraints.

Syntax

The following shows the moment-based LVF OCV modeling syntax.

library (lib_name) {

lu_table_template (lu_template_name) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

variable_3: related_out_total_output_net_capacitance;

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

}

…

cell (cell_name) {

…

pin | bus | bundle (name) {

direction: inout | output;

timing() {

…

/* delay nominal values */

cell_rise (lu_template_name) {

…

}

cell_fall (lu_template_name) {

…

}

/* delay variation values */

ocv_std_dev_cell_rise(lu_template_name){

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

values ("float,…, float", \

…, \

"float,…, float");

}

ocv_std_dev_cell_fall(lu_template_name){

index_1 ("float,…, float");

Liberty User Guide Volume 1

R-2020.09

720

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

index_2 ("float,…, float");

index_3 ("float,…, float");

values ("float,…, float", \

…, \

"float,…, float");

}

ocv_std_dev_retaining_rise(lu_template_name){

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

values ( "float,…, float", \

…, \

"float,…, float");

}

ocv_std_dev_retaining_fall(lu_template_name){

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

values ( "float,…, float", \

…, \

"float,…, float");

}

ocv_mean_shift_cell_rise(lu_template_name){

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

values ( "float,…, float", \

…, \

"float,…, float");

}

ocv_mean_shift_cell_fall(lu_template_name){

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

values ( "float,…, float", \

…, \

"float,…, float");

}

ocv_mean_shift_retaining_rise(lu_template_name){

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

values ( "float,…, float", \

…, \

"float,…, float");

}

ocv_mean_shift_retaining_fall(lu_template_name){

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

values ( "float,…, float", \

…, \

Liberty User Guide Volume 1

R-2020.09

721

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

"float,…, float");

}

ocv_skewness_cell_rise(lu_template_name){

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

values ( "float,…, float", \

…, \

"float,…, float");

}

ocv_skewness_cell_fall(lu_template_name){

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

values ( "float,…, float", \

…, \

"float,…, float");

}

ocv_skewness_retaining_rise(lu_template_name){

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

values ( "float,…, float", \

…, \

"float,…, float");

}

ocv_skewness_retaining_fall(lu_template_name){

index_1 ("float,…, float");

index_2 ("float,…, float");

index_3 ("float,…, float");

values ( "float,…, float", \

…, \

"float,…, float");

}

/* transition nominal values */

rise_transition (lu_template_name) {

…

}

fall_transition (lu_template_name) {

…

}

/* transition variation values */

ocv_std_dev_rise_transition(lu_template_name){

...

}

ocv_std_dev_fall_transition(lu_template_name){

...

}

ocv_std_dev_retain_rise_slew(lu_template_name){

...

}

ocv_std_dev_retain_fall_slew(lu_template_name){

Liberty User Guide Volume 1

R-2020.09

722

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

...

}

ocv_mean_shift_rise_transition(lu_template_name){

...

}

ocv_mean_shift_fall_transition(lu_template_name){

...

}

ocv_mean_shift_retain_rise_slew(lu_template_name){

...

}

ocv_mean_shift_retain_fall_slew(lu_template_name){

...

}

ocv_skewness_rise_transition(lu_template_name){

...

}

ocv_skewness_fall_transition(lu_template_name){

...

}

ocv_skewness_retain_rise_slew(lu_template_name){

...

}

ocv_skewness_retain_fall_slew(lu_template_name){

...

}

} /* end of timing */

} /* end of inout | output pin */

…

pin | bus | bundle (name) {

direction: inout | input;

timing() {

…

/* constraint nominal values */

rise_constraint(lu_template_name){

…

}

fall_constraint(lu_template_name){

…

}

/* constraint variation values */

ocv_std_dev_rise_constraint(lu_template_name){

...

}

ocv_std_dev_fall_constraint(lu_template_name){

...

}

ocv_mean_shift_rise_constraint(lu_template_name){

...

}

ocv_mean_shift_fall_constraint(lu_template_name){

...

}

Liberty User Guide Volume 1

R-2020.09

723

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

ocv_skewness_rise_constraint(lu_template_name){

...

}

ocv_skewness_fall_constraint(lu_template_name){

...

}

…

} /* end of timing */

} /* end of inout | input pin */

…

} /* end of cell */

…

} /* end of library */

Library-Level Groups

This section describes library-level groups to model asymmetric timing variation

distributions of delays, transitions, and constraints.

lu_table_template Group

The lu_table_template group defines the template for the following timing-level groups:

•

ocv_std_dev_*

•

ocv_mean_shift_*

• ocv_skewness_*

The template definition is same as that of the lu_table_template Group on page 715

described in “LVF Retain Arc Models.”

Timing Arc Level Groups

This section describes timing-level groups to model asymmetric timing variation

distributions of delays, transitions, and constraints. These groups are lookup tables that

can be scalar, one, two, or three-dimensional.

Define these groups in the timing group together with the nominal retain arc tables.

These groups are defined under the timing group together with the nominal tables.

ocv_std_dev_* Groups

The ocv_std_dev_cell_rise, ocv_std_dev_cell_fall,

ocv_std_dev_rise_transition, ocv_std_dev_fall_transition,

ocv_std_dev_retaining_rise, ocv_std_dev_retaining_fall,

ocv_std_dev_retain_rise_slew, ocv_std_dev_retain_fall_slew,

Liberty User Guide Volume 1

R-2020.09

724

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

ocv_std_dev_rise_constraint, and ocv_std_dev_fall_constraint look up tables

store the values of standard deviation of the timing variation distribution.

ocv_mean_shift_* Groups

The ocv_mean_shift_cell_rise, ocv_mean_shift_cell_fall,

ocv_mean_shift_rise_transition, ocv_mean_shift_fall_transition,

ocv_mean_shift_retaining_rise, ocv_mean_shift_retaining_fall,

ocv_mean_shift_retain_rise_slew, ocv_mean_shift_retain_fall_slew,

ocv_mean_shift_rise_constraint, and ocv_mean_shift_fall_constraint lookup

tables specify the offset value from the mean of the timing variation distribution to the

nominal value.

The mean values of the timing variation distribution are calculated as:

mean rise delay = nominal rise delay +

ocv_mean_shift_cell_rise

mean fall delay = nominal fall delay +

ocv_ mean_shift_cell_fall

mean rise transition = nominal rise transition +

ocv_mean_shift_rise_transition

mean fall transition = nominal fall transition +

ocv_ mean_shift_fall_transition

mean retaining rise = nominal retaining rise +

ocv_mean_shift_retaining_rise

mean retaining fall = nominal retaining fall +

ocv_mean_shift_retaining_fall

mean retain rise slew = nominal retain rise slew +

ocv_mean_shift_retain_rise_slew

mean retain fall skew = nominal retain fall slew +

ocv_ mean_shift_retain_fall_slew

mean rise constraint = nominal rise constraint +

ocv_mean_shift_rise_constraint

mean fall constraint = nominal fall constraint +

ocv_ mean_shift_fall_constraint

ocv_skewness_* Groups

These ocv_skewness_cell_rise, ocv_skewness_cell_fall,

ocv_skewness_rise_transition, ocv_skewness_fall_transition,

ocv_skewness_retaining_rise, ocv_skewness_retaining_fall,

ocv_skewness_retain_rise_slew, ocv_skewness_retain_fall_slew,

Liberty User Guide Volume 1

R-2020.09

725

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

ocv_skewness_rise_constraint, ocv_skewness_fall_constraint lookup tables

specify the skewness values of the timing variation distribution.

Library Example

The following example shows a library with moment-based LVF models of a biased timing

variation distribution.

library (lib1) {

lu_table_template(2D_lu_template) {

variable_1: input_net_transition;

variable_2: total_output_net_capacitance;

index_1 ("1,2,3");

index_2 ("1,2,3");

}

cell (cell1) {

…

pin(pin1) {

direction: output;

timing() {

…

related_pin : "CLKIN" ;

timing_type : rising_edge ;

cell_rise( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

cell_fall ( scalar ){

values ("0.095");

}

rise_transition( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

fall_transition ( scalar ){

values ("0.095");

}

ocv_std_dev_cell_rise( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

Liberty User Guide Volume 1

R-2020.09

726

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

ocv_std_dev_cell_fall ( scalar ){

values ("0.005");

}

ocv_std_dev_rise_transition( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

ocv_std_dev_fall_transition ( scalar ){

values ("0.005");

}

ocv_std_dev_retaining_rise( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

ocv_std_dev_retaining_fall ( scalar ){

values ("0.005");

}

ocv_std_dev_retain_rise_slew( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

ocv_std_dev_retain_fall_slew ( scalar ){

values ("0.005");

}

ocv_mean_shift_cell_rise( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

ocv_mean_shift_cell_fall( scalar ){

values ("0.015");

}

ocv_mean_shift_rise_transition( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

ocv_mean_shift_fall_transition ( scalar ){

values ("0.005");

}

Liberty User Guide Volume 1

R-2020.09

727

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

ocv_mean_shift_retaining_rise( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

ocv_mean_shift_retaining_fall ( scalar ){

values ("0.005");

}

ocv_mean_shift_retain_rise_slew( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

ocv_mean_shift_retain_fall_slew ( scalar ){

values ("0.005");

}

ocv_skewness_cell_rise( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

ocv_skewness_cell_fall( scalar ){

values ("0.015");

}

ocv_skewness_rise_transition( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

ocv_skewness_fall_transition( scalar ){

values ("0.015");

}

ocv_skewness_retaining_rise( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

ocv_skewness_retaining_fall ( scalar ){

values ("0.005");

}

ocv_skewness_retain_rise_slew( 2D_lu_template ){

index_1 ( "0.3, 0.4, 0.6");

index_2 ( "0.01, 0.02, 0.03");

Liberty User Guide Volume 1

R-2020.09

728

Chapter 15: On-Chip Variation (OCV) Modeling

LVF Moment-Based Models For Ultra-Low Voltage Designs

values ( "0.04, 0.05, 0.06",\

"0.07, 0.08, 0.09",\

"0.1, 0.2, 0.3");

}

ocv_skewness_retain_fall_slew ( scalar ){

values ("0.005");

}

…

} /* end of timing */

…

} /* end of pin */

…

} /* end of cell */

…

} /* end of library */

Liberty User Guide Volume 1

R-2020.09

729

Defining I/O Pads

To define I/O pads, you use the library, cell, and pin group attributes that describe

input, output, and bidirectional pad cells.

To model I/O pads, you must understand the following concepts covered in this chapter:

• Special Characteristics of I/O Pads

• Identifying Pad Cells

• Defining Units for Pad Cells

• Describing Input Pads

• Describing Output Pads

• Modeling Wire Load for Pads

• Programmable Driver Type Support in I/O Pad Cell Models

• Pad Cell Examples

Special Characteristics of I/O Pads

I/O pads are the special cells at the chip boundaries that allow communication with the

world outside the chip. Their characteristics distinguish them from the other cells that

make up the core of an integrated circuit.

Pads typically have longer delays and higher drive capabilities than the cells in an

integrated circuit’s core. Because of their higher drive, CMOS pads sometimes exhibit

noise problems. Slew-rate control is available on output pads to help alleviate this

problem.

Pads are fixed resources—a limited number are available on each die size. In addition,

special types, such as clock pads, might be more limited than others. These limits must be

modeled.

A distinguishing feature of pad cells is the voltage level at which input pads transfer logic 0

or logic 1 signals to the core or at which output pad drivers communicate logic values from

the core.

Liberty User Guide Volume 1

R-2020.09

730

Chapter 16: Defining I/O Pads

Identifying Pad Cells

Integrated circuits that communicate with one another must have compatible voltage levels

at their pads. Because pads communicate with the world outside the integrated circuit, you

must describe the pertinent units of peripheral library properties, such as external load,

drive capability, delay, current, power, and resistance. This description makes it easier to

design chips from multiple technologies.

Some libraries create logical pads out of multiple cells; such logical pads must be modeled

so that they are just as easy to insert automatically on a design as a single-cell pad.

You must capture all these properties in the library to make it possible for the integrated

circuit designer to insert the correct pads during synthesis.

Identifying Pad Cells

Use the attributes described in the following sections to specify I/O pads and pad pin

behaviors.

is_pad Attribute

After you identify a cell as a pad cell, you must indicate which pin represents the pad.

The is_pad simple attribute must be used on at least one pin of a cell with a pad_cell

attribute.

The direction attribute indicates whether the pad is an input, output, or bidirectional pad.

Syntax

is_pad : true | false ;

Example

cell(INBUF){

...

pin(PAD){

direction : input ;

is_pad : true ;

}

driver_type Attribute

A driver_type attribute defines two types of signal modifications: transformation and

resolution.

•

Transformation specifies an actual signal transition from 0/1 to L/H/Z. This signal

transition performs a function on an input signal and requires only a straightforward

mapping.

Liberty User Guide Volume 1

R-2020.09

731

Chapter 16: Defining I/O Pads

Identifying Pad Cells

• Resolution resolves the value Z on an existing circuit node without actually performing

a function and implies a constant (0/1) signal source as part of the resolution.

Syntax

driver_type : pull_up | pull_down | open_drain | open_source |

bus_hold

| resistive | resistive_0 | resistive_1 ;

pull_up

The pin is connected to power through a resistor. If it is a three-state output

pin, it is in the Z state and its function is evaluated as a resistive 1 (H). If it is

an input or inout pin and the node to which it is connected is in the Z state, it

is considered an input pin at logic 1 (H). For a pull_up cell, the pin constantly

stays at logic 1 (H).

pull_down

The pin is connected to ground through a resistor. If it is a three-state output

pin, it is in the Z state and its function is evaluated as a resistive 0 (L). If it is

an input or inout pin and the node to which it is connected is in the Z state, it is

considered an input pin at logic 0 (L). For a pull_down cell, the pin constantly

stays at logic 0 (L).

open_drain

The pin is an output pin without a pull-up transistor. Use this driver type only for

off-chip output or inout pins representing pads. The pin goes to high impedance

(Z) when its function is evaluated as logic 1.

Note:

An n-channel open-drain pad is flagged with open_drain, and a p-

channel open-drain pad is flagged with open_source.

open_source

The pin is an output pin without a pull-down transistor. Use this driver type

only for off-chip output or inout pins representing pads. The pin goes to high

impedance (Z) when its function is evaluated as logic 0.

bus_hold

The pin is a bidirectional pin on a bus holder cell. The pin holds the last logic

value present at that pin when no other active drivers are on the associated net.

Pins with this driver type cannot have function or three_state attributes.

resistive

The pin is an output pin connected to a controlled pull-up or pull-down resistor

with a control port EN. When EN is disabled, the pull-up or pull-down resistor is

Liberty User Guide Volume 1

R-2020.09

732

Chapter 16: Defining I/O Pads

Identifying Pad Cells

turned off and has no effect on the pin. When EN is enabled, a functional value

of 0 evaluated at the pin is turned into a weak 0, a functional value of 1 is turned

into a weak 1, but a functional value of Z is not affected.

resistive_0

The pin is an output pin connected to power through a pull-up resistor that has a

control port EN. When EN is disabled, the pull-up resistor is turned off and has

no effect on the pin. When EN is enabled, a functional value of 1 evaluated at

the pin turns into a weak 1, but a functional value of 0 or Z is not affected.

resistive_1

The pin is an output pin connected to ground through a pull-down resistor that

has a control port EN. When EN is disabled, the pull-down resistor is turned

off and has no effect on the pin. When EN is enabled, a functional value of 0

evaluated at the pin turns into a weak 0, but a functional value of 1 or Z is not

affected.

Table 35 lists the driver types, their signal mappings, and the applicable pin types.

Table 35 Driver Types

Driver type Description Signal mapping Applicable pin

types

pull_up Resolution 01Z -> 01H in, out

pull_down Resolution 01Z -> 01L in, out

bus_hold Resolution 01Z -> 01S inout

open_drain Transformation 01Z -> 0ZZ out

open_source Transformation 01Z -> Z1Z out

resistive Transformation 01Z -> LHZ out

resistive_0 Transformation 01Z -> 0HZ out

resistive_1 Transformation 01Z -> L1Z out

In Table 35, the pull_up, pull_down, and bus_hold driver types define a resolution

scheme. The remaining driver types define transformations.

The following example describes an output pin with a pull-up resistor and the bidirectional

pin on a bus_hold cell.

Liberty User Guide Volume 1

R-2020.09

733

Chapter 16: Defining I/O Pads

Defining Units for Pad Cells

Example

cell (bus) {

pin(Y) {

direction : output ;

driver_type : pull_up ;

pulling_resistance : 10000 ;

function : "IO" ;

three_state : "OE" ;

}

cell (bus_hold) {

pin(Y) {

direction : inout ;

driver_type : bus_hold ;

}

Defining Units for Pad Cells

To process pads for full-chip synthesis, specify the units of time, capacitance, resistance,

voltage, current, and power:

•

time_unit

•

capacitive_load_unit

• pulling_resistance_unit

•

voltage_unit

•

current_unit

• leakage_power_unit

All these attributes are defined at the library level, as described in Input-Capacitance

Characterization Attributes on page 764. These values are required.

Capacitance

The capacitive_load_unit attribute defines the capacitance associated with a standard

load. If you already represent capacitance values in terms of picofarads or femtofarads,

use this attribute to define your base unit. If you represent capacitance in terms of the

standard load of an inverter, define the exact capacitance for that inverter—for example,

0.101 pF.

Example

capacitive_load_unit( 0.1,ff );

Liberty User Guide Volume 1

R-2020.09

734

Chapter 16: Defining I/O Pads

Describing Input Pads

Resistance

You must supply a pulling_resistance attribute for pull-up and pull-down devices on

pads and identify the unit to use with the pulling_resistance_unit attribute.

Example

pulling_resistance_unit : "1kohm";

Voltage

You can use the input_voltage and output_voltage groups to define a set of input

or output voltage ranges for your pads. To define the units of voltage you use for these

groups, use the voltage_unit attribute. All the attributes defined inside input_voltage

and output_voltage groups are scaled by the value defined for voltage_unit. In

addition, the voltage attribute in the operating_conditions groups also represents its

values in these units.

Example

voltage_unit : "1V";

Current

You can define the drive current that can be generated by an output pad and also define

the pulling current for a pull-up or pull-down transistor under nominal voltage conditions.

Define all current values with the library-level current_unit attribute.

Example

current_unit : "1uA";

Describing Input Pads

To represent input pads in your logic library, you must describe the input voltage

characteristics and indicate whether hysteresis applies.

The input pad properties are described in the next section. Examples at the end of this

chapter describe a standard input buffer, an input buffer with hysteresis, and an input clock

buffer.

hysteresis Attribute

Specify the hysteresis attribute for an input pad for a long transition time or when the

pad is driven by a noisy line.

Liberty User Guide Volume 1

R-2020.09

735

Chapter 16: Defining I/O Pads

Describing Output Pads

The default is false. When true, the vil and vol voltage ratings are actual transition

points.

Example

hysteresis : true;

Pads with hysteresis can have derating factors that are different from the core cells. Use

the scaled_cell group to describe the timing of cells with hysteresis. This construct

provides derating capabilities and minimum, typical, or maximum timing for cells.

Describing Output Pads

To represent output pads in your logic library, you must describe the output voltage

characteristics and the drive-current rating of output and bidirectional pads. Additionally,

you must include information about the slew rate of the pad. These output pad properties

are described in the sections that follow.

Examples at the end of this chapter show a standard output buffer and a bidirectional pad.

Drive Current

Output and bidirectional pads in a technology can have different drive-current capabilities.

To define the drive current supplied by the pad buffer, use the drive_current attribute on

an output or bidirectional pad or auxiliary pad pin. The value is in units consistent with the

current_unit attribute you defined.

Example

pin(PAD) {

direction : output;

is_pad : true;

drive_current : 1.0;

}

Slew-Rate Control

The slew_control attribute accepts one of four possible enumerations: none, low,

medium, and high; the default is none. Increasing the slew control level slows down the

transition rate. This method is the coarsest way to measure the level of slew-rate control

associated with an output pad.

In Figure 117, A is a positive number and a linear approximation of the change in current

as a function of time from the beginning of the rising transition to the threshold. B is a

negative number and a linear approximation of the current change over time from the

threshold to the end of transition.

Liberty User Guide Volume 1

R-2020.09

736

Chapter 16: Defining I/O Pads

Describing Output Pads

Figure 117 Slew-Rate Attributes—Rising Transitions

For falling transitions, the graph is reversed and A becomes negative and B positive as

shown in Figure 118.

Liberty User Guide Volume 1

R-2020.09

737

Chapter 16: Defining I/O Pads

Modeling Wire Load for Pads

Figure 118 Slew-Rate Attributes—Falling Transitions

Example 140 Slew-Rate Control Attributes

pin(PAD) {

is_pad : true;

direction : output;

output_voltage : GENERAL;

slew_control : high;

rise_current_slope_before_threshold : 0.18;

rise_time_before_threshold : 0.8;

rise_current_slope_after_threshold : -0.09;

rise_time_after_threshold : 2.4;

fall_current_slope_before_threshold : -0.14;

fall_time_before_threshold : 0.55;

fall_current_slope_after_threshold : 0.07;

fall_time_after_threshold : 1.8;

...

}

Modeling Wire Load for Pads

You can define several wire_load groups that contain all the information to estimate

interconnect wiring delays. Estimated wire loads for pads can be significantly different from

those of core cells.

Liberty User Guide Volume 1

R-2020.09

738

Chapter 16: Defining I/O Pads

Programmable Driver Type Support in I/O Pad Cell Models

The wire load model for the net connecting an I/O pad to the core needs to be handled

separately, because such a net is usually longer than most other nets in the circuit. Some

pad nets extend completely across the chip.

You can define the wire_load group, which you want to use for wire load estimation, on

the pad ring. Add a level of hierarchy by placing the pads in the top level and by placing all

the core circuitry at a lower level.

dc_shell> set_wire_load Pad_WireLoad

A different model is defined for the core hierarchical level.

Programmable Driver Type Support in I/O Pad Cell Models

To support pull-up and pull-down circuit structures, the Liberty models for I/O pad cells

support pull-up and pull-down driver information using the driver_type attribute with the

pull_up or pull_down values.

Liberty syntax also supports conditional (programmable) pull-up and pull-down driver

information for I/O pad cells. The programmable pin syntax has also been extended to

other driver_type attribute values, such as bus_hold, open_drain, open_source,

resistive, resistive_0, and resistive_1.

Syntax

The following syntax supports programmable driver types in I/O pad cell models. Unlike

the nonprogrammable driver type support, the programmable driver type support allows

you to specify more than one driver type within a pin.

pin (pin_name) { /* programmable driver type pin */

...

pull_up_function : "function string";

pull_down_function : "function string";

bus_hold_function : "function string";

open_drain_function : "function string";

open_source_function : "function string";

resistive_function : "function string";

resistive_0_function : "function string";

resistive_1_function : "function string";

...

}

Programmable Driver Type Functions

The driver type function attributes in Table 36 help model the programmable driver types.

The same rules that apply to nonprogrammable driver types also apply to these functions.

Liberty User Guide Volume 1

R-2020.09

739

Chapter 16: Defining I/O Pads

Programmable Driver Type Support in I/O Pad Cell Models

Table 36 Programmable Driver Type Functions

Programmable driver type Applicable on pin types

pull_up_function Input, output and inout

pull_down_function Input, output and inout

bus_hold_function Inout

open_drain_function Output and inout

open_source_function Output and inout

resistive_function Output and inout

resistive_0_function Output and inout

resistive_1_function Output and inout

With the exception of pull_up_function and pull_down_function, if any of the driver

type functions in Table 36 is specified on an inout pin, it is used only for output pins.

The following rules apply to programmable driver type functions (as well as

nonprogrammable driver types in I/O pad cell models):

•

The attribute can be applied to pad cell only.

•

Only the input and inout pin can be specified in the function string.

•

The function string is a Boolean function of input pins.

The following rules apply to an inout pin:

•

If pull_up_function or pull_down_function and open_drain_function are

specified within the same inout pin, pull_up_function or pull_down_function is

used for the input pins.

•

If bus_hold_function is specified on an inout pin, it is used for input and output pins.

Example

Example 141 Model of a Programmable Driver Type in an I/O Pad Cell

library(cond_pull_updown_example) {

delay_model : table_lookup;

time_unit : 1ns;

voltage_unit : 1V;

capacitive_load_unit (1.0, pf);

current_unit : 1mA;

Liberty User Guide Volume 1

R-2020.09

740

Chapter 16: Defining I/O Pads

Programmable Driver Type Support in I/O Pad Cell Models

cell(conditional_PU_PD) {

dont_touch : true ;

dont_use : true ;

pad_cell : true ;

pin(IO) {

drive_current : 1 ;

min_capacitance : 0.001 ;

min_transition : 0.0008 ;

is_pad : true ;

direction : inout ;

max_capacitance : 30 ;

max_fanout : 2644 ;

function : "(A*ETM')+(TA*ETM)" ;

three_state : "(TEN*ETM')+(EN*ETM)" ;

pull_up_function : "(!P1 * !P2)" ;

pull_down_function : "( P1 * P2)" ;

capacitance : 2.06649 ;

timing() {

related_pin : "IO A ETM TEN TA" ;

cell_rise(scalar) {

values("0" ) ;

}

rise_transition(scalar) {

values("0" ) ;

}

cell_fall(scalar) {

values("0" ) ;

}

fall_transition(scalar) {

values("0" ) ;

}

timing() {

timing_type : three_state_disable;

related_pin : "EN ETM TEN" ;

cell_rise(scalar) {

values("0" ) ;

}

rise_transition(scalar) {

values("0" ) ;

}

cell_fall(scalar) {

values("0" ) ;

}

fall_transition(scalar) {

values("0" ) ;

}

pin(ZI) {

direction : output;

Liberty User Guide Volume 1

R-2020.09

741

Chapter 16: Defining I/O Pads

Pad Cell Examples

function : "IO" ;

timing() {

related_pin : "IO" ;

cell_rise(scalar) {

values("0" ) ;

}

rise_transition(scalar) {

values("0" ) ;

}

cell_fall(scalar) {

values("0" ) ;

}

fall_transition(scalar) {

values("0" ) ;

}

pin(A) {

direction : input;

capacitance : 1.0;

}

pin(EN) {

direction : input;

capacitance : 1.0;

}

pin(TA) {

direction : input;

capacitance : 1.0;

}

pin(TEN) {

direction : input;

capacitance : 1.0;

}

pin(ETM) {

direction : input;

capacitance : 1.0;

}

pin(P1) {

direction : input;

capacitance : 1.0;

}

pin(P2) {

direction : input;

capacitance : 1.0;

}

} /* End cell conditional_PU_PD */

} /* End Library */

Pad Cell Examples

These are examples of input, clock, output, and bidirectional pad cells.

Liberty User Guide Volume 1

R-2020.09

742

Chapter 16: Defining I/O Pads

Pad Cell Examples

Input Pads

Example 142 Standard Input Buffer

library (example1) {

date : "August 14, 2015" ;

revision : 2015.05;

...

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1uA";

pulling_resistance_unit : "1kohm";

capacitive_load_unit( 0.1,ff );

...

define_cell_area(bond_pads,pad_slots);

define_cell_area(driver_sites,pad_driver_sites);

...

input_voltage(CMOS) {

vil : 1.5;

vih : 3.5;

vimin : -0.3;

vimax : VDD + 0.3;

}

...

/***** INPUT PAD*****/

cell(INBUF) {

area : 0.000000;

pad_cell : true;

bond_pads : 1;

driver_sites : 1;

pin(PAD ) {

direction : input;

is_pad : true;

input_voltage : CMOS;

capacitance : 2.500000;

fanout_load : 0.000000;

}

pin(Y ) {

direction : output;

function : "PAD";

timing() {

cell_rise(scalar) {

values( " 3.07 ");

}

rise_transition(scalar) {

values( " 0.50 ");

}

cell_fall(scalar) {

values( " 2.95 ");

}

fall_transition(scalar) {

values( " 0.50 ");

Liberty User Guide Volume 1

R-2020.09

743

Chapter 16: Defining I/O Pads

Pad Cell Examples

}

related_pin :"PAD";

}

Example 143 Input Buffer With Hysteresis

library (example1) {

date : "August 14, 2015" ;

revision : 2015.05;

...

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1uA";

pulling_resistance_unit : "1kohm";

capacitive_load_unit( 0.1,ff );

...

input_voltage(CMOS_SCHMITT) {

vil : 1.0;

vih : 4.0;

vimin : -0.3;

vimax : VDD + 0.3;

}

...

/*INPUT PAD WITH HYSTERESIS*/

cell(INBUFH) {

area : 0.000000;

pad_cell : true;

pin(PAD ) {

direction : input;

is_pad : true;

hysteresis : true;

input_voltage : CMOS_SCHMITT;

capacitance : 2.500000;

fanout_load : 0.000000;

}

pin(Y ) {

direction : output;

function : "PAD";

timing() {

cell_rise(scalar) {

values( " 3.07 ");

}

rise_transition(scalar) {

values( " 0.50 ");

}

cell_fall(scalar) {

values( " 2.95 ");

}

fall_transition(scalar) {

values( " 0.50 ");

}

Liberty User Guide Volume 1

R-2020.09

744

Chapter 16: Defining I/O Pads

Pad Cell Examples

related_pin :"PAD";

}

Example 144 Input Clock Buffer

library (example1) {

date : "August 12, 2015" ;

revision : 2015.05;

...

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1uA";

pulling_resistance_unit : "1kohm";

capacitive_load_unit( 0.1,ff );

...

input_voltage(CMOS) {

vil : 1.5;

vih : 3.5;

vimin : -0.3;

vimax : VDD + 0.3;

}

...

/***** CLOCK INPUT BUFFER *****/

cell(CLKBUF) {

area : 0.000000;

pad_cell : true;

pad_type : clock;

pin(PAD ) {

direction : input;

is_pad : true;

input_voltage : CMOS;

capacitance : 2.500000;

fanout_load : 0.000000;

}

pin(Y ) {

direction : output;

function : "PAD";

max_fanout : 2000.000000;

timing() {

cell_rise(scalar) {

values( " 5.70 ");

}

rise_transition(scalar) {

values( " 0.009921 ");

}

cell_fall(scalar) {

values( " 6.90 ");

}

fall_transition(scalar) {

values( " 0.010238 ");

}

Liberty User Guide Volume 1

R-2020.09

745

Chapter 16: Defining I/O Pads

Pad Cell Examples

related_pin :"PAD";

}

Output Pads

Example 145 Standard Output Buffer

library (example1) {

date : "August 12, 2015" ;

revision : 2015.05;

...

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1uA";

pulling_resistance_unit : "1kohm";

capacitive_load_unit( 0.1,ff );

...

output_voltage(GENERAL) {

vol : 0.4;

voh : 2.4;

vomin : -0.3;

vomax : VDD + 0.3;

}

/***** OUTPUT PAD *****/

cell(OUTBUF) {

area : 0.000000;

pad_cell : true;

pin(D ) {

direction : input;

capacitance : 1.800000;

}

pin(PAD ) {

direction : output;

is_pad : true;

drive_current : 2.0;

output_voltage : GENERAL;

function : "D";

timing() {

cell_rise(scalar) {

values( " 8.487 ");

}

rise_transition(scalar) {

values( " 0.16974 ");

}

cell_fall(scalar) {

values( " 9.347 ");

}

fall_transition(scalar) {

values( " 0.18696 ");

Liberty User Guide Volume 1

R-2020.09

746

Chapter 16: Defining I/O Pads

Pad Cell Examples

}

related_pin :"D";

}

Bidirectional Pad

Example 146 Bidirectional Pad Cell With Three-State Enable

library (example1) {

date : "August 12, 2015" ;

revision : 2015.08;

...

time_unit : "1ns";

voltage_unit : "1V";

current_unit : "1uA";

pulling_resistance_unit : "1kohm";

capacitive_load_unit( 0.1,ff );

...

output_voltage(GENERAL) {

vol : 0.4;

voh : 2.4;

vomin : -0.3;

vomax : VDD + 0.3;

}

/***** BIDIRECTIONAL PAD *****/

cell(BIBUF) {

area : 0.000000;

pad_cell : true;

pin(E D ) {

direction : input;

capacitance : 1.800000;

}

pin(Y ) {

direction : output;

function : "PAD";

driver_type : "open_source pull_up";

pulling_resistance : 10000;

timing() {

cell_rise(scalar) {

values( " 3.07 ");

}

rise_transition(scalar) {

values( " 0.50 ");

}

cell_fall(scalar) {

values( " 2.95 ");

}

fall_transition(scalar) {

values( " 0.50 ");

Liberty User Guide Volume 1

R-2020.09

747

Chapter 16: Defining I/O Pads

Pad Cell Examples

}

related_pin :"PAD";

}

pin(PAD ) {

direction : inout;

is_pad : true;

drive_current : 2.0;

output_voltage : GENERAL;

input_voltage : CMOS;

function : "D";

three_state : "E";

timing() {

cell_rise(scalar) {

values( " 8.483 ");

}

rise_transition(scalar) {

values( " 0.34686 ");

}

cell_fall(scalar) {

values( " 19.065 ");

}

fall_transition(scalar) {

values( " 0.3813 ");

}

related_pin :"E";

}

timing() {

cell_rise(scalar) {

values( " 17.466 ");

}

rise_transition(scalar) {

values( " 0.16974 ");

}

cell_fall(scalar) {

values( " 9.348 ");

}

fall_transition(scalar) {

values( " 0.18696 ");

}

related_pin :"D";

}

Cell with contention_condition and x_function

Example 147 Cell With contention_condition and x_function Attributes

default_fanout_load : 0.1;

default_inout_pin_cap : 0.1;

Liberty User Guide Volume 1

R-2020.09

748

Chapter 16: Defining I/O Pads

Pad Cell Examples

default_input_pin_cap : 0.1;

default_output_pin_cap : 0.1;

capacitive_load_unit(1, pf);

pulling_resistance_unit : 1ohm;

voltage_unit : 1V;

current_unit : 1mA;

time_unit : 1ps;

cell (cell_a) {

area : 1;

contention_condition : "!ap & an";

pin (ap, an) {

direction : input;

capacitance : 1;

}

pin (io) {

direction : output;

function : "!ap & !an";

three_state : "ap & !an";

x_function : "!ap & an";

timing() {

related_pin : "ap an";

timing_type : three_state_disable;

cell_rise(scalar) {

values( " 0.10 ");

}

rise_transition(scalar) {

values( " 0.01 ");

}

cell_fall(scalar) {

values( " 0.10 ");

}

fall_transition(scalar) {

values( " 0.01 ");

}

timing() {

related_pin : "ap an";

timing_type : three_state_enable;

cell_rise(scalar) {

values( " 0.10 ");

}

rise_transition(scalar) {

values( " 0.01 ");

}

cell_fall(scalar) {

values( " 0.10 ");

}

fall_transition(scalar) {

values( " 0.01 ");

Liberty User Guide Volume 1

R-2020.09

749

Chapter 16: Defining I/O Pads

Pad Cell Examples

}

pin (z) {

direction : output;

function : "!ap & !an";

x_function : "!ap & an | ap & !an";

}

See contention_condition Attribute on page 64 and the “x_function Attribute” description in

Describing Clock Pin Functions on page 96 for more information about these attributes.

Liberty User Guide Volume 1

R-2020.09

750

Library Characterization Configuration

Library information is generated by characterizing the behavior of the library cells under

specific conditions. You can specify these conditions in one or more of the char_config

groups.

Specifying the library characterization settings includes the following concepts and tasks

explained in this chapter:

• The char_config Group

• Common Characterization Attributes

• NLPM Characterization Attributes

• CCS Timing Characterization Attributes

• Input-Capacitance Characterization Attributes

The char_config Group

The char_config group represents library characterization configuration and is a group

of attributes that specify the settings to characterize a library. The library characterization

settings include general and specific settings. The general settings are for common tasks,

such as characterizing delays, input waveforms, output loads, and handling simulation

results. The specific settings include settings for specific characterization models, such as

delay, slew, constraint, power, and capacitance models.

Without the appropriate settings, library data can be misinterpreted. This can result in

significant differences between the library data and SPICE simulation results. These

settings are also critical for accurate recharacterization of the library.

You can define the char_config group within the library, cell, pin, and timing

groups. You should use only one char_config group within each of these groups.

Library Characterization Configuration Syntax

Example 148 shows the general syntax for library characterization configuration.

Liberty User Guide Volume 1

R-2020.09

751

Appendix A: Library Characterization Configuration

The char_config Group

Example 148 General Syntax for Library Characterization Configuration

library (library_name) {

char_config() {

/* characterization configuration attributes */

}

...

cell (cell_name) {

char_config() {

/* characterization configuration attributes */

}

...

pin(pin_name) {

char_config() {

/* characterization configuration attributes */

}

timing() {

char_config() {

/* characterization configuration attributes */

}

} /* end of timing */

...

} /* end of pin */

...

} /* end of cell */

...

} /* end of library */

The char_config group includes simple, and complex characterization configuration

attributes.

These characterization configuration attributes are divided into the following categories:

•

Common configuration

• Three-state

•

Composite current source (CCS) timing

•

Input capacitance

Example 149 shows the use of these attributes to document the library characterization

settings.

Example 149 Library Characterization Configuration Example

library (library_test) {

lu_table_template(waveform_template) {

variable_1 : input_net_transition;

variable_2 : normalized_voltage;

index_1 ("0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7");

index_2 ("0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

}

Liberty User Guide Volume 1

R-2020.09

752

Appendix A: Library Characterization Configuration

The char_config Group

normalized_driver_waveform (waveform_template) {

driver_waveform_name : input_driver;

values ("0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.07, 0.08, 0.09", \

"0.11, 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19", \

...

"0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

}

normalized_driver_waveform (waveform_template) {

driver_waveform_name : input_driver_cell_test;

values ("0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.07, 0.08, 0.09", \

"0.11, 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19", \

...

"0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

}

normalized_driver_waveform (waveform_template) {

driver_waveform_name : input_driver_rise;

values ("0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.07, 0.08, 0.09", \

"0.11, 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19", \

...

"0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

}

normalized_driver_waveform (waveform_template) {

driver_waveform_name : input_driver_fall;

values ("0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.07, 0.08, 0.09", \

"0.11, 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19", \

...

"0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9");

}

char_config() {

/* library level default attributes*/

driver_waveform(all, input_driver);

input_stimulus_transition(all, 0.1);

input_stimulus_interval(all, 100.0);

unrelated_output_net_capacitance(all, 1.0);

default_value_selection_method(all, any);

merge_tolerance_abs( nldm, 0.1) ;

merge_tolerance_abs( constraint, 0.1) ;

merge_tolerance_abs( capacitance, 0.01) ;

merge_tolerance_abs( nlpm, 0.05) ;

merge_tolerance_rel( all, 2.0) ;

merge_selection( all, max) ;

internal_power_calculation : exclude_switching_on_rise ;

ccs_timing_segment_voltage_tolerance_rel: 1.0 ;

ccs_timing_delay_tolerance_rel: 2.0 ;

ccs_timing_voltage_margin_tolerance_rel: 1.0 ;

receiver_capacitance1_voltage_lower_threshold_pct_rise : 20.0;

receiver_capacitance1_voltage_upper_threshold_pct_rise : 50.0;

receiver_capacitance1_voltage_lower_threshold_pct_fall : 50.0;

receiver_capacitance1_voltage_upper_threshold_pct_fall : 80.0;

receiver_capacitance2_voltage_lower_threshold_pct_rise : 20.0;

receiver_capacitance2_voltage_upper_threshold_pct_rise : 50.0;

receiver_capacitance2_voltage_lower_threshold_pct_fall : 50.0;

Liberty User Guide Volume 1

R-2020.09

753

Appendix A: Library Characterization Configuration

Common Characterization Attributes

receiver_capacitance2_voltage_upper_threshold_pct_fall : 80.0;

capacitance_voltage_lower_threshold_pct_rise : 20.0;

capacitance_voltage_lower_threshold_pct_fall : 50.0;

capacitance_voltage_upper_threshold_pct_rise : 50.0;

capacitance_voltage_upper_threshold_pct_fall : 80.0;

...

}

...

cell (cell_test) {

char_config() {

/* input driver for cell_test specifically */

driver_waveform (all, input_driver_cell_test);

/* specific default arc selection method for constraint */

default_value_selection_method (constraint, max);

default_value_selection_method_rise(nldm_transition, min);

default_value_selection_method_fall(nldm_transition, max);

internal_power_calculation : exclude_switching_on_rise;

...

}

...

pin(pin1) {

char_config() {

driver_waveform_rise(delay, input_driver_rise);

internal_power_calculation : exclude_switching_on_rise;

}

...

timing() {

char_config() {

driver_waveform_rise(constraint, input_driver_rise);

driver_waveform_fall(constraint, input_driver_fall);

/* specific ccs segmentation tolerance for this timing arc */

ccs_timing_segment_voltage_tolerance_rel: 2.0 ;

}

} /* timing */

} /* pin */

} /* cell */

} /* lib */

Common Characterization Attributes

To specify the common characterization settings, set the common configuration attributes.

All common configuration attributes of the char_config group are complex. A complex

characterization configuration attribute has the following syntax:

Syntax

complex_attribute_name ( char_model, value ) ;

The first argument of the complex attribute is the characterization model. The second

argument is a value of this attribute, such as a waveform name, a specific characterization

Liberty User Guide Volume 1

R-2020.09

754

Appendix A: Library Characterization Configuration

Common Characterization Attributes

method, a numerical value of a model parameter, or other values. Use the syntax to apply

the attribute value to a specific characterization model. You can specify multiple complex

attributes in the char_config group. You can also specify a single complex attribute

multiple times for different characterization models.

However, when you specify the same attribute in multiple char_config groups at different

levels, such as at the library, cell, pin, and timing levels, the attribute specified at the lower

level gets priority over the ones specified at the higher levels. For example, the pin-level

char_config group attributes have higher priority over the library-level char_config

group attributes. Table 37 lists the valid characterization models of the char_config group

and their corresponding descriptions.

Table 37 Valid Characterization Models of the char_config Group

Characterization model Description

all Default model. The all model has the lowest priority

among the characterization models. Any other

characterization model overrides the all model.

ndlm Nonlinear delay model (NLDM)

nldm_delay

nldm_transition

Specific NLDMs with higher priority over the default NLDM

capacitance Capacitance model

constraint Constraint model

constraint_setup

constraint_hold

constraint_recovery

constraint_removal

constraint_skew

constraint_min_pulse_width

constraint_no_change

constraint_non_seq_setup

constraint_non_seq_hold

constraint_minimum_period

Specific constraint models with higher priority over the

general constraint model

nlpm Nonlinear power model (NLPM)

Liberty User Guide Volume 1

R-2020.09

755

Appendix A: Library Characterization Configuration

Common Characterization Attributes

Characterization model Description

nlpm_leakage

nlpm_input

nlpm_output

Specific NLPMs with higher priority over the general

NLPM

Example 150 shows the syntax of the characterization configuration complex attributes.

Example 150 Syntax of Common Configuration Complex Attributes in the char_config Group

char_config() {

driver_waveform(char_model, waveform_name);

driver_waveform_rise(char_model, waveform_name);

driver_waveform_fall(char_model, waveform_name);

input_stimulus_transition(char_model, float);

input_stimulus_interval(char_model, float);

unrelated_output_net_capacitance(char_model, float);

default_value_selection_method(char_model, method);

default_value_selection_method_rise(char_model, method);

default_value_selection_method_fall(char_model, method);

merge_tolerance_abs(char_model, float) ;

merge_tolerance_rel(char_model, float) ;

merge_selection(char_model, method) ;

...

}

Figure 119 illustrates the use of driver_waveform, input_stimulus_transition, and

input_stimulus_interval attributes for the delay arc characterization of a D flip-flop.

Liberty User Guide Volume 1

R-2020.09

756

Appendix A: Library Characterization Configuration

Common Characterization Attributes

Figure 119 Delay Arc Characterization

In Figure 119, an input stimulus with multiple transitions characterizes the delay arc,

CP to Q or QN. The input_stimulus_transition and input_stimulus_interval

attributes define and control the transitions and corresponding intervals, respectively. The

driver_waveform attribute controls the last transition of the clock pulse, CP.

driver_waveform Attribute

The driver_waveform attribute defines the driver waveform to characterize a specific

characterization model.

You can define the driver_waveform attribute within the char_config group at the

library, cell, pin, and timing levels. If you define the driver_waveform attribute within the

char_config group at the library level, the library-level normalized_driver_waveform

group is ignored when the driver_waveform_name attribute is not defined.

If you do not define this attribute in the char_config group, the ramp waveform is used by

default.

Liberty User Guide Volume 1

R-2020.09

757

Appendix A: Library Characterization Configuration

Common Characterization Attributes

driver_waveform_rise and driver_waveform_fall Attributes

The driver_waveform_rise and driver_waveform_fall attributes define a specific

rising and falling driver waveform, respectively, for a specific characterization model.

You can define the driver_waveform_rise and driver_waveform_fall attributes

within the char_config group at the library, cell, pin, and timing levels. If you define the

driver_waveform_rise and driver_waveform_fall attributes within the char_config

group at the library level, the library-level normalized_driver_waveform group is ignored

when the driver_waveform_name attribute is not defined.

If you do not define these attributes in the char_config group, the ramp waveform is used

by default.

input_stimulus_transition Attribute

The input_stimulus_transition attribute specifies the transition time for all the input-

signal edges except the arc input pin's last transition, during generation of the input

stimulus for simulation. For example, in figure in Common Characterization Attributes, the

last transition of the clock pulse, CP, uses the driver_waveform attribute, and not the

input_stimulus_transition attribute.

The time units of the input_stimulus_transition attribute are specified by the library-

level time_unit attribute.

You must define this attribute.

input_stimulus_interval Attribute

The input_stimulus_interval attribute specifies the time-interval between the input-

signal toggles to generate the input stimulus for a characterization cell. The time units of

this attribute are specified by the library-level time_unit attribute.

You must define the input_stimulus_interval attribute.

unrelated_output_net_capacitance Attribute

The unrelated_output_net_capacitance attribute specifies a load value for an output

pin that is not a related output pin of the characterization model. The valid value is a

floating-point number, and is defined by the library-level capacitive_load_unit attribute.

If you do not specify this attribute for the nldm_delay and nlpm_output characterization

models, the unrelated output pins use the load value of the related output pin. However,

you must specify this attribute for any other characterization model.

Liberty User Guide Volume 1

R-2020.09

758

Appendix A: Library Characterization Configuration

Common Characterization Attributes

default_value_selection_method Attribute

The default_value_selection_method attribute defines the method of selecting a

default for

•

The delay arc from state-dependent delay arcs.

•

The constraint arc from state-dependent constraint arcs.

• Pin-based minimum pulse-width constraints from simulated results with side pin

combinations.

•

Internal power arcs from multiple state-dependent internal_power groups.

•

The cell_leakage_power attribute from the state-dependent values in leakage power

models.

•

The input-pin capacitance from capacitance values for input-slew values used for

timing characterization.

default_value_selection_method_rise and

default_value_selection_method_fall Attributes

Use the default_value_selection_method_rise and

default_value_selection_method_fall attributes when the selection methods for rise

and fall are different.

You must define either the default_value_selection_method

attribute, or the default_value_selection_method_rise and

default_value_selection_method_fall attributes. Table 38 lists the

valid selection methods for the default_value_selection_method,

default_value_selection_method_rise, default_value_selection_method_fall,

and merge_selection attributes and their descriptions.

Table 38 Valid Common Configuration Selection Methods

Method Description

any Selects a random value from the state-dependent data

min Selects the minimum value from the state-dependent data at each index point.

max Selects the maximum value from the state-dependent data at each index point.

average Selects an average value from the state-dependent data at each index point.

Liberty User Guide Volume 1

R-2020.09

759

Appendix A: Library Characterization Configuration

Common Characterization Attributes

Method Description

min_mid_table When the state-dependent data is a lookup table (LUT), this method selects the

minimum value from the LUT. The minimum value is selected by comparing the

middle value in the LUT, with each of the table-values.

Note:

The middle value corresponds to an index value. If the number of index

values is odd, then the middle value is taken as the median value. However,

if the number of index values is even, then the smaller of the two values is

selected as the middle value.

max_mid_table When the state-dependent data is a lookup table (LUT), this method selects the

maximum value from the LUT. The maximum value is selected by comparing

the middle value in the LUT, with each of the table-values.

Note:

The middle value corresponds to an index value. If the number of index

values is odd, then the middle value is taken as the median value. However,

if the number of index values is even, then the smaller of the two values is

selected as the middle value.

follow_delay Selects the value from the state-dependent data for delay selection. This

method is valid only for the nldm_transition characterization model, that

is, the follow_delay method applies specifically to default transition-table

selection and not any other default selection.

merge_tolerance_abs and merge_tolerance_rel Attributes

The merge_tolerance_abs and merge_tolerance_rel attributes specify the absolute

and relative tolerances, respectively, to merge arc simulation results. Specify the absolute

tolerance value in the corresponding library unit, and the relative tolerance value in

percent, for example, 10.0 for 10 percent.

If you specify both the merge_tolerance_abs and merge_tolerance_rel attributes, the

results are merged if either or both the tolerance conditions are satisfied. If you do not

specify any of these attributes, data including identical data is not merged.

merge_selection Attribute

The merge_selection attribute specifies the method of selecting the merged data.

When multiple sets of state-dependent data are merged, the attribute selects a

Liberty User Guide Volume 1

R-2020.09

760

Appendix A: Library Characterization Configuration

NLPM Characterization Attributes

particular set of the state-dependent data to represent the merged data. See the table in

default_value_selection_method_rise and default_value_selection_method_fall Attributes

for the valid methods and their descriptions of the merge_selection attribute.

You must define the merge_selection attribute if you have defined either of the

merge_tolerance_abs or merge_tolerance_rel attributes.

NLPM Characterization Attributes

The NLPM internal_power group of the output pin includes the rise_power and

fall_power lookup tables that store the respective values. The internal_power lookup

table values account for the switching energy. This is done using one of the following two

methods:

•

Deducting CV

from only the rise_power total energy values

•

Deducting CV

/2 from each of the rise_power and fall_power total energy values

The total energy is the energy dissipated when the pin makes a transition excluding the

static leakage energy. CV

is the switching energy dissipated by the capacitive load on a

net when the net makes a logical transition.

To specify the method to deduct the switching energy from the internal_power

table values, set the internal_power_calculation attribute. Specify this

attribute only if the internal_power group exists in the library. You can define the

internal_power_calculation attribute within the char_config group at the library, cell,

and pin levels.

Example 151 example shows the syntax of the internal_power_calculation simple

attribute.

Example 151 Syntax of NLPM Characterization Simple Attribute

char_config() {

internal_power_calculation : exclude_switching_on_rise | \

exclude_switching_on_rise_and_fall | include_switching];

...

}

The internal_power_calculation attribute has the following values:

•

exclude_switching_on_rise

Indicates that the switching energy is deducted only from the rise_power table values.

•

exclude_switching_on_rise_and_fall

Indicates that the switching energy is deducted from both the rise_power and

fall_power table values

Liberty User Guide Volume 1

R-2020.09

761

Appendix A: Library Characterization Configuration

CCS Timing Characterization Attributes

• include_switching

Indicates that the switching energy is not deducted from the table values in the

internal_power group

The attribute does not have a default.

The following example shows the use of the internal_power_calculation attribute.

library (lib1) {

…

char_config () {

…

internal_power_calculation : exclude_switching_on_rise;

…

}

cell (cell1) {

char_config () {

…

internal_power_calculation : exclude_switching_on_rise_and_fall;

…

}

pin(pin1) {

char_config () {

…

internal_power_calculation : include_switching;

…

}

…

} /* end of pin */

…

} /* end of cell */

…

} /* end of library */

CCS Timing Characterization Attributes

To specify the CCS timing characterization settings, set the simple attributes that define

CCS timing generation. Example 152 shows the syntax of these simple attributes.

Example 152 Syntax of CCS Timing Simple Attributes

char_config() {

ccs_timing_segment_voltage_tolerance_rel: float;

ccs_timing_delay_tolerance_rel: float;

ccs_timing_voltage_margin_tolerance_rel: float;

receiver_capacitance1_voltage_lower_threshold_pct_rise : float;

receiver_capacitance1_voltage_upper_threshold_pct_rise : float;

receiver_capacitance1_voltage_lower_threshold_pct_fall : float;

receiver_capacitance1_voltage_upper_threshold_pct_fall : float;

receiver_capacitance2_voltage_lower_threshold_pct_rise : float;

Liberty User Guide Volume 1

R-2020.09

762

Appendix A: Library Characterization Configuration

CCS Timing Characterization Attributes

receiver_capacitance2_voltage_upper_threshold_pct_rise : float;

receiver_capacitance2_voltage_lower_threshold_pct_fall : float;

receiver_capacitance2_voltage_upper_threshold_pct_fall : float;

...

}

You must define all these attributes if the library includes a CCS model.

ccs_timing_segment_voltage_tolerance_rel Attribute

The ccs_timing_segment_voltage_tolerance_rel attribute specifies the maximum

permissible voltage difference between the simulation waveform and the CCS waveform to

select the CCS model point. The floating-point value is specified in percent, where 100.0

represents 100 percent maximum permissible voltage difference.

ccs_timing_delay_tolerance_rel Attribute

The ccs_timing_delay_tolerance_rel attribute specifies the acceptable difference

between the CCS waveform delay and the delay measured from simulation. The floating-

point value is specified in percent, where 100.0 represents 100 percent acceptable

difference.

ccs_timing_voltage_margin_tolerance_rel Attribute

The ccs_timing_voltage_margin_tolerance_rel attribute specifies the voltage

tolerance to determine whether a signal has reached the rail-voltage value. The floating-

point value is specified as a percentage of the rail voltage, such as 96.0 for 96 percent of

the rail voltage.

CCS Receiver Capacitance Attributes

The following attributes specify the current integration limits, as a percentage of the

voltage, to calculate the CCS receiver capacitances:

•

receiver_capacitance1_voltage_lower_threshold_pct_rise

•

receiver_capacitance1_voltage_upper_threshold_pct_rise

• receiver_capacitance1_voltage_lower_threshold_pct_fall

•

receiver_capacitance1_voltage_upper_threshold_pct_fall

•

receiver_capacitance2_voltage_lower_threshold_pct_rise

• receiver_capacitance2_voltage_upper_threshold_pct_rise

Liberty User Guide Volume 1

R-2020.09

763

Appendix A: Library Characterization Configuration

Input-Capacitance Characterization Attributes

• receiver_capacitance2_voltage_lower_threshold_pct_fall

• receiver_capacitance2_voltage_upper_threshold_pct_fall

The floating-point values of these attributes can vary from 0.0 to 100.0.

Input-Capacitance Characterization Attributes

To specify input-capacitance characterization settings, set the simple attributes that

define input-capacitance measurement. Example 153 shows the syntax of these simple

attributes.

Example 153 Syntax of Input-Capacitance Characterization Simple Attributes

char_config() {

capacitance_voltage_lower_threshold_pct_rise : float;

capacitance_voltage_lower_threshold_pct_fall : float;

capacitance_voltage_upper_threshold_pct_rise : float;

capacitance_voltage_upper_threshold_pct_fall : float;

...

}

Each floating-point threshold value is specified as a percentage of the supply voltage, and

can vary from 0.0 to 100.0.

You must define all the simple attributes mentioned in Example 153, in the char_config

group for input-capacitance characterization.

capacitance_voltage_lower_threshold_pct_rise and

capacitance_voltage_lower_threshold_pct_fall Attributes

The capacitance_voltage_lower_threshold_pct_rise and

capacitance_voltage_lower_threshold_pct_fall attributes specify the lower-

threshold value of a rising and falling voltage waveform, respectively, for calculating the

NLDM input-pin capacitance.

capacitance_voltage_upper_threshold_pct_rise and

capacitance_voltage_upper_threshold_pct_fall Attributes

The capacitance_voltage_upper_threshold_pct_rise and

capacitance_voltage_upper_threshold_pct_fall attributes specify the upper-

threshold value of a rising and falling voltage waveform, respectively, for calculating the

NLDM input-pin capacitance.

Liberty User Guide Volume 1

R-2020.09

764