Liberty

Liberty User Guide
Version 1998, October 1998

Copyright Notice and Proprietary Information
Copyright  1998 Synopsys, Inc. All rights reserved. This software and documentation are owned by Synopsys, Inc., and
furnished under a license agreement. The software and documentation 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 exclusive use of
__________________________________________ and its employees. This is copy number
__________.”
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.
Registered Trademarks
Synopsys, the Synopsys logo, BiNMOS-CBA, CMOS-CBA, COSSAP, DESIGN (ARROWS), DesignPower, DesignWare,
dont_use, Eagle Design Automation, ExpressModel, in-Sync, LM-1000, LM-1200, Logic Modeling, Logic Modeling
(logo), Memory Architect, ModelAccess, ModelTools, PathMill, PLdebug, Powerview, Retargeter, SmartLicense,
SmartLogic, SmartModel, SmartModels, SNUG, SOLV-IT!, SourceModel Library, Stream Driven Simulator_,
Synopsys, Synopsys (logo), Synopsys VHDL Compiler, Synthetic Designs, Synthetic Libraries, TestBench Manager,
TimeMill, ViewBase, ViewData, ViewDoc, ViewDraw, ViewFault, ViewFlow, VIEWFPGA, ViewGen, Viewlogic,
ViewPlace, ViewPLD, ViewScript, ViewSim, ViewState, ViewSynthesis, ViewText, Workview, Workview Office, and
Workview Plus are registered trademarks of Synopsys, Inc.
Trademarks
3-D Debugging, AC/Grade, AMPS, Arcadia, Arkos, Aurora, BCView, BOA, BRT, CBA Design System,
CBA-Frame, characterize, Chip Architect, Chronologic, Compiler Designs, Core Network, Core Store, Cyclone, Data
Path Express, DataPath Architect, DC Expert, DC Expert Plus, DC Professional, Delay Mill, Design Advisor, Design
Analyzer_proposed, Design Exchange, Design Source, DesignTime, DesignWare Developer, Direct RTL, Direct
Silicon Access, dont_touch, dont_touch_network, DW 8051, DWPCI, DxDataBook, DxDataManager, Eagle, Eaglei,
Eagle V, Embedded System Prototype, Floorplan Manager, Formality, FoundryModel, FPGA Compiler II, FPGA
Express, Fusion, FusionHDL, General Purpose Post-Processor, GPP, HDL Advisor, HTX, Integrator, IntelliFlow,
Interactive Waveform Viewer, ISIS, ISIS PreVUE, LM-1400, LM-700, LM-family, Logic Model, ModelSource,
ModelWare, MOTIVE, MS-3200, MS-3400, PathBlazer, PDQ, POET, PowerArc, PowerCODE, PowerGate, PowerMill,
PreVUE, PrimeTime, Protocol Compiler, QUIET, QUIET Expert, RailMill, RTL Analyzer, Shadow Debugger, Silicon
Architects, SimuBus, SmartCircuit, SmartModel Windows, Source-Level Design, SourceModel, SpeedWave, SWIFT,
SWIFT interface, Synopsys Behavioral Compiler, Synopsys Design Compiler, Synopsys ECL Compiler, Synopsys
ECO Compiler, Synopsys FPGA Compiler, Synopsys Frame Compiler, Synopsys Graphical Environment, Synopsys
HDL Compiler, Synopsys Library Compiler, Synopsys ModelFactory, Synopsys Module Compiler, Synopsys Power
Compiler, Synopsys Test Compiler, Synopsys Test Compiler Plus, TAP-in, Test Manager, TestGen, TestGen Expert
Plus, TestSim, Timing Annotator, TLC, Trace-On-Demand, VCS, DCS Express, VCSi, VHDL System Simulator,
ViewAnalog, ViewDatabook, ViewDRC, ViewLibrarian, ViewLibrary, ViewProject, ViewSymbol, ViewTrace, Visualyze,
Vivace, VMD, VSS Expert, VSS Professional VWaves, XFX, XNS, and XTK are trademarks of Synopsys, Inc.
Service Marks
SolvNET is a service mark of Synopsys, Inc.
All other product or company names may be trademarks of their respective owners.
Printed in the U.S.A.
Liberty User Guide, Version 1998
ii
Table of Contents
1 Sample Library Description

General Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Group Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Attribute Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Simple Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Complex Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Define Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
2 Library Groups
Naming the Library Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
General Library Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
technology Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
delay_model Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
bus_naming_style Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
routing_layers Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Defining Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
time_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
voltage_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
current_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
pulling_resistance_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
capacitive_load_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
leakage_power_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
iii
Using Piecewise Linear Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
piece_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
piece_define Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
3 Environment Attributes
Library-Level Default Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Setting Default Cell Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
default_cell_leakage_power Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Setting Default Pin Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Default Timing Attributes for All Delay Models . . . . . . . . . . . . . . . . . . . . . . . 3-4
CMOS Linear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
CMOS Piecewise Linear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Setting Wire Load Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
default_wire_load Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
default_wire_load_capacitance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
default_wire_load_resistance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
default_wire_load_area Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Setting Other Environment Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
default_max_utilization Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
default_operating_conditions Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Examples of Library-Level Default Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Defining Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
operating_conditions Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
timing_range Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Defining Power Supply Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
power_supply group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Defining Wire Load Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
wire_load Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
wire_load_table Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Specifying Delay Scaling Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Intrinsic Delay Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
Slope Sensitivity Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
Drive Capability Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
Pin and Wire Capacitance Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Wire Resistance Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Pin Resistance Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Intercept Delay Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Power Scaling Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
iv
Timing Constraint Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Delay Scaling Factors Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
Scaling Factors for Individual Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Scaling Factors Associated with the Nonlinear Delay Model . . . . . . . . . . . . . . . . 3-27
4 Defining Core Cells

Defining Cell Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
cell Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
area Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
contention_condition Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
handle_negative_constraint Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
pad_cell Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
pad_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
pin_equal Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
pin_opposite Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
scaling_factors Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
type Group Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
base_type Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
bit_from Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
bit_to Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
bit_width Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
data_type Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
vhdl_name Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Cell Group Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Defining Cell Routability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
routing_track Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
tracks Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
total_track_area Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Defining Pin Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
pin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
General Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
capacitance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
clock_gate_enable_pin Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
direction Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
inverted_output Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
pin_func_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
v
Describing Design Rule Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
fanout_load Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
max_fanout Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
min_fanout Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
max_transition Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
min_transition Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
max_capacitance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
min_capacitance Attribute .................................... 4-23
cell_degradation Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
Describing Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
clock Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
min_period Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
min_pulse_width_high and min_pulse_width_low Attributes . . . . . . . . . . . 4-26
Describing Pin Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
function Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
three_state Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
x_function attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
state_function Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31
internal_node Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31
CMOS Pin Group Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31
Defining Bused Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
type Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
base_type Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33
bit_from Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33
bit_to Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33
bit_width Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
data_type Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
down_to Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
bus Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
bus_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36
Pin Attributes and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36
Sample Bus Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-37
Defining Signal Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41
bundle Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41
members Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41
pin Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42
Multibit Latch Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42
vi
Defining a Layout-Related Multibit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43
single_bit_degenerate Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43
Defining Scaled Cell Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44
Scaled Cell Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-45
5 Defining Sequential Cells

Cell Definition Formats for Sequential Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Describing a Flip-Flop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Using an ff Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
clocked_on and clocked_on_also Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
next_state and nextstate_type Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
clear Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
preset Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
clear_preset_var1 Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
clear_preset_var2 Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
ff Group Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Describing a Single-Stage Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Describing a Master-Slave Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Using the function Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Describing a Multibit Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Describing a Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
latch Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
enable and data_in Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
clear Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
preset Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
clear_preset_var1 and clear_preset_var2 Attributes . . . . . . . . . . . . . . . . . . 5-16
Describing a Multibit Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
Describing Sequential Cells with Statetable Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23
statetable Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26
Using Shorthand Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27
Partitioning the Cell into a Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
Defining an Output Pin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
internal_node Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31
input_map Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31
state_function Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
inverted_output Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
Internal Pin Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
vii
Flip-Flop and Latch Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35
Examples of Portions of Cell Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40
6 Modeling Memory Modules

Memory Modeling Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
memory Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
address_width Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
word_width Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
column_address Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
row_address Simple Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
memory_read Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
address Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
memory_write Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
address Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
clocked_on Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
enable Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Examples of Memory Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
7 Defining Input and Output Pads

Identifying Pad Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
pad_cell and auxiliary_pad_cell Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
pad_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
is_pad Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
driver_type Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Defining Units for Pad Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Capacitance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Current. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Describing Input Pads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
input_voltage Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
hysteresis Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
Describing Output and Bidirectional Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
output_voltage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
drive_current Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
driver_type Attribute for Bidirectional Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
viii
Slew-Rate Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
slew_control Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Threshold Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Describing Pull-Up and Pull-Down Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
Modeling Wire Load for Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
Examples of Pad Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
Input Pad and Clock Pad Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
Output Pad Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Bidirectional Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23
8 Defining Test Cells

Describing a Scan Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
test_cell Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Pin Groups in the test_cell Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
test_output_only Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
signal_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Describing a Multibit Scan Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Scan Cell Modeling Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Simple Multiplexed D Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Multibit Cells with Multiplexed D Flip-Flop and Enable . . . . . . . . . . . . . . . . . . . . 8-15
LSSD Scan Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
Clocked-Scan Test Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26
Scan Flip-Flop with Auxiliary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-29
9 Modeling Power
Power Dissipation Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Modeling Leakage Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
cell_leakage_power Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
leakage_power Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
when Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
value Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
k_volt_cell_leakage_power, k_temp_cell_leakage_power, and
k_process_cell_leakage_power Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
leakage_power_unit Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
default_cell_leakage_power Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
ix
Modeling Internal Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
Creating Internal Power Lookup Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
power_lut_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
Template Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Template Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Scalar power_lut_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
internal_power Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
equal_or_opposite_output Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
related_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
when Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
power Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
fall_power Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
rise_power Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17
Syntax for One-Dimensional, Two-Dimensional, and
Three-Dimensional Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
Internal Power Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
One-Dimensional Power Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Two-Dimensional Power Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Three-Dimensional Power Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22
Power-Scaling Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-23
Modeling Libraries with Multiple Power Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-23
Defining power_supply Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
default_power_rail Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
power_rail Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
Defining Cells with Multiple Power Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
rail_connection Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
power_level Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-26
input_signal_level and output_signal_level Attributes. . . . . . . . . . . . . . . . . . 9-27
Multiple Power Supply Library Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28
Example Library with Multiple Power Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29
10 Timing Arcs
Understanding Timing Arcs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Combinational Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Sequential Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
Impossible Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
x
Understanding Delay Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
delay_model Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6
CMOS Linear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
CMOS Piecewise Linear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
piece_define Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
piece_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
CMOS Nonlinear Delay Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Defining the CMOS Nonlinear Delay Model Template . . . . . . . . . . . . . . . . . 10-9
lu_table_template Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
Template Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
Template Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
Creating Lookup Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
Defining Timing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11
timing Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12
timing Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12
related_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13
related_bus_pins Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15
timing_sense Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15
timing_type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16
intrinsic_rise Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19
intrinsic_fall Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20
rise_resistance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20
fall_resistance Attribute ...................................... 10-20
rise_pin_resistance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-21
fall_pin_resistance Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-21
rise_delay_intercept Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-22
fall_delay_intercept Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-22
rise_transition and fall_transition Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 10-23
rise_propagation and fall_propagation Groups . . . . . . . . . . . . . . . . . . . . . 10-24
cell_rise and cell_fall Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-25
slope_rise Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-27
slope_fall Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-27
related_output_pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28
Describing Three-State Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28
Describing Three-State Disable Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28
Describing Three-State Enable Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-29
Timing Model Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-30
Describing Edge-Sensitive Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-31
xi
Describing Preset and Clear Timing Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-31
Describing Preset Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-32
Describing Clear Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-33
Describing Intrinsic Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-34
In the CMOS Linear and Piecewise Linear Delay Models . . . . . . . . . . . . . . . . . 10-35
In the CMOS Nonlinear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-35
Describing Transition Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-35
In the CMOS Linear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-36
In the CMOS Piecewise Linear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-36
Defining Delay Arcs with Lookup Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-38
Modeling Transition Time Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-42
Describing Slope Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-44
In the CMOS Linear and Piecewise Linear Delay Models . . . . . . . . . . . . . . . . . . 10-45
Describing State-Dependent Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-45
when Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-46
sdf_cond Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-47
Setting Setup and Hold Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-49
In the CMOS Linear and Piecewise Linear Delay Models . . . . . . . . . . . . . . . . . 10-51
Setup Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-51
Hold Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-52
Setup and Hold Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-53
rise_constraint and fall_constraint Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 10-54
Modeling Load Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-56
Setting Nonsequential Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-58
Setting Recovery and Removal Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-59
Recovery Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-59
Removal Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-61
Setting No-Change Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-63
In the CMOS Linear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-65
Setting Skew Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-67
Setting Conditional Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-68
when and sdf_cond Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-69
when_start Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-69
sdf_cond_start Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-70
xii
when_end Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-70
sdf_cond_end Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-71
sdf_edges Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-71
min_pulse_width Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-71
constraint_high and constraint_low Attributes . . . . . . . . . . . . . . . . . . . . . . 10-72
when and sdf_cond Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-72
minimum_period Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-73
constraint Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-73
when and sdf_cond Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-73
Using Conditional Attributes with No-Change Constraints . . . . . . . . . . . . . . . . . 10-73
Examples of Libraries Using Delay Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-74
CMOS Linear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-74
CMOS Piecewise Linear Delay Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-77
CMOS Nonlinear Delay Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-79
11 Interface Timing of Complex Sequential Blocks

Interface Timing Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Sequential Cell Timing without ITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Specifying Interface Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Describing Blocks with Interface Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
Examples of Interface Timing Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
Input Setup and Hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Output Propagation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Through Combinational Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8
Interface Timing of a Complex Sequential Block . . . . . . . . . . . . . . . . . . . . . . . . . 11-9
RAM Example Using ITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13
A Technology Library Attributes

How to Use the Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
xiii
xiv
1
Sample Library Description 1
This chapter familiarizes you with the basic format and syntax of a library description.
The first example shows the general syntax of the library. Next, you will learn about the
syntax used to describe a library and how the library description is structured. These
topics are covered in the following sections:
• General Syntax
• Statements
For a complete list of all the groups and attributes in a technology library, see Appendix A.
General Syntax
Example 1-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 library
as a whole. These statements define library features such as technology type, and
definitions and defaults that apply to the library in general. Every cell in the library has
a separate cell description. For more information on cell descriptions, see Chapter 4,
"Defining Core Cells."
Sample Library Description

1-1
Example 1-1 General Syntax of the Library Description
library (name) {
technology (name) ;/* library-level attributes */
delay_model : generic_cmos | table_lookup |
cmos2 | piecewise_cmos ;
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/* environment definitions */
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
}
}

1-2
Statements
Statements are the building blocks of a library. All library information is described in one
of the following types of statements:
• Group statements
• Simple attribute statements
• Complex attribute statements
• Define statements
A statement can continue across multiple lines. A continued line ends with the backslash
character (\).
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 1-2 defines pin group A.
Example 1-2 Group Statement Specification
pin(A) {
... pin group statements ...
}

1-3
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 manual, the word 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:
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 1-3 adds a direction attribute to the pin group in Example 1-2.
Example 1-3 Simple Attribute Specification

pin(A) {
direction : output ;
}
For some simple attributes, you must enclose the attribute_value in quotes:
attribute_name : ”attribute_value” ;
Example 1-4 adds the function X + Y to the pin example.
Example 1-4 Defining the Function of a Pin

pin (A) {
function : ”X + Y” ;
}
Complex Attributes
This is the syntax of a complex attribute statement. Include one or more parameters in
parentheses.
attribute_name (parameter1 [, parameter2, parameter3 ...] );

1-4
The following example uses the complex attribute line 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 values you want to allow for the new attribute: string, integer, or floating
point.
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” ;

1-5
1-6
2
Library Groups 1
A library group is the superior group in a technology library and contains the entire library
description. All other groups and attributes are defined within a library group. The library
description starts with group statements that are defined at the library group level. These
group statements are covered in Chapter 4, "Defining Core Cells."
The library description identifies the characteristics of a technology library and the cells
it contains. Each library source file must have only one library group. Attributes that apply
to the entire library are defined at the library-group level, and come at the beginning of
the description. This chapter covers library-level attributes in the following sections:
• Naming the Library Group

• General Library Attributes
• Defining Units
• Declaring Piecewise Linear Attributes
Library Groups
2-1
Naming the Library Group
The library group statement defines the name of the library you want to describe. It is
required as the first executable line in your library.
Syntax:
library (name) {
Example:
library (my_library) {
...
}
General Library Attributes
The following attributes apply generally to the technology library:
• technology
• delay_model
• bus_naming_style
• routing_layers
technology Attribute
This complex attribute identifies which of the following technology families is used in the
library:
• CMOS (default)
• FPGA
The technology attribute must be the first attribute defined, and it must be placed at the
top of the listing.
Syntax:
technology (”name”) ;
name
CMOS or FPGA. The default is CMOS.
Library Groups
2-2
Example:
technology (”cmos”) ;
delay_model Attribute
This simple attribute indicates the delay model to use in the delay calculations. Models
are
• generic_cmos (default)
• table_lookup
• cmos2
• piecewise_cmos
This attribute must follow the technology attribute; or, if a technology attribute is not
present, it must be the first attribute in the library.
Syntax:
delay_model : ”model” ;
model
Use generic_cmos (default), table_lookup, cmos2, or piecewise_cmos.
Example:
delay_model : ”piecewise_cmos” ;
bus_naming_style Attribute
This attribute defines the naming convention for buses in the library.
Syntax:
bus_naming_style : ”string” ;
string
Can contain 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, but at least one nonnumeric character must
separate them.
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.
Library Groups
2-3
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 symbol,
and the member number replaces the %d symbol.
The default style for the bus_naming_style attribute is:
bus_naming_style : ”%s[%d]” ;
routing_layers Attribute
This complex attribute declares the routing layers available for place and route for the
library, and must be defined before other routability information in a cell. This attribute
is a string that represents the symbolic name used later in a library to describe routability
information associated with each layer.
Each library can have only one routing_layers complex attribute.
Syntax:
routing_layers (”routing_layer_1_name”, ...,
”routing_layer_n_name”) ;
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 (such as nanoseconds or picofarads) used in the
library definitions.
Library Groups
2-4
time_unit Attribute
The VHDL library generator uses this attribute to identify the physical time unit used in
the generated library.
Syntax:
time_unit : ”unit” ;
unit
Values are 1ps, 10ps, 100ps, and 1ns. The default is 1ns.
Example:
time_unit : ”10ps”;
voltage_unit Attribute
All voltage values in the operating_conditions group are in the voltage units specified
by the voltage_unit attribute. This simple attribute also determines the units for the
input_voltage and output_voltage groups. See Chapter 3, “Environment Attributes,” for
more information.
Syntax:
voltage_unit : ”unit” ;
unit
Values are 1mV, 10mV, 100mV, and 1V. The default value is 1V.
Example:
voltage_unit : ”100mV”;
current_unit Attribute
This simple attribute specifies the units for the drive current generated by output pads.
See Chapter 7, "Defining Input and Output Pads," for more information.
The units you specify for current_unit also apply to the pulling_current attribute for a pull-
up or pull-down transistor.
Syntax:
current_unit : ”unit” ;
Library Groups
2-5
unit
Values are 1uA, 10uA, 100uA, 1mA, 10mA, 100mA, and 1A. No default value exists
for current_unit.
Example:
current_unit : "1mA";
pulling_resistance_unit Attribute
This attribute defines pulling resistance values for pull-up and pull-down devices.
Syntax:
pulling_resistance_unit : ”unit” ;
unit
Valid unit values are 1ohm, 10ohm, 100ohm, and 1kohm. No default value exists
for pulling_resistance_unit if the attribute is omitted.
Example:
pulling_resistance_unit : ”10ohm” ;
capacitive_load_unit Attribute
This complex attribute specifies the units for all capacitance values within the technology
library, including default capacitances, maximum fanout capacitances, pin capacitances,
and wire capacitances.
Syntax:
capacitive_load_unit (value,unit) ;
value,unit
Unit values are ff and pf. The first line in the following example sets the capacitive
load unit to 1 picofarad. The second line represents capacitance in terms of the
standard unit load of an inverter.
Example:
capacitive_load_unit (1,pf) ;
capacitive_load_unit (0.059,pf) ;
The capacitive_load_unit attribute has no default value.
Library Groups
2-6
leakage_power_unit Attribute
This simple 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 : ”unit” ;
unit
Values are 1mW, 100uW, 10uW, 1uW, 100nW, 10nW, 1nW, 100pW, 10pW, and 1pW.
Example:
leakage_power_unit : ”100uW” ;
Using Piecewise Linear Attributes
If your library uses piecewise linear delay models, use these library-level attributes:
• piece_type
• piece_define
For more information on delay models, see Chapter 10, "Timing Arcs."
piece_type Attribute
This simple attribute allows you the option of using capacitance instead of wire length
to define the piecewise linear model.
Syntax:
piece_type : value ;
value
Possible values: piece_length, piece_wire_cap, piece_pin_cap, or piece_total_cap.
Example:
piece_type : piece_length ;
Library Groups
2-7
The piece_wire_cap, piece_pin_cap, and piece_total_cap values represent the
piecewise linear model extensions that cause modeling to use capacitance instead of
length. These values are used to indicate wire capacitance alone, total pin capacitance,
or the total wire and pin capacitance. If the piece_type attribute is not defined, modeling
defaults to the piece_length model.
piece_define Attribute
This attribute defines the pieces used in the piecewise linear delay model. With this
attribute, you can define the ranges of length or capacitance for indexed variables, such
as rise_pin_resistance, used in the delay equations.
You must include in this statement all ranges of wire length or capacitance for which you
want to enter a unique attribute value.
Syntax:
piece_define (”range0 [range1 range2 ...]”) ;
Each range is a floating-point number defining the lower limit of the respective range. If
the piecewise linear model is in the piece_length mode, as described in the "piece_type
Attribute" section, a wire whose length is between range0 and range1 is named as piece
0; a wire whose length is between range1 and range2 is piece 1; and so on.
For example, in the following piece_define specification, a wire of length 5 is referred to

as piece 0; a wire of length 12 is piece 1; and length 20 or more is piece 2.
Example:
piece_define (”0 10 20”) ;
Each capacitance is a positive floating-point number defining the lower limit of the
respective range. A piece of wire whose capacitance is between range0 and range1 is
identified as piece 0, a capacitance between range1 and range2 is piece 1, and so on.
Library Groups
2-8
3
Environment Attributes 1
Variations in operating temperature, supply voltage, and manufacturing process cause
performance variations in electronic networks. These variations are modeled with
environment attributes in a technology library.
The following types of environment attributes are discussed in this chapter:
• Library-level default attributes

• Operating conditions
• Power supply groups
• Wire load groups
• Delay scaling factors
Library-Level Default Attributes
All environment attributes have built-in default settings for typical delays. You can create
your own default settings at the library level by using the default attributes described in
this section.
Environment Attributes
3-1
This section lists default attributes that are set at the library-group level and apply globally
to the technology library. These attributes are categorized as cell-level, pin-level, wire
load, or other environment attributes. You can override many of these defaults with
attributes at the pin level or timing-group level, as shown in Table 3-1.
Table 3-1 CMOS Default Attributes

Attribute Description Override with
default_cell_leakage_power Default leakage power cell_leakage_power
default_edge_rate_breakpoint_f0 a Default edge_rates edge_rate_breakpoint_f0
default_edge_rate_breakpoint_f1 a Default edge_rates edge_rate_breakpoint_f1
default_edge_rate_breakpoint_r0 a Default edge_rates edge_rate_breakpoint_r0
default_edge_rate_breakpoint_r1 a Default edge_rates edge_rate_breakpoint_r1
default_fall_delay_intercept b Falling-edge intercept of timing arc fall_delay_intercept
default_fall_pin_resistance b Fall resistance of output pins fall_pin_resistance
default_fanout_load Fanout load of input pins fanout_load
default_inout_pin_cap Capacitance of inout pins capacitance
default_inout_pin_fall_res c Fall resistance of inout pins fall_resistance
default_inout_pin_rise_res c Rise resistance of inout pins rise_resistance
default_input_pin_cap Capacitance of input pins capacitance
default_intrinsic_fall Intrinsic fall delay of a timing arc intrinsic_fall
default_intrinsic_rise Intrinsic rise delay of a timing arc intrinsic_rise
default_max_capacitance Maximum capacitance of max_capacitance
output pins
default_max_fanout Maximum fanout of all output pins max_fanout
default_max_transition Maximum transition of output pins max_transition
default_max_utilization Maximum limit of utilization No override available
default_operating_conditions Default operating conditions operating_conditions
for the library
default_output_pin_cap Capacitance of output pins capacitance
default_output_pin_fall_res c Fall resistance of output pins fall_resistance
default_output_pin_rise_res c Rise resistance of output pins rise_resistance
default_rc_fall_coefficient a Scaling factor for an rc fall No override available
default_rc_rise_coefficient a Scaling factor for an rc rise No override available
default_reference_capacitance a Default capacitance used during cell reference_capacitance
characterization
default_rise_delay_intercept b Rising-edge intercept of timing arc rise_delay_intercept
default_rise_pin_resistance b Rise resistance of output pins rise_pin_resistance
default_slope_fall Fall sensitivity factor of a slope_fall
timing arc
3-2
Attribute Description Override with
default_slope_rise Rise sensitivity factor of a slope_rise
timing arc
default_wire_load Wire load No override available
default_wire_load_area Wire-load area No override available
default_wire_load_capacitance Wire-load capacitance No override available
default_wire_load_resistance Wire load resistance No override available
default_wire_load_selection Wire load selection No override available
a. CMOS2 delay model only
b. Piecewise linear delay model only
c. CMOS linear delay model only
Setting Default Cell Attributes

This section lists the default cell attribute that is specified at the library level and applies
to all cells in a library.
default_cell_leakage_power Attribute
The default_cell_leakage_power attribute is a library-level attribute. It indicates the
default leakage power for those cells that do not have the cell_leakage_power attribute
assigned.
Example:
default_cell_leakage_power : .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. The
CMOS nonlinear delay model does not support default timing attributes. Use only the
default attributes that apply to your timing model, which can be one of the following:
• CMOS linear (standard) delay model

• CMOS piecewise linear delay model
See Chapter 10, "Timing Arcs," for more information on delay models and timing
attributes.
3-3
Default Timing Attributes for All Delay Models
The attributes described in this section apply to all delay models. For each attribute,
value is a floating-point number.
default_inout_pin_cap : value;
Sets a default value for capacitance for all inout pins in a library.
default_input_pin_cap : value;
Sets a default value for capacitance for all input pins in a library.
default_output_pin_cap : value;
Sets a default value for capacitance for all output pins in library.
default_fanout_load : value;
Sets a default value for fanout_load for all input pins in the library.
default_max_fanout : value;
Sets a default value for max_fanout for all output pins in the library.
default_max_transition : value;
Sets a default value for max_transition for all output pins in the library.
Example 3-1 shows default pin attributes in a CMOS library:
Example 3-1 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 ;
...
}
CMOS Linear Delay Model

These are the default timing attributes for a library that uses a CMOS linear delay model.
For each attribute, value is a floating-point number.
default_inout_pin_fall_res : value;
Sets a default value for fall_resistance for all inout pins in a library.
3-4
default_output_pin_fall_res : value;
Sets a default value for fall_resistance for all output pins in a library.
default_inout_pin_rise_res : value;
Sets a default value for rise_resistance for all inout pins in library.
default_output_pin_rise_res : value;
Sets a default value for rise_resistance for all output pins in a library.
default_slope_fall : value;
Sets a default value for slope_fall for all output pins in the library.
default_slope_rise : value;
Sets a default value for slope_rise for all output pins in the library.
default_intrinsic_fall : value;
Sets a default value for intrinsic_fall for all timing arcs in the library.
default_intrinsic_rise : value;
Sets a default value for intrinsic_rise for all timing arcs in the library.
Example 3-2 sets the default timing attributes for a CMOS linear delay model.
Example 3-2 Setting Standard Timing Default Attributes

library (example) {
...
/* default timing attributes */
default_inout_pin_fall_res : 12.0;
default_output_pin_fall_res : 12.0;
default_inout_pin_rise_res : 15.2;
default_output_pin_rise_res : 15.3;
default_intrinsic_fall : 1.0;
default_intrinsic_rise : 1.0;
...
}
CMOS Piecewise Linear Delay Model

These are the default timing attributes for a library that uses the CMOS piecewise linear
delay model. For each attribute, value is a floating-point number.
default_rise_delay_intercept : value;
Sets a default value for rise_delay_intercept on all output pins in the library.
default_fall_delay_intercept : value;
Sets a default value for fall_delay_intercept on all output pins in the library.
3-5
default_rise_pin_resistance : value;
Sets a default value for rise_pin_resistance on all output pins in the library.
default_fall_pin_resistance : value;
Sets a default value for fall_pin_resistance on all output pins in the library.
default_intrinsic_fall : value;
Sets a default value for intrinsic_fall for all timing arcs in the library.
default_intrinsic_rise : value;
Sets a default value for intrinsic_rise for all timing arcs in the library.
Example 3-3 illustrates the default timing attribute settings for a piecewise linear timing
delay model.
Example 3-3 Setting Piecewise Linear Default Timing Attributes

library (example) {
...
default_rise_delay_intercept : 1.0;
default_fall_delay_intercept : 1.0;
default_rise_pin_resistance : 1.5;
default_fall_pin_resistance : 0.4;
...
}
Setting Wire Load Defaults

This section discusses library-level attributes used to set wire load defaults:
default_wire_load Attribute
Assigns the default values to the wire_load group. You can select a wire load
automatically by using the wire_load_selection attribute.
Syntax:
default_wire_load : wire_load_name;
Example:
default_wire_load : WL1;
3-6
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_area : value;
Example:
default_wire_load_area : 0.33;
Setting Other Environment Defaults

This section covers miscellaneous library-level attributes that set other environment
defaults.
default_max_utilization Attribute
Defines the upper limit placed on the utilization of a chip.
Syntax:
default_max_utilization : value;
3-7
Example:
default_max_utilization : 0.08;
Utilization is defined as the percentage of total die size taken up by total cell area.
For example, if total cell area is 100,000 and the total die size on which these cells will
be placed is 150,000, then utilization is 66.6 percent. The utilization of a chip implicitly
defines how much room there is for routing between layers of silicon.
Generally, the higher the utilization you place on a chip, the more difficult a design is to
route because there is less physical area available to do the routing.
default_operating_conditions Attribute
Assigns a default operating_conditions group name for the library. It must be specified
after all operating_conditions groups are specified. If this attribute is not used, nominal
operating conditions apply. See “Defining Operating Conditions” later in this chapter.
Syntax:
default_operating_conditions : operating_condition_name;
Example:
default_operating_conditions : WCCOM1;
Examples of Library-Level Default Attributes

Example 3-4 illustrates a library-level default attribute setting for a CMOS library. 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 3-4 Setting Library-Level Defaults 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;
3-8
default_slope_fall : 0.0;
default_slope_rise : 0.0;
default_fanout_load : 1.0;
default_max_fanout : 10.0;
wire_load (WL1) {
...
}
operating_conditions (OP1) {
...
}
default_wire_load : WL1;
default_operating_conditions : OP1;
default_wire_load_mode : enclosed;
...
}
Defining Operating Conditions
This section explains how to define and determine various operating conditions for a
technology library.
operating_conditions Group
An operating_conditions group is defined in a library group. The syntax is
library ( lib_name ) {
operating_conditions ( name ) {
... operating conditions description ...
}
}
The name identifies the set of operating conditions. Names of all operating_conditions
groups and wire_load groups must be unique within a library.
3-9
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:
power_rail : “name” ;
The power_supply group can define one or more power_rail attributes. The
power_rail attribute identifies all power supplies that have nominal operating
conditions (defined in the operating_conditions group) and the nominal voltage
values.
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.
temperature : value;
The ambient temperature in which the design is to operate, often 25 degrees Celsius
(room temperature). The value is a floating-point number from -300 through +500.
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 1000, representing the absolute value of
the actual voltage. Define voltage units consistently. See the section on the
voltage_unit attribute in Chapter 2, “Library Groups,” for more information.
tree_type : model;
The definition for the environment interconnect model. The model is one of the
following:
best_case_tree
Models the case where 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 where 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 where 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.
power_rail (name, value)
Identifies all power supplies that have the nominal operating conditions (defined
in the operating_conditions group) and the nominal voltage values.
3-10
timing_range Group
A timing_range group models statistical fluctuations in the defined operating conditions
defined for your design during the optimization process. A timing_range group is defined
at the library-group level:
library (lib_name) {
timing_range (name) {
... timing_range description ...
}
}
A timing_range group defines two multipliers that scale the signal arrival times. In the
following attributes, multiplier is a floating-point number:
faster_factor : multiplier;
Scaling factor applied to the signal arrival time to model the fastest possible arrival
time.
slower_factor : multiplier;
Scaling factor applied to the signal arrival time to model the slowest possible arrival
time.
Example 3-5 describes the SLOW_RANGE and FAST_RANGE timing ranges.
Example 3-5 Defining Timing Ranges

library (example) {
...
timing_range (SLOW_RANGE) {
faster_factor : 1.05;
slower_factor : 1.2;
}
timing_range (FAST_RANGE) {
faster_factor : 0.90;
slower_factor : 0.96;
}
...
}
Defining Power Supply Groups
Use the power_supply group to model multiple power supply cells. See Chapter 9,
"Modeling Power," for more information.
3-11
power_supply group
The power_supply group captures all nominal information on voltage variation. It is
defined before the operating_conditions group and before the cell groups. All the power
supply names defined in the power_supply group exist in the operating_conditions group.
The power_supply group is defined at the library level.
Syntax:
power_supply () {
default_power_rail : name ;
power_rail (name, value) ;
power_rail (name, value) ;
...
...
}
Example:
power_supply () {
default_power_rail ; VDD0;
power_rail (VDD1, 5.0) ;
}
Defining Wire Load Groups
Use the wire_load group and wire_load_selection group statements to select 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;
3-12
fanout_length(fanout, length, average_capacitance,
standard_deviation, number_of_nets);
}
Note:
The average_capacitance, standard_deviation, and number_of_nets values
for the fanout_length attribute are considered reserved words. See Appendix
A for a list of reserved words.
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.
You can define any number of wire_load groups in a technology library, but all wire_load
groups and operating_conditions groups must have unique names.
You can define the following attributes in a wire_load group:
resistance : value ;
value is a floating-point number representing wire resistance per unit length of
interconnect wire.
capacitance : value ;
value is a floating-point number representing capacitance per unit length of
interconnect wire.
area : value;
value is a floating-point number representing the area per unit length of interconnect
wire.
slope : value;
value is 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.
fanout_length (fanout, length, average_capacitance, standard_deviation,

number_of_nets);
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.
Note:
If you create a wire load manually, define only fanout and length.
average_capacitance : value
value is a floating-point number that represents average capacitance per net for
all nets in the group.
3-13
standard_deviation : value
value is a floating-point number that represents the statistics of deviation during
the process of creating the attribute.
number_of_nets : value
value is an integer used to indicate how many nets have a fanout number equal
to fanoutint.
Note:
You must define at least one pair (fanout, length) per wire load model. You
can define as many additional pairs as necessary to characterize the fanout-
length behavior you want.
If you do not define a wire_load group, wire resistance and wire capacitance are defined
by default_wire_load_resistance and default_wire_load_capacitance.
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—wire capacitance and resistance no
longer have to be strictly proportional to each other, which, in some cases, results in
more accurate connect delay estimates.
Syntax:
wire_load_table(name) {
fanout_length(fanout, length);
fanout_capacitance(fanout, capacitance);
fanout_resistance(fanout, resistance);
fanout_area(fanout, area);
}
Unlike in the wire_load group, fanout_capacitance, fanout_resistance, and fanout_area

in the wire_load_table group are exact values, not per length coefficients.
Specifying Delay Scaling Factors
Scaling factors are set in the technology library environment. These k-factors (attributes
that begin with k_) are multipliers that scale defined library values, taking into account
the effects of changes in process, temperature, and voltage.
3-14
The following types of attributes deal with the effects of process, temperature, and
voltage variations on circuit timing:
• 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. See “Scaling Factors for Individual Cells” later in this chapter.
The scaling factors you define for your library depend on the timing delay model you
use. The following k-factors are used for all delay models unless otherwise indicated:
• Intrinsic delay factors

• Slope sensitivity factors (CMOS linear delay model)
• Drive capability factors (CMOS linear delay model)
• Pin and wire capacitance factors
• Wire resistance factors
• Pin resistance factors (CMOS piecewise linear delay model)
• Intercept delay factors (CMOS piecewise linear delay model)
• Power scaling factors
• Timing constraint factors
Intrinsic Delay Factors

Intrinsic delay factors scale the intrinsic delay according to process, temperature, and
voltage variations. Each attribute gives the multiplier for a certain portion of the intrinsic-
rise delay or intrinsic-fall delay of all cells in the library. In the following syntax, multiplier
is a floating-point number:
k_process_intrinsic_fall : multiplier ;
Scaling factor applied to the intrinsic fall delay of a timing arc to model process
variation.
k_process_intrinsic_rise : multiplier ;
Scaling factor applied to the intrinsic rise delay of a timing arc to model process
variation.
k_temp_intrinsic_fall : multiplier ;
Scaling factor applied to the intrinsic fall delay of a timing arc to model temperature
variation.
3-15
k_temp_intrinsic_rise : multiplier ;
Scaling factor applied to the intrinsic rise delay of a timing arc to model temperature
variation.
k_volt_intrinsic_fall : multiplier ;
Scaling factor applied to the intrinsic fall delay of a timing arc to model voltage
variation.
k_volt_intrinsic_rise : multiplier ;
Scaling factor applied to the intrinsic rise delay of a timing arc to model voltage
variation.
Slope Sensitivity Factors

You can define slope sensitivity factors only in a library that uses a CMOS linear delay
model.
The slope sensitivity factors scale the delay slope according to process, temperature,
and voltage variations. Each attribute gives the multiplier for a certain portion of the rise-
delay slope or fall-delay slope of all cells in the library. In the following syntax, multiplier
is a floating-point number:
k_process_slope_fall : multiplier ;
Scaling factor applied to timing arc fall slope sensitivity to model process variation.
k_process_slope_rise : multiplier ;
Scaling factor applied to timing arc rise slope sensitivity to model process variation.
k_temp_slope_fall : multiplier ;
Scaling factor applied to timing arc fall slope sensitivity to model temperature
variation.
k_temp_slope_rise : multiplier ;
Scaling factor applied to timing arc rise slope sensitivity to model temperature
variation.
k_volt_slope_fall : multiplier ;
Scaling factor applied to timing arc fall slope sensitivity to model voltage variation.
k_volt_slope_rise : multiplier ;
Scaling factor applied to timing arc rise slope sensitivity to model voltage variation.
3-16
Drive Capability Factors
You can define drive capability factors only in a library that uses a CMOS linear delay
model.
The drive capability factors scale the drive capability of a pin according to process,
temperature, and voltage variations. Each attribute gives the multiplier for a certain
portion of a pin’s drive capability in rise delay or fall delay analysis. In the following syntax,
multiplier is a floating-point number:
k_process_drive_current : multiplier;
Scaling factor applied to a timing arc drive_current attribute to model process
variation.
k_process_drive_fall : multiplier ;
Scaling factor applied to a timing arc fall_resistance attribute to model process
variation.
k_process_drive_rise : multiplier ;
Scaling factor applied to a timing arc rise_resistance attribute to model process
variation.
k_temp_drive_current : multiplier;
Scaling factor applied to a timing arc drive_current attribute to model temperature
variation.
k_temp_drive_fall : multiplier ;
Scaling factor applied to a timing arc fall_resistance attribute to model temperature
variation.
k_temp_drive_rise : multiplier ;
Scaling factor applied to a timing arc rise_resistance attribute to model temperature
variation.
k_volt_drive_current : multiplier;
Scaling factor applied to a timing arc drive_current attribute to model voltage
variation.
k_volt_drive_fall : multiplier ;
Scaling factor applied to a timing arc fall_resistance attribute to model voltage
variation.
k_volt_drive_rise : multiplier ;
Scaling factor applied to a timing arc rise_resistance attribute to model voltage
variation.
3-17
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 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.
Wire Resistance Factors

Wire resistance factors scale wire resistance according to process, temperature, and
voltage variations. Each attribute gives the multiplier for a certain portion of the wire
resistance. In the following syntax, multiplier is a floating-point number:
k_process_wire_res : multiplier ;
Scaling factor applied to wire resistance to model process variation.
k_temp_wire_res : multiplier ;
Scaling factor applied to wire resistance to model temperature variation.
k_volt_wire_res : multiplier ;
Scaling factor applied to wire resistance to model voltage variation.
3-18
Pin Resistance Factors
You can define pin resistance factors only in libraries that use a CMOS piecewise linear
delay model.
Pin resistance factors scale resistance according to process, temperature, and voltage
variations. Each attribute gives the multiplier for a certain portion of the wire and pin
resistance. In the following syntax, multiplier is a floating-point number:
k_process_rise_pin_resistance : multiplier ;
Scale factor applied to the rise_pin_resistance attribute to model process variation.
k_process_fall_pin_resistance : multiplier ;
Scale factor applied to the fall_pin_resistance attribute to model process variation.
k_temp_rise_pin_resistance : multiplier ;
Scale factor applied to the rise_pin_resistance attribute to model temperature
variation.
k_temp_fall_pin_resistance : multiplier ;
Scale factor applied to the fall_pin_resistance attribute to model temperature
variation.
k_volt_rise_pin_resistance : multiplier ;
Scale factor applied to the rise_pin_resistance attribute to model voltage variation.
k_volt_fall_pin_resistance : multiplier ;
Scale factor applied to the fall_pin_resistance attribute to model voltage variation.
Intercept Delay Factors

You can define intercept delay factors only in libraries that use a CMOS piecewise linear
delay model.
Intercept delay factors scale the delay intercept according to process, temperature, and
voltage variations. These factors are used with slope or intercept-type timing equations.
Each attribute gives the multiplier for a certain portion of the rise and fall intercepts of
all cells in the library. In the following syntax, multiplier is a floating-point number:
k_process_rise_delay_intercept : multiplier ;
Scale factor applied to the rise_delay_intercept attribute to model process variation.
k_process_fall_delay_intercept : multiplier ;
Scale factor applied to the fall_delay_intercept attribute to model process variation.
3-19
k_temp_rise_delay_intercept : multiplier ;
Scale factor applied to the rise_delay_intercept attribute to model temperature
variation.
k_temp_fall_delay_intercept : multiplier ;
Scale factor applied to the fall_delay_intercept attribute to model temperature
variation.
k_voltage_rise_delay_intercept : multiplier ;
Scale factor applied to the rise_delay_intercept attribute to model voltage variation.
k_voltage_fall_delay_intercept : multiplier ;
Scale factor applied to the fall_delay_intercept attribute to model voltage variation.
Power Scaling Factors

You can define power factors only in libraries that use a CMOS technology. Power scaling
factors scale the power computation according to process, temperature, and voltage.
The power-scaling factors are listed below. In the following syntax, multiplier is a floating-
point number:
k_process_cell_leakage_power : multiplier ;
Specifies process derating factors for the cell_leakage_power attribute.
k_process_internal_power : multiplier ;
Specifies process derating factors for the internal_power attribute.
k_temp_cell_leakage_power : multiplier ;
Specifies temperature derating factors for the cell_leakage_power attribute.
k_temp_internal_power : multiplier ;
Specifies temperature derating factors for the internal_power attribute.
k_volt_cell_leakage_power : multiplier ;
Specifies voltage derating factors for the cell_leakage_power attribute.
k_volt_internal_power : multiplier ;
Specifies voltage derating factors for the internal_power attribute.
3-20
Timing Constraint Factors
Timing constraint factors scale the following timing constraint values to account for the
effects of changes in process, temperature, and voltage:
• Setup time
• Hold time
• No-change time
• Recovery time
• Removal time
• Minimum pulse width
• Minimum clock period
• Skew
For setup, hold, and recovery time constraints, the k-factors containing the _rise suffix
are applied to the related intrinsic_rise value of the constraint timing group. Those with
the _fall suffix are applied to the related intrinsic_fall value.
For minimum pulse width constraints, the factors with the _high suffix are applied to the
min_pulse_width_high constraint. Those with the _low suffix are applied to the
min_pulse_width_low constraint.
The multiplier scaling factor for temperature and voltage is a floating-point number. The
multiplier value for process is a nonnegative floating-point number.
The constraint k-factors are
k_process_hold_rise : multiplier ;
Scaling factor applied to hold constraints (with rising edge active) to model process
variation.
k_process_hold_fall : multiplier ;
Scaling factor applied to hold constraints (with falling edge active) to model process
variation.
k_process_removal_rise : multiplier ;
Scaling factor applied to removal constraints (with rising edge active) to model
process variation.
3-21
k_process_removal_fall : multiplier ;
Scaling factor applied to removal constraints (with falling edge active) to model
process variation.
k_temp_hold_rise : multiplier ;
Scaling factor applied to hold constraints (with rising edge active) to model
temperature variation.
k_temp_hold_fall : multiplier ;
Scaling factor applied to hold constraints (with falling edge active) to model
temperature variation.
k_temp_removal_rise : multiplier ;
Scaling factor applied to removal constraints to model temperature variation.
k_temp_removal_fall : multiplier ;
Scaling factor applied to removal constraints to model temperature variation.
k_volt_hold_rise : multiplier ;
Scaling factor applied to hold constraints to model voltage variation.
k_volt_hold_fall : multiplier ;
Scaling factor applied to hold constraints to model voltage variation.
k_volt_removal_fall : multiplier ;
Scaling factor applied to removal constraints to model voltage variation.
k_volt_removal_rise : multiplier ;
Scaling factor applied to removal constraints to model voltage variation.
k_process_setup_rise : multiplier ;
Scaling factor applied to setup constraints to model process variation.
k_process_setup_fall : multiplier ;
Scaling factor applied to setup constraints to model process variation.
k_temp_setup_rise : multiplier ;
Scaling factor applied to setup constraints to model temperature variation.
k_temp_setup_fall : multiplier ;
Scaling factor applied to setup constraints to model temperature variation.
k_volt_setup_rise : multiplier ;
Scaling factor applied to setup constraints to model voltage variation.
k_volt_setup_fall : multiplier ;
Scaling factor applied to setup constraints to model voltage variation.
3-22
k_process_nochange_rise : multiplier ;
Scaling factor applied to no-change constraints to model process variation.
k_process_nochange_fall : multiplier ;
Scaling factor applied to no-change constraints to model process variation.
k_temp_nochange_rise : multiplier ;
Scaling factor applied to no-change constraints to model temperature variation.
k_temp_nochange_fall : multiplier ;
Scaling factor applied to no-change constraints to model temperature variation.
k_volt_nochange_rise : multiplier ;
Scaling factor applied to no-change constraints to model voltage variation.
k_volt_nochange_fall : multiplier ;
Scaling factor applied to no-change constraints to model voltage variation.
k_process_recovery_rise : multiplier ;
Scaling factor applied to recovery constraints to model process variation.
k_process_recovery_fall : multiplier ;
Scaling factor applied to recovery constraints to model process variation.
k_temp_recovery_rise : multiplier ;
Scaling factor applied to recovery constraints to model temperature variation.
k_temp_recovery_fall : multiplier ;
Scaling factor applied to recovery constraints to model temperature variation.
k_volt_recovery_rise : multiplier ;
Scaling factor applied to recovery constraints to model voltage variation.
k_volt_recovery_fall : multiplier ;
Scaling factor applied to recovery constraints to model voltage variation.
k_process_min_pulse_width_high : multiplier ;
Scaling factor applied to minimum pulse width constraints to model process
variation.
k_process_min_pulse_width_low : multiplier ;
Scaling factor applied to minimum pulse width constraints to model process
variation.
k_temp_min_pulse_width_high : multiplier ;
Scaling factor applied to minimum pulse width constraints to model temperature
variation.
3-23
k_temp_min_pulse_width_low : multiplier ;
Scaling factor applied to minimum pulse width constraints to model temperature
variation.
k_volt_min_pulse_width_high : multiplier ;
Scaling factor applied to minimum pulse width constraints to model voltage variation.
k_volt_min_pulse_width_low : multiplier ;
Scaling factor applied to minimum pulse width constraints to model voltage variation.
k_process_min_period : multiplier ;
Scaling factor applied to minimum period constraints to model process variation.
k_temp_min_period : multiplier ;
Scaling factor applied to minimum period constraints to model temperature
variation.
k_volt_min_period : multiplier ;
Scaling factor applied to minimum period constraints to model voltage variation.
k_process_skew_fall : multiplier ;
Scaling factor applied to skew constraints to model process variation.
k_process_skew_rise : multiplier ;
Scaling factor applied to skew constraints to model process variation.
k_temp_skew_fall : multiplier ;
Scaling factor applied to skew constraints to model temperature variation.
k_temp_skew_rise : multiplier ;
Scaling factor applied to skew constraints to model temperature variation.
k_volt_skew_fall : multiplier ;
Scaling factor applied to skew constraints to model voltage variation.
k_volt_skew_rise : multiplier ;
Scaling factor applied to skew constraints to model voltage variation.
3-24
Delay Scaling Factors Example
Example 3-6 shows delay scaling factors. This example assumes a CMOS linear delay
model.
Example 3-6 Setting k-Factors

library (example) {
...
k_process_drive_fall : 1.0;
k_process_drive_rise : 1.0;
k_process_hold_rise : 1.0;
k_process_hold_fall : 1.0;
k_process_intrinsic_fall : 1.0;
k_process_intrinsic_rise : 1.0;
k_process_pin_cap : 0.0;
k_process_slope_fall : 1.0;
k_process_slope_rise : 1.0;
k_process_wire_cap : 0.0;
k_process_wire_res : 1.0;
k_temp_drive_fall : 0.004;
k_temp_drive_rise : 0.004;
k_temp_hold_rise : .0037;
k_temp_hold_fall : .0037;
k_temp_intrinsic_fall : 0.004;
k_temp_intrinsic_rise : 0.004;
k_temp_pin_cap : 0.0;
k_temp_slope_fall : 0.0;
k_temp_slope_rise : 0.0;
k_temp_wire_cap : 0.0;
k_temp_wire_res : 0.0;
k_volt_drive_fall : -0.4;
k_volt_drive_rise : -0.4
k_volt_hold_rise : -0.26;
k_volt_hold_fall : -0.26;
k_volt_intrinsic_fall : -0.4;
k_volt_intrinsic_rise : -0.4;
k_volt_pin_cap : 0.0;
k_volt_slope_fall : 0.0;
k_volt_slope_rise : 0.0;
k_volt_wire_cap : 0.0;
k_volt_wire_res : 0.0;
...
}
In this example, only the intrinsic rise, intrinsic fall, rise resistance, and fall resistance
delays are affected by a change in operating voltage. Change to the other voltage factors
is prevented by using 0.0.
3-25
Scaling Factors for Individual Cells
The k-factors you define for the library as a whole do not produce accurate timing for
certain cells because not all cells in the same library scale uniformly: Pads scale
differently from core cells, the timing of voltage-level pads varies with temperature, and
some cells are designed to produce a constant delay and do not scale at all.
Other cells do not scale in a linear manner for process, voltage, or temperature. You can
define a separate set of scaling factors in a library-level group called scaling_factors and
apply the k-factors in this group to selected cells by using the scaling_factors attribute.
You can apply library-level k-factors to the majority of cells in your library and use this
construct to provide additional accurate scaling factors for special cells. Example 3-7
illustrates the user-defined scaling factors.
Example 3-7 Individual Scaling Factors

library (example) {
k_volt_intrinsic_rise : 0.987 ;
...
scaling_factors(”IO_PAD_SCALING”) {
...
}
cell (INPAD_WITH_HYSTERESIS) {
area : 0 ;
scaling_factors : IO_PAD_SCALING ;
...
}
...
}
Example 3-7 defines a scaling factor group called IO_PAD_SCALING, which contains
k-factors that are different from the library-level k-factors.
You can use any k-factors in a scaling_factors group. The scaling_factors attribute in the
INPAD_WITH_HYSTERESIS cell is set to IO_PAD_SCALING, so all k-factors set in the
IO_PAD_SCALING group are applied to the cell.
By default, all cells without a scaling_factors attribute continue to use the library-level k-
factors.
You can model cells that do not scale at all by creating a scaling_factors group in which
all the k-factor values are set to 0.0; no scaling is done.
3-26
Scaling Factors Associated with the Nonlinear Delay Model
As with the other delay models, the CMOS nonlinear delay model scaling factors scale
the delay based on the variation in process, temperature, and voltage. The process,
temperature, and voltage scaling factors for other CMOS delay models are not valid with
the CMOS nonlinear timing model. Only the following scaling factors are valid for the
CMOS nonlinear timing model:
• k_process_cell_rise
• k_temp_cell_rise
• 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
You define the scaling factors for setup, hold, recovery, removal, and skew in the
nonlinear delay model in the same way you do for the other delay models. For the
nonlinear delay model, however, the scaling factors apply to the values given in the
associated constraint lookup table.
3-27
For example, the timing constraint equation for setup rise is
rise_constraint x (1 + delta_voltage x k_volt_setup_rise)

x (1 + delta_temp x k_temp_setup_rise)
x (1 + delta_process x k_process_setup_rise).
rise_constraint is a value in the rise_constraint table of the timing arc. These are the
scaling factors for the setup_rising timing constraint:
• k_volt_setup_rise
• k_temp_setup_rise
• k_process_setup_rise
The scaling_factors group is not affected by the change from linear to nonlinear delay
model. The scaling factors for setup rise are valid in the scaling_factors group.
3-28
4
Defining Core Cells 1
Cell descriptions are a major part of a technology library. They provide information on
the area, function, and timing of each component in an ASIC technology.
Defining core cells for CMOS technology libraries involves the following concepts and
tasks described in this chapter:
• Defining cell groups

• Defining cell routability
• Defining pin groups
• Defining bused pins
• Defining signal bundles
• Defining a layout-related multibit attribute
• Defining scaled cell groups
Defining Core Cells

4-1
Defining Cell Groups
A cell group defines a single cell in the technology library.
This chapter discusses the attributes in a cell. For information about groups within a cell
group, refer to the following sections in this chapter:
• “Defining Pin Groups”

• “Defining Bused Pins”
• “Defining Signal Bundles”
For information about test cell groups, see Chapter 8, “Defining Test Cells."
See Example 4-3 at the end of this section for a sample cell description.
cell Group
The cell group statement gives the name of the cell being described. It appears at the
library-group level as shown here:
...
cell( name ) {
... cell description ...
}
...
}
The name should correspond to the name the ASIC vendor uses for the cell.
To create the cell group for the AND2 cell, use this syntax:
cell( AND2 ) {
... description of AND2 ...
}
A CMOS cell group typically has these attributes (listed alphabetically):
• area
• bundle (see "Defining Signal Bundles" later in this chapter)
• bus (see "Defining Bused Pins" later in this chapter)
Defining Core Cells

4-2
• contention_condition
• ff (this group is explained in Chapter 5, "Defining Sequential Cells")
• handle_negative_constraint
• pad_cell
• pad_type
• pin_equal
• pin_opposite
• scaling_factors
• vhdl_name
area Attribute
This simple attribute specifies the cell area.
Syntax:
area : float ;
float
A floating-point number. No units are explicitly given for the value, but you should
use the same unit for the area of all cells in a library. Typical area units include gate-
equivalents, square microns, and transistors.
The following example shows a cell with an area of three units:
area : 3 ;
All cells except for pad cells should have an area attribute. Pad cells should have an
area of zero because they are not used as internal gates. For unknown or undefined
(black box) cells, the area attribute is optional.
contention_condition Attribute
This attribute specifies the conditions that cause contention in a cell. Contention is a
clash of 0 and 1 signals. In certain cells, it can be a forbidden condition and cause circuits
to short.
Defining Core Cells

4-3
Syntax:
contention_condition : “Boolean expression” ;
Boolean expression
Can be true or false.
Example:
contention_condition : “!ap * an” ;
handle_negative_constraint Attribute
Use this attribute during generation of VITAL models to indicate whether the cell needs
negative constraint handling. It is an optional Boolean attribute for timing constraints in
a cell group.
Syntax:
handle_negative_constraint : Boolean expression ;
Boolean expression
Can be true or false. The default is false.
Example:
handle_negative_constraint : true ;
pad_cell Attribute
The pad_cell attribute in a cell group identifies the cell as a pad.
Syntax:
pad_cell : Boolean expression ;
Boolean expression
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. See the is_pad attribute description in Chapter 7, “Defining
Input and Output Pads.”
Defining Core Cells

4-4
If more than one pad cell is used to build a logical pad, put the following attribute in the
cell definitions of all the component pad cells:
auxiliary_pad_cell : true ;
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.
pad_type Attribute
This simple attribute identifies a type of pad_cell or auxiliary_pad_cell.
Syntax:
pad_type : value ;
value
Is clock, which identifies a pad cell as a clock driver.
Example:
pad_type : clock ;
pin_equal Attribute
This complex attribute describes a group of logically equivalent input or output pins in
the cell.
Syntax:
pin_equal ("name_list") ;
name_list
A name_list of input pins requires the input values to be equal. A name_list of output
pins requires the output values to be equal.
Example:
pin_equal : (”IP1 IP0”) ;
In this example, the input pins IP1 and IP0 are logically equivalent.
Note: Use the pin_equal attribute only in cells without function information or
when you want to define required input values.
Defining Core Cells

4-5
pin_opposite Attribute
This attribute describes functionally opposite (logical inverse) groups of pins in a cell.
The pin_opposite attribute also incorporates the functionality of the pin_equal attribute.
Syntax:
pin_opposite ("name_list1", "name_list2") ;
name_list1, name_list2
A name_list of input pins requires the supplied input values to be opposite. A
name_list of output pins requires the supplied output values to be opposite
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.
Note: Use the pin_opposite attribute only in cells without function information or
when you want to define required inputs.
scaling_factors Attribute
This simple attribute applies the k-factors defined in the scaling_factors group at the
library level.
Syntax:
scaling_factors : group_name ;
group_name
Name assigned to the set of k-factors you defined in a scaling_factors group.
Example:
Scaling factors (or k-factors) are defined in a library-level group called scaling_factors
and applied to selected cells using the scaling_factors cell attribute. You can apply
library-level k-factors to the majority of cells in your library while using the scaling_factors
attribute to provide more accurate scaling factors for other cells.
See the section on “Scaling Factors for Individual Cells” in Chapter 3, “Environment
Attributes,” for additional information on the scaling_factors group.
Defining Core Cells

4-6
By default, all cells without a scaling_factors attribute continue to use the library-level
scaling factors.
Example 4-1 shows these scaling factors in the library description and cell description.
Example 4-1 Individual Scaling Factors

library (example) {
...
scaling_factors(IO_PAD_SCALING) {
...
}
cell (INPAD_WITH_HYSTERESIS) {
area : 0 ;
...
}
...
}
Example 4-1 defines a scaling factor group called IO_PAD_SCALING, which contains
scaling factors that differ from the library-level scaling factors. The scaling_factors
attribute in the INPAD_WITH_HYSTERESIS cell is set to IO_PAD_SCALING, so all
scaling factors set in the IO_PAD_SCALING group are applied to this cell.
Scaling factors not defined within a scaling_factors group are set to 0.0 for that group.
Cells that do not scale at all can be modeled with an empty scaling_factors group. In
this case, all scaling factors in the scaling_factors group are set to the default, 0.0, so
no scaling is done.
type Group Attribute

The type group, when defined within a cell, is a type definition local to the cell. It cannot
be used outside the cell.
Syntax:
cell (name) {
type (name) {
... type description ...
}
}
Defining Core Cells

4-7
The type group has the following simple attributes associated with it:
base_type : array ;
bit_from : integer ;
bit_to : integer ;
bit_width : integer ;
data_type : bit ;
base_type Simple Attribute

The base type must be set to array.
Example:
base_type : array ;
bit_from Simple Attribute

The member number assigned to the most-significant bit (MSB) of successive array
members.
Syntax:
integer
Indicates the member number assigned to the MSB of successive array members.
The default is 0.
Example:
bit_from : 0 ;
bit_to Simple Attribute

The member number assigned to the least-significant bit (LSB) of successive array
members.
Syntax:
bit_to : integer ;
integer
Indicates the member number assigned to the LSB of successive array members.
The default is 0.
Example:
bit_to : 3 ;
Defining Core Cells

4-8
bit_width Simple Attribute
An integer that designates the number of bus members.
Syntax:
integer
Designates the number of bus members. The default is 1.
Example:
bit_width : 4 ;
data_type Simple Attribute

The data type must be set to bit.
Example:
data_type : bit ;
Example 4-2 illustrates a type group statement in a cell.
Example 4-2 type Group within a Cell

cell (buscell4) {
type (BUS4) {
base_type : array ;
bit_from : 0 ;
bit_to : 3 ;
bit_width : 4 ;
data_type : bit ;
}
}
vhdl_name Attribute
In cell and pin groups, defines valid VHDL object names.
Syntax:
vhdl_name : ”string” ;
string
A character string identifying a VHDL object name.
Defining Core Cells

4-9
Example:
vhdl_name : ”INb” ;
Cell Group Example

Example 4-3 shows cell definitions that include some of the CMOS cell attributes
described so far.
Example 4-3 Cell Group Example

library (cell_example){
scaling_factors(IO_PAD_SCALING) {
k_volt_intrinsic_rise : 0.846;
}
cell (inout){
pad_cell : true;
vhdl_name : ”inpad”;
area : 0; /* pads do not normally consume internal core area */
scaling_factors : IO_PAD_SCALING;
pin (A) {
direction : input;
capacitance : 0;
}
pin (Z) {
direction : output;
function : ”A”;
timing () {
...
}
}
}
cell(inverter_med){
area : 3;
pin (A) {
direction : input;
capacitance : 1.0;
}
pin (Z) {
direction : output;
function : ”A’ ”;
timing () {
...
}
}
}
Defining Core Cells

4-10
cell(nand){
area : 4;
pin(A) {
direction : input;
capacitance : 1;
fanout_load : 1.0;
}
pin(B) {
direction : input;
capacitance : 1;
fanout_load : 1.0;
}
pin (Y) {
direction : output;
function : ”(A * B)’ ”;
timing() {
...
}
}
}
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;
intrinsic_rise : 0.1;
intrinsic_fall : 0.1;
}
timing() {
related_pin : ”ap an”;
timing_type : three_state_enable;
}
}
pin (z) {
direction : output;
function : ”!ap & !an”;
x_function : ”!ap & an | ap & !an”;
Defining Core Cells

4-11
}
}
}
cell(and_nand){
area : 4;
pin_opposite(”Y”, ”Z”);
pin(A) {
direction : input
capacitance : 1
fanout_load : 1.0
}
pin(B) {
direction : input
capacitance : 1
fanout_load : 1.0
}
pin (Y) {
direction : output
function : ”(A * B)’”
timing() {...}
}
pin (Z){
direction : output
function : ”(A * B)”
timing() {...}
}
}
cell(buff1){
area : 3;
pin_equal (”Y Z”);
pin (A) {
direction : input;
capacitance : 1.0;
}
pin (Y) {
direction : output;
function : ”A”;
timing () {...}
}
pin (Z) {
direction : output;
function : ”A”;
timing () {...}
}
}
} /
* End of Library */
Defining Core Cells

4-12
Defining Cell Routability
You declare a routing_track group in the routing_layers attribute of the library group to
add routability information for the cell. Names must be unique for each routing_track
group.
routing_track Group
The syntax for the routing_track group is
Syntax:
library (name){
cell (name){
routing_track (routing_layer_name){
... routing track description ...
}
}
}
The simple attributes associated with the routing_track group are tracks and
total_track_area. Descriptions of these attributes follow.
tracks Attribute
This simple attribute indicates the number of tracks available for routing on any particular
layer.
Syntax:
tracks : integer ;
integer
A number larger than or equal to 0.
Example:
tracks : 2 ;
total_track_area Simple Attribute

Specifies the total routing area of the routing tracks.
Syntax:
total_track_area : float ;
Defining Core Cells

4-13
float
A floating-point number larger than or equal to 0.0, and less than or equal to the
area on the cell.
Example:
total_track_area : 0.2 ;
Each routing layer declared in the routing_layers attribute must have a corresponding
routing_track group in a cell. Do not use two routing_track groups for the same routing
layer in the same cell.
Example 4-4 shows a library that contains routability information.
Example 4-4 A Library with Routability

library(lib_with_routability) {
default_min_porosity : 15.0;
routing_layers(“metal2”, “metal3”);
cell(”ND2”) {
area :1;
...
}
cell(”ND2P”) {
area : 2;
routing_track(metal2) {
tracks : 2;
total_track_area : 0.2;
}
routing_track(metal3) {
tracks : 4;
total_track_area : 0.4;
}
...
}
...
}
Note: For a scaled_cell or test_cell attribute, routability information is not allowed.

For pad cells, routability information is optional.
Defining Pin Groups
A pin group describes the characteristics of a pin or pins within a cell. A pin group is
defined inside a cell group, which must contain descriptions of all pins in the cell. All pin
names within a cell group must be unique.
Defining Core Cells

4-14
A pin group often contains an internal_power group and a timing group. Internal power
groups are described in Chapter 9, “Modeling Power.” Timing groups are described in
detail in Chapter 10, “Timing Arcs.”
Example 4-9, later in this chapter, shows a pin group specification.
pin Group
A pin group is defined within a cell group or a bus group. The general format is shown
below.
...
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” later in this chapter for descriptions of bus groups and pin
group notation for bus members. See “Defining Signal Bundles” later in this chapter for
descriptions of bundle groups.
Pin groups are also valid within test_cell groups. They have different requirements from
pin groups in cell, bus, or bundle groups. See Chapter 8, “Defining Test Cells,” for specific
information and restrictions on describing test 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
with a large number of pins. Do not confuse defining multiple pins in a single pin group
with defining a bus or bundle. See “Defining Bused Pins” and “Defining Signal Bundles,”
later in this chapter.
Defining Core Cells

4-15
In Example 4-5, the AND cell has two pins: A and B.
Example 4-5 Cell Description for an AND Cell

cell (AND) {
area : 3 ;
vhdl_name : ”AND2” ;
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 shown
in Example 4-6.
Example 4-6 Alternate Cell Description Using a pin Group

cell (AND) {
area : 3 ;
pin (A,B) {
direction : input ;
capacitance : 1 ;
}
}
General Attributes
To define the pin, use these general pin group attributes:
• capacitance
• clock_gate_enable_pin
• direction
• inverted_output
• pin_func_type
Defining Core Cells

4-16
capacitance Attribute
This simple attribute defines the load of an input or output pin.
Syntax:
capacitance : float ;
float
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.
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 ;
}
}
Note: 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.
clock_gate_enable_pin Attribute
This attribute identifies an input port connected to an enable signal.
Syntax:
clock_gate_enable_pin : Boolean expression ;
Boolean expression
You can set this attribute to true on only one input port of a 2-input AND, NAND, OR, or
NOR gate.The other input port is the clock.
Example:
clock_gate_enable_pin : true;
Defining Core Cells

4-17
direction Attribute
This attribute designates the pin being described as an input, output, internal, or
bidirectional (inout) pin.
Syntax:
direction : input | output | inout | internal ;
In the following example, both A and B in the AND cell are input pins; Y is an output pin.
cell (AND) {
area : 3 ;
pin (A,B) {
direction : input ;
}
pin (Y) {
direction : output;
}
}
inverted_output Attribute
The inverted_output attribute is an optional, Boolean attribute that you can set for any
output port.
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;
}
pin_func_type Attribute
This attribute defines the clock as the clock-enabling mechanism (that is, the clock-
enable pin). This attribute also specifies whether the active edge of the enable pin of
latches is high or low, and whether the active level of the flip-flop clock is rising or falling.
Defining Core Cells

4-18
Syntax:
pin_func_type : clock_enable | active_high |
active_low | active_rising | active_falling ;
clock_enable
Enables the clocking mechanism.
active_high or active_low
Describes the clock active edge or level of the enable pin of the latches.
active_rising or active_falling
Describe the clock active edge or level of the clock pin of the flip-flops.
Example:
pin_func_type : clock_enable ;
Describing Design Rule Checks

To define design rule checks, use these pin group attributes and group:
• fanout_load Attribute
• max_fanout Attribute
• min_fanout Attribute
• max_transition Attribute
• min_transition Attribute
• max_capacitance Attribute
• min_capacitance Attribute
• cell_degradation Group
fanout_load Attribute
This simple attribute gives the internal fanout load for an input pin.
Syntax:
fanout_load : float ;
float
A floating-point number that represents the internal fanout of the input pin. There
are no fixed units for fanout_load. Typical units are standard loads or pin count.
Defining Core Cells

4-19
The following example describes pin B with a fanout load of 2.0.
pin (B) {
direction : input ;
fanout_load : 2.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 4-1 illustrates max_fanout and fanout_load attributes for a cell.
Figure 4-1 Fanout Attributes
fanout_load : 1.0
fanout_load : 1.0
fanout_load : 1.0
max_fanout : 10 ;
max_fanout Attribute
This simple attribute defines the maximum fanout load that an output pin can drive. You
can specify max_fanout at the library level or pin level.
Syntax:
max_fanout : float ;
float
A floating-point number that represents the number of fanouts the pin can drive.
There are no fixed units for max_fanout. Typical units are standard loads or pin count.
In the following example, pin X can drive a fanout load of no more than 11.0.
pin (X) {
max_fanout : 11.0 ;
}
Defining Core Cells

4-20
Some designs have input load limitations 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 Figure 4-1.)
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. Both real and integer values are
acceptable.
Although you can use capacitance as the unit for your max_fanout and fanout_load
specifications, it should be used to constrain routability requirements. It differs from the
capacitance pin attribute in that the fanout values are used only for design rule checking.
min_fanout Attribute
This attribute defines the minimum fanout load that an output or inout pin should drive.
The sum of fanout loads cannot be less than the minimum fanout value.
Syntax:
min_fanout : float ;
float
A floating-point number that represents the minimum number of fanouts the pin can
drive. There are no fixed units for min_fanout. Typical units are standard loads or
pin count.
In the following example, pin X can drive a fanout load of no less than 3.0.
pin (X) {
min_fanout : 3.0 ;
}
max_transition Attribute
This simple attribute defines a design rule constraint for the maximum acceptable
transition time of an input or output pin. You can specify max_transition at the library
level or the pin level.
Syntax:
max_transition : float ;
float
A floating-point number in units consistent with other time values in the library.
Defining Core Cells

4-21
Example:
pin(A) {
direction : input;
max_transition : 4.2;
}
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) {
max_transition : 5.2 ;
}
min_transition Attribute
This attribute defines a design rule constraint for the minimum acceptable transition time
of an input or output pin.
Syntax:
min_transition : float ;
float
A floating-point number in units consistent with other time values in the library.
Example:
pin(A) {
direction : input;
min_transition : 1.0;
}
max_capacitance Attribute
This simple 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.
Syntax:
max_capacitance : float ;
Defining Core Cells

4-22
float
A floating-point number.
Example:
pin(Q) {
direction : output;
max_capacitance : 5.0;
}
You can specify max_capacitance at the library level or the pin level.
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.
Syntax:
min_capacitance : float ;
float
Example:
pin(Q) {
direction : output;
min_capacitance : 1.0;
}
cell_degradation Group
Use the cell_degradation group to describe a cell performance degradation design rule.
A cell degradation design rule specifies the maximum capacitive load a cell can drive
without causing cell performance degradation during the fall transition.
Note: You can model cell degradation only in libraries that use the CMOS
nonlinear delay model.
This description is restricted to functionally related input and output pairs. You can
determine the degradation value by switching inputs while keeping other inputs 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.
Defining Core Cells

4-23
Cell degradation modeling uses the same format of templates and lookup tables used
to model delay with the nonlinear delay model. To model cell degradation, follow this
procedure:
1. Create a one-dimensional lookup table template that is indexed by input transition

time.
2. Use the cell_degradation group and the cell degradation template to create a one-
dimensional lookup table for each timing arc in the cell.
This is 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 Chapter 10, “Timing Arcs,” under
the section “Defining the CMOS Nonlinear Delay Model Template.” 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) {
index_1 (”0.0, 1.0, 2.0”);
}
The following example illustrates the use of the cell_degradation group statement.
pin(output) {
timing() {
cell_degradation(deg_constraint) {
index_1 (”0.5, 1.5, 2.5”);
values (”0.0, 2.0, 4.0”);
}
}
}
See Chapter 10, “Timing Arcs,” for more information about lookup table templates.
You can describe cell_degradation groups only in timing groups of the following timing
types:
• combinational
• three_state_enable
Defining Core Cells

4-24
• three_state_disable
• rising_edge
• falling_edge
• preset
• clear
Each of these timing groups is explained in Chapter 10, “Timing Arcs,” in the section
“Defining Timing Groups.”
Describing Clocks
Use these pin group attributes to define clocks and clocking:
• clock
• min_period
• min_pulse_width_high
• min_pulse_width_low
clock Attribute
This simple attribute indicates whether or not an input pin is a clock pin.
Syntax:
clock : true | false ;
A true value labels the pin as a clock pin. A false value labels the pin as not a clock pin,
even though it may behave as a clock.
The following example defines pin CLK2 as a clock pin.
pin(CLK2) {
direction : input ;
capacitance : 1.0 ;
clock : true ;
}
Defining Core Cells

4-25
min_period Attribute
Place the min_period attribute on the clock pin of a flip-flop or latch to specify the
minimum clock period required for the input pin. Minimum period is the sum of the data
arrival time and setup time. This time must be consistent with the max_transition time.
Syntax:
min_period : float ;
float
A floating-point number indicating a time unit.
The following example shows a pin group description containing a min_period attribute.
pin (CLK4) {
direction : input ;
capacitance : 1 ;
clock : true ;
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). You can place these
attributes on a clock input pin or an asynchronous clear/preset pin of a flip-flop or latch.
Syntax:
min_pulse_width_high : float ;
min_pulse_width_low : float ;
float
A floating-point number defined in units consistent with other time values in the
library.
Example 4-7 shows both attributes on a clock pin.
Example 4-7 Minimum-Pulse-Width Specification for a Clock Pin

pin(CLK) {
direction : input ;
capacitance : 1 ;
min_pulse_width_high : 3 ;
min_pulse_width_low : 3 ;
}
Defining Core Cells

4-26
Describing Pin Functions
To define a pin’s function, use these pin group attributes:
• function
• three_state
• x_function
• state_function
• internal_node
function Attribute
The function attribute in a pin group defines the value of an output or inout pin in terms
of the cell’s input or inout pins.
Syntax:
function : ”Boolean expression” ;
Table 4-1 lists the valid Boolean operators in a function statement.
Table 4-1 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 precedence of the operators is left to right, with inversion performed first, then XOR,
then AND, then OR.
Defining Core Cells

4-27
The following example describes pin Q with the function A OR B.
Example:
pin(Q) {
function : ”A + B” ;
}
Note: A pin name beginning with a number must be enclosed in double quotation
marks preceded by a backslash (\), as shown here:
function : ” \”1A\” + \”1B\” ” ;
The absence of a backslash causes the quotation marks to terminate the

function string.
The following function statements all describe 2-input multiplexers. The parentheses are
optional. The operators and operands are separated by spaces.
function : ”A S + B S’” ;
function : ”A & S | B & !S” ;
function : ”(A * S) + (B * S’)” ;
Grouped Pins in function Statements
Grouped pins can be used as variables in the function statement. In function statements
that use bus or bundle names, all the variables in that statement must be either buses
or bundles of the same width, or a single pin. See “Defining Bused Pins” and “Defining
Signal Bundles,” later in this chapter.
Ranges of buses or bundles are valid so long as 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.
Defining Core Cells

4-28
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)” ;
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
This simple attribute defines a three-state output pin in a cell.
Syntax:
three_state : ”Boolean expression”
Boolean expression
An equation defining the condition that causes the pin to go to the high-impedance
state.
The syntax of this equation is the same as the syntax of the function statement in a pin
group (described in the previous section). The three_state attribute can be used in both
combinational and sequential pin groups, with bus or bundle variables.
Defining Core Cells

4-29
In Example 4-8, 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 4-8 Three-State Cell Description

library(example){
technology (cmos) ;
cell(TRI_INV2) {
area : 3 ;
pin(A) {
direction : input ;
capacitance : 2 ;
}
pin(E) {
direction : input ;
capacitance : 2 ;
}
pin(Z) {
function : ”A’” ;
three_state : ”E’” ;
timing() {
...
}
}
}
}
x_function attribute
Use this attribute to describe the X behavior of a pin. X is a state other than 0, 1, or Z.
Syntax:
x_function : “Boolean expression” ;
Boolean expression
An equation defining the condition that causes the pin to go to the X state.
The function, three_state, 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, as shown below.
Example:
pin (y) {
direction: output;
function : “!ap * !an” ;
x_function : “!ap * an” ;
three_state : “ap * !an” ;
Defining Core Cells

4-30
state_function Attribute
This simple attribute defines output logic. If the output logic is a function of only the
inputs, the output is purely combinational (for example, feedthrough 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.
Syntax:
state_function : Boolean expression ;
Ports in the state_function Boolean expression must be either input, three-state inout,
or ports with an internal_node attribute.
Example:
state_function : QN;
internal_node Attribute
This simple attribute describes the sequential behavior of an internal pin or an output
pin. It indicates the relationship between an internal node in the statetable group and a
pin of a cell. Each output or internal pin with the internal_node attribute may also have
the optional input_map attribute.
Syntax:
internal_node : name ;
name
Name of internal node.
Example:
internal_node : ”Q”;
CMOS Pin Group Example

Example 4-9 shows pin attributes in a CMOS library.
Example 4-9 CMOS Pin Group Example

library(example){
cell(AN2) {
area : 2;
pin(A) {
direction : input;
capacitance : 1.3;
fanout_load : 2; /* internal fanout load */
Defining Core Cells

4-31
max_transition : 4.2;/* design-rule constraint */
}
pin(B) {
direction : input;
capacitance : 1.3;
}
pin(Z) {
direction : output;
function : ”A * B”;
max_transition : 5.0;
timing() {
intrinsic_fall : 0.69 ;
rise_resistance : 0.1378;
fall_resistance : 0.0465;
related_pin : ”A B”;
}
}
}
Defining Bused Pins
To define bused pins, you must first define a type group. Then you can define a bus
group in the cell group.
Once a bus is defined, the bus or a bus member can be used in Boolean expressions
in the function attribute.
Note: 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 shown here:
type ( name ) {
... type description ...
}
}
name
Identifies the bus type.
Defining Core Cells

4-32
A type group can contain the following attributes:
base_type : array ;
bit_to : integer ;
data_type : bit ;
downto : true | false ;
base_type Simple Attribute

The only valid value is array.
Example:
base_type : array ;
bit_from Simple Attribute

The member number assigned to the most-significant bit (MSB) of successive array
members.
Syntax:
integer
Indicates the member number assigned to the MSB of successive array members.
The default is 0.
Example:
bit_from : 0 ;
bit_to Simple Attribute

The member number assigned to the least-significant bit (LSB) of successive array
members.
Syntax:
bit_to : integer ;
integer
Indicates the member number assigned to the LSB of successive array members.
The default is 0.
Example:
bit_to : 3 ;
Defining Core Cells

4-33
bit_width Simple Attribute
An integer that designates the number of bus members.
Syntax:
integer
Designates the number of bus members. The default is 1.
Example:
bit_width : 4 ;
data_type Simple Attribute

The only valid value is bit.
Example:
data_type : bit ;
down_to Simple Attribute

A Boolean expression that indicates whether the MSB is high or low.
downto : true | false ;
true
indicates that member number assignment is from high to low. The default is false
(low to high).
Example 4-10 illustrates a type group statement.
Example 4-10 type Group Description
type ( BUS4 ) {
base_type : array ;
data_type : bit ;
bit_width : 4 ;
bit_from : 0 ;
bit_to : 3 ;
downto :false ;
}
Defining Core Cells

4-34
The type group statements in Example 4-11 are both valid descriptions of BUS4 in
Example 4-10.
Example 4-11 Alternate type Group Descriptions

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 in a bus group to describe bused pins.
bus Group
A bus group describes the characteristics of a bus. You define it in a cell group, as shown
here:
cell (cell_name) {
area : float ;
bus ( name ) {
... bus description ...
}
}
}
A bus group contains the following elements:
• bus_type attribute
• pin attributes and groups
In a bus group, use the number of bus members (pins) defined by the bit_width attribute
in the applicable type group.
Defining Core Cells

4-35
bus_type Attribute
The bus_type attribute specifies the bus type. It is a required element in all bus groups
and must be the first attribute in a bus group.
Syntax:
bus_type : name ;
name
Defined in the applicable type group in the library, as shown in Example 4-12.
Example 4-12 Bused Pins
library (ExamBus) {
type (bus4) { /* bus name */
bit_width : 4 ; /* number of bused pins */
...
...
}
cell (bused cell) {
...
bus (A) {
bus_type : bus4 ; /* bus 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 the “Defining Pin Groups”
section earlier in this chapter 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.
Defining Core Cells

4-36
The following example shows a bus group that defines bus A with default values 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 ;
}
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. This is valid for nonbused pins.
See Table 4-2 for a comparison of bused and single-pin formats.
Table 4-2 Comparison of Bused and Single-Pin Formats

Pin Type Technology Library
Bused Pin pin x[3:0]
Single Pin pin x
Sample Bus Description

Example 4-13 is a complete bus description that includes type and bus groups. It also
shows the use of bus variables in function, related_pin, pin_opposite, and pin_equal
attributes.
Defining Core Cells

4-37
Example 4-13 Bus Description
library (ExamBus) {
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() {
/* 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”;
Defining Core Cells

4-38
three_state : ”!E”;
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() {
power() {
...
}
}
}
pin (Z[2]) {
function ”A[2]”;
timing () {
related_pin : ”A[2]”;
}
internal_power() {
power() {
...
}
}
}
pin (Z[3]) {
function : ”!A[3]”;
timing () {
related_pin : ”A[3]”;
}
internal_power() {
power() {
Defining Core Cells

4-39
...
}
}
}
}
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() {
/* A[0] and B[0] are related to X[0],
A[1] and B[1] are related to X[1], etc. */
}
}
}
}
}
Defining Core Cells

4-40
Defining Signal Bundles
A bundle groups several pins that have similar timing or functionality. Bundles are used
for multibit cells such as multibit latches, multibit flip-flops, and multibit AND gates.
bundle Group
You define a bundle group in a cell group, as illustrated below:
cell (cell_name) {
area : float ;
bundle ( name ) {
... bundle description ...
}
}
}
A bundle group contains the following elements:
• members attribute
• pin attributes
members Attribute
The members attribute lists the pin names of the signals in a bundle. The members
attribute must be 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 defined for it, it is copied to all bundle members. Example 4-14
defines two bundles named A and B.
Example 4-14 Parent and Child Bundle Groups

pin (C) {
direction : input ;
...
}
bundle(A) {
members(A0, A1, A2, A3);
function : ”B’+ C”;
...
}
Defining Core Cells

4-41
bundle(B) {
members(B0, B1, B2, B3);
direction : input;
...
}
According to the function definition in Example 4-14, the members of the A bundle (the
parent bundle) have these values:
A0 = B0’ + C;
A1 = B1’ + C;
A2 = B2’ + C;
A3 = B3’ + C;
Note that each bundle operand in the child bundle (B) must have the same width as the
function parent bundle (A).
pin Attributes
Pin attributes in a bundle group specify default attribute values for all pins in that bundle.
When pin attributes are found in pin groups within a bundle group, they define attribute
values for specific bundle pins or groups of pins. Values used in pin groups override the
default attribute values defined for the bundle. For more information about pin attributes,
see the “Defining Pin Groups” section earlier in this chapter.
Multibit Latch Example

Example 4-15 shows how to define a bundle group in a multibit latch.
Example 4-15 Multibit Latch with Signal Bundles

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);
Defining Core Cells

4-42
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;
:
}
members(D1, D2, D3, D4); /*must be first attribute */
direction : input;
}
bundle (Q) {
direction : output;
}
bundle (QN) {
direction : output;
}
enable : ”G” ;
data_in : ”D” ;
}
Defining a Layout-Related Multibit Attribute
This section discusses the single_bit_degenerate attribute, a layout-related attribute that

applies to multibit, sequential, and combinational cells.
single_bit_degenerate Attribute
The single_bit_degenerate attribute is used on multibit bundle or bus cells that are black
boxes. The value of this attribute is the name of a single-bit library cell.
Defining Core Cells

4-43
Syntax:
single_bit_degenerate : string ;
string
A character string identifying a single-bit cell in the library.
Example 4-16 shows multibit library cells with the single_bit_degenerate attribute.
Example 4-16 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 : 32 ;
single_bit_degenerate : FDB ;
bus (D) {
bus_type : bus4 ;
direction : input ;
...
timing () {
...
...
}
}
}
Defining Scaled Cell Groups
Not all cells scale uniformly. Some cells are designed to produce a constant delay and
do not scale at all; other cells do not scale in a linear manner for process, voltage, or
temperature. The values you set for a cell under one set of operating conditions do not
produce accurate results for the cell when scaled for different conditions.
You can use a scaled cell group to set the values explicitly for a cell under certain
operating conditions.
Defining Core Cells

4-44
Use a scaled cell group only when absolutely necessary. The size of the library database
increases proportionately to the number of scaled cells you define. This size increase
may increase processing and load times.
Scaled Cell Groups

You can use the scaled_cell group to supply an alternate set of values for an existing
cell. The choice is based on the set of operating conditions used.
Syntax:
scaled_cell (existing_cell, operating_conditions_group) {
... scaled cell description ...
}
existing_cell
The name of a cell defined in a previous cell group.
operating_conditions_group
The library-level operating_conditions group with which the scaled cell is
associated.
Example:
library (example) {
operating_conditions(WCCOM) {
...
}
cell(INV) {
pin(A) {
direction : input ;
capacitance : 1.0 :
}
pin(Z) {
function : ”A’” ;
timing() {
intrinsic_rise : 0.36 ;
rise_resistance : 0.0653 ;
fall_resistance : 0.0331 ;
related_pin : ”A” ;
}
}
}
scaled_cell(INV, WCCOM) {
pin(A) {
direction : input ;
capacitance : 0.7 ;
Defining Core Cells

4-45
}
pin(Z) {
timing() {
}
}
}
}
Defining Core Cells

4-46
5
Defining Sequential Cells 1
This chapter describes how to define flip-flops and latches, building on the cell
description syntax given in Chapter 4, “Defining Core Cells.” It describes group
statements that apply only to sequential cells, and a variation of the function attribute
that makes use of state variables.
To model flip-flops and latches, you must understand the following concepts and tasks:
• Cell definition formats for sequential cells

• Describing a flip-flop
• Using the function attribute
• Describing a multibit flip-flop
• Describing a latch
• Describing a multibit latch
• Describing sequential cells with statetable format
Defining Sequential Cells

5-1
Cell Definition Formats for Sequential Cells
You can describe sequential cells with the following cell definition formats:
• ff/latch format
Cells using ff/latch format are identified by the ff group and latch group.
• statetable format
Cells using statetable format are identified by the statetable group. Statetable format
supports all the sequential cells supported by the ff/latch format. In addition,
statetable format supports more 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
- Internal-state sequential cells, such as master-slave cells
- Multistate sequential cells, such as counters and shift registers
- Sequential cells that also have 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 (Low) and H (High) permutations of table input are explicitly specified.
Some cells cannot be modeled with statetable format. For example, you cannot use
statetable format to model a cell whose function depends on differential clocks when
the inputs change.
Describing a Flip-Flop
To describe an edge-triggered storage device, include an ff group or a statetable group

in a cell definition. This section describes how to define a flip-flop using the ff/latch format.
See “Describing Sequential Cells with Statetable Format” later in this chapter for the
way to define cells using the statetable group.

5-2
Using an ff Group
An ff group can describe either a single-stage or a master-slave flip-flop. An ff_bank
group is used to represent multibit registers, such as a bank of flip-flops. See “Describing
a Multibit Flip-Flop,” later in this chapter, for more information on the ff_bank group.
Syntax:
cell (cell_name) {
...
ff ( variable1, variable2 ) {
clocked_on : ”Boolean_expression” ;
next_state : ”Boolean_expression” ;
clear : ”Boolean_expression” ;
preset : ”Boolean_expression” ;
clear_preset_var1 : value ;
clocked_on_also : ”Boolean_expression” ;
}
}
}
variable1
The state of the noninverting output of the flip-flop, also known as the 1-bit storage
of the flip-flop.
variable2
The state of the inverting output.
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.
clocked_on and clocked_on_also Attributes

The clocked_on and clocked_on_also attributes identify the active edge of the clock
signals. Single-stage flip-flops use only the clocked_on attribute. When you are
describing 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.

5-3
Example:
This describes a positive edge-triggered device:
clocked_on : ”CP”;
This describes a negative edge-triggered device:
clocked_on : ”CP’”;
next_state and nextstate_type Attributes

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 equation determines the
value of the master stage’s output signals at the next active transition of the clocked_on
attribute.
Syntax:
next_state : Boolean expression ;
Boolean expression
Identifies the active edge of the clock signal.
Example:
next_state : ”(J K IQ’) + (J K’) + (J’ K’ IQ)” ;
The nextstate_type attribute is a pin group attribute that defines the type of next_state
pin used in the ff or ff_bank group.
Syntax:
nextstate_type : data | preset | clear | load | scan_in | scan_enable ;
data
Identifies the pin as a synchronous data pin. This is the default value.
preset
Identifies the pin as a synchronous preset pin.
clear
Identifies the pin as a synchronous clear pin.

5-4
load
Identifies the pin as a synchronous load pin.
scan_in
Identifies the pin as a synchronous scan-in pin.
scan_enable
Identifies the pin as a synchronous scan-enable pin.
Any pin with the nextstate_type attribute must be in the next_state function.
Example:
nextstate_type : clear;
Figure 5-1 shows how to use the nextstate_type attribute.
Example 5-1 Partial D Flip-Flop Description

cell (dff) {
area : 1 ;
pin (CLK) {
direction : input ;
capacitance : 0 ;
}
pin (D) {
nextstate_type : data;
direction : input ;
capacitance : 0 ;
}
clear Attribute
The clear attribute gives the active value for the clear input.
Example:
This example defines an active-low clear signal.
clear : ”CD’” ;
See the “Describing a Single-Stage Flip-Flop” section for more information about the
clear attribute.
preset Attribute
The preset attribute gives the active value for the preset input.

5-5
Example:
This example defines an active-high preset signal.
preset : ”PD” ;
preset attribute.
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;
clear_preset_var1 attribute, including its function and values.
clear_preset_var2 Attribute
are both active at the same time.
Example:
clear_preset_var2 : L ;
clear_preset_var2 attribute, including its function and values.
ff Group Examples
This is an example of an ff group for a single-stage D flip-flop.
ff(IQ, IQN) {
next_state : ”D” ;
clocked_on : ”CP” ;
}
This example defines two variables, IQ and IQN. The next_state equation determines
the value of IQ after the next active transition of the clocked_on attribute. In the example
above, IQ is assigned the value of the D input.

5-6
In some flip-flops, the next state depends on the current state. In such cases, the first
state variable, IQ in the example, can be used in the next_state statement; the second
state variable, IQN, cannot.
For example, the ff declaration for a JK flip-flop looks like this:
ff(IQ,IQN) {
next_state : ”(J K IQ’) + (J K’) + (J’ K’ IQ)”;
}
The next_state and clocked_on attributes completely define the synchronous behavior
of the flip-flop.
Describing a Single-Stage Flip-Flop

Table 5-1 shows the functions of the attributes in an ff group for a single-stage flip-flop.
Table 5-1 Function Table for Single-Stage Flip-Flop

active edge clear preset variable1 variable2
clocked_on inactive inactive next_state !next_state
-- active inactive 0 1
-- inactive active 1 0
-- active active clear_preset_var1 clear_preset_var2
The clear_preset_var1 and clear_preset_var2 attributes give the values that variable1
and variable2 have when clear and preset are both active at the same time. Valid values
are
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 include both clear and preset, you must use either clear_preset_var1 or
clear_preset_var2, or both. Conversely, if you include clear_preset_var1 or
clear_preset_var2, or both, you must use both clear and preset.
The flip-flop cell is activated whenever clear, preset, or clocked_on changes.

5-7
Example 5-2 is an ff group for a single-stage D flip-flop with rising-edge sampling,
negative clear and preset, and output pins set to 0 when both clear and preset are active
(low).
Example 5-2 Single-Stage D Flip-Flop

ff(IQ, IQN) {
preset : ”PD’” ;
}
Example 5-3 is an ff group for a single-stage, rising-edge triggered JK flip-flop with scan
input, negative clear and preset, and output pins set to 0 when clear and preset are both
active.
Example 5-3 Single-Stage JK Flip-Flop

ff(IQ, IQN) {
next_state :”(TE*TI)+(TE’*J*K’)+(TE’*J’*K’*IQ)+(TE’*J*K*IQ’)” ;
preset : ”PD’” ;
}
Example 5-4 is an ff group for a D flip-flop with synchronous negative clear.
Example 5-4 D Flip-Flop with Synchronous Negative Clear

ff(IQ, IQN) {
next_state : ”D * CLR” ;
}
Describing a Master-Slave Flip-Flop

The syntax 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 5-2 shows the functions of the
attributes in the ff group for a master-slave flip-flop.

5-8
Table 5-2 Function Tables for Master-Slave Flip-Flop
active edge clear preset internal1 * internal2 * variable1 variable2
clocked_on inactive inactive next_state !next_state
clocked_on_ inactive inactive internal1 internal2

also
-- active active clear_preset_ clear_preset_ clear_preset_ clear_preset_
var1 var2 var1 var2
-- active inactive 0 1 0 1
inactive active 1 0 1 0
*. You do not need to specify the internal1 and internal2 variables, which represent internal stages in the flip-flop.
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 clear and preset are both active at the same time.
Example 5-5 shows an ff group for a master-slave D flip-flop with rising-edge sampling,
falling-edge data transfer, negative clear and preset, and output values set high when
clear and preset are both active.
Example 5-5 Master-Slave D Flip-Flop

ff(IQ, IQN) {
clocked_on : ”CLK” ;
clocked_on_also : ”CLKN’” ;
clear : ”CDN’” ;
preset : ”PDN’” ;
clear_preset_var1 : 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 5-6 shows a complete functional description of a positive edge-triggered D flip-

flop with active-low clear and preset.

5-9
Example 5-6 D Flip-Flop Description
cell (dff) {
area : 1 ;
pin (CLK) {
direction : input ;
capacitance : 0 ;
}
pin (D) {
direction : input ;
capacitance : 0 ;
}
pin (CLR) {
direction : input ;
capacitance : 0 ;
}
pin (PRE) {
direction : input ;
capacitance : 0 ;
}
ff (IQ, IQN) {
clear : ”CLR’” ;
preset : ”PRE’” ;
}
pin (Q) {
}
pin (QN) {
function : ”IQN” ;
}
} /* end of cell dff */
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 also
be used in cell and test_cell groups.

5-10
The syntax is similar to that of the ff group; see the “Describing a Flip-Flop” section
earlier in this chapter.
Syntax:
cell (cell_name) {
...
pin (pin_name) {
...
}
bundle (bundle_name) {
...
}
ff_bank ( variable1, variable2, bits ) {
clocked_on : ”Boolean_expression” ;
next_state : ”Boolean_expression” ;
clocked_on_also : ”Boolean_expression” ;
}
}
}
An input 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. To specify this function, add a three_state attribute
to an output bus or bundle.
The bits value in the ff_bank definition is the number of bits in this multibit cell.
Figure 5-1 shows a multibit register containing four positive edge-triggered D flip-flops
with clear and preset.

5-11
Figure 5-1 Multibit Flip-Flop
PRE
PRE
D1 D Q Q1
CLK CLK
QN Q1N
CLR
CLR
PRE
D2 D Q Q2
CLK Q2N
QN
CLR
PRE
D3 D Q Q3
CLK
QN Q3N
CLR
PRE
D Q
D4 Q4
CLK
QN Q4N
CLR
Example 5-7 is the description of the multibit register shown in Figure 5-1.
Example 5-7 Multibit D Flip-Flop Register

cell (dff4) {
area : 1 ;
pin (CLK) {
direction : input ;
capacitance : 0 ;
}

5-12
bundle (D) {
members(D1, D2, D3, D4);
direction : input ;
capacitance : 0 ;
timing() {
related_pin : ”CLK” ;
timing_type : setup_rising ;
}
timing() {
timing_type : hold_rising ;
}
}
pin (CLR) {
direction : input ;
capacitance : 0 ;
timing() {
timing_type : recovery_rising ;
}
}
pin (PRE) {
direction : input ;
capacitance : 0 ;
timing() {
timing_type : recovery_rising ;
}
}
ff_bank (IQ, IQN, 4) {
}
bundle (Q) {
function : ”(IQ)” ;
timing() {
timing_type : rising_edge ;

5-13
}
timing() {
related_pin : ”PRE” ;
timing_type : preset ;
timing_sense : negative_unate ;
}
timing() {
related_pin : ”CLR” ;
timing_type : clear ;
timing_sense : positive_unate ;
}
}
bundle (QN) {
members(Q1N, Q2N, Q3N, Q4N);
timing() {
}
timing() {
}
timing() {
}
}
} /* end of cell dff4 */
Describing a Latch
To describe a level-sensitive storage device, include a latch group or statetable group

in the cell definition. This section describes how to define a latch using the ff/latch format.
See “Describing Sequential Cells with Statetable Format” later in this chapter for the
way to define cells using the statetable group.

5-14
latch Group
The syntax for a latch group is shown below.
Syntax:
cell (cell_name) {
...
latch ( variable1, variable2 ) {
enable : ”Boolean_expression” ;
data_in : ”Boolean_expression” ;
}
}
}
variable1
The state of the noninverting output of the latch. It is considered the one-bit storage
of the latch.
variable2
The state of the inverting output.
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 or
clear_preset_var2, or both. Conversely, if you include clear_preset_var1 or
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 data_in
gives the state of the data input.
Example:
enable : ”G” ;
data_in : ”D”;

5-15
clear Attribute
The clear attribute gives the active value for the clear input.
Example:
This example defines an active-low clear signal.
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 and clear_preset_var2 Attributes

are both active at the same time. 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:
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
Example:
clear_preset_var1 : L;

5-16
Table 5-3 shows the functions of the attributes in the latch group.
Table 5-3 Function Table for 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 the clear, preset, enable, or data_in attribute
changes.
Figure 5-8 shows a latch group for a D latch with an active-high enable and negative clear.
Example 5-8 D Latch with Active-High Enable and Negative Clear

latch(IQ, IQN) {
enable : ”G” ;
data_in : ”D” ;
}
Example 5-9 shows a latch group for an SR latch. Note that the enable and data_in
attributes are not required for an SR latch.
Example 5-9 SR Latch

latch(IQ, IQN) {
clear : ”S’” ;
preset : ”R’” ;
}
A fully described D latch can be found at the end of the “Examples of Portions of Cell
Descriptions” section, later in this chapter.
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 to represent multibit registers in cell
and test_cell groups.

5-17
The syntax for the latch_bank group is similar to that of the latch group. See the
“Describing a Latch” section earlier in this chapter.
Syntax:
cell (cell_name) {
...
pin (pin_name) { ...
}
bundle (bus_name) { ...
}
latch_bank ( variable1, variable2, bits ) {
enable : “Boolean_expression” ;
data_in : “Boolean_expression” ;
}
}
}
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 5-10 shows a latch_bank group for a multibit register containing four positive
edge-triggered D latches.
Example 5-10 Multibit D Latch

cell (latch4) {
area: 16;
pin (G) { /* gate enable signal, active-high */
direction : input;
...
}
members(D1, D2, D3, D4);/*must be first bundle attribute*/
direction : input;
...
}
bundle (Q) {
direction : output;
function : “IQ” ;

5-18
...
}
bundle (QN) {
direction : output;
function : “IQN”;
...
}
enable : “G” ;
data_in : “D” ;
}
...
}
Figure 5-2 shows a multibit register containing four high-enable D latches with clear.

5-19
Figure 5-2 Multibit Latch
PREA
PRE
DA D Q QA
EN EN
QN QNA
CLR
CLRA
PREB
PRE
DB D Q QB
EN
QN QNB
CLR
CLRB
PREC
PRE
DC D Q QC
EN
QN QNC
CLR
CLRC
PRED
PRE
D Q
DD QD
EN QN
QND
CLR
CLRD
Example 5-11 is the cell description of the multibit register shown in Figure 5-2.
Example 5-11 Multibit Latches with Clear

cell (DLT2) {
/* note: 0 hold time */
area : 1 ;

5-20
pin (EN) {
direction : input ;
capacitance : 0 ;
}
bundle (D) {
members(DA, DB, DC, DD);
direction : input ;
capacitance : 0 ;
timing() {
related_pin : ”EN” ;
timing_type : setup_falling ;
}
timing() {
timing_type : hold_falling ;
}
}
bundle (CLR) {
members(CLRA, CLRB, CLRC, CLRD);
direction : input ;
capacitance : 0 ;
timing() {
timing_type : recovery_falling ;
}
}
bundle (PRE) {
members(PREA, PREB, PREC, PRED);
direction : input ;
capacitance : 0 ;
timing() {
timing_type : recovery_falling ;
}
}
data_in : ”D” ;
enable : ”EN” ;

5-21
}
bundle (Q) {
members(QA, QB, QC, QD);
timing() {
related_pin : ”D” ;
}
timing() {
}
timing() {
}
timing() {
}
}
bundle (QN) {
members(QNA, QNB, QNC, QND);
timing() {
related_pin : ”D” ;
}
timing() {
}
timing() {

5-22
}
timing() {
}
}
} /* end of cell DLT2
Describing Sequential Cells with Statetable Format
Statetable format provides an intuitive way to describe the function of complex sequential
cells. This format turns a state table in a databook into a Liberty cell description.
Figure 5-3 shows how you can model each sequential output port (OUT and OUTN) in
a sequential library cell.
Figure 5-3 Generic Sequential Library Cell Model
delay* Internal Nodes

IN
Statetable
OUT
Output Logic
delay*
OUTN
Output Logic
OUT and OUTN

Sequential output ports of the sequential cell.

5-23
IN
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 statetable 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 statetable.
Internal Nodes
As storage elements, internal nodes store the output values of the statetable. There
can be any number of internal nodes.
Output Logic
A combinational lookup table. For the sequential cells supported in ff/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. The purpose of this group is to define the statetable in Figure 5-3. The statetable
group syntax maps to the truth tables in databooks.
Figure 5-4 is an example of a table that maps a truth table from an ASIC vendor’s
databook to the statetable syntax. See the “statetable Group” section later in this chapter
for table input token values.

5-24
Figure 5-4 Mapping Databook Truth Table to a Statetable
Databook Meaning Statetable Input Statetable Output
f Fall F N/A
No event
nc No event N/A N from current
value
r Rise R N/A
Toggle
tg Toggle N/A (1) flag tg (1)
u Undefined N/A X Unknown
x Don’t Care _ X
_ _
Not Used X
Rising edge Don't care Falling edge

(from low to high) (from high to low)
To map a databook truth table to a statetable:
1. When the databook truth table includes the name of an input port, replace that port
name with the tokens for low/high (L/H).
2. 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.
3. 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.
In the truth table, an output port preceded with a hyphen (-) symbol is inverted.
Sometimes you must map f to ~R (not rising edge) and r to ~F (not falling edge).

5-25
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”;
}
These are statetable group conventions:
• Give nodes unique names.

• Separate node names with white space.
• Use double quotes around the list of input node names, and around the internal
node names.
• Place each rule on a separate line followed by a comma and the line continuation
character (\). A rule consists of a set of input node values, current internal values,
and next internal values 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 character space is allowed. For example, you cannot
insert a comment within an H/L token or after the line continuation character (\).
Figure 5-5 shows an example of a statetable group.
Figure 5-5 statetable Group Example
statetable ( "G CD D" , "IQ" ) {

table : "- L - :- : L, \
H H L/H :- : L/H, \
L H - :-: N" ;
}
Input Node Values Current Next

Internal Internal
Values Values
Table Inputs

5-26
Table 5-4 shows the token values for table inputs.
Table 5-4 Legitimate Values for Table Inputs (Input and Current Internal Nodes)
Input Node Current Internal State Represented
Values Node Values
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 5-5 shows the token values for next internal nodes.
Table 5-5 Legitimate Values for Next Internal Node

Next Internal State Represented
Node Value
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 Hold. No event from current value. Use
only when all asynchronous inputs and
clocks are inactive.
Note: 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.
Using Shorthand Notation

To represent a statetable explicitly, you list the next internal node once for every
permutation of L and H for the current inputs, previous inputs, and current states.

5-27
This is an example of a 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 shorthand notation 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/L R F : L - : H/L L,\
H/L R 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";
}

5-28
• 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 lines:
H H H : - : L,
H H L : - : H,
can be written more concisely as follows:
H H H/L : - : 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 (that is, 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”;
This is the internal representation of the same 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.
Use shorthand notation with care. When in doubt, be explicit.

5-29
Partitioning the Cell into a Model
You can partition a structural netlist to match the general sequential output model
described in Example 5-12 by performing these tasks:
1. Represent every storage element by an internal node.

2. 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.
Example 5-12 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”;
}
Note: It is very important to use the nonactive N value. There are two ways to
specify that an output does not change logic values. Example 5-12 shows
both ways.
In Example 5-12, 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 attribute.
An output pin can have one of the following combinations:
• An internal_node attribute, an input_map attribute (optional), a three_state attribute

(optional) and an inverted_output attribute (required for statetable format only;
optional otherwise)
• A state_function attribute, a three_state attribute (optional), and an inverted_output
attribute (required for statetable format only; optional otherwise)

5-30
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 may have an optional input_map
attribute.
Syntax:
internal_node : name ;
name
Name of the internal node.
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 statetable. An input map is a list of port names
corresponding to internal nodes, separated by white space.
Syntax:
input_map : name | name_list ;
name
A string of port names, separated by white spaces, that correspond to the input pin
names, followed by the internal node names.
Example:
input_map : ”Gx1 CDx1 Dx1 QN”;/*QN is internal node*/
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.

5-31
The input_map attribute can be completely unspecified, completely specified, or may
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.
Mapping port and internal pin names to table input and internal nodes occurs through
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 attribute, 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, if a statetable has input nodes A and B, and internal node Z, and you want
to map them to ports D, CP, and Q respectively, set the input_map attribute as follows:
input_map : ”D CP Q”
With the input_map attribute, the functional syntax for ganged cells is identical to
nonganged cells. You can use input_map to represent the interconnection of any network
of sequential cells (for example, shift registers and counters).
The delayed nature of outputs specified in the input_map 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.
For example, Figure 5-6 shows a circuit consisting of latch U1 and flip-flop U2.
Figure 5-6 Circuit with Latch and Flip-Flop

5-32
In Figure 5-6, 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.
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 output, the state_function attribute cannot have a Boolean expression that
uses pin E.
Note: An inout port in the state_function expression is treated only as an input

port.
Syntax:
state_function : Boolean expression ;
Example:
pin(Q)
direction : output;
state_function : ”A”; /*combinational feedthrough*/
inverted_output Attribute
The inverted_output attribute is a required Boolean attribute for 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;
An output is considered inverted if it has any data input with a negative sense. This
definition may be inconsistent with a user’s intentions. For example, whether a toggle
output is considered inverted or noninverted is arbitrary.

5-33
Internal Pin Type
In ff/latch format, pin, bus, or bundle groups can have a direction attribute with input,
output, or inout values. In statetable format, the direction attribute for any library cell
(combinational or sequential) can also have the value internal. A pin whose direction
attribute has the value internal 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 with the following
exceptions:
• It cannot have the three_state attribute.

• It cannot have the state_function attribute.
An internal pin can have timing arcs and can have timing arcs related to it, just like an
input, output, or inout pin. Timing arcs on internal pins can be used to describe a
distributed delay model for multistate sequential cells.
Example:
pin (IQ) {
direction : internal;
Figure 5-13 shows a pin with a direction attribute that has the value internal.
Example 5-13 Internal Pin Type

pin (n1) {
internal_node :”IQ”; /* use default input_map */
...
pin (QN) {
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 */
...

5-34
Flip-Flop and Latch Examples
The following examples show flip-flops and latches in ff/latch and statetable syntax.
Example 5-14 D Flip-Flop
/* ff/latch format */
ff (IQ,IQN) {
}
/* statetable format */
statetable(”D CP”, ”IQ”) {

table : ”H/L R : - : H/L,\
- ~R : - : N”;
}
Example 5-15 D Flip-Flop with Gated Clock
ff (IQ,IQN) {
clocked_on : ”C1 * C2” ;
}
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”;
}
Example 5-16 D Flip-Flops with Master-Slave Clock Input Pins
ff (IQ,IQN) {
clocked_on : ”CK” ;
clocked_on_also : ”CKN’” ;
}

5-35
statetable(” D CK CKN”, ”MQ SQ”) {
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 5-17 D Flip-Flop with Active-Low Direct-Clear and Active-Low Direct-Set
ff (IQ,IQN) {
clear : ” CD’ ” ;
preset : ” SD’ ” ;
}
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 5-18 D Flip-Flop with Active-Low Direct-Clear, Active-Low Direct-Set, and One Output
ff (IQ,IQN) {
preset : ” SD’ ” ;
}
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”;
}

5-36
Example 5-19 JK Flip-Flop with Active-Low Direct-Clear and Negative-Edge Clock
ff (IQ, IQN) {
next_state : ” (J’ K’ IQ) + (J K’) + (J K IQ’)” ;
clocked_on : ” CN’” ;
clear : ” CD’” ;
}
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 5-20 D Flip-Flop with Scan Input Pins
ff (IQ,IQN) {
next_state : ” (D TE’) + (TI TE)” ;
}
statetable(” D TE TI CP”, ”IQ”) {

table : ” H/L L - R : - : H/L,\
- H H/L R : - : H/L,\
- - - ~R : - : N”;
}
Example 5-21 D Flip-Flop with Synchronous Clear
ff (IQ, IQN) {
next_state : ”D CR” ;
}

5-37
statetable(” D CR CP”, ”IQ”) {

table : ” H/L H R : - : H/L,\
- L R : - : L,\
- - ~R : - : N”;
}
Example 5-22 D Latch
latch (IQ,IQN) {
data_in : ”D” ;
enable : ”G” ;
}
statetable(” D G”, ”IQ”) {

table : ” H/L H : - : H/L,\
- L : - : N”;
}
Example 5-23 SR Latch
latch (IQ,IQN) {
clear : ”R” ;
preset : ”S” ;
}
statetable(” R S”,”IQ IQN”) {

table : ” H L : - - : L H,\
L H : - - : H L,\
H H : - - : L L,\
L L : - - : N N”;
}
Example 5-24 D Latch with Active-Low Direct-Clear
latch (IQ,IQN) {
data_in : ”D” ;
enable : ”G” ;

5-38
}
statetable(” D G CD”, ”IQ”) {

table : ” H/L H H : - : H/L,\
- L H : - : N,\
- - L : - : L”;
}
Example 5-25 Multibit D Latch with Active-Low Direct-Clear
data_in : ”D” ;
enable : ”EN” ;
}
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 5-26 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”;
}

5-39
Examples of Portions of Cell Descriptions
The examples in this section are illustrations of some of the concepts this chapter
discusses.
Example 5-27 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) {
input_map : ”D G1”;
timing() {
related_pin : ”G1”;
}
}
pin (Q) {
direction : output;
input_map : ”mq G2”;
timing() {
}
}
pin (QN) {
direction : output;
internal_node : ”QN”;

5-40
input_map : ”mq G2”;
timing() {
}
}
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 5-28 FF Shift Register (timing removed)
cell(shift_reg_ff) {
area : 16;
pin (D) {
direction : input;
capacitance : 1;
}
pin (CP) {
direction : input;
capacitance : 2;
}
pin (Q0) {
direction : output;
input_map : ”D CP”;
}
pin (Q1) {
direction : output;
input_map : ”Q0 CP”;
}
pin (Q2) {
direction : output;
}

5-41
pin (Q3) {
direction : output;
}
statetable( ”D CP”, ”Q QN” ) {
table : ”- ~R : - - : N N,\
H/L R : - - : H/L L/H”;
}
}
Example 5-29 FF Counter (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;
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”;
}
}

5-42
Example 5-30 Fully Described D Latch
cell(D_LATCH) {
area : 5;
pin (D) {
direction : input;
capacitance : 1;
timing() {
timing_type : setup_falling; /*To falling edge of G */
related_pin : ”G”;
}
timing() {
timing_type : hold_falling; /*To falling edge of G */
}
}
pin (G) {
direction : input;
capacitance : 1;
}
pin (CD) {
direction : input;
capacitance : 1;
}
latch (”IQ”,”IQN”) {
data_in : ”D”;
enable : ”G”;
clear : ”CD’”;
}
pin (Q) {
direction : output;
internal_power() {
related_pin : D, G, CD’ ;
equal_or_opposite_output : QN ;
power(output_by_cap_and_trans) {
values(”0.5, 0.9, 1.3”, ”0.3, 0.7, 1.1”, ”0.2, 0.5, 0.9”) ;
}
}
timing() {
timing_type : rising_edge; /* Arc activates when */
intrinsic_rise : 0.89; /* enable goes active */
intrinsic_fall : 0.86; /* (rises). */

5-43
}
timing() {
intrinsic_rise : 0.65
timing_sense : positive_unate;
related_pin : ”D”;
}
timing() {
timing_type : clear;
related_pin : ”CD”;
}
}
pin(QN) {
direction : output;
timing() {
timing_type : rising_edge;
}
timing() {
timing_sense : negative_unate;
}
timing() {
timing_type : preset;
related_pin : ”CD”;
}
}
}

5-44
6
Modeling Memory Modules 1
This chapter describes how to model memory modules (both RAM and ROM) with
Liberty syntax.
Memory Modeling Approaches
RAM and ROM modules can be modeled in either of two ways:
• As a design netlist of smaller primitive elements

• As a black box
Figure 6-1 shows a block diagram of a RAM or ROM module. Logic blocks are netlists
of arbitrary combinational and sequential logic. The memory block is an array of storage
elements in which every individual bit can be read from or written to.
Modeling Memory Modules

6-1
Figure 6-1 Block Diagram of RAM or ROM Module
RAM/ROM cell
Inputs Logic Memory Block Logic Outputs
The method outlined in this chapter uses a functional description contained in a memory
group. Timing information comes from the interface timing specification (ITS) available
from the ASIC vendor and is specified in a timing group. The ITS describes the static
timing of a block (such as RAM or ROM) as seen from the outside. For more information
on ITS semantics, see Chapter 11, “Interface Timing of Complex Sequential Blocks.”
For timing group syntax, see Chapter 10, “Timing Arcs.”
Memory modeling syntax supports unparameterized memory cells with the following
characteristics:
• Synchronous and asynchronous RAMs

• Multiport and single port
• Same data-in and data-out port
• Same read and write address ports
• Separate read and write address ports
• Control pins (chip select, write enable, and clock)
• Ability to write to bits of a word
This is the general procedure for modeling a memory module:
1. In the technology library, add the memory group to a cell group.

2. In the bus group of the memory cell, use the memory_write group to define the way
data is written into the memory block. Use the memory_read group to define the
function of the output.
You can use statetable format to describe the function of the cell. See Chapter 5,
“Defining Sequential Cells,” for information about statetable format. Example 6-11
shows a function description with statetable format.
3. Obtain the module’s ITS description from the ASIC vendor, or create one. See
Chapter 11, “Interface Timing of Complex Sequential Blocks,” for information about
creating an ITS description.

6-2
See the “Examples of Memory Modules” section in this chapter for examples of memory
modules and their functional descriptions.
memory Group
The memory group is in the cell group. The memory group tags the cell as a memory
cell and contains general information about the memory cell, described with these
attributes:
• type
• address_width
• word_width
• column_address
• row_address
Syntax:
cell()
memory() {
type : [ram | rom ];
address_width : “integer” ;
word_width : “integer” ;
column_address : ”integer” ;
row_address : ”integer” ;
}
}
type Attribute
This simple attribute specifies the type of memory block. Type can be ram or rom.
Syntax:
type : [ram | rom] ;
ram, rom
The enumerated type of the memory block.
Example:
type : ram;

6-3
address_width Attribute
This simple attribute specifies the number of inputs needed to address the memory block.
Syntax:
address_width : integer ;
integer
Number of address inputs.
Example:
address_width : 4;
word_width Attribute
This attribute specifies the width (number of data bits in the word) of the memory block.
Syntax:
word_width : integer ;
integer
Number of bits in the memory word.
Example:
word_width : 4;
column_address Simple Attribute

This attribute specifies the number or range of numbers of indexes for a column.
Syntax:
column_address : ”index1 [range1 index2 index3 ...]” ;
integer
Number or range of numbers of indexes. Separate the numbers in a range with a
colon.
Example:
column_address : ”0:4 5” ;

6-4
row_address Simple Attribute
This attribute specifies the number or range of numbers of indexes for a row.
Syntax:
row_address : ”index1 [range1 index2 index3 ...]” ;
integer
Number or range of numbers of indexes. Separate the numbers in a range with a
colon.
Example:
row_address : ”6:9” ;
Example 6-16 at the end of this chapter shows a RAM cell with a memory description
that includes the column_address and row_address attributes.
memory_read Group
The memory_read group is in the bus group. All memory-block output requires a
memory_read group to define how the output functions. This group is allowed only on
output buses and internal buses. It cannot be used in input bus groups.
Note: The bus cannot have a state_function attribute or an internal_node attribute.
Syntax:
cell()
...
bus() {
...
memory_read() {
address : bus ;
}
}
}

6-5
address Attribute
This simple attribute is required in the memory_read group. It specifies the name of the
address bus to be read. The width of the bus must be the same as address_width in the
memory group. An output bus with a memory_read attribute always reflects the values
stored in the location pointed to by the address.
Syntax:
address : ram_addr bus ;
ram_addr bus
The bus name of the memory block to be read.
Example:
address : ADDR;
memory_write Group
The memory_write group is in the bus group. All data input requires a memory_write
group to define how the data is written into the memory block. The attributes in this group
are
• address
• clocked_on
• enable
Syntax:
cell()
bus() {
...
memory_write() {
address : bus ;
clocked_on : name ;
enable : name ;
}
}
}

6-6
address Attribute
This simple attribute is required in the memory_write group. It specifies the name of the
bus to be written. The width of the bus must be the same as address_width in the
memory group.
Syntax:
address : ram_addr bus ;
ram_addr bus
The bus name of the memory block to be read.
Example:
address : ADDR ;
clocked_on Attribute
This simple attribute identifies the active edge of the clock input for a synchronous RAM
cell. It is a pin or bus name. If it is a bus, it must have the same width as word_width in
the memory group.
Note: You cannot specify clocked_on if enable is specified.
Syntax:
clocked_on : string ;
string
Identifies the active edge of the clock signals of a pin or bus.
Example:
clocked_on : ”EN”;
enable Attribute
This simple attribute identifies the active level of the enable input for an asynchronous
RAM cell. It is a pin or bus name. If it is a bus, it must have the same width as word_width
in the memory group. This attribute requires the address attribute.
Note: You cannot specify enable if clocked_on is specified.

6-7
Syntax:
enable : string ;
string
The asynchronous enable input pin or bus.
Example:
enable : WR;
Examples of Memory Modules
The rest of this chapter comprises examples of memory modules in a library. Timing
data comes from the interface timing specification (ITS) for each cell.
Example 6-1 shows an asynchronous 4-word by 2-bit RAM cell with a single port.
Example 6-1 Asynchronous 4x2 RAM Cell with Single Port

library ( memory) {
...
type(bus4) {
base_type : array;
data_type : bit;
bit_width : 4;
bit_from : 0;
bit_to : 3;
downto : false;
}
type(bus2) {
base_type : array;
data_type : bit;
bit_width : 2;
bit_from : 0;
bit_to : 1;
downto : false;
}
...
cell(async_single) {
area : 778.000;
interface_timing : TRUE;
memory() { /* Indicates this is a memory cell */
type : ram;
address_width : 4;
word_width : 2;
}
bus (RA) {
bus_type : ”bus4”;

6-8
direction : input;
capacitance : 0.241;
timing () { /*Address setup time */
timing_type : setup_falling;
related_pin : ”WR”;
}
timing () { /* Address hold time */
timing_type : hold_rising;
}
}
bus (DI) {
bus_type : ”bus2”
direction : input;
memory_write() { /* Indicates this is a write port */
address : RA;
enable : WR;
}
timing () { /* Input data setup time */
timing_type : setup_rising;
}
timing () { /* Input data hold time */
}
}
pin (WR) {
direction : input;
capacitance : 0.28;
clock : true; /* WR pulse is modeled as a clock */
}
bus(DO){
direction : output;
memory_read() { /* Indicates this is a read port */
address : RA;
}
timing () {
timing_sense : non_unate; /* combinational delay */

6-9
related_bus_pins : ”RA”;
}
}
}
...
}
Example 6-2 shows an asynchronous 4-word by 2-bit RAM cell with a single port and
address latches.
Example 6-2 Asynchronous 4x2 RAM Cell with Single Port and Address Latches
library ( memory) {
...
type(bus2) {
base_type : array;
data_type : bit;
bit_width : 2;
bit_from : 0;
bit_to : 1;
downto : false;
}
...
cell (async_add_latch) {
area : 5000.000;
type : ram;
address_width : 2;
word_width : 2;
}
statetable ( ” RA RE”, ”RQ”) { /* address latch */
table : ” L/H H : - : L/H ,\
- L : - : N ”;
}
bus (RA) {
direction : input;
capacitance : 1.46;
timing () { /* Address setup times */
related_pin : ”RE”;
}
related_pin : ”RE”;
}
}

6-10
bus (RQ) {
capacitance : 1.46;
pin (RQ[0]) { /* The constraints for pin RQ[0] */
internal_node : ”RQ”;
input_map : ” RA[0], RE ”;
timing () {
related_pin : ”WE”;
}
timing () {
}
}
pin (RQ[1]) { /* The constraints for pin RQ[1] */
internal_node : ”RQ”;
input_map : ” RA[1], RE ”;
timing () {
}
timing () {
}
}
}
bus (DI) {
direction : input;
capacitance : 1.46;
memory_write() {
address : RQ ;
enable : WE;
}
timing () {
}
timing () {

6-11
}
}
pin (WE) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (RE) {
direction : input;
capacitance : 1.13;
clock : true;
}
bus(DO){
direction : output;
memory_read() {
address : RQ;
}
timing () {
timing_sense : non_unate;
related_pin : ”RA”;
}
}
}
}
Although a different size, this cell has the same timing and functionality as the one in
Example 6-1.

library ( memory) {
...
type(bus4) {
base_type : array;
data_type : bit;
bit_width : 4;
bit_from : 0;
bit_to : 3;
downto : false;
}
type(bus18) {
base_type : array;
data_type : bit;

6-12
bit_width : 18;
bit_from : 0;
bit_to : 17;
downto : false;
}
...
cell (async_single_16X18) {
area : 2556.000;
memory() {
type : ram;
address_width : 4;
word_width : 18;
}
bus (RA) {
direction : input;
}
}
}
bus (DI) {
direction : input;
capacitance : 1.46;
memory_write() {
address : RA;
enable : WR;
}
timing () { /* Input data setup time */
}
timing () { /* Input data hold time */
}
}
pin (WR) {

6-13
direction : input;
capacitance : 0.28;
clock : true;
}
bus(DO){
direction : output;
address : RA;
}
timing () {
}
}
}
...
}
This cell has a different size but the same timing and functionality as the asynchronous
cell in Example 6-1.

library ( memory) {
...
type(bus4) {
base_type : array;
data_type : bit;
bit_width : 4;
bit_from : 0;
bit_to : 3;
downto : false;
}
type(bus32) {
base_type : array;
data_type : bit;
bit_width : 32;
bit_from : 0;
bit_to : 31;
downto : false;
}
...
cell (async_single_16X32) {
area : 4908.000;

6-14
type : ram;
address_width : 4;
word_width : 32;
}
bus (RA) {
direction : input;
}
}
}
bus (DI) {
direction : input;
memory_write() {/* Indicates this is a write port */
address : RA;
enable : WR;
}
timing () {
}
timing () {
}
}
pin (WR) {
direction : input;
capacitance : 0.28;
clock : true;
}
bus(DO){
direction : output;

6-15
address : RA;
}
timing () {
}
}
}
...
}
Example 6-5 shows an asynchronous 1K-word by 8-bit RAM cell with a single port,
active-low write enable (WE), and active-low chip enable (CE).
Example 6-5 Asynchronous 1Kx8 RAM Cell with Single Port

library ( memory) {
...
type(bus10) {
base_type : array;
data_type : bit;
bit_width : 10;
bit_from : 0;
bit_to : 9;
}
type(bus8) {
base_type : array;
data_type : bit;
bit_width : 8;
bit_from : 0;
bit_to : 7;
downto : false;
}
...
cell (async_chp_enb) {
area : 1381.000;
memory() {
type : ram;
address_width : 10;
word_width : 8;
}
bus (RA) {
direction : input;
timing () {
intrinsic_rise : 2.1; /* Address setup time */

6-16
}
timing () {
intrinsic_rise : 0.0; /* Address hold time */
}
}
pin (WRE) {
capacitance : 0.28;
state_function : ”!(WE’ * CE’)”;
clock : true; /* write occurs only when WE and CE are active */
}
bus (DI) {
direction : input;
memory_write() {
address : RA;
enable : ”WRE”;
}
timing () {
intrinsic_rise : 1.50; /* input data setup time */
}
timing () {
intrinsic_rise : 0.65; /* input data hold time */
}
timing () {
related_pin : ”CE”;
}
timing () {
}
}
pin (WE) {
direction : input;
capacitance : 0.28;
clock : true;

6-17
}
pin (CE) {
direction : input;
capacitance : 0.28;
clock : true; /* CE must be active for write or read to occur */
}
bus(DO){
direction : output;
memory_read() {
address : RA;
}
timing () {
intrinsic_rise : 5.15; /* tacc*/
}
timing () {
intrinsic_rise : 1.6; /* output data setup time */
}
timing () {
intrinsic_rise : 0.01; /* output data hold time */
}
}
}
...
}
Example 6-6 shows an asynchronous 1K-word by 8-bit RAM cell with a single data port.
Example 6-6 Asynchronous 1Kx8 RAM Cell with Single Data Port
library ( memory) {
...
type(bus10_1) {
base_type : array;
data_type : bit;
bit_width : 10;
bit_from : 9;
bit_to : 0;
downto : true
}

6-18
type(bus8_1) {
base_type : array;
data_type : bit;
bit_width : 8;
bit_from : 7;
bit_to : 0;
downto : true;
}
...
cell (async_bidir) {
area : 2300.000000;
memory() {
type : ram;
address_width : 10;
word_width : 8;
}
bus (RA) {
bus_type : ”bus10_1”;
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
pin (WE) {
direction : input;
capacitance : 1.13;
fanout_load : 1.13;
clock : true;
}
pin (CE) {
direction : input;
capacitance : 1.13;
fanout_load : 1.13;
clock : true;
}
bus (data) {
bus_type : ”bus8_1”
direction : inout;
capacitance : 1.46;
memory_read() {

6-19
address : RA;
}
memory_write () {
address : RA;
enable : WE;
}
three_state : ”CE”;
timing () {
}
timing () {
}
timing () {
}
}
}
...
}
Example 6-7 shows an asynchronous 9-bit by 2-word RAM cell with dual port, read bar,
and write bar.
Example 6-7 Asynchronous 9x2 RAM Cell with Dual Port

library ( memory) {
...
type(bus3) {
base_type : array;
data_type : bit;
bit_width : 3;
bit_from : 0;
bit_to : 2;
downto : false;
}
type(bus2) {
base_type : array;
data_type : bit;
bit_width : 2;
bit_from : 0;

6-20
bit_to : 1;
downto : false;
}
...
cell (async_web_oeb) {
area : 5000.000;
memory() {
type : ram;
address_width : 3;
word_width : 2;
}
bus (RA) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
related_pin : ”OE”;
}
timing () {
}
}
bus (WA) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
bus (DI) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;

6-21
memory_write() {
address : WA;
enable : ”WEB”;
}
timing () {
}
timing () {
}
}
pin (WE) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (OE) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (WEB) {
capacitance : 1.13;
state_function : ”!WE”;
clock : true;
}
bus(QO){
direction : output;
memory_read() {
address : RA;
}
three_state : ”!OE”;
timing () {
}
timing () {
intrinsic_rise : 1.50; /* output data setup time */

6-22
}
timing () {
intrinsic_rise : 0.65; /* output data hold time */
}
}
}
...
}
Example 6-8 shows an asynchronous 16-bit by 18-word RAM cell with dual port.

library ( memory) {
...
type(bus18) {
base_type : array;
data_type : bit;
bit_width : 18;
bit_from : 0;
bit_to : 17;
downto : false;
}
type(bus4) {
base_type : array;
data_type : bit;
bit_width : 4;
bit_from : 0;
bit_to : 3;
downto : false;
}
...
cell (async_dual_16X18) {
area : 5000.000;
memory() {
type : ram;
address_width : 4;
word_width : 18;
}
bus (RA) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {

6-23
}
timing () {
}
}
bus (WA) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
bus (DI) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
memory_write() {
address : WA;
enable : WE;
}
timing () {
}
timing () {
}
}
pin (WE) {
direction : input;
capacitance : 1.13;
clock : true;
}

6-24
pin (OE) {
direction : input;
capacitance : 1.13;
clock : true;
}
bus(QO){
direction : output;
memory_read() {
address : RA;
}
three_state : ”OE”;
timing () {
}
timing () {
}
timing () {
}
}
}
...
}
Example 6-9 shows an asynchronous 16-bit by 32-word RAM cell with dual port.

library ( memory) {
type(bus4) {
base_type : array;
data_type : bit;
bit_width : 4;
bit_from : 0;
bit_to : 3;
downto : false;
}
type(bus32) {
base_type : array;
data_type : bit;

6-25
bit_width : 32;
bit_from : 0;
bit_to : 31;
downto : false;
}
cell (async_dual_16X32) {
area : 5000.000;
memory() {
type : ram;
address_width : 4;
word_width : 32;
}
bus (RA) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
bus (WA) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
bus (DI) {
direction : input;
capacitance : 1.46;

6-26
fanout_load : 1.46;
memory_write() {
address : WA;
enable : WR;
}
timing () {
}
timing () {
}
}
pin (WR) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (OE) {
direction : input;
capacitance : 1.13;
clock : true;
}
bus(QO){
direction : output;
memory_read() {
address : RA;
}
timing () {
}
}
}
}

6-27
Example 6-10 shows an asynchronous 1K-word by 8-bit RAM cell with a dual port.
Example 6-10 Asynchronous 1Kx8 RAM Cell with Dual Port

library ( memory) {
...
type(bus10_1) {
base_type : array;
data_type : bit;
bit_width : 10;
bit_from : 9;
bit_to : 0;
downto : true
}
type(bus8_1) {
base_type : array;
data_type : bit;
bit_width : 8;
bit_from : 7;
bit_to : 0;
downto : true;
}
...
cell (async_dual) {
area : 5000.000;
memory() {
type : ram;
address_width : 10;
word_width : 8;
}
bus (RA) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}

6-28
bus (WA) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
bus (DI) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
memory_write() {
address : WA;
enable : WE;
}
timing () {
}
timing () {
}
}
pin (WE) {
direction : input;
capacitance : 1.13;
fanout_load : 1.13;
clock : true;
}
pin (OE) {
direction : input;
capacitance : 1.13;
fanout_load : 1.13;
clock : true;
}

6-29
bus(QO){
direction : output;
memory_read() {
address : RA;
}
timing () {
}
}
}
...
}
Example 6-11 is an asynchronous 16-word by 8-bit RAM cell with two write ports, two
read ports, and active-high write enables (WE). All the addresses are held in latches
that are clocked by the RAMCLK input pin. Write port 1 is enabled by WE1. Write port
2 is enabled by WE2. If both write ports write to the same address, write port 1 dominates
and write port 2 is inhibited. The potential conflict is prevented by creating an internal
pin named WE2_CONDITIONED. WE2_CONDITIONED equals WE2 unless
WE2_CONDITIONED is inhibited by write port 1 and write port 2 writing to the same
address.
Example 6-11 Asynchronous 16x8 RAM Cell with Two Write Ports and Two Read Ports
cell (RAM2_16Bx8) {
area : 2500.000;
memory() {
type : ram;
address_width : 4;
word_width : 8;
}
statetable ( ” D RAMCLK ”, ” Q”) {
table : ” L/H H : - : L/H,\
- L : - : N”;
}
bus (READADDR1_IN) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
intrinsic_rise : 3.20; /* tads */

6-30
related_pin : ”RAMCLK”;
}
timing () {
intrinsic_rise : 1.85; /* tadh */
}
}
bus (READADDR2_IN) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
bus (READADDR1_LATCHED) {
capacitance : 1.85;
pin (READADDR1_LATCHED[0]) {
input_map : ” READADDR1_IN[0], RAMCLK”;
timing() {
related_pin : ”READADDR1_IN[0]”;
}
timing () {
related_pin : ”READADDR1_IN[0]”;
}
}

6-31
timing() {
}
timing () {
}
}
timing() {
}
timing () {
}
}
timing() {
}
timing () {
}
}
}
bus (READADDR2_LATCHED) {
capacitance : 1.85;

6-32
timing() {
}
timing () {
}
}
timing() {
}
timing () {
}
}
timing() {
}
timing () {
}
}
timing() {

6-33
}
timing () {
}
}
}
bus (WRITEADDR1_IN) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
related_pin : WE1;
}
timing () {
related_pin : WE1;
}
}
bus (WRITEADDR2_IN) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
related_pin : WE2;
}
timing () {
related_pin : WE2;
}
}
bus (WRITEADDR1_LATCHED) {
capacitance : 1.85;
pin (WRITEADDR1_LATCHED[0]) {

6-34
input_map : ” WRITEADDR1_IN[0], RAMCLK”;
timing() {
}
timing () {
}
}
timing() {
}
timing () {
}
}
timing() {
}
timing () {
}
}
timing() {

6-35
}
timing () {
}
}
}
bus (WRITEADDR2_LATCHED) {
capacitance : 1.85;
timing() {
}
timing () {
}
}
timing() {
}
timing () {
}
}
timing() {

6-36
}
timing () {
}
}
timing() {
}
timing () {
}
}
}
bus (RAMDATA1_IN) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
memory_write() {
address : WRITEADDR1_LATCHED;
enable : WE1;
}
timing () {
related_pin : ”WE1”;
}
timing () {
}
}
bus (RAMDATA2_IN) {
direction : input;

6-37
capacitance : 1.46;
fanout_load : 1.46;
memory_write() {
address : WRITEADDR2_LATCHED;
enable : WE2_CONDITIONED;
}
timing () {
}
timing () {
}
}
pin (WE1) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (WE2) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (WE2_CONDITIONED) {
capacitance : 0.85;
state_function : ”WE2 * (!WE1 + (WRITEADDR1_LATCHED[0] ^
WRITEADDR2_LATCHED[0]) + (WRITEADDR1_LATCHED[1] ^
WRITEADDR2_LATCHED[3]))”;
}
pin (RAMCLK) {
direction : input;
capacitance : 1.13;
clock : true;
}
bus(RAM1_OUT){
direction : output;
memory_read() {
address : READADDR1_LATCHED;
}
timing () {

6-38
related_bus_pins : ”READADDR1_LATCHED”;
}
}
bus(RAM2_OUT){
direction : output;
memory_read() {
address : READADDR2_LATCHED;
}
timing () {
related_bus_pins : ”READADDR2_LATCHED”;
}
}
}
Example 6-12 shows a synchronous 16-word by 2-bit RAM cell with a single port.
Example 6-12 Synchronous 16x2 RAM Cell with Single Port

library ( memory) {
...
type(bus4) {
base_type : array;
data_type : bit;
bit_width : 4;
bit_from : 0;
bit_to : 3;
downto : false;
}
type(bus2) {
base_type : array;
data_type : bit;
bit_width : 2;
bit_from : 0;
bit_to : 1;
downto : false;
}
cell (sync_single) {
area : 5000.000;
memory() {
type : ram;
address_width : 4;
word_width : 2;
}

6-39
bus (ADDR) {
direction : input;
capacitance : 1.46;
timing () {
related_pin : ”CLK”;
}
timing () {
}
}
bus (DI) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
memory_write() {
address : ADDR;
clocked_on : ”EN”;
}
timing () {
related_pin : ”WEN”;
}
timing () {
}
timing () {
related_pin : ”CSN”;
}
timing () {
}
}

6-40
pin (CLK) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (WEN) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (CSN) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (EN) {
capacitance : 1.13;
clock : true;
state_function : ”!CSN * !WEN * CLK”;
}
bus (QO){
direction : output;
memory_read() {
address : ADDR;
}
timing () {
related_bus_pins : ”ADDR”;
}
}
}
}
Example 6-13 shows a synchronous 16-word by 2-bit RAM cell with a dual port.
Example 6-13 Synchronous 16x2 RAM Cell with Dual Port

library ( memory) {
...
type(bus4) {
base_type : array;
data_type : bit;
bit_width : 4;
bit_from : 0;
bit_to : 3;
downto : false;
}

6-41
type(bus2) {
base_type : array;
data_type : bit;
bit_width : 2;
bit_from : 0;
bit_to : 1;
downto : false;
}
...
cell (sync_dual) {
area : 5000.000;
memory() {
type : ram;
address_width : 4;
word_width : 2;
}
bus (RA) {
direction : input;
capacitance : 1.46;
timing () {
}
timing () {
}
}
bus (WA) {
direction : input;
capacitance : 1.46;
timing () {
}
timing () {
}
}

6-42
bus (DI) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
memory_write() {
address : WA;
clocked_on : ”EN1”;
}
timing () {
}
timing () {
}
}
bus (WEN) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (OEN) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (CLK) {
direction : input;
capacitance : 1.13;
clock : true;
}
bus (EN1) {
capacitance : 1.13;
clock : true;
state_function : ”!OEN * !WEN * CLK”;
}
bus (QO){
direction : output;
memory_read() {
address : RA;
}
timing () {

6-43
}
}
}
}
Example 6-14 is a synchronous 16-word by 8-bit RAM cell with one write port and one
read port, a positive edge-triggered clock (CLK), active-high write enable (WE), chip
select (CS), and read enable (RE). Data is clocked in from the RAMDATA_IN bus on the
positive edge of CLK, but only when WE is active. Both CS and RE must be active for
the RAM_OUT bus to drive the output. Otherwise, RAM_OUT is in a three-state mode.
Example 6-14 Synchronous 16x8 RAM Cell with One Write Port and One Read Port
cell (RAM1_16Bx8) {
area : 2500.000;
memory() {
type : ram;
address_width : 4;
word_width : 8;
}
bus (ADDR_IN) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
bus (RAMDATA_IN) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
memory_write() {

6-44
address : ADDR_IN;
clocked_on : ”WECLK”;
}
timing () {
}
timing () {
}
}
pin (WE) {
direction : input;
capacitance : 1.13;
clock : false;
}
pin (CLK) {
direction : input;
capacitance : 1.5;
clock : true;
}
pin (RE) {
direction : input;
capacitance : 1.2;
clock : false;
}
pin (CS) {
direction : input;
capacitance : 1.15;
clock : false;
}
pin (WECLK) {
capacitance : 1.5;
clock : false;
state_function : ”WE * CLK”;
}
bus(RAM_OUT){
direction : output;
memory_read() {
address : ADDR_IN;
}
three_state : ”!CS + !RE”;
timing () {

6-45
related_bus_pins : ”ADDR_IN”;
}
}
}
Example 6-15 shows a 16-word by 8-bit level-sensitive RAM cell with a three-port register
file and three-state output.
Example 6-15 Three-Port Register File 16x8 RAM Cell with Three-State Output
library ( memory) {
...
type(bus4) {
base_type : array;
data_type : bit;
bit_width : 4;
bit_from : 0;
bit_to : 3;
downto : false;
}
type(bus8_1) {
base_type : array;
data_type : bit;
bit_width : 8;
bit_from : 7;
bit_to : 0;
downto : true;
}
cell (reg_file) {
area : 8000.000;
memory() {
type : ram;
address_width : 4;
word_width : 8;
}
bus (RA1) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {

6-46
}
}
bus (RA2) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
bus (WA) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
bus (DI) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
memory_write() {
address : WA;
enable : WCLK;
}
timing () {
intrinsic_rise : 1.50; /* tdis */

6-47
}
timing () {
intrinsic_rise : 0.65; /* tdih */
}
}
pin (WE) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (CLK) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (G1) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (G2) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (WCLK) {
capacitance : 1.13;
clock : true;
state_function : ”WE * CLK”;
}
bus (QO1){
direction : output;
memory_read() {
address : RA1;
}
three_state : ”G1”;
timing () {
related_bus_pins : ”RA1”;
}
}

6-48
bus (QO2){
direction : output;
memory_read() {
address : RA2;
}
three_state : ”G2”;
timing () {
related_bus_pins : ”RA2”;
}
}
}
...
}
Example 6-16 shows an example of a RAM cell whose memory description includes the
column_address and row_address attributes.
Example 6-16 RAM Cell with Address Rows and Columns Description
cell (RAM_10_8) {
area : 2300.000000;
type(bus10) {
base_type : array;
data_type : bit;
bit_width : 10;
bit_from : 0;
bit_to : 9;
}
type(bus8) {
base_type : array;
data_type : bit;
bit_width : 8;
bit_from : 0;
bit_to : 7;
}
memory() {
type : ram;
address_width : 10;
word_width : 8;
column_address : “0:4 5”;
row_address : “6:9”;
}
bus (ram_addr) {
bus_type : “bus10”;
direction : input;
capacitance : 1.46;

6-49
fanout_load : 1.46;
timing () {
related_pin : “WR”;
}
timing () {
}
}
bus (data_in) {
bus_type : “bus8”
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
memory_write() {
address : ram_addr;
enable : WR;
}
timing () {
}
timing () {
}
}
pin (WR) {
direction : input;
capacitance : 1.13;
fanout_load : 1.13;
}
bus(data_out){
bus_type : “bus8”;
direction : output;
memory_read() {
address : ram_addr;
}
timing () {

6-50
related_bus_pins : “ram_addr”;
}
}
} /* end cell */
Example 6-17 shows a ROM cell with output enable, chip select, and clock.
Example 6-17 ROM Cell

library ( memory) {
...
type(bus8) {
base_type : array;
data_type : bit;
bit_width : 8;
bit_from : 0;
bit_to : 7;
downto : false;
}
type(bus4) {
base_type : array;
data_type : bit;
bit_width : 4;
bit_from : 0;
bit_to : 3;
downto : false;
}
...
cell (ROM) {
area : 5000.000;
memory() {
type : rom;
address_width : 4;
word_width : 8;
}
bus (ADDR) {
direction : input;
capacitance : 1.46;
timing () {
}
timing () {
}

6-51
timing () {
related_pin : ”OEN”;
}
timing () {
related_pin : ”OEN”;
}
timing () {
}
timing () {
}
}
pin (CLK) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (OEN) {
direction : input;
capacitance : 1.13;
clock : true;
}
pin (CSN) {
direction : input;
capacitance : 1.13;
clock : true;
}
bus(QO){
direction : output;
memory_read() {
address : ADDR;
}
three_state : ”!CSN * !OEN * CLK”;

6-52
timing () {
related_bus_pins : ”ADDR”;
}
}
}
...
}

6-53
6-54
7
Defining Input and Output Pads 1
Input/output (I/O) pads are the cells at the chip boundaries that allow communication
with the world outside the chip. Pads are fixed resources—a limited number are available
on each die. Their characteristics distinguish them from other cells that make up the
core of an integrated circuit.
For example, one 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. 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.
To capture all these properties in the library, you must understand the following major
tasks:
• Identifying pad cells

• Defining units for pad cells
• Describing input pads
• Describing output and bidirectional pads
• Describing pull-up and pull-down devices
• Modeling wire load for pads
Defining Input and Output Pads

7-1
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.
Identifying Pad Cells
I/O pads are identified by the following attributes, which are explained in this section:
• pad_cell
• auxiliary_pad_cell (for multicell pads only)
• pad_type (for clock pads only)
• is_pad
• driver_type
pad_cell and auxiliary_pad_cell Attributes

In a cell group, these simple attributes identify a cell as a pad cell.
Syntax:
pad_cell : Boolean expression ;
auxiliary_pad_cell : Boolean expression ;
Boolean expression
If a pad_cell or auxiliary_pad_cell attribute is included in a cell definition (with the value

true), at least one pin in the cell must have an is_pad attribute, which is described later
in this section.
If more than one pad cell can be used to build a logical pad, use the auxiliary_pad_cell
attribute in the cell definitions of all the component pad cells.
Example:
pad_cell : true ;
auxiliary_pad_cell : true ;
If the pad_cell or auxiliary_pad_cell attribute is omitted, the cell is treated as an internal

core cell rather than as a pad cell.

7-2
Note: A cell with an auxiliary_pad_cell attribute can also be used as a core cell;
a pull-up or pull-down cell is an example of such a cell.
pad_type Attribute
To designate a clock pad on a cell that is tagged with a pad_cell or an auxiliary_pad_cell
attribute, use the pad_type attribute statement.
Syntax:
pad_type : value ;
value
Must be clock, to indicate a clock pad.
Example:
pad_type : clock ;
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;

7-3
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.
• 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.

7-4
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 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 7-1 lists the driver types, their signal mappings, and the applicable pin types.
Table 7-1 Pin Driver Types

Driver Type Signal Mapping Pin
pull_up 01Z->01H in, out
pull_down 01Z->01L in, out
open_drain 01Z->0ZZ out
open_source 01Z->Z1Z out
bus_hold 01Z->01Z inout
resistive 01Z->LHZ out
resistive_0 01Z->0HZ out
resistive_1 01Z->L1Z out
In Table 7-1, the pull_up, pull_down, and bus_hold driver types define a resolution
scheme. The remaining driver types define transformations.

7-5
Example 7-1 describes an output pin with a pull-up resistor and the bidirectional pin on
a bus_hold cell.
Example 7-1 Pin Driver Type Specifications

cell (bus) {
pin(Y) {
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
Units for the physical quantities of time, capacitance, resistance, voltage, current, and
power are supplied with these attributes:
• capacitive_load_unit
• pulling_resistance_unit
• voltage_unit
• current_unit
All these attributes are defined at the library group level, as described in Chapter 2,
“Library Groups.”
Capacitance
The capacitive_load_unit defines the capacitance associated with a standard load. If
you already represent capacitance values in terms of picofarads or femtofarads, define
your base unit. If you represent capacitances 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 );

7-6
Resistance
In timing groups, you can define a rise_resistance and a fall_resistance value. These
values are used expressly in timing calculations and are normalized to the defined default
capacitive loading unit. The values indicate how many time units it takes to drive a
capacitive load of one capacitance unit to either 1 or 0.
You must supply a pulling_resistance attribute for pull-up and pull-down resistors on
pads, and identify the unit to use with the pulling_resistance_unit attribute.
Example:
pulling_resistance_unit : ”1kohm”;
See the section on “Describing Pull-up and Pull-down Devices” later in this chapter for
more information.
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”;
See the section on “Describing Input Pads” for an example of the input_voltage group.
See the section on “Describing Output and Bidirectional Pads” for an example of the
output_voltage group.
Current
You can define the drive_current that can be generated by an output pad, and the
pulling_current for a pull-up or pull-down device under nominal voltage conditions. Define
all current values with the library-level current_unit attribute.
Example:
current_unit : ”1uA”;

7-7
For more information on the drive_current attribute, see the section on “Describing
Output and Bidirectional Pads.” For more information on the pulling_current attribute,
see the section on “Describing Pull-up and Pull-down Devices.”
Describing Input Pads
To represent input pads in your technology library, you must describe the input voltage
characteristics using the input_voltage group attribute at the library level. At the pin group
level, indicate whether hysteresis applies. The pin group must also contain the following
statement:
direction : input;
At the end of this chapter are input pad examples that describe a standard input buffer,
an input buffer with hysteresis, and an input clock buffer.
input_voltage Group
You can use the input_voltage group at the library level to define a set of input voltage
levels at which an input pad is driven. You can then assign this set of voltage ranges to
the input pin of a pad cell.
Syntax:
library (name) {
input_voltage (name) {
vil : float | expression ;
vih : float | expression ;
vimin : float | expression ;
vimax : float | expression ;
}
vil
The maximum input voltage for which the input to the core is guaranteed to be a
logic 0.
vih
The minimum input voltage for which the input to the core is guaranteed to be a
logic 1.
vimin
The minimum acceptable input voltage.

7-8
vimax
The maximum acceptable input voltage.
The value of each attribute is expressed as a floating-point number, an expression, or

both. Table 7-2 lists predefined variables that can be used in an expression.
Table 7-2 input_voltage Voltage-Level Variables

CMOS/BiCMOS Default Value
Variable
VDD 5V
VSS 0V
VCC 5V
The default values represent nominal operating conditions. These values fluctuate with
the voltage range defined in the operating_conditions group. All voltage values are in
the units you define with the library group voltage_unit attribute.
Example 7-2 shows a collection of input voltage groups.
Example 7-2 Input Voltage Groups

...
input_voltage(CMOS) {
vil : 0.3 * VDD ;
vih : 0.7 * VDD ;
vimin : -0.5 ;
vimax : VDD + 0.5 ;
}
input_voltage(TTL_5V) {
vil : 0.8 ;
vih : 2.0 ;
vimin : -0.5 ;
vimax : VDD + 0.5 ;
}
After you define an input_voltage group, you can use its name with the input_voltage
simple attribute in a pin group of a pad cell.
For example, you can define an input_voltage group called TTL with a set of high and
low thresholds and minimum and maximum voltage levels, and use TTL in the pin group
to assign those ranges to the pad cell pin, as shown here.
Example:
input_voltage : TTL ;

7-9
hysteresis Attribute
This attribute is used on pads that are expected to have a long transition time or may
be driven by a noisy line. A pad with this attribute has wider threshold tolerances, so
voltage spikes on the input do not propagate to the core cells.
You can indicate an input pad with hysteresis using the hysteresis attribute. The default
for this attribute is false. When the value is true, the vil and vol voltage ratings are actual
transition points.
Example:
hysteresis : true;
Pads with hysteresis sometimes have different derating factors from cells in the core.
As a result, you need to describe the timing of cells that have hysteresis with a scaled_cell
group, which is described in Chapter 4, “Defining Core Cells.” This construct provides
derating capabilities and minimum, typical, or maximum timing for cells.
Describing Output and Bidirectional Pads
To represent output pads in your technology library, you must describe the output voltage
characteristics using the output_voltage group attribute at the library level. (Bidirectional
pads must also have an input_voltage group attribute at the library level, as shown in
the previous section on “Describing Input Pads.”) In the pin group, indicate the drive-
current rating of output and bidirectional pads. The pin group also includes information
about the slew rate of the pad, indicated by the slew_control attribute. Additionally, the
pin group must contain one of the following statements:
direction : output;
for output pads or
direction : inout;
for bidirectional pads.
A description of a standard output buffer and a bidirectional pad are included in the
examples at the end of this chapter.

7-10
output_voltage Group
You can use the output_voltage group at the library level to define a set of output voltage
ranges for your pads. You can then use the output_voltage attribute at the pin level to
assign this set of voltage ranges to the output pin of a pad cell.
Syntax:
library (name) {
output_voltage (name) {
vol : float | expression ;
voh : float | expression ;
vomin : float | expression ;
vomax : float | expression ;
}
}
vol
The maximum output voltage generated to represent a logic 0.
voh
The minimum output voltage generated to represent a logic 1.
vomin
The minimum output voltage the pad can generate.
vomax
The maximum output voltage the pad can generate.
The values for vol, voh, vomin, and vomax are expressed as a floating-point number or
an expression. An expression allows you to define voltage levels as a percentage of
VSS or VDD.
Table 7-3 lists the predefined variables you can use in an output_voltage expression
attribute. Separate variables are defined for CMOS and BiCMOS.
Table 7-3 output_voltage Voltage-Level Variables

CMOS/BiCMOS Default Value
Variable
VDD 5V
VSS 0V
VCC 5V
The default values represent nominal operating conditions. These values fluctuate with
the voltage range defined in the operating_conditions groups. All voltage values are in
the units you define with the library group voltage_unit attribute.

7-11
Example 7-3 shows an example of an output_voltage group.
Example 7-3 output_voltage Group

output_voltage (GENERAL) {
vol : 0.4 ;
voh : 2.4 ;
vomin : -0.3 ;
vomax : VDD + 0.3 ;
}
}
After you define an output_voltage group, you can use its name with the output_voltage
simple attribute in a pin group of a pad cell. In the pin group, assign those ranges to the
pad cell pin with the output_voltage attribute:
pin(Z) {
direction : output;
is_pad : true;
output_voltage : GENERAL ;
}
drive_current Attribute
Most output and bidirectional pad cells are characterized with an approximate drive-
current capability. You select the pad with the lowest drive current that meets your
alternating currents timing constraints.
Syntax:
drive_current : float ;
float
A floating-point number that represents the drive current the pad supplies in the
units defined with the current_unit library-level attribute.
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. Output and inout pads are required
to have the drive_current attribute assigned. The value is in units consistent with the
current_unit you defined.
Example:
pin(PAD ) {
direction : output;
is_pad : true;
drive_current : 1.0;
}

7-12
Note: Each library cell can have only one drive_current attribute. You may need
to create a different pad cell for each drive-current possibility in your library.
driver_type Attribute for Bidirectional Pads

Bidirectional pads often require one driver type for the output behavior and another driver
type associated with the input behavior. In this case, you can define multiple driver types
in one driver_type attribute, as shown here:
driver_type : ”open_drain pull_up” ;
Slew-Rate Control
Slew-rate control limits peak noise by smoothing out fast output transitions and thus
decreasing the possibility of a momentary disruption in the power or ground planes.
There are two levels of slew-rate control: the slew_control attribute is for coarse tuning
and the threshold attributes are for fine tuning.
slew_control Attribute
The slew_control attribute provides increasing levels of slew-rate control to slow down
the transition rate. This attribute accepts one of four possible enumerations: none, low,
medium, and high; the default is none. Using the slew_control attribute is the coarsest
way to measure the level of slew-rate control associated with an output pad. The more
slew-rate control you apply, the slower the output transitions are.
Threshold Attributes
You can define slew-rate control in terms of threshold attributes that define a two-piece
approximation of the current vs. time characteristics of the pad (dI/dT).
Syntax:
threshold_attribute : value ;
value
A floating-point number in the units specified by current_unit for current-related
attributes and time_unit for time-related attributes. The eight threshold attributes are
rise_current_slope_before_threshold
This value represents a linear approximation of the change in current with respect
to time from the beginning of the rising transition to the threshold point.

7-13
rise_current_slope_after_threshold
to time from the point at which the rising transition reaches the threshold to the
end of the transition.
fall_current_slope_before_threshold
to time from the beginning of the falling transition to the threshold point.
fall_current_slope_after_threshold
to time from the point at which the falling transition reaches the threshold to the
end of the transition.
rise_time_before_threshold
This value gives the time interval from the beginning of the rising transition to
the point at which the threshold is reached.
rise_time_after_threshold
This value gives the time interval from the threshold point of the rising transition
to the end of the transition.
fall_time_before_threshold
This value gives the time interval from the beginning of the falling transition to
the point at which the threshold is reached.
fall_time_after_threshold
This value gives the time interval from the threshold point of the falling transition
to the end of the transition.
The rise_current_slope_ attributes are shown graphically in Figure 7-1. The A value is
a positive number representing a linear approximation of the change of current as a
function of time from the beginning of the rising transition to the threshold point. The B
value is a negative number representing a linear approximation of the current change
over time from the point at which the rising transition reaches the threshold to the end
of the transition.

7-14
Figure 7-1 Slew-Rate Attributes—Rising Transitions
Current
Threshold
A B
Positive dI/dT Negative dI/dT
Time
A = rise_current_slope_before_threshold
B = rise_current_slope_after_threshold
For falling transitions, the graph is reversed: A is negative and B is positive, as shown
in Figure 7-2.

7-15
Figure 7-2 Slew-Rate Attributes—Falling Transitions
Current
Threshold
A B
Negative dI/dT Positive dI/dT
Time
A = rise_current_slope_before_threshold
B = rise_current_slope_after_threshold
Example 7-4 shows the slew-rate control attributes on an output pad pin.
Example 7-4 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;
...
}

7-16
Describing Pull-Up and Pull-Down Devices
To indicate a pad as a pull-up or pull-down device, use the driver_type attribute in the
pin group.
Example:
See the earlier section “Identifying Pad Cells” for the complete syntax of the driver_type
attribute.
In addition, these attributes let you define the resistance or current-drawing capability
of a pull-up or pull-down device on a pin:
• pulling_current
• pulling_resistance
Syntax:
pulling_current : current value ;
pulling_resistance : resistance value ;
current value
The current-drawing capability of a pull-up or pull-down device on a pin. Assigning
a negative value to pulling_current produces a current flow in the opposite or
negative direction.
Note: If you characterize your pull-up or pull-down devices in terms of the current
drawn during nominal operating conditions, use pulling_current instead of
pulling_resistance.
resistance value
The resistive strength of the pull-up or pull-down device.
Example:
pin(Y) {
pulling_resistance : 1000 ;
...
}

7-17
Modeling Wire Load for Pads
You can define a number of wire_load groups that contain information used to estimate
interconnect wiring delays. Estimated wire loads for pads can be significantly different
from those of core cells.
The wire_load model for the net connecting an I/O pad to the core needs to be handled
separately because it is usually longer than most other nets in the circuit. Some I/O pad
nets extend completely across the chip.
You can define a wire_load group to use for wire load estimation on the pad ring. For
example, you could name the group Pad_WireLoad. You can add a level of hierarchy
and place the pads in the top level with all the core circuitry included at a lower level.
You should define a different model for each core level of hierarchy.
For more information on defining a wire_load group, see Chapter 3, “Defining

Environments.”
Examples of Pad Cells
This section includes examples of input, clock, output, and bidirectional pad cells.
Input Pad and Clock Pad Examples

This section includes definitions for a standard input buffer, an input buffer with
hysteresis, and an input clock buffer.
The first input pad example includes the attribute define_cell_area, which defines the
area resources a cell uses, such as the number of pad slots.
Syntax:
define_cell_area (area_name, resource_type) ;
area_name
A user-defined name of a resource type. You can associate more than one
area_name with each of the predefined resource types.

7-18
The resource_type can be
• pad_slots (a pad slot)

• pad_driver_sites (a pad driver site) Use this resource type when you do not need
to discriminate between input and output pad driver sites.
• pad_input_driver_sites (an input pad driver site) Use with pad_output_driver_sites.
• pad_output_driver_sites (an output pad driver site) Use with
pad_input_driver_sites.
You can define as many cell area types as you need, as shown here.
Example:
define_cell_area (bond_pads, pad_slots) ;
define_cell_area (pad_drivers, pad_driver_sites) ;
After you define the cell area types, use the area attribute in a cell group to identify how
many of each resource type the cell requires, as shown here.
Example:
cell(IV_PAD) {
area : 1 ;
...
}
Example 7-5 Input Buffer

library (example1) {
...
time_unit : ”1ns”;
...
define_cell_area (bond_pads, pad_slots);
define_cell_area (driver_sites, pad_driver_sites);
...
vil : 1.5;
vih : 3.5;
vimin : -0.3;
vimax : VDD + 0.3;
}
...
/***** INPUT PAD*****/
cell(INBUF) {
area : 0.000000;

7-19
pad_cell : true;
bond_pads : 1;
driver_sites : 1;
pin(PAD ) {
direction : input;
is_pad : true;
input_voltage : CMOS;
fanout_load : 0.000000;
}
pin(Y ) {
direction : output;
function : ”PAD”;
timing() {
intrinsic_fall : 2.952000
fall_resistance : 0.500000
rise_resistance : 0.500000
related_pin :”PAD”;
}
}
}
Example 7-6 Input Buffer with Hysteresis

...
...
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;
}

7-20
pin(Y ) {
direction : output;
timing() {
}
}
}
Example 7-7 Input Clock Buffer

...
...
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;
}
pin(Y ) {
direction : output;
max_fanout : 2000.000000;
timing() {
}

7-21
}
}
}
Output Pad Examples

The output pad definition in Example 7-8 represents a standard output buffer.
Example 7-8 Output Buffer

...
...
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;
}
pin(PAD ) {
direction : output;
is_pad : true;
function : ”D”;
timing() {
related_pin :”D”;
}
}
}

7-22
Bidirectional Pad
Example 7-9 shows a bidirectional pad cell with three-state enable.
Example 7-9 Bidirectional Pad

...
...
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;
}
pin(Y ) {
direction : output;
driver_type : ”open_source pull_up”;
pulling_resistance : 10000;
timing() {
related_pin :”PAD “;
}
}
pin(PAD ) {
direction : inout;
is_pad : true;
function : ”D”;
three_state : ”E”;

7-23
timing() {
related_pin :”E”;
}
timing() {
related_pin :”D”;
}
}
}

7-24
8
Defining Test Cells 1
A test cell contains information that supports a full-scan or partial-scan test methodology.
A library must contain scannable versions of non-scan flip-flops and latches if a scan
test methodology is employed.
Scannable cells in a technology library include test-specific details that can be used to
determine the types of unscannable cells they replace for a given scan methodology. To
describe these types of cells, you must understand the following concepts:
• Describing a scan cell

• Describing a multibit scan cell
Describing a Scan Cell
To describe a scan cell, add the test_cell group to that scan 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 group declaration, or
statetable format, and pin function attributes.Refer to Chapter 5, “Defining Sequential
Cells,” for details on ff, ff_bank, latch, or latch_bank declarations and their attributes, as
well as statetable format.
Defining Test Cells

8-1
Note: Refer to Chapter 5, “Defining Sequential Cells,” for details on ff, ff_bank,
latch, or latch_bank declarations and their attributes, as well as statetable
format.
test_cell Group
The test_cell group defines only the nontest-mode function of a scan cell. Figure 8-1
illustrates the relationship between a test_cell group and the scan cell in which it is
defined.
Figure 8-1 Scan Cell with test_cell Group
Scan Cell
D D test_cell Q Q
SI
SQ
SE
CLK CLK QN QN
Follow these rules when defining a scan cell such as the one in Figure 8-1:
• The 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:
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.
Defining Test Cells

8-2
Pin Groups in the test_cell Group
Both test pins and nontest pins appear in pin groups within a test_cell group. All pin
groups in a test_cell group have the following characteristics:
• Each pin defined in the cell group must have a corresponding pin with the same
name defined at the test_cell group level.
• 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 declaration, or
have a signal_type attribute assigned to them.
• An output pin must have a function attribute, a signal_type attribute, or both.
For a full description of the direction and function attributes, see Chapter 4, “Defining
Core Cells.” Chapter 5, “Defining Sequential Cells,” contains information on ff, ff_bank,
latch, and latch_bank groups.
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 ;
signal_type Attribute
Defined in a test_cell group, this attribute identifies the type of test pin.
Syntax:
signal_type : value ;
Defining Test Cells

8-3
The signal_type attribute can have any of the following values:
test_scan_in
Identifies the scan-in pin of a scan cell. The scanned value is the same as the value
present on the scan-in pin. All scan cells must have a pin with either the test_scan_in
or the test_scan_in_inverted attribute.
test_scan_in_inverted
Identifies the scan-in pin of a scan cell as having inverted polarity. The scanned
value is the inverse of the value on the scan-in pin.
For multiplexed flip-flop scan cells, the polarity of the scan-in pin is inferred from the
next_state attribute in the latch or ff declaration of the cell itself. For other types of
scan cells, clocked-scan, level-sensitive scan design (LSSD), and multiplexed flip-
flop latches, you use statetable format, so there is no ff or latch declaration of the
entire scan cell. For these cases, use the test_scan_in_inverted attribute for the
scan-in pin in the latch or ff declarations in the test_cell group.
test_scan_out
Identifies the scan-out pin of a scan cell. The value on the scan-out pin is the same
as the scanned value. All scan cells must have a pin with either a test_scan_out or
a test_scan_out_inverted attribute.
The scan-out pin corresponds to the output of the slave latch in the LSSD
methodologies.
test_scan_out_inverted
Identifies the scan-out of a test cell as having inverted polarity. The value on this
pin is the inverse of the scanned value.
test_scan_enable
Identifies the pin of a scan cell that, when high, indicates that the cell is configured
in scan-shift mode. In this mode, the clock transfers data from the scan-in input to
the scan-out input.
test_scan_enable_inverted
Identifies the pin of a scan cell that, when low, indicates that the cell is configured
in scan-shift mode. In this mode, the clock transfers data from the scan-in input to
the scan-out input.
test_scan_clock
Identifies the test_scan_clock (an edge-sensitive signal) for the clocked-scan
methodology. The active edge transfers data from the scan-in pin to the scan-out
pin of a cell. The sense of this clock is determined by the sense of the associated
timing arcs.
Defining Test Cells

8-4
test_scan_clock_a
Identifies the a clock pin in a cell that supports a single-latch LSSD, double-latch
LSSD, clocked LSSD, or auxiliary clock LSSD methodology. When the a clock is at
the active level, the master latch of the scan cell can accept scan-in data. The sense
of this clock is determined by the sense of the associated timing arcs. Example 8-2
shows a default clocked LSSD scan cell with a and b clocks.
test_scan_clock_b
Identifies the b clock pin in a cell that supports the single-latch LSSD, clocked LSSD,
or auxiliary clock LSSD methodologies. When the b clock is at the active level, the
slave latch of the scan cell can accept the value of the master latch. The sense of
this clock is determined by the sense of the associated timing arcs.
test_clock
Identifies an edge-sensitive clock pin used to strobe the scan-in data in test mode
with the auxiliary clock LSSD methodology.
If you use an input pin in both test and nontest modes (such as the clock input in the
multiplexed flip-flop methodology), do not include a signal_type statement for that pin in
the test_cell pin definition.
If you use an input pin of a scan cell only in nontest mode, and that pin does not exist
on the equivalent non-scan cell, you must include a signal_type statement for that pin
in the test_cell pin definition.
If you use an output pin in nontest mode, it needs a function statement. The signal_type
statement identifies an output pin as a scan-out pin. In a test_cell group, the pin group
for an output pin can contain a function statement, a signal_type attribute, or both.
Note: You do not have to define a function or signal_type attribute in the pin group
if the pin is defined in a previous test_cell group for the same cell.
Example:
signal_type : test_scan_in ;
Defining Test Cells

8-5
Example 8-2 and Example 8-3 show names of pins that are referred to in the list of
signal_type values.
Figure 8-2 Default Clocked LSSD Scan Cell
d 1D q/scan_out
(test_scan_out)
clk C1
1D 2D
qb/scan_out_inverted
C1 C2 (test_scan_out_inverted)
scan_in 2D
(test_scan_in)
a C2
(test_scan_clock_a)
b
(test_scan_clock_b)
Example 8-3 shows a clocked-scan cell.
Figure 8-3 Default Clocked Scan Cell
d 1D q/scan_out
(test_scan_out)
clk C1
scan_in 2D
(test_scan_in) qb/scan_out_inverted
sc C2 (test_scan_out_inverted)
(test_scan_clock)
Example 8-1 shows a library model for a multiplexed D flip-flop scan cell with multiple
test_cell groups.
Example 8-1 Multiplexed D Flip-Flop Scan Cell

cell(SDFF1) {
area : 9;
pin(D) {
direction : input;
capacitance : 1;
timing() {
Defining Test Cells

8-6
}
timing() {
}
}
pin(CLK) {
direction : input;
capacitance : 1;
}
pin(SI) {
direction : input;
capacitance : 1;
prefer_tied : ”0”;
timing() {
}
timing() {
}
}
pin(SE) {
direction : input;
capacitance : 1;
timing() {
}
timing() {
}
}
ff(”IQ”,”IQN”) {
next_state : ”(D & !SE) | (SI & SE)”;
clocked_on : ”CLK”;
}
Defining Test Cells

8-7
pin(Q) {
direction : output;
function : ”IQ”
timing() {
}
}
pin(QN) {
direction : output;
function : ”IQN”
timing() {
}
}
/* first test_cell group defines nontest
behavior with both Q and QN */
test_cell() {
pin(D,CLK) {
direction : input;
}
pin(SI) {
direction : input;
}
pin(SE) {
direction : input;
signal_type : test_scan_enable ;
}
ff (”IQ”,”IQN”) {
}
pin(Q) {
direction : output;
signal_type : test_scan_out ;
}
pin(QN) {
direction : output;
signal_type : test_scan_out_inverted ;
}
}
Defining Test Cells

8-8
/* second test_cell group defines nontest
behavior with only Q */
test_cell() {
pin(D,CLK) {
direction : input;
}
pin(SI) {
direction : input;
}
pin(SE) {
direction : input;
}
}
pin(Q) {
direction : output;
}
pin(QN) {
direction : output;
/* notice no function attribute for QN pin */
}
}
}
Describing a Multibit Scan Cell
You can model a multibit scan cell using the ff_bank or latch_bank group in the test_cell
description. One type of multibit scan cell is a 4-bit flip-flop. Figure 8-4 illustrates a 2-bit
piece of a 4-bit D flip-flop with scan and enable.
Defining Test Cells

8-9
Figure 8-4 Multibit Scan Cell
QC0 Q0 QC1 Q1
QN Q QN Q
CP CP
T
EN
TE MUX TE
MUX
SM
1 0 1 0
TI D TI D
FSX2
D0 D1
SI
Figure 8-5 shows the test_cell group (the nontest mode) of the cell in Figure 8-4.
Figure 8-5 test_cell Group of Multibit Scan Cell
QC0 Q0 QC1 Q1
QN Q QN Q
CP CP
EN
FSX2
T
D0 D1
Defining Test Cells

8-10
To create a multibit scan cell, use statetable format in the full cell description, as shown
in Example 8-2.
Example 8-2 Statetable in Full-Cell Description

cell (FSX2) {
...
bundle (D) {
member (D0, D1);
...
}
bundle (Q) {
member (Q0, Q1);
...
pin (Q0) {
input_map : “D0 T SI SM”;
...
}
pin (Q1) {
input_map : “D1 T Q0 SM”;
...
}
}
pin (SI) {
...
}
pin (SM) {
...
}
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 “
}
}
In Example 8-2, statetable format describes the behavior of a single slice of the cell.
The input_map statements on pin Q0 and pin Q1 indicate the interconnection of the
different slices of the cell—for example, the fact that Q of bit 0 goes to TI of bit 1.
Defining Test Cells

8-11
Example 8-3 shows the test_cell description for multibit pins, using the ff_bank and
bundle group attributes.
Example 8-3 test_cell Description for Multibit Scan Cells

cell (FSX2) {
...
bundle (D) {
member (D0, D1);
...
}
bundle (Q) {
member (Q0, Q1);
...
}
pin(SI){
...
}
pin(SM){
...
}
pin(T){
...
}
pin(EN) {
...
}
statetable (...) {
...
}
test_cell {
ff_bank(IQ,IQN,2){
next_state : D;
clocked_on: “T & EN”;
}
bundle (D) {
member (D0, D1);
...
}
bundle (Q) {
member (Q0, Q1);
function : IQ;
}
bundle(QC) {
member (QC0, QC1);
function : IQN;
}
Defining Test Cells

8-12
pin (SI) {
...
}
pin (SM) {
...
}
pin (T) {
...
}
}
}
For a complete description of multibit scan cells, see Example 8-5 later in this chapter.
Scan Cell Modeling Examples
This section contains modeling examples for these test cells:
• Simple multiplexed D flip-flop

• Multibit cells with multiplexed D flip-flop and Eenable
• Level-sensitive scan device (LSSD) element
• Clocked scan
• Scan D flip-flop with auxiliary clock
Each example contains a complete cell description.
Simple Multiplexed D Flip-Flop

Example 8-4 shows how to model a simple multiplexed D flip-flop test cell.
Example 8-4 Simple Multiplexed D Flip-Flop Scan Cell

cell(SDFF1) {
area : 9;
pin(D) {
direction : input;
capacitance : 1;
timing() {...}
}
Defining Test Cells

8-13
pin(CP) {
direction : input;
capacitance : 1;
timing() {...}
}
pin(TI) {
direction : input;
capacitance : 1;
timing() {...}
}
pin(TE) {
direction : input;
capacitance : 2;
timing() {...}
}
ff(IQ,IQN) {
/* model full behavior (if possible): */
next_state : ”D TE’ + TI TE ”;
}
pin(Q) {
direction : output;
timing() {...}
}
pin(QN) {
direction : output;
timing() {...}
}
test_cell() {
pin(D) {
direction : input
}
pin(CP){
direction : input
}
pin(TI) {
direction : input;
}
pin(TE) {
direction : input;
}
ff(IQ,IQN) {
/* just model non-test operation behavior */
}
pin(Q) {
direction : output;
Defining Test Cells

8-14
}
pin(QN) {
direction : output;
}
}
}
Multibit Cells with Multiplexed D Flip-Flop and Enable

Example 8-5 contains complete descriptions of multibit scan cells.
Example 8-5 Multibit Scan Cells with Multiplexed D Flip-Flop and Enable
library(banktest) {
default_input_pin_cap : 1.0;
default_output_pin_cap : 0.0;
default_slope_fall : 0.0;
default_slope_rise : 0.0;
default_fanout_load : 1.0;
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() {
Defining Test Cells

8-15
related_pin : ”CP”;
}
timing() {
}
}
pin(CP) {
direction : input;
capacitance : 1;
}
pin(TI) {
direction : input;
capacitance : 1;
timing() {
}
timing() {
}
}
pin(TE) {
direction : input;
capacitance : 2;
timing() {
}
timing() {
}
}
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” ;
}
Defining Test Cells

8-16
bus(Q) {
bus_type : bus4;
direction : output;
timing() {
}
pin(Q[0]) {
input_map : ”D[0] CP TI TE”;
}
pin(Q[1]) {
input_map : ”D[1] CP Q[0] TE”;
}
pin(Q[2]) {
}
pin(Q[3]) {
}
}
bus(QN) {
bus_type : bus4;
direction : output;
timing() {
}
pin(QN[0]) {
input_map : ”D[0] CP TI TE”;
}
pin(QN[1]) {
}
pin(QN[2]) {
}
pin(QN[3]) {
}
}
Defining Test Cells

8-17
test_cell() {
bus (D) {
bus_type : bus4;
direction : input;
}
pin(CP) {
direction : input;
}
pin(TI) {
direction : input;
}
pin(TE) {
direction : input;
}
ff_bank(”IQ”,”IQN”, 4) {
}
bus(Q) {
bus_type : bus4;
direction : output;
}
bus(QN) {
bus_type : bus4;
direction : output;
}
}
}
cell(SCAN2) {
area : 18;
bundle(D) {
members(D0, D1);
direction : input;
capacitance : 1;
timing() {
related_pin : ”T”;
}
timing() {
}
}
Defining Test Cells

8-18
pin(T) {
direction : input;
capacitance : 1;
}
pin(EN) {
direction : input;
capacitance : 2;
timing() {
}
timing() {
}
}
pin(SI) {
direction : input;
capacitance : 1;
timing() {
}
timing() {
}
}
pin(SM) {
direction : input;
capacitance : 2;
timing() {
}
timing() {
}
}
Defining Test Cells

8-19
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;
timing() {
}
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;
timing() {
}
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;
}
Defining Test Cells

8-20
pin(T) {
direction : input;
}
pin(EN) {
direction : input;
}
pin(SI) {
direction : input;
}
pin(SM) {
direction : input;
}
ff_bank(”IQ”,”IQN”, 2) {
clocked_on : ”T EN”;
}
bundle(Q) {
members(Q0, Q1);
direction : output;
}
bundle(QN) {
members(Q0N, Q1N);
direction : output;
}
}
}
LSSD Scan Cell

Example 8-6 shows how to model a level-sensitive scan device (LSSD) element. For
latch-based designs, this form of scan cell has two test_cell groups so that it can be
used in either single-latch or double-latch mode.
Example 8-6 LSSD Scan Cell

cell(LSSD) {
area : 12;
pin(D) {
direction : input;
capacitance : 1;
timing() {
Defining Test Cells

8-21
related_pin : ”MCLK”;
}
timing() {
timing_type : hold_falling;
}
}
pin(SI) {
direction : input;
capacitance : 1;
timing() {
related_pin : ”ACLK”;
}
timing() {
}
}
pin(MCLK,ACLK,SCLK) {
direction : input;
capacitance : 1;
}
pin(Q1) {
direction : output;
timing() {
}
timing() {
}
timing() {
Defining Test Cells

8-22
}
timing() {
related_pin : ”SI”;
}
}
pin(Q1N) {
direction : output;
state_function : ”Q1’”;
timing() {
}
timing() {
}
timing() {
}
timing() {
related_pin : ”SI”;
}
}
pin(Q2) {
direction : output;
timing() {
Defining Test Cells

8-23
related_pin : ”SCLK”;
}
}
pin(Q2N) {
direction : output;
state_function : ”Q2’”;
timing() {
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;
}
pin(ACLK) {
direction : input;
signal_type : test_scan_clock_a ;
}
pin(SCLK) {
direction : input;
signal_type : test_scan_clock_b ;
}
data_in : ”D”;
enable : ”MCLK”;
}
pin(Q1) {
direction : output;
}
pin(Q1N) {
direction : output;
}
Defining Test Cells

8-24
pin(Q2) {
direction : output;
}
pin(Q2N) {
direction : output;
}
}
test_cell() { /* for MSFF1 */
pin(D,MCLK,SCLK) {
direction : input;
}
pin(SI) {
direction : input;
}
pin(ACLK) {
direction : input;
}
clocked_on : ”MCLK”;
clocked_on_also : ”SCLK”;
}
pin(Q1,Q1N) {
direction : output;
}
pin(Q2) {
direction : output;
}
pin(Q2N) {
direction : output;
}
}
}
Defining Test Cells

8-25
Clocked-Scan Test Cell
Example 8-7 shows how to model a level-sensitive latch with separate scan clocking.
This example shows the scan cell used in clocked-scan implementation.
Example 8-7 Clocked-Scan Test Cell

cell(SC_DLATCH) {
area : 12;
pin(D) {
direction : input;
capacitance : 1;
timing() {
}
timing() {
}
}
pin(SI) {
direction : input;
capacitance : 1;
timing() {
related_pin : ”ScanClock”;
}
timing() {
}
}
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”;
}
Defining Test Cells

8-26
pin(Q) {
direction : output;
timing() {
}
timing() {
}
timing() {
}
}
pin(QN) {
direction : output;
timing() {
}
timing() {
}
timing() {
Defining Test Cells

8-27
timing() {
}
}
test_cell() {
pin(D,G) {
direction : input;
}
pin(SI) {
direction : input;
}
pin(ScanClock) {
direction : input;
signal_type : test_scan_clock ;
}
pin(SE) {
direction : input;
}
data_in : ”D”;
enable : ”G”;
}
pin(Q) {
direction : output;
}
pin(QN) {
direction : output;
}
}
}
Defining Test Cells

8-28
Scan Flip-Flop with Auxiliary Clock
Example 8-8 shows how to model a scan D flip-flop with one input and an auxiliary clock.
Example 8-8 Scan D Flip-Flop with Auxiliary Clock

cell(AUX_DFF1) {
area : 12;
pin(D) {
direction : input;
capacitance : 1;
timing() {
related_pin : ”CK”;
}
timing() {
related_pin : ”CK”;
}
timing() {
related_pin : ”IH”;
}
timing() {
related_pin : ”IH”;
}
}
pin(CK,IH,A,B) {
direction : input;
capacitance : 1;
}
pin(SI) {
direction : input;
capacitance : 1;
timing() {
Defining Test Cells

8-29
related_pin : ”A”;
}
timing() {
}
}
pin(Q) {
direction : output;
timing() {
related_pin : ”CK IH”;
}
timing() {
related_pin : ”B”;
}
}
pin(QN) {
direction : output;
timing() {
related_pin : ”CK IH”;
}
timing() {
}
}
Defining Test Cells

8-30
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;
}
pin(A){
direction : input;
}
pin(B){
direction : input;
signal_type : test_scan_clock_b ;
}
ff (”IQ”,”IQN”){
clocked_on : ”CK”;
}
pin(Q){
direction : output;
Defining Test Cells

8-31
pin(QB){
direction : output;
}
}
}
Defining Test Cells

8-32
9
Modeling Power 1
This chapter provides an overview of modeling static and dynamic power for CMOS
technology.
To model CMOS static and dynamic power, you must know about the following topics:
• Power dissipation components

• Modeling leakage power
• Modeling internal power
• Modeling libraries with multiple power supplies
Modeling Power
9-1
Power Dissipation Components
The three components of power dissipation are
• Leakage power
Leakage power is dissipated by a gate when it is inactive (or static). The largest
percentage of leakage power results from source-to-drain sub-threshold leakage.
This leakage is caused by reduced threshold voltages that prevent the gate from
turning off completely. Leakage power also results when current leaks between the
diffusion layers and substrate.
• Internal power
During switching, a circuit dissipates internal power by the charging or discharging
of any existing capacitances internal to the cell. 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 definition of internal power
includes power dissipated by a momentary short circuit between the P-type and N-
type transistors of a gate, called short-circuit power.
Note: 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.
• 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. Because such charging and discharging is the
result of the logic transitions at the output of the cell, as logic transitions increase,
switching power increases. 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.
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 modeling purposes, switching power is considered to be a component of internal

power, and is modeled as such.
Modeling Power
9-2
Figure 9-1 illustrates components of power dissipation and 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.
Figure 9-1 Components of Power Dissipation
Vdd
P
Rising signal Falling signal
at IN at OUT
Ilk
IN OUT
Isc
Voltage Voltage
Isw
Time Time
N
Cload
Ilk
Ilk Leakage current
lsc Short-circuit current
GND
lsw Switching current
Cload Capacitance power
Figure 9-1 shows how the capacitance (Cload) is charged and discharged as the N or
the P-type transistor turns on. Switching power, or capacitance power, accounts for 70
to 90 percent of the power dissipation of an active CMOS circuit.
Short-circuit power varies according to the circuit. For circuits with fast transition times,
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.
Some power is 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 can be ignored.
Modeling Power
9-3
Figure 9-2 shows two examples of an input transition that does not cause a
corresponding output transition.
Figure 9-2 Complex Gate Example
AO22
1 A
NAND2
X
0 A 1
B
0 E 1
Z Z
0*>1 F
B 1 C
Y
1->0 1*>0
D
Case 1 Case 2
In Case 1, input B of the NAND2 gate undergoes a 0-to-1 transition but the output remains
stable at 0. The transition might consume a small amount of power as one of the N-type
transistors opens, but the current flow will be very small.
In 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.
Modeling 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.
Normally, leakage power is only a very small component of the total power (typically,
much less than 1 percent), but it is important to model for designs that are in an idle
state most of the time.
Leakage power information is represented by
• The cell_leakage_power attribute in the cell group

• The leakage_power group in the cell group
Modeling Power
9-4
• The associated library-level attributes that specify scaling factors, units, and a
default value. These attributes are explained in detail in Chapter 3, “Defining
Environment Attributes.”
cell_leakage_power Attribute
This simple 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 : float ;
float
A floating-point number indicating the leakage power of the cell.
Example:
cell_leakage_power : 0.1;
The cell_leakage_power attribute is also recognized in the scaled_cell group, where it

is used to model nonlinear scaling of leakage power relative to certain process, voltage,
and temperature conditions.
leakage_power Group
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
leakage power. To model state-dependent leakage power, declare a leakage_power
group along with the following simple attributes:
• when
• value
Syntax:
leakage_power ( ) {
when : "Boolean expression";
value: float;
when Attribute
This simple attribute specifies the state-dependent condition that determines whether
the leakage power is accessed.
Modeling Power
9-5
Syntax:
when : "Boolean expression";
Boolean expression
Name or names of pins, buses, and bundles with corresponding Boolean operators.
Table 9-1 shows the valid Boolean operators.
Table 9-1 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.
You must define mutually exclusive conditions for state-dependent leakage power.
Mutually exclusive means no more than one condition defined by the when attribute can
be met at any given time.
You can use buses and bundles with the when attribute in the leakage_power group as
shown here:
Example:
bus (A) {
...
}
bus (Z) {
leakage_power () {
when : "A";
...
}
}
Modeling Power
9-6
value Attribute
This simple attribute in the leakage_power group represents the leakage power for a
given state of a cell. It takes the value of a floating point number.
Syntax:
value : float;
float
A leakage power value.
Example:
cell (my cell) {
...
leakage_power () {
when : "! A";
value : 2.0;
}
}
k_volt_cell_leakage_power, k_temp_cell_leakage_power, and

k_process_cell_leakage_power Attributes
These scaling factor attributes specify the environmental (voltage, temperature, and
process) derating factors for the cell_leakage_power attribute. The range for these
scaling factors is [-100.0 : 100.0]. The default value is zero.
Example:
library(power_sample) {
leakage_power_unit : 1nW;
default_cell_leakage_power : 0.1;
k_volt_cell_leakage_power : 0.000000;
k_temp_cell_leakage_power : 0.000000;
k_process_cell_leakage_power : 0.000000;
...
cell(AN2) {
...
leakage_power () {
when : ”A” ;
value : 2.0 ;
}
}
}
Modeling Power
9-7
See Chapter 3, “Defining Environment Attributes,” for information about scaling factors,
units, and default values.
leakage_power_unit Attribute
This simple attribute indicates the units of the leakage-power values in the library. If this
attribute is missing, the leakage-power values are expressed without units.
Syntax:
leakage_power_unit : unit ;
unit
Values are 1mW, 100uW, 10uW, 1uW, 100nW, 10nW, 1nW, 100pW, 10pW, and 1pW.
Example:
leakage_power_unit : 100uW;
default_cell_leakage_power Attribute
This simple attribute indicates the default leakage power for those cells that do not have
the cell_leakage_power attribute. If you do not define the default leakage power, it will
default to zero.
Syntax:
default_cell_leakage_power : value;
value
A non-negative floating-point number.
Example:
default_cell_leakage_power : .5;
Modeling Internal Power
You can describe power dissipation in libraries by using
• The library-level power_lut_template group to define templates of common

information to use with lookup tables
• The internal_power group in a pin group within a cell
Modeling Power
9-8
• The associated library-level attributes that specify scaling factors and a default value
The next section describes how to create internal power lookup tables. These tables are
used in the internal_power group.
Creating Internal Power Lookup Tables

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.
Internal power is dissipated whenever an output pin makes a transition. The following
definitions for internal (or short-circuit) power determine the values for the internal power
lookup tables:
• 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 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 the output pin capacitance.
Note: The input pin power is added to the output pin power. When you model the
library, avoid double counting.
Modeling Power
9-9
Figure 9-3 is an example of the three-dimensional lookup table for modeling output pin
power in a cell.
Figure 9-3 Internal Power Table for Cell Output
z Energy/
Transition
(0.098, 0.06, 0.234)
(0.098, 0.03, 0.227)

(0.587, 0.06, 0.329)
(0.587, 0.03, 0.323) 0.05 Output

Capacitance
0.03 0.06 0.09 0.12 0.15
y
0.098
0.32
0.587
1.077
1.566
Input
Transition x
Time
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. So that power lookup tables
can refer to the template, place its name as 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 ;
index_1(”float, ... , float”) ;
}
Modeling Power
9-10
Template Variables
The 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.
The following values are valid for variable_1, variable_2, and variable_3:
total_output_net_capacitance
This is the loading of the output net capacitance of the pin specified in the pin group
that contains the internal_power group.
total_output2_net_capacitance
This is 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
This is 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 “internal_power Group” later in this
chapter.
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 increasing order.
You must define at least one index_1 in the power_lut_template group. For a one-
dimensional table, use only variable_1.
Modeling Power
9-11
The number of floating-point numbers in the indexes determines the size of each
dimension, as Example 9-1 illustrates.
Example 9-1 shows four power_lut_template groups that have one-, two-, and three-
dimensional templates.
Example 9-1 Four power_lut_template Groups

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_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) {
index_1 (”0.0, 1.0, 5.0”) ;
}
power_lut_template (output_by_cap2_and_trans) {
variable_3 : output2_net_cap ;
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. A predefined template named
scalar exists; its value size is 1. You can refer to it by placing the string, scalar, as the
group name of a fall_power group, power group, or rise_power group in the
For an example, please refer to the “Internal Power Examples” section later in this
chapter.
Note: You can use the scalar template with an assigned value of zero (indicating
that no power is consumed) for an internal_power group with a rise_power
table and a fall_power table. When one group contains the scalar template,
the other must contain one-, two-, or three-dimensional power values.
Modeling Power
9-12
internal_power Group
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, this implies that the cell does not
consume any internal power. Optional complex attributes index_1, index_2, and index_3
can be defined in this group to overwrite the index_1, index_2, and index_3 attributes
defined in the library-level power_lut_template to which it refers (see Example 9-3 later
in this chapter).
The library also supports power scalar values in the internal_power groups within the
pin group.
To define an internal_power group in a pin group, use these attributes and groups:
• equal_or_opposite_output attribute
• related_pin attribute
• when attribute
• power group
• fall_power group
• rise_power group
equal_or_opposite_output Attribute
This simple attribute designates optional output pins whose capacitance provides
access to a three-dimensional table in the internal_power group.
Syntax:
equal_or_opposite_output : ”name” ;
name
Name of output pin or list of pins.
Note: This pin (or pins) has to be functionally equal or opposite to the pin or pins
named in the same pin group.
Example:
equal_or_opposite_output : ”Q” ;
Note: The output capacitance of this pin (or pins) is used as the
total_output2_net_capacitance variable in the internal power lookup table.
Modeling Power
9-13
related_pin Attribute
This simple attribute associates the internal_power group with a specific input or output
pin. If the related_pin is an output pin, it must be functionally equal or opposite to the
pin in that pin group.
If the 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
Name of input or output pin or list of pins.
Example:
related_pin : ”A B” ;
The pin or pins in the related_pin attribute denote the path dependency for the
If you want to define a two-dimensional or three-dimensional table, specify all functionally

related pins in a related_pin attribute.
when Attribute
This simple attribute specifies a state-dependent condition that determines whether a
particular power table is accessed.
You can use the when attribute to define one-, two-, or three-dimensional tables in the
Syntax:
when : ”Boolean expression” ;
Boolean expression
Name or names of input and output pins, buses, and bundles with corresponding
Boolean operators.
Table 9-1 earlier in this chapter lists the Boolean operators that are valid in a when
statement.
Example:
when : "A B" ;
Modeling Power
9-14
The following example illustrates a pin that does not require a default internal power
table because the when attribute contains all the paths that will sensitize the related_pin
B to the output.
Example:
pin (Z) {
function : "A & B";
internal_power () {
related_pin : "B";
when : "A";
...
}
}
In the following example, the internal power table is ignored because pin B exists in both
the when and the related_pin attributes.
Example:
pin (Z) {
function : "A & B & C";
internal_power () {
related_pin : "B";
when : "!A & B";
...
}
}
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 ...
}
}
}
}
}
Modeling Power
9-15
Complex Attributes
index_1 (”float, ..., float”) ;
values (”float, ..., float”) ;
float
Floating-point numbers that identify the amount of energy per rise or fall transition
the cell consumes internally.
values Attribute
This attribute defines internal power consumption per rise or fall transition.
Power information is accessed when the pin defined by the pin group has a rise transition
or fall transition. The values in the table referenced by the power group specify the
average power per transition.
fall_power Group
A fall_power group is defined in an internal_power group in a pin group at the cell level,
as shown here:
cell (name) {
pin (name) {
internal_power () {
fall_power (template name) {
... fall power description ...
}
}
}
}
Complex Attributes
index_3 (”float, ..., float” ;
float
Floating-point numbers that identify the amount of energy per fall transition the cell
consumes internally.
index_1, index_2, index_3

These attributes identify internal cell consumption per transition. Define the index_X
attribute in the internal_power group or in the library-level power_lut_template
group.
Modeling Power
9-16
values Attribute
This attribute defines internal cell consumption per fall transition.
Fall power is used when the pin has a fall transition. If you have a fall_power group, you
must also have a rise_power group.
rise_power Group
A rise_power group is defined in an internal_power group in a pin group at the cell level,
as shown below.
Syntax:
cell (name) {
pin (name) {
internal_power () {
rise_power (template name) {
... rise power description ...
}
}
}
}
Complex Attributes
float
Floating-point numbers that identify the amount of energy per rise transition the cell
consumes internally.
index_1, index_2, index_3

These attributes identify internal cell consumption per rise transition. Define the
index_x attribute in the internal_power group or in the library-level
power_lut_template group.
values Attribute
This attribute defines internal cell consumption per rise transition.
Rise power is accessed when the pin has a rise transition. If you have a rise_power
group, you must also have a fall_power group.
Modeling Power
9-17
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 ways:
• Using the power group (for one-dimensional tables). 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() {
values(”float, ..., float”) ;
}
}
The syntax for a one-dimensional table using fall_power and rise_power groups is shown
here:
internal_power() {
values(“float, ..., float”);
}
values(”float, ..., float”);
}
}
The syntax for a two-dimensional table using the power group and related_pin groups
is shown below:
Syntax:
internal_power() {
related_pin : ”name | name_list” ;
}
}
Modeling Power
9-18
The syntax for a two-dimensional table using related_pin, fall_power, and rise_power
groups is shown here:
internal_power() {
related_pin : ”name ” ;
}
}
}
The syntax for a three-dimensional table using the power group and related_pin groups
is shown here:
internal_power() {
}
}
The syntax for a three-dimensional table using related_pin, fall_power, and rise_power
groups is shown here:
internal_power() {
}
}
}
Internal Power Examples

The examples in this section show how to describe the internal power of the 2-input
sequential gate in Figure 9-4 using one-, two-, and three-dimensional lookup tables.
Modeling Power
9-19
Figure 9-4 Library Cell with internal_power Information
A
cell_w_2d_power Z
B
D
cell_w_1d_power Q
CK
One-Dimensional Power Lookup Table

Example 9-2 is the library description of a cell with two one-dimensional internal_power
tables defined in the pin groups.
Example 9-2 One-Dimensional Internal Power Table

library(internal_power_example) {
...
power_lut_template(output_by_cap) {
index_1(”0.0, 5.0, 20.0”) ;
}
...
power_lut_template(input_by_trans) {
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”) ;
}
}
}
...
Modeling Power
9-20
pin(Q) {
direction : input ;
internal_power()
power(output_by_cap) {
values(”9.0, 5.0, 2.0”) ;
}
}
}
}
}
Two-Dimensional Power Lookup Table

Example 9-3 is the library description of a cell with a two-dimensional internal_power
table defined in the pin groups.
Example 9-3 Two-Dimensional Internal Power Table

...
power_lut_template(output_by_cap_and_trans) {
index_1 (”0.0, 5.0, 20.0”);
index_2 (”0.0, 1.0, 20.0”);
}
...
cell(AN2) {
pin(Z) {
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”);
}
}
}
pin(A) {
direction : input ;
...
}
pin(B) {
direction : input ;
...
}
}
Modeling Power
9-21
Three-Dimensional Power Lookup Table
Example 9-4 is the library description for a cell with a three-dimensional internal_power
table.
Example 9-4 Three-Dimensional Internal Power Table

...
power_lut_template(output_by_cap1_cap2_and_trans) {
variable_1 : total_output1_net_capacitance ;
variable_2 : total_output2_net_capacitance ;
index_1 (”0.0, 5.0, 20.0”) ;
index_2 (”0.0, 5.0, 20.0”) ;
index_3 (”0.0, 1.0, 2.0”) ;
}
cell(FLOP1) {
pin(CP) {
direction : input ;
...
}
pin(D) {
direction : input ;
...
}
pin(S) {
direction : input ;
...
}
pin(R) {
direction : input ;
...
}
pin(Q) {
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” ;
}
...
}
}
}
Modeling Power
9-22
Power-Scaling Factors
These attributes specify the environmental (voltage, temperature, and process) derating
factors for the internal_power group.
• k_volt_internal_power
• k_temp_internal_power
• k_process_internal_power
The range for these scaling factors is [-100.0 : 100.0]. The default value is zero.
Example:
library(power_sample) {
k_volt_internal_power : 0.000000;
k_temp_internal_power : 0.000000;
k_process_internal_power : 0.000000;
}
Modeling Libraries with Multiple Power Supplies
This section describes how to model multiple power supply technology libraries with
Liberty syntax. In most technologies, factors such as operating temperature, supply
voltage, and the manufacturing process can strongly affect circuit performance.
However, the power supply for many new processes has switched from 5V to 3.3V (or
less) to decrease power consumption. Therefore, to support more than one power supply
(for example, 3.3V and 5V), you need to make several changes to your technology library.
• Use the power_supply group, defined at the library level, to specify the various
voltage supplies needed in the library.
• For cells with multiple power supplies, define the rail_connection attribute in the cell
group. At the pin group level, define the input_signal_level and output_signal_level
attributes.
• Specify which voltage is used to characterize the internal power of a pin by defining
a power_level attribute in the internal_power group.
• In the operating_conditions group, specify voltage values for all power rails defined
in the power_supply group. See Example 9-8 for an operating_conditions group that
reflects multiple power supplies.
Modeling Power
9-23
Defining power_supply Groups
To specify a technology library with multiple power supplies, use the power_supply group
at the library level as shown here:
library(name) {
power_supply() {
... power supply information ...
}
}
To define a power_supply group in a library, use these attributes:
• default_power_rail
• power_rail
Note: Libraries that contain only one default power supply do not require a
power_supply group.
default_power_rail Attribute
This simple attribute designates the name of the default power supply under nominal
operating conditions.
Syntax:
default_power_rail : power_supply_name ;
Example:
default_power_rail : VDD1 ;
power_rail Attribute
The power_supply group contains one power_rail attribute for each power supply. This
complex attribute identifies each power supply by its name and nominal voltage value.
Syntax:
power_rail (power_supply_name,voltage_value)
power_supply_name
Specifies a power supply name that can be referenced by the rail_connection
attribute, the input_signal_level attribute, or the output_signal_level attribute.
voltage_value
Identifies the voltage value associated with the string. The value is in the units you
define by the voltage_unit attribute in the library group.
Modeling Power
9-24
Example:
Defining Cells with Multiple Power Supplies

To define a cell with multiple power supplies, use the rail_connection attributes in the
cell group. Add the power_level attribute to the internal_power group to indicate the
power level used for the lookup tables. To specify input and output voltages at the pin
level, use the input_signal_level and output_signal_level attributes.
rail_connection Attribute
This complex attribute is used only when the cell has multiple power supplies. A cell with
multiple power supplies contains two or more rail_connection attributes.
Syntax:
cell (name) {
...
rail_connection (connection_name, power_supply_name) ;
...
}
connection_name
Specifies a power connection to be used as the value for the power_level attribute
in the internal_power group (defined in the pin group).
power_supply_name
Specifies the power supply group already defined in the power_supply group at the
library level.
Example 9-5 shows a cell with two power supplies, VDD1 and VDD2.
Example 9-5 cell with rail_connection Attributes

cell (IBUF1) {
...
rail_connection (PV1, VDD1) ;
...
}
Modeling Power
9-25
power_level Attribute
This simple attribute is included in the internal_power group at the pin level to specify
the power level used to characterize the lookup tables.
Syntax:
power_level : “name” ;
name
Name of the power rail defined in the power_supply group.
Example:
power_level : “VDD1” ;
For an output pin within a multiple power supply cell, regardless of the
output_signal_level value, you must define internal_power groups for all the rail
connections of the cell. Table 9-6 shows a cell with two power supplies and two
internal_power groups with lookup table values.
Example 9-6 Cell with Two Power Supplies

cell ( cell7 ) {
area : 6.000 ;
rail_connection(PV1, VDD1);
pin ( Z ) {
capacitance : 0.000 ;
function : ”(A & B)”;
output_signal_level : VDD1;
internal_power() {
power_level : VDD1; /* required */
power (power_load) {
values (” 0.111111, 0.111111, 0.111111, 0.111111, 0.111111”);
}
}
internal_power() {
power_level : VDD2; /* required */
power (power_load) {
values (” 0.111111, 0.111111, 0.111111, 0.111111, 0.111111”);
}
}
}
...
}
Modeling Power
9-26
For an input pin within a multiple power supply cell, you must define an internal_power
group to match the input_signal_level value. The rest of the rail connections are optional.
Table 9-7 shows an input pin, CP, with an input signal level of VDD1. Only an internal
power table for VDD1 must be provided.
Example 9-7 Cell with Three Power Supplies

cell ( cell1 ) {
...
pin ( CP ) {
direction : input ;
input_signal_level : VDD1;
...
internal_power() {
power_level : VDD1 ;/* this table is required */
power (power_ramp) {
values (”1.934150, 2.148130, 2.449420, 3.345050, 4.305690”);
}
}
internal_power() {
power_level : VDD2 ;/* this table is optional */
power (power_ramp) {
values (”1.934150, 2.148130, 2.449420, 3.345050, 4.305690”);
}
}
/* no table for VDD3 */
}
}
input_signal_level and output_signal_level Attributes

All input and inout pins of a cell that has more than one power supply require an
input_signal_level attribute or an output_signal_level attribute in the pin group of the
cell. These attributes indicate which voltage level to apply to the pins by assigning a
power supply name that was defined with the power_rail attribute in the power_supply
group.
If the pin group does not contain an input_signal_level attribute or output_signal_level

attribute, Liberty uses the power supply name defined by the default_power_rail attribute
in the power_supply group at the library level.
Syntax:
input_signal_level: string ;
output_signal_level: string ;
Modeling Power
9-27
string
Name of the power supply already defined at the library level.
Example:
input_signal_level: VDD1 ;
output_signal_level: VDD2 ;
Table 9-8 shows a library with a power_supply group, nominal operating conditions, and
an operating_conditions group.
Example 9-8 Library with power_supply Group

library (multiple_power_supply) {
power_supply ( ) { /* Define before operating
conditions and cells. */
default_power_rail : VDD0 ;
...
}
nom_process : 1.0 ;
nom_temperature : 25.0 ;
nom_voltage : 5.0 ;
...
operating_conditions (MPSS) {
process : 1.5 ;
temperature : 70 ;
voltage : 4.75 ;
tree_type : worst_case_tree ;
}
}
Multiple Power Supply Library Requirements

A library with multiple power supplies must meet the following requirements:
• The power_supply group is defined before the operating_conditions group and

before the cell groups.
• The power supply names associated with the default_power_rail and power_rail
attributes are unique within a library.
• A power_rail attribute in an operating_conditions group has a power supply string
name predefined in the power_supply group.
• All the power supply names defined by the power_rail attribute in the power_supply
group exist in the operating_conditions group.
Modeling Power
9-28
• An input_signal_level attribute and an output_signal_level attribute in a pin group
have predefined power supply names in the power_supply group.
• The rail_connection names within a cell are unique.
• A rail_connection attribute in a cell group has a predefined power supply name in
the power_supply group.
• In any cell with two or more power supplies, all the pins, buses, and bundles have
an input_signal_level for input type and an output_signal_level attribute for output
type.
• In any cell with two or more power supplies, all the inout pins, buses, and bundles
have an input_signal_level and an output_signal_level attribute.
• An output pin within a cell that has multiple power supplies requires an
internal_power tables with the power_level attribute for each of the rail_connections
of the cell.
• An input pin within a cell that has multiple power supplies requires an internal_power
table with the power_level value matching the input_signal_level value.
Example Library with Multiple Power Supplies

Example 9-9 shows a library with multiple power supplies defined at the library level
(with the power_supply group), cell level (with the rail_connection attribute), and pin level
(with the input_signal_level and output_signal_level attributes).
Example 9-9 Library Example with power_supply Group

library(pow) {
...
power_supply() {
default_power_rail : VDD0;
power_rail(VDD1, 5.0);
}
operating_conditions(WCCOM) {
process : 1.5 ;
temperature : 70 ;
voltage : 4.75 ;
tree_type : ”worst_case_tree” ;
}
cell(IBUF1) {
...
pin(A) {
Modeling Power
9-29
direction : input;
...
}
pin(EN) {
direction : input;
...
}
pin(Z) {
direction : output;
...
}
pin(Z1) {
direction : inout;
...
}
}
}
Example 9-10 Library Example 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;
}
Example 9-11 Example of 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 */
Modeling Power
9-30
Example 9-12 Example of Cell with One Power Supply
cell(with_one_power_supply) {
area : 10;
pin (A) {
direction: input;
capacitance: 1.0;
}
pin (Z) {
direction: output;
function : ”!A”;
}
} /* end cell */
Example 9-13 Example of Cell with Two Power Supplies

cell(with_2_power_supplies) {
area : 0;
pin (A) {
direction: input;
capacitance: 1.0;
input_signal_level: VDD1;
}
pin (EB) {
direction: input;
capacitance: 1.0;
}
pin (Z) {
direction: output;
function : ”A”;
three_state: ”EB”;
output_signal_level: VDD2;
}
} /* end cell */
Example 9-14 Example of Cell with Two Power Supplies and Bidirectional Pin
cell(bidir_with_2_power_supplies) {
area : 0
pin(PAD) {
direction : inout;
function : ”A”;
three_state : ”EN”;
}
Modeling Power
9-31
pin(A) {
direction : input;
capacitance : 3;
}
pin(EN) {
direction : input;
capacitance : 3;
}
pin(X) {
direction : output;
}
} /* end cell */
Modeling Power
9-32
10
Timing Arcs 1
Timing is modeled by describing delay (the actual circuit timing) and specifying
constraints (boundaries). This chapter discusses timing concepts and describes the
timing group attributes for setting constraints and defining delay with the different delay
models.
To describe delay, you need to know these concepts and tasks:
• Understanding timing arcs

• Understanding delay models
• Defining timing groups
• Describing three-state timing arcs
• Describing edge-sensitive timing arcs
• Describing preset and clear timing arcs
• Describing intrinsic delay
• Describing transition delay
• Describing slope sensitivity
• Describing state-dependent delays
Timing Arcs
10-1
To set constraints, you need to understand these tasks:
• Setting setup and hold constraints

• Setting nonsequential timing constraints
• Setting recovery and removal constraints
• Setting no-change timing constraints
• Setting skew constraints
• Setting conditional timing constraints
Understanding Timing Arcs
Timing arcs describe timing characteristics for combinational and sequential cells. Each
timing arc has a startpoint and an endpoint. The startpoint can be an input, output, or
inout pin. The endpoint is always an output or inout pin. The only exception is a constraint
timing arc, such as a setup or hold constraint, between two input pins in a sequential cell.
Figure 10-1 shows timing arcs AC and BC for an AND gate. All delay information in a
library refers to an input-to-output pin pair or an output-to-output pin pair.
Figure 10-1 Timing Arcs
A
C
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 has one of the following values assigned to the timing_type
attribute:
• combinational
• three_state_disable
Timing Arcs
10-2
• three_state_enable
Note: The timing_group attributes, including timing_type, are discussed in the

section on "Defining Timing Groups."
Timing information for combinational cells such as the one in Figure 10-2 can be modeled
in one of two different ways, as Figure 10-3 shows.
Figure 10-2 Two-Inverter Cell
A Y
Z
In Figure 10-3, 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 10-3 Two Modeling Techniques for the Two-Inverter Cell
Model A Model B
Y Y
A A
Z Z
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.
Timing Arcs
10-3
Sequential Timing Arcs
Sequential timing arcs describe the timing characteristics of sequential elements. When
describing the relationship between a clock transition and data output (input to output),
the timing arc is considered a delay arc. When describing the relationship between a
clock transition and data input (input to input), the timing arc is considered a constraint
arc.
A sequential timing arc has one of the following values assigned to the timing_type
attribute:
• rising_edge or falling_edge
• preset or clear
• setup_rising, setup_falling, hold_rising, or hold_falling
• non_seq_setup_rising, non_seq_setup_falling, non_seq_hold_rising, or
non_seq_hold_falling
• recovery_rising, recovery_falling, removal_rising, removal_falling
• no_change_high_high, no_change_high_low, no_change_low_high,
no_change_low_low
Note: The timing_group attributes, including timing_type, are discussed in the

next section.
Impossible Transitions
This section describes timing arc limitations. The information applies to combinational
and three-state timing arcs for all delay models.
Certain output transitions cannot result from a single input change when function,
three_state, and x_function share input.
Timing Arcs
10-4
In Table 10-1, Y is the function of A, B, and C.
Table 10-1 Function Table for Inputs A, B, and C, and Output Y

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 change on A can cause the 1-to-Z or Z-to-1 transitions on Y. Therefore, there
is no three-state timing arc from A to Y, although the two are functionally related.
Three_state_enable has no rising value (Z-to-1), and three_state_disable has no falling

value (1-to-Z).
Understanding Delay Models
Timing groups are defined by the timing group attributes. The delay model you use
determines which set of attributes for delay calculation you specify in a timing group.
The three main types of delay models are:
• CMOS linear delay model

This is the standard delay model.
• CMOS piecewise linear delay model
The equations this model uses to calculate timing delays consider the delay effect
of different wire lengths.
• CMOS nonlinear delay model

The nonlinear delay model is characterized by lookup tables that define the timing
arcs. To describe delay or constraint arcs with this model,
1. Use the library-level lu_table_template group to define templates of common

information to use in lookup tables.
Timing Arcs
10-5
2. 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 the delay_model attribute in the library group.
Syntax:
delay_model : ”model” ;
model
Use generic_cmos, table_lookup, piecewise_cmos, or cmos2. The default value is
generic_cmos. Note that generic_cmos and CMOS linear are different names for
the same delay model.
Example 10-2 shows delay_model attribute values and their corresponding common
names.
Table 10-2 Mapping of delay_model Attribute Values to Common Name

delay_model Value Common Name
generic_cmos CMOS linear
table_lookup CMOS nonlinear
piecewise_cmos CMOS piecewise linear
cmos2 Obsolete, but supported
The delay_model attribute must be the first attribute in the library if a technology attribute
is not present. Otherwise, it should follow the technology attribute.
Example:
library (demo) {
delay_model : table_lookup;
}
Timing Arcs
10-6
Delay analysis involves calculating the delay between the input pin of a gate and the
input pin of the next gate. This timing delay includes the connect delay from the driving
pins to the load pins.
The total delay of a network is divided into four physical components whose sum is the
total delay through a circuit element:
Dtotal = DI + DS + DC + DT
The four components of the delay model are:
DI
Intrinsic delay inherent in the gate and independent of any particular instantiation.
DS
Slope delay caused by the ramp time of the input signal.
DC
Connect media delay to an input pin (wire delay).
DT
Transition delay caused by loading of the output pin.

When using a piecewise linear delay model, you must include the piece_define attribute
in the library group. The piece_type attribute is optional.
piece_define Attribute
The piece_define complex attribute defines the pieces used in the piecewise linear delay
model. With this attribute, you can define the ranges of length or capacitance for indexed
variables, such as rise_pin_resistance, used in the delay equations.
Syntax:
piece_define (”range0 [range1 range2 ...]”) ;
Each range is a floating-point number defining the lower limit of the respective range. If
the piecewise linear model is in the piece_length mode, as described in the “piece_type
Attribute” section, a wire whose length is between range0 and range1 is named as piece
0; a wire whose length is between range1 and range2 is piece 1; and so on.
Timing Arcs
10-7
For example, in the following piece_define specification, a wire of length 5 is referred to
as piece 0; a wire of length 12 is piece 1; and length 20 or more is piece 2.
Example:
piece_define (”0 10 20”) ;
If the piece_type attribute indicates that capacitance is used to define each piece, each
capacitance is a positive floating-point number defining the lower limit of the respective
range. A piece of wire whose capacitance is between range0 and range1 is identified
as piece 0, a capacitance between range1 and range2 is piece 1, and so on.
The piece_define statement must include all ranges of wire length or capacitance for
which you want to enter a unique attribute value.
piece_type Attribute
The piece_type attribute indicates whether capacitance or wire length is used to define
the piecewise linear model.
Syntax:
piece_type : value ;
value
Possible values: piece_length, piece_wire_cap, piece_pin_cap, and
piece_total_cap.
The piece_wire_cap, piece_pin_cap, and piece_total_cap values represent the

piecewise linear model extensions that cause modeling to use capacitance instead of
length. These values indicate wire capacitance alone, total pin capacitance, or the total
wire and pin capacitance. If the piece_type attribute is not defined, modeling defaults to
the piece_length model.
Example:
piece_type : piece_wire_cap ;
CMOS Nonlinear Delay Model

The CMOS nonlinear delay model uses lookup tables and interpolation to compute delay.
The delay information is stored in the lookup tables.
Timing Arcs
10-8
Defining the CMOS Nonlinear Delay Model 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
Lookup table templates are defined in the library group.
Syntax:
lu_table_template(name) {
variable_1 : value;
variable_2 : value;
variable_3 : value;
}
Template Variables
The template for specifying timing delays uses two associated variables: variable_1 and
variable_2. These variables indicate the parameters used to index into the lookup table
along the first and second table axes. The parameters are the input transition time of a
constrained pin and a related pin.
These are valid values for variable_1 and variable_2:
• input_net_transition
• total_output_net_capacitance
• output_net_length
• output_net_wire_cap
• output_net_pin_cap
• constrained_pin_transition
• related_pin_transition
The template for specifying load-dependent constraints uses a third variable, variable_3,
to indicate the parameter used to index into the lookup table along the third table axis.
The third parameter is a related pin for output loading. In addition to the values for
variable_1 and variable_2 listed previously, variable_3 can have any of these values:
• related_out_total_output_net_capacitance
• related_out_output_net_length
Timing Arcs
10-9
• related_out_output_net_wire_cap
• related_out_output_net_pin_cap
Template Breakpoints
The index statements define the breakpoints for an axis. The breakpoints defined by the
index_1 breakpoint 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 both delay arcs and constraints. See
“Describing Intrinsic Delay” and “Describing Transition Delay” later in this chapter for the
groups to use as delay lookup tables. See the sections on the different constraints for
the groups to use as constraint lookup tables.
This is the syntax for lookup table groups:
lu_table(name) {
values(”float, ..., float”, ..., ”float, ..., float”);
}
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 the same as 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 and cell table delay values must be 0.0 or greater. Propagation tables
can contain negative delay values.
Timing Arcs
10-10
- In a one-dimensional table, represent the delay value as a list of nindex_1
floating-point numbers.
- In a two-dimensional or three-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 a predefined scalar table template
as the template for that timing arc. To use the scalar table template, place the
string scalar in your lookup table group statement as shown in Example 10-8
later in this chapter.
• Each group of floating-point numbers enclosed in double quotes (“”) represents a
row in the table.
- The number of floating-point numbers in a group must equal nindex_2, and the
number of groups in the values attribute must equal nindex_1.
- In a one-dimensional table, nindex_2 is ”1”.
- In a three-dimensional table, the total number of groups is nindex_1 x nindex_2
and each group contains the same number of 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.
Example 10-8, later in this chapter, shows a library that uses the CMOS nonlinear delay
model to describe delay.
Defining Timing Groups
Timing groups define the timing arcs through a cell and the relationships between clock
and data input signals.
Timing groups describe
• 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
Timing Arcs
10-11
timing Group
A timing group is defined in a pin group.
Syntax:
cell (cell_name) {
pin (pin_name) {
timing () {
... timing description ...
}
}
}
}
The name of a timing group is always null.
Define the timing group in the pin group of the endpoint of the timing arc.
timing Group Attributes

The delay model you use determines which set of attributes for delay model calculation
you specify in a timing group. Table 10-3 summarizes the available timing group attributes
for each delay model. The syntax for each attribute is given in this section, while
applications for each attribute are found in subsequent sections.
Timing Arcs
10-12
Table 10-3 timing Group Attributes in the Delay Models
Purpose CMOS Linear CMOS Piecewise Linear CMOS Nonlinear
To identify timing arc startpoint. related_pin related_pin related_pin
related_bus_pin related_bus_pin related_bus_pin
To describe logical effect of input pin timing_sense timing_sense timing_sense
on output pin.
To identify an arc as combinational timing_type timing_type timing_type
or sequential.
To describe intrinsic delay on an intrinsic_rise intrinsic_rise (inherent)
output pin, or propagation time intrinsic_fall intrinsic_fall
for three_state_enable and
three_state_disable timing types, or
setup and hold times.
To specify transition delay. Used with rise_resistance rise_pin_resistance rise_transition

propagation delay in CMOS nonlinear rise_delay_intercept
delay model.
fall_resistance fall_pin_resistance fall_transition
fall_delay_intercept
To specify propagation delay in total rise_propagation
cell delay. Used with transition delay fall_propagation
in CMOS nonlinear delay model.
To specify cell delay independent of cell_rise

transition delay. cell_fall
To describe incremental delay added slope_rise slope_rise

to slope of input waveform. slope_fall slope_fall
To specify output pin for load- related_output_pin

dependency model.
related_pin 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.
Syntax:
related_pin : ”name1 [name2 name3 ... ]” ;
Pin names in a related_pin statement can start with a nonalphabetic character.
Timing Arcs
10-13
In a cell with input pin A and output pin B, define A and its relationship to B in the
related_pin attribute statement in the timing group that describes pin B.
Example:
pin (B){
function : ”A’”;
timing () {
...
}
}
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 here.
pin (Z) {
direction : output;
function : ”(A * B)’” ;
timing () {
... timing information ...
}
}
When you use a bus name in a related_pin attribute statement, the bus members, or
range of members, are distributed across all members of the parent bus. The width of
the bus or range must be the same as the width of the parent bus.
In the following 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).
Example:
bus (A) {
bus_type : bus2;
...
}
bus (B) {
bus_type : bus2;
direction : output;
function : “A’”;
timing () {
}
}
Timing Arcs
10-14
related_bus_pins 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.
Syntax:
related_bus_pins : ”Boolean expression” ;
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;
timing () {
related_bus_pins : ”A” ;
}
}
timing_sense Attribute
The timing_sense attribute describes the way an input pin logically affects an output pin.
Define the timing_sense of a pin when you are characterizing a noncombinational gate
such as a three-state component, or when you model multiple paths between an input
pin and an output pin, as in an XOR gate.
Syntax:
timing_sense : positive_unate | negative_unate | non_unate ;
positive_unate
Combines incoming rise delays with local rise delays and compares incoming fall
delays with local fall delays.
negative_unate
Combines incoming rise delays with local fall delays and compares incoming fall
delays with local rise delays.
Timing Arcs
10-15
non_unate
Combines local delays with the worst-case incoming delay value. The non-unate
timing sense represents a function whose output value change cannot be
determined from the direction of the change in the input value.
Example:
timing () {
}
A function is said to be unate if a rising (or falling) change on a positive (or negative)
unate input variable causes the output function variable to rise (or fall) or not change.
For a non-unate variable, further state information is required to determine the effects
of a particular state transition.
Sometimes, one path is positive unate while another is negative unate. In this case,
each path has its own 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. See “Describing Three-State Timing Arcs”
for more information.
If a related_pin is an output pin, you must define timing_sense for that pin.
timing_type Attribute
The timing_type attribute distinguishes between combinational and sequential cells by
defining the type of timing arc. The default is combinational.
Syntax:
timing_type : combinational | three_state_disable |
three_state_enable | rising_edge | falling_edge |
preset | clear | hold_rising | hold_falling |
setup_rising | setup_falling | recovery_rising |
recovery_falling | skew_rising | skew_falling |
removal_rising | removal_falling |
non_seq_setup_rising | non_seq_setup_falling |
nochange_high_high | nochange_high_low |
nochange_low_high | nochange_low_low ;
Example:
timing () {
}
Timing Arcs
10-16
The following sections show the timing_type attribute values for the different timing arcs:
Combinational Timing Arcs
combinational
This argument is used for high_impedance_to_0 or high_impedance_to_1 timing
arcs. The combinational designation is redundant, however, because it is the default
value used in the absence of a defined timing_type attribute.
three_state_disable
This argument is used for three-state output pins.
three_state_enable
This argument is used for three-state output pins.
Sequential Timing Arcs
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.
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.
Timing Arcs
10-17
recovery_rising
Uses the rising edge of the related pin for the recovery time check. The clock is
positive edge-triggered.
recovery_falling
Uses the falling edge of the related pin for the recovery time check. The clock is
negative 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 of the timing group.
The intrinsic_rise value is the maximum skew time between the reference pin rising
to the parent pin rising. The intrinsic_fall value is the maximum skew time between
the reference pin rising to 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 of the timing group.
The intrinsic_rise value is the maximum skew time between the reference pin falling
to the parent pin rising. The intrinsic_fall value is the maximum skew time between
the reference pin falling to the parent pin falling.
removal_rising
Used when the cell is a low-enable latch or a rising edge triggering flip-flop. For
active-low asynchronous control signals, define the removal time with the
intrinsic_rise attribute. For active-high asynchronous control signals, define the
removal time with the intrinsic_fall attribute.
removal_falling
Used when the cell is a high-enable latch or a falling edge-triggering flip-flop. For
active-low asynchronous control signals, define the removal time with the
intrinsic_rise attribute. For active-high asynchronous control signals, define the
removal time with the intrinsic_fall attribute.
Nonsequential Timing Arcs
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. The _rising designation means that the rising edge of the related pin
is active.
Timing Arcs
10-18
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. The _falling designation means that the falling edge of the related pin
is active.
No-Change Timing Check
The four no-change timing types are used for latch devices with latch-enable signals.
These timing types define the pulse waveforms of both the constrained signal and the
related signal in standard CMOS and nonlinear CMOS delay models.
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.
intrinsic_rise Attribute
On an output pin, intrinsic_rise defines the 0-to-Z propagation time for a
three_state_disable timing type and a Z-to-1 propagation time for a three_state_enable
timing type. For a combinational cell’s output pin, intrinsic_rise defines the 0-to-1
propagation time.
On an input pin, intrinsic_rise defines a setup, hold, or recovery timing requirement for
a logic 0-to-1 transition.
Syntax:
intrinsic_rise : value ;
value
Timing Arcs
10-19
Example:
intrinsic_fall Attribute
On an output pin, intrinsic_fall defines the 1-to-Z propagation time for a
three_state_disable timing type and the Z-to-0 propagation time for a three_state_enable
timing type. For a combinational cell’s output pin, intrinsic_fall defines the 1-to-0
propagation time.
On an input pin, intrinsic_fall defines a setup, hold, or recovery timing requirement for a
logic 1-to-0 transition.
Syntax:
intrinsic_fall : value ;
value
Example:
rise_resistance Attribute
This attribute represents the output resistance, or drive capability, for a logic 0-to-1
transition.
Syntax:
rise_resistance : value;
value
A positive floating-point number for the delay time per load unit.
Example:
fall_resistance Attribute
This attribute represents the output resistance, or drive capability, for a logic 1-to-0
transition.
Syntax:
fall_resistance : value;
Timing Arcs
10-20
value
A positive floating-point number for the delay time per load unit.
Example:
rise_pin_resistance Attribute
For piecewise models only, rise_pin_resistance defines the drive resistance applied to
pin loads in the rising edge in the transition delay equation.
Syntax:
rise_pin_resistance (piece, ”float”) ;
piece
An integer defining the segment of wire in accordance with the piece_define
statement.
float
The floating point value assigned to the corresponding range.
Examples from a CMOS library:
rise_pin_resistance (0,”0.25”); /* piece 0 */

fall_pin_resistance Attribute
For piecewise models only, fall_pin_resistance defines the drive resistance applied to
pin loads in the falling edge in the transition delay equation.
Syntax:
fall_pin_resistance (piece, ”float”) ;
piece
statement.
float
Timing Arcs
10-21
fall_pin_resistance (0,”0.25”) ; /* piece 0 */

rise_delay_intercept Attribute
For CMOS piecewise linear delay models only, rise_delay_intercept defines the intercept
for vendors using slope- or intercept-type timing equations. The value of the attribute is
added to the rising edge in the delay equation.
Syntax:
rise_delay_intercept (piece, ”float”) ;
piece
statement.
float
rise_delay_intercept (0,”1.0”) ; /* piece 0 */

rise_delay_intercept (1,”0.0”) ; /* piece 1 */
fall_delay_intercept Attribute
For CMOS piecewise linear delay models only, fall_delay_intercept defines the intercept
for vendors using slope- or intercept-type timing equations. The value of this attribute is
added to the falling edge in the delay equation.
Syntax:
fall_delay_intercept (piece, ”float”) ;
piece
statement.
float
Timing Arcs
10-22
fall_delay_intercept (0,”1.0”) ; /* piece 0 */

fall_delay_intercept (1,”0.0”) ; /* piece 1 */
fall_delay_intercept (2,”-1.0”) ; /* piece 2 */
rise_transition and fall_transition Groups

These groups introduce a lookup table that provides transition delay values for the CMOS
nonlinear delay model. Transition time is the time it takes a driving pin to make a transition
from 0 to 1 (defined in the rise_transition group) or from 1 to 0 (defined in the fall_transition
group). Transition delay is a function of capacitance at the output pin and input transition
time.
Syntax:
library (name) {
cell (name) {
pin (name) {
timing () {
rise_transition (name) {
... rise transition description ...
}
fall_transition (name) {
... fall transition description ...
}
}
}
}
}
name
The name of the rise_transition or fall_transition group.
The rise_transition and fall_transition groups take the following complex attributes:

values (”float, ..., float”, ..., ”float, ...,float”);
Example:
pin(Q) {
...
timing() {
...
rise_transition(trans_template) {
values (”0.1, 0.15, 0.20, 0.29”);
}
Timing Arcs
10-23
fall_transition (trans_template) {
values (”0.1, 0.11, 0.18, 0.40”);
}
}
}
rise_propagation and fall_propagation Groups

These groups introduce a lookup table that provides propagation delay values for the
CMOS nonlinear delay model. Propagation delay is the delay between the thresholds
in the transition at the input of a gate and the start of the output transition, as shown in
Figure 10-4.
Note: If you define propagation delay tables for a timing arc, you cannot specify
cell delay tables for that arc.
Figure 10-4 Propagation Delay Time Waveforms
transition transition
threshold
tPLH tPHL
tPLH - propagation delay time for a low-to-high transition

tPHL - propagation delay time for a high-to-low transition
Syntax:
library (name) {
cell (name) {
pin (name) {
timing () {
rise_propagation (template_name) {
... rise propagation description...
}
fall_propagation (template_name) {
... fall propagation description...
}
}
}
}
}
Timing Arcs
10-24
template_name
Indicates which lu_table_template (defined in the library group) to use.
The rise_propagation and fall_propagation groups take the following complex attributes:

values(”float, ..., float”, ..., ”float, ...,float”);
Example:
pin(Z) {
...
timing() {
...
rise_propagation (scalar) {
values (”0.12”);
}
fall_propagation(scalar) {
values (”0.12”);
}
}
}
See Chapter 3, “Environment Attributes,” for information about calculating delay factors.
cell_rise and cell_fall Groups

These groups define cell delay lookup tables (independently of transition delay) in CMOS
nonlinear delay models.
Cell delay is usually a function of both output loading and input transition time.
Note: If you define cell delay tables for a timing arc, you cannot specify
propagation delay tables for that arc.
Timing Arcs
10-25
Syntax:
library (name) {
cell (name) {
pin (name) {
timing () {
cell_rise (template_name){
... cell rise description...
}
cell_fall (template_name){
... cell fall description...
}
}
}
}
}
template_name
The name of the lu_table_template (defined in the library group) that this lookup
table should use.
The cell_rise and cell_fall groups take the following complex attributes:

values(”float, ..., float”, ..., ”float, ...,float”);
You can overwrite index_1, index_2, or index_3 in a lookup table, but the overwrite must
occur before the values are defined. The number of floating-point numbers for index_1,
index_2, or index_3 must be the same as the number you used in the lu_table_template.
The delay value of the table is stored in a values complex attribute. It is a list of nindex_1
floating-point numbers for a one-dimensional table, nindex_1 x nindex_2 floating-point
numbers for a two-dimensional table, or nindex_1 x nindex_2 x nindex_3 floating-point
numbers for a three-dimensional table.
In a two-dimensional table, nindex_1 and nindex_2 are the size of index_1 and index_2 of
the lu_table_template group. Group nindex_1 and nindex_2 together using quotation marks
(” ”).
In a three-dimensional table, nindex_1 x nindex_2 x nindex_3 are the sizes of index_1,

index_2, and index_3 of the lu_table_template group. Group nindex_1, nindex_2, and
nindex_3 together using quotation marks (” ”).
Transition and cell table delay values must be 0.0 or greater. Propagation tables can
contain negative delay values.
Timing Arcs
10-26
Example:
cell (general) {
pin(a) {
direction: output;
timing() {
cell_rise(basic_template) {
values (”0.0, 0.13, 0.17, 0.19”, ”0.21, 0.23, 0.30, \
0.41”, ”0.22, 0.31, 0.35, 0.47”, ”0.33, \
0.37, 0.45, 0.50”);
}
}
}
slope_rise Attribute
The value of this attribute represents the incremental delay to add to the slope of the
input waveform for a logic 0-to-1 transition.
Syntax:
slope_rise : float ;
float
A positive floating-point number multiplied by the transition delay, resulting in the
slope delay.
Example:
slope_rise : 1.0 ;
slope_fall Attribute
The value of this attribute represents the incremental delay to add to the slope of the
input waveform for a logic 1-to-0 transition.
Syntax:
slope_fall : float ;
float
A positive floating-point number multiplied by the transition delay, resulting in the
slope delay.
Example:
slope_fall : 0.8 ;
Timing Arcs
10-27
related_output_pin Attribute
The related_output_pin attribute specifies the output or inout pin used to describe a
load-dependent constraint.
Syntax:
related_output_pin : value ;
value
The value you supply depends on the information you have available from the cell
characterization. Possible values are:
- related_out_total_output_net_capacitance
- related_out_output_net_length
- related_out_output_net_wire_cap
- related_out_output_net_pin_cap
Example:
related_output_pin : related_out_output_net_pin_cap ;
Describing Three-State Timing Arcs
Three-state arcs describe a three-state output pin in a cell. This section explains how
to describe three-state disable and three-state enable timing arcs.
Describing Three-State Disable Timing Arcs

To designate a three-state disable timing arc when defining a three-state pin:
1. Assign related_pin to the enable pin of the three-state function.
2. Define the 0-to-Z propagation time with the intrinsic_rise statement.
3. Define the 1-to-Z propagation time with the intrinsic_fall statement.
4. Include the timing_type : three_state_disable statement in the timing group.
Timing Arcs
10-28
This example describes a three-state disable timing arc for a three-state pin:
timing () {
related_pin : ”OE” ;
timing_type : three_state_disable ;
intrinsic_rise : 1.0 ; /* 0 to Z time */
intrinsic_fall : 1.0 ; /* 1 to Z time */
}
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_disable attribute. 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. 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.
Describing Three-State Enable Timing Arcs

To designate a three-state enable timing arc when defining a three-state pin:
1. Assign related_pin to the enable pin of the three-state function.
2. Define the Z-to-1 propagation time with the intrinsic_rise statement.
3. Define the Z-to-0 propagation time with the intrinsic_fall statement.
4. Include the timing_type : three_state_enable statement in the timing group.
This example shows a three-state enable timing arc for a three-state pin:
timing () {
related_pin : ”OE” ;
timing_type : three_state_enable ;
intrinsic_rise : 1.0 ; /* Z-to-1 time */
intrinsic_fall : 1.0 ; /* Z-to-0 time */
}
}
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. If a 1 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_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 positive_unate for the three_state_enable
timing arc.
Timing Arcs
10-29
Timing Model Example
Example 10-1 describes the timing model for an inverter with a three-state output and
active-high enable in a CMOS linear library.
Example 10-1 Three-State Cell with Disable and Enable Timing Arcs
library(example){
technology (cmos);
...
cell(TRI_INV2) {
area : 3;
pin(A) {
direction : input;
capacitance : 2;
}
pin(E) {
direction : input;
capacitance : 2;
}
pin(Z) {
direction : output;
three_state : ”E’”;
timing() {
}
timing() {
timing_type : three_state_enable;
related_pin : ”E”;
}
timing() {
timing_type : three_state_disable;
related_pin : ”E”;
}
}
}
Timing Arcs
10-30
Describing Edge-Sensitive Timing Arcs
For edge-sensitive timing arcs, such as the arc from the clock on a flip-flop, the
timing_type attribute in the timing group can take the following values:
• rising_edge
• falling_edge
Edge-sensitive timing arcs are path-traced; the path-tracer propagates only the active
edge (rise or fall) path values along the timing arc.
Example 10-2 shows the timing arc for the QN pin in a JK flip-flop in a CMOS library
using a CMOS linear delay model.
Example 10-2 Timing Arc for JK Flip-Flop

pin(QN) {
timing() {
}
}
The QN pin makes a transition after the clock signal rises. The values of intrinsic_rise
and rise_resistance determine the amount of delay between the clock and QN pin
transitions.
Describing Preset and Clear Timing Arcs
Preset and clear timing arcs affect only the rise or fall arrival time on the arc’s endpoint
pin. You can use these timing arcs for an asynchronous reset pin on a flip-flop.
Include timing information on all other paths through the cell for which you are assigning
clear or preset timing arcs. These arcs are path-traced. If all timing arcs associated with
a pin are clear arcs, the pin has uninitialized rise arrival times. Similar problems can
occur with a pin that is associated only with preset timing arcs.
Timing Arcs
10-31
Describing Preset Arcs
Preset arcs affect only the rise arrival time of the arc’s endpoint pin. A preset arc means
that you are asserting a logic 1 on the output pin when the designated related_pin is
asserted.
To designate a preset arc,
1. Select the preset value for the timing_type attribute:

timing_type : preset;
2. Assign the appropriate value to the timing_sense attribute. Valid values are
positive_unate
Indicates that the rise arrival time of the arc’s source pin is used to calculate
the arc’s delay. This calculation produces the rise arrival time on the arc’s
endpoint pin. In the case of slope delays, the source pin’s rise transition time
is added to the arc’s delay. The source pin is active high.
negative_unate
Indicates that the fall arrival time of the arc’s source pin is used to calculate the
arc’s delay. This calculation produces the rise arrival time on the arc’s endpoint
pin. In the case of slope delays, the source pin’s fall transition time is added to
the arc’s delay. The source pin is active low.
non_unate
Indicates that the maximum of the rise and fall arrival times of the arc’s source
pin is used to calculate the arc’s delay. This calculation produces the maximum
arrival time on the arc’s endpoint pin. In the case of slope delays, the maximum
of the source pin’s rise and fall transition times are added to the arc’s delay.
Example:
In addition to the timing_type and timing_sense attributes, you can assign the following
attributes if you are using the CMOS linear delay model:
• intrinsic_rise
• rise_resistance
• slope_rise
Timing Arcs
10-32
Example 10-3 shows the timing description for a preset arc.
Example 10-3 Preset Arc Timing Description

timing () {
slope_rise : 1.0 ;
}
Describing Clear Arcs

Clear arcs affect only the fall arrival time of the arc’s endpoint pin. A clear arc means
that you are asserting a logic 0 on the output pin when the designated related_pin is
asserted.
To designate a clear arc,
1. Select the clear value for the timing_type attribute:

timing_type : clear;
2. Assign the appropriate value to the timing_sense attribute. Valid values are
positive_unate
Indicates that the fall arrival time of the arc’s source pin is used to calculate the
arc’s delay. This calculation produces the fall arrival time on the arc’s endpoint
pin. In the case of slope delays, the source pin’s fall transition time is added to
the arc’s delay. The source pin is active low.
negative_unate
Indicates that the rise arrival time of the arc’s source pin is used to calculate
the arc’s delay. This calculation produces the fall arrival time on the arc’s
endpoint pin. In the case of slope delays, the source pin’s rise transition time
is added to the arc’s delay. The source pin is active high.
non_unate
Indicates that the maximum of the rise and fall arrival times of the arc’s source
pin is used in calculating the arc’s delay. This calculation produces the maximum
fall arrival time on the arc’s endpoint pin. In the case of slope delays, the
maximum of the source pin’s rise and fall transition times is added to the arc’s
delay.
Timing Arcs
10-33
Example:
In addition to the timing_type and timing_sense attributes, you can assign the following
attributes if you are using the CMOS linear delay model:
• intrinsic_fall
• fall_resistance
• slope_fall
Example 10-4 shows the timing description of a clear arc.
Example 10-4 Clear Arc Timing Description

timing (){
slope_fall : 0.8 ;
}
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 upon 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
describe the timing requirements for that pin. Pin D in Example 10-22 near the end of
this chapter illustrates the intrinsic delay attributes used as timing constraints. Timing
constraints are not used in the delay equation.
Timing Arcs
10-34
In the CMOS Linear and Piecewise Linear Delay Models
The intrinsic_rise and intrinsic_fall attributes describe the intrinsic delay of a pin when
you use the CMOS linear or piecewise delay models.
Example 10-5 shows the timing group for a 2-input NAND gate with an intrinsic rise delay
of 0.58 and intrinsic fall delay of 0.69.
Example 10-5 Timing Group for Two-Input NAND

pin (Z) {
timing () {
...
}
}
In the CMOS Nonlinear Delay Model

Intrinsic delay is inherently described in the lookup tables that you create for the CMOS
nonlinear delay model. See “Understanding Delay Models” earlier in this chapter for the
way to create and use templates for lookup tables in a library using the CMOS nonlinear
delay model.
Describing Transition Delay
The transition delay of an output pin on a net is a function of the capacitance of all pins
on the net and the capacitance of the interconnect network that ties the pins together.
Transition delay attributes represent the resistance encountered in making logic
transitions.
The components of the total delay calculation depend upon the timing delay model used.
The transition delay attributes that apply to the delay model you are using belong in the
timing group.
Timing Arcs
10-35
In the CMOS Linear Delay Model
The rise_resistance and fall_resistance attributes are used exclusively for linear
(standard) delay models. Note that the resistance values used in the piecewise linear
delay model (rise_pin_resistance and fall_pin_resistance) are not valid in the standard
delay model.
Example 10-6 is a combinational timing description of a NAND gate in a library that uses
a standard CMOS linear delay model.
Example 10-6 NAND Gate Timing Description (CMOS Linear Delay Model)
cell (NAND2) {
area : 1 ;
pin(A, B) {
direction : input ;
capacitance : 1 ;
}
pin(Z) {
timing() {
}
timing() {
related_pin : ”B” ;
}
}
}
In the CMOS Piecewise Linear Delay Model

Transition delay for piecewise linear delay models is modeled with delay-intercept
attributes and pin-resistance attributes. Delay-intercept attributes define the intercept
for vendors who use slope or intercept-type timing equations. Pin-resistance attributes
describe the resistance encountered in making logic transitions.
When using a piecewise linear delay model, you must include the piece_define attribute
in the library group. Optionally, you can include the piece_type attribute statements.
Timing Arcs
10-36
Syntax:
attribute_name (piece, ”value”);
attribute_name
Any of the following delay-intercept and pin-resistance attributes. Their syntax is
found in the section “Defining Timing Groups.”
- rise_delay_intercept
- fall_delay_intercept
- rise_pin_resistance
- fall_pin_resistance
piece
statement.
value
Example 10-7 shows how to define a NOR gate.
Example 10-7 Combinational Timing Description (Piecewise Linear Delay)

library (example) {
piece_define ( ”0 15 40” ) ;
cell(NOR2) {
area : 1;
pin(A, B) {
direction : input;
capacitance : 1;
}
pin(Z) {
direction : output;
function : ”(A+B)’”;
timing() {
rise_delay_intercept(0,”1.0”); /* piece 0 */
rise_delay_intercept(1,”0.0”); /* piece 1 */
rise_delay_intercept(2,”-1.0”); /* piece 2 */
fall_delay_intercept(0,”1.0”); /* piece 0 */
fall_delay_intercept(1,”0.0”); /* piece 1 */
fall_delay_intercept(2,”-1.0”); /* piece 2 */
rise_pin_resistance(0,”0.25”); /* piece 0 */
fall_pin_resistance(0,”0.25”); /* piece 0 */
Timing Arcs
10-37
}
}
}

Transition time is the time it takes for an input signal to make a transition between the
high and low logic states. With nonlinear delay models, transition time 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 groups are valid lookup tables for delay arcs:
• rise_transition
• fall_transition
• cell_rise
• cell_fall
• rise_propagation
• fall_propagation
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.
You can define delay arcs using one of two methods. Choose the method that best fits
your library data characterization.
Method 1
To specify cell delay independently of transition delay, use at least two of these timing
group attributes as your lookup table:
• rise_transition (use with cell_rise)

• fall_transition (use with cell_fall)
• cell_rise
• cell_fall
Timing Arcs
10-38
Example:
pin(a) {
direction: output;
timing() {
. . .
/* Inherit the ‘basic_template’ template */
/* Specify all the values */
values (”0.0, 0.13, 0.17, 0.19”, ”0.21, 0.23, 0.30, \

0.41”, ”0.22, 0.31, 0.35, 0.47”, ”0.33, \
0.37, 0.45, 0.50”);
}
rise_transition (basic_template) {
values (”0.0, 0.13, 0.17, 0.19”, ”0.21, 0.23, 0.30, \

0.41”, ”0.22, 0.31, 0.35, 0.47”, ”0.33, \
0.37, 0.45, 0.50”);
}
}
. . .
}
Method 2
To specify transition delay as a term in the total cell delay, use at least two of these timing
group attributes as your lookup table:
• rise_transition (use with rise_propagation)

• fall_transition (use with fall_propagation)
• rise_propagation
• fall_propagation
Example:
pin(Z) {
...
timing() {
...
rise_propagation (scalar) {
values (”0.12”);
}
fall_propagation (scalar) {
values (”0.12”);
}
Timing Arcs
10-39
rise_transition (trans_template) {
values (”0.1, 0.15, 0.20, 0.29”);
}
fall_transition (trans_template) {
values (”0.1, 0.15, 0.20, 0.29”);
}
}
Example 10-8 shows how to use lookup tables and templates to describe transition delay
with the nonlinear delay model.
Example 10-8 Using Templates in the CMOS Nonlinear Timing Model

library( vendor_a ) {
delay_model : table_lookup; /* Use CMOS nonlinear timing model */
. . .
/* Define template of size 4 x 4*/
lu_table_template(basic_template) {
variable_2 : total_output_net_capacitance;
index_1 (”0.0, 0.5, 1.5, 2.0”);
index_2 (”0.0, 2.0, 4.0, 6.0”);
}
/* Define library-level one-dimensional lu_table of size 4 */
lu_table_template(one_dimensional) {
index_1 (”0.0, 0.5, 1.5, 2.0”);
}
/* Define a cell with pins containing lu_table groups that */

/* inherit the library level template information */
cell (general) {
. . .
pin(a) {
direction: output;
timing() {
. . .
/* Inherit the ‘basic_template’ template */
values (”0.0, 0.13, 0.17, 0.19”, ”0.21, 0.23, 0.30, \

0.41”, ”0.22, 0.31, 0.35, 0.47”, ”0.33, \
0.37, 0.45, 0.50”);
}
Timing Arcs
10-40
rise_transition (basic_template) {
values (”0.0, 0.13, 0.17, 0.19”, ”0.21, 0.23, 0.30, \

0.41”, ”0.22, 0.31, 0.35, 0.47”, ”0.33, \
0.37, 0.45, 0.50”);
}
}
. . .
}
pin(b) {
direction: output;
timing() {
. . .
/* Inherit the ‘one_dimensional’ template */
cell_rise(one_dimensional) {
/*Specify all the values (enclosed in a pair of ””)*/
values (”0.1, 0.15, 0.20, 0.29”);

}
rise_transition (one_dimensional) {
/*Specify all the values (enclosed in a pair of ””)*/
values (”0.13, 0.18, 0.25, 0.39”);

}
}
}
pin(c) {
direction: output;
timing() {
. . .
/* Use the predefined ‘scalar’ template */
cell_rise(scalar) {
/* Specify the value */
values (”0.12”);
}
rise_transition {
/* Specify the value */
values (”0.15”);
}
}
}
}
/* The rest of the library. */

}
Timing Arcs
10-41
Modeling Transition Time Degradation
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 10-5. The higher the interconnect load, the greater the
flattening effect and the greater the transition delay.
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
Figure 10-5 Transition Time Degradation
Transition
at load 1
Transition
at driver
Transition
at load 2
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):
• connect_delay
• output_pin_transition
You can assign either connect_delay or output_pin_transition to variable_1 or variable_2

as long as the index and table values are consistent with the assignment. The values
you use in the table are your characterized delay values.
Timing Arcs
10-42
Degraded transition values are computed according to this formula:
degraded_transition = table_lookup(f(output_pin_transition, connect_delay))
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 the following example, K is a factor generated by the ASIC vendor as applicable to its
technology and delay model.
new_rise_transition = output_pin_transition + K * connect_delay
Example 10-9 shows the use of the degradation tables. In this example, trans_deg is
the name of the template for the transition degradation.
Example 10-9 Using Degradation Tables

library (simple_tlu) {
/* 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”);
}
Timing Arcs
10-43
/* the new degradation tables */
rise_transition_degradation(trans_deg) {
values(”0.0, 0.6”, \
”1.0, 1.6”);
}
fall_transition_degradation(trans_deg) {
values(”0.0, 0.8”, \
”1.0, 1.8”);
}
/* other library level defaults */
...
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 using

four table points.
Describing Slope Sensitivity
The slope delay of an element is the incremental time delay due to slowly changing input
signals. Slope delay is calculated by multiplying the transition delay at the previous output
pin by 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. It is
defined in the timing group of the driving pin.
The value in the attribute statements for slope sensitivity is a positive floating-point
number that results in slope delay when multiplied by the transition delay.
Timing Arcs
10-44
Use these slope sensitivity attributes for CMOS linear or piecewise linear technology
only:
• slope_rise
• slope_fall
Example 10-10 shows two timing groups that include the slope_rise and slope_fall
attributes.
Example 10-10 Slope Sensitivity Factors

timing () {
slope_rise : 1.0 ;
}
timing (){
slope_fall : 0.8 ;
}
Describing State-Dependent Delays
In the timing group of a technology library, you can specify state-dependent delays that
correspond to entries in OVI SDF 2.1 syntax.
To define a state-dependent timing arc, use these attributes:
• when
• sdf_cond
For state-dependent timing, each timing group requires both sdf_cond and when
attributes.
Timing Arcs
10-45
You must define mutually exclusive conditions for state-dependent timing arcs. Mutually
exclusive means no more than one condition (defined in the when attribute) can be met
at any time. You must also define a default timing arc that contains no when attribute.
The default timing arc is used if none of the when conditions are satisfied.
when Attribute
The when attribute is a Boolean expression in the timing group that specifies the
condition that a timing arc depends on 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.
See Table 9-1 in Chapter 9, “Modeling Power,” for the valid Boolean operators.
Syntax:
when : ”Boolean expression” ;
Boolean expression
A Boolean expression containing names of input, output, inout, and internal pins.
Example:
when : ”CD * SD” ;
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, the timing_type of the arc determines the valid pins or variables
to use with the when attribute.
• For timing_type : rising_edge and timing_type : falling_edge, pins in these attributes

are allowed in the when attribute:
- next_state
- clocked_on
- clocked_on_also
- enable
- data_in
Timing Arcs
10-46
• 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.
- 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.
All input pins in a black box cell (a cell without a function attribute) are allowed in the
when attribute.
sdf_cond Attribute
Defined in the state-dependent timing group, the sdf_cond attribute supports Standard
Delay Format (SDF) file generation.
Syntax:
sdf_cond = ”SDF expression” ;
SDF expression
A string that represents a Boolean description of the state dependency of the delay.
Use a Boolean description that conforms to the valid syntax defined in the SDF
specification from Open Verilog International (OVI). For a complete description of
valid syntax for these expressions, refer to the OVI specification for SDF, v1.0.
Example:
sdf_cond = ”b == 1’b1”;
The sdf_cond attribute should be logically equivalent to the when attribute in the same
timing arc.
Timing Arcs
10-47
Figure 10-6 shows an XOR gate.
Figure 10-6 XOR Gate with State-Dependent Timing Arc
Timing arc
B
out
A
Example 10-11 shows how to use the when attribute for a 2-input 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. The intrinsic delay between pin A and pin OUT is 1.3
for rising and 1.5 for falling when pin B = 1. When pin B = 0, the timing arc between the
same two pins has intrinsic_rise 1.4 and intrinsic_fall 1.6 .
Example 10-11 XOR Cell with State-Dependent Timing

cell(XOR) {
pin(A) {
direction : input;
...
}
pin(B) {
direction : input;
...
}
pin(out) {
direction : output;
function : ”A ^ B”;
timing() {
when : ”B”;
sdf_cond : ” B == 1’B1 ”;
}
timing() {
when : ”!B”;
sdf_cond : ” B == 1’B0 ”;
}
Timing Arcs
10-48
timing() { /* default timing arc */
}
timing() {
when : ”A”;
sdf_cond : ”A == 1’B1 ”;
}
timing() {
when : ”!A”;
sdf_cond : ”A == 1’B0 ”;
}
timing() { /* default timing arc */
}
}
}
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
may 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 constant.
If the data signal makes a transition during the hold time, an incorrect value may be
latched.
Timing Arcs
10-49
By combining a setup time and a hold time, you can ensure the stability of data that is
latched.
Figure 10-7 shows setup and hold timing for a positive edge-triggered flip-flop. The
activating edge of the clock in this case is the rising edge.
Figure 10-7 Setup and Hold Constraints for Positive Edge-Triggered Flip-Flop
C
A
Clock
Data
B D
A = data low setup time C = data high setup time

B = data low hold time D = data high hold time
Figure 10-8 illustrates setup and hold timing for a high-enable latch. The deactivating
edge of the enable signal in this case is the falling edge.
Figure 10-8 Setup and Hold Constraints for High-Enable Latch
A C
Enable
Data
B D

Timing Arcs
10-50
Use setup and hold constraints only between data pins and clock pins.
Setup Constraints
To define a setup constraint,
1. Assign one of these values to the timing_type attribute:

setup_rising
Designates the rising edge of the related pin for the setup check.
setup_falling
Designates the falling edge of the related pin for the setup check.
The setup_rising and setup_falling values define timing arcs that are used for setup
checks on clocked elements.
2. Specify a related pin in the timing group.

The related_pin attribute in a timing arc with a setup_rising or setup_falling timing
type identifies the pin used for the timing check. The rising or falling designation
indicates which edge of the related pin is active for the setup check.
Example 10-12 describes the setup arc for the data pin on the positive edge-triggered
D flip-flop shown in Figure 10-7. The intrinsic_rise value represents setup time C and
the intrinsic_fall value represents setup time A. The syntax shown assumes a linear or
piecewise linear delay model.
Example 10-12 Setup Arc for Data Pin on D Flip-Flop

timing() {
related_pin : ”Clock” ;
}
Timing Arcs
10-51
Example 10-13 describes the setup constraint for the data pin on the high-enable latch
shown in Figure 10-8. The intrinsic_rise value represents setup time C and the
intrinsic_fall value represents setup time A.
Example 10-13 Setup Constraint for Data Pin on High-Enable Latch

timing() {
timing_type : setup_falling ;
related_pin : ”Enable” ;
}
Hold Constraints
To define a hold constraint,
hold_rising
This value designates the rising edge of the related pin for the hold check.
hold_falling
This value designates the falling edge of the related pin for the hold check.
The hold_rising and hold_falling values of the timing_type attribute define timing
constraints that are used for hold checks on clocked elements.
2. Specify a related pin in the timing group.

The related_pin attribute in a timing arc with a hold_rising or hold_falling timing type
identifies the pin used for the timing check. The rising or falling designation indicates
which edge of the related pin is active for the hold check.
Example 10-14 shows the hold constraint for pin D on the positive edge-triggered D flip-
flop in Figure 10-7. The intrinsic_rise value represents hold time B and the intrinsic_fall
value is hold time D.
Example 10-14 Hold Constraint for Data Pin on D Flip-Flop

timing() {
}
Timing Arcs
10-52
Example 10-15 shows the hold constraint for the data pin on the high-enable latch in
Figure 10-8. The intrinsic_rise value represents hold time B and the intrinsic_fall value
represents hold time D.
Example 10-15 Hold Constraint for Data Pin on High-Enable Latch

timing() {
timing_type : hold_falling ;
}
Setup and Hold Timing Constraints

A complete setup and hold timing constraint is described by combining a setup constraint
and a hold constraint. The following example shows setup and hold timing constraints
on pin K in a JK flip-flop.
Example 10-16 Setup and Hold Timing Constraints for JK Flip-Flop

pin(K) {
direction : input ;
capacitance : 1.3 ;
timing() {
}
timing() {
timing_type : hold_rising ;
}
}

The CMOS nonlinear delay model can support timing constraints that are sensitive to
clock or data-input transition times. Each constraint is defined by a timing group with
either or both of the following groups:
• rise_constraint group
• fall_constraint group
Timing Arcs
10-53
rise_constraint and fall_constraint Groups
These constraint tables take the place of the intrinsic_rise and intrinsic_fall attributes
used in the other delay models. The format of the lookup table template and the format
of the lookup table are the same as described previously in “Defining the CMOS
Nonlinear Delay Model Template” and “Creating Lookup Tables.”
These are valid variable values for the timing constraint template:
constrained_pin_transition
Value for the transition time of the pin that for which the timing group is specified.
related_pin_transition
Value for the transition time of the related_pin defined in the timing group.
At least one table is required for each timing group that contains one of the following
timing_type attribute values:
• 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
Only one table is required for timing groups with one of the following timing_type attribute
values:
• recovery_rising
• recovery_falling
• removal_rising
• removal_falling
Timing Arcs
10-54
Example 10-17 shows how to specify setup constraints for a flip-flop using tables.
Example 10-17 CMOS Nonlinear Timing Model Using Constraint

library( vendor_b ) {
/* 1. Use delay lookup table */
/* 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”;
/* Inherit the ‘constraint_template’ template */

rise_constraint(constraint_template) {

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”);
}
}
. . .
}
}
. . .
}
Timing Arcs
10-55
Modeling Load Dependency
The section on “Describing Transition Delay” 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.
Note: Load-dependent constraints are allowed only in the CMOS nonlinear delay
model.
This is the procedure for modeling load dependency.
1. In the timing group of the output pin,

- Set the timing_type attribute to one of the following values:
setup_rising setup_falling
hold_rising hold_falling
removal_rising removal_falling
recovery_rising recovery_falling
skew_rising skew_falling
nochange_high_high nochange_high_low
nochange_low_high nochange_low_low
non_seq_setup_rising non_seq_setup_falling
non_seq_hold_rising non_seq_hold_falling
- Specify the output pin used to figure the load dependency with the
related_output_pin attribute.
2. 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
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 CMOS Nonlinear Delay Model Template” earlier in this chapter.
3. Create a three-dimensional lookup table using the table template and the index_3
attribute in the lookup table group. See “Creating Lookup Tables” earlier in this
chapter. The following groups are valid lookup tables for output load modeling:
- rise_constraint
Timing Arcs
10-56
- fall_constraint
Example 10-18 shows a library that includes a load-dependent model.
Example 10-18 Load-Dependent Model

library(load_dependent) {
...
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”);
}
}
}
}
Setting Nonsequential Timing Constraints
You can set constraints that require the data signal on an input pin to 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.
Timing Arcs
10-57
Scaling of nonsequential setup and hold constraints based on the environment use the
K-factors for sequential setup and hold constraints.
To model nonsequential setup and hold constraints for a cell,
1. Assign one of these values to the timing_type attribute in a timing group of an input
or inout pin.
non_seq_setup_rising
This value designates the rising edge of the related pin for the setup check.
non_seq_setup_falling
This value designates the falling edge of the related pin for the setup check.
non_seq_hold_rising
This value designates the rising edge of the related pin for the hold check.
non_seq_hold_falling
This value designates the falling edge of the related pin for the hold check.
2. 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 as the related pin except for output pins and the
constrained pin itself.
You can use both rising and falling edges as the active edge of the related pin for
one cell, as shown in Example 10-19.
Example 10-19 Setup Constraint with Rising and Falling Active Edges
pin(T) {
timing() {
timing_type : non_seq_setup_falling;
related_pin : ”S”;
}
}
Figure 10-9 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 intrinsic_rise value describes setup time C or hold time B. The intrinsic_fall value
describes setup time A or hold time D.
Timing Arcs
10-58
Figure 10-9 Nonsequential Setup and Hold Constraints
A C
Enable
Data
B D

Setting Recovery and Removal 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 inactive during this time or an incorrect
value might appear at the outputs.
Timing Arcs
10-59
Figure 10-10 shows the recovery timing arc for a positive edge-triggered flip-flop with
active-low clear.
Figure 10-10 Recovery Timing Constraint for a Positive Edge-Triggered Flip-Flop
Clock
Clear
A = clear to clock recovery time
Figure 10-11 shows the recovery timing arc for a low-enable latch with active-high preset.
Figure 10-11 Recovery Timing Constraint for a Low-Enable Latch
A
Enable
Preset
A = clear to clock recovery time
To define a recovery time constraint for an asynchronous control pin,

recovery_rising
Uses the rising edge of the related pin for the recovery time check; the clock is
positive edge-triggered. Use recovery_rising for positive edge-triggered flip-flops
and low-enable latches.
recovery_falling
Uses the falling edge of the related pin for the recovery time check; the clock is
negative edge-triggered. Use recovery_falling for negative edge-triggered flip-
flops and high-enable latches.
2. Identify the synchronous clock pin as the related_pin.
Timing Arcs
10-60
3. For active-low control signals, define the recovery time with the intrinsic_rise
statement. For active-high control signals, define the recovery time with the
intrinsic_fall statement.
Example 10-20 shows a recovery timing arc for the active-low clear signal in a positive
edge-triggered flip-flop. The intrinsic_rise value represents clock recovery time A in
Figure 10-10.
Example 10-20 Recovery Timing Arc for Active-Low Clear Signal

pin (Clear) {
direction : input ;
capacitance : 1 ;
timing() {
timing_type : recovery_rising;
}
}
Example 10-21 shows a recovery timing arc for the active-high preset signal in a low-
enable latch. The intrinsic_fall value represents clock recovery time A in Figure 10-11.
Example 10-21 Recovery Timing Arc for Active-High Preset

pin (Preset) {
direction : input ;
capacitance : 1 ;
timing() {
timing_type : recovery_rising;
}
}
Removal Constraint
The removal constraint describes the minimum allowable time between the active edge
of the clock pin while the asynchronous pin is active and the inactive edge of the same
asynchronous control pin (see Figure 10-12).
This constraint is also known as the asynchronous control signal hold time.
Timing Arcs
10-61
Figure 10-12 Timing Diagram for Removal Constraint
removal
SET
CK1
(ref)
To define a removal constraint,
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.
2. Identify the synchronous clock pin as the related_pin.
3. For active-low asynchronous control signals, define the removal time with the
intrinsic_rise attribute.
For active-high asynchronous control signals, define the removal time with the
intrinsic_fall attribute.
Example:
pin ( SET ) {
....
timing() {
timing_type : removal_rising;
related_pin : ” CK1 ”;
}
}
Timing Arcs
10-62
Setting No-Change Timing Constraints
A no-change timing check checks a constrained signal against
• A level-sensitive related signal (which must remain stable during an established

setup period)
• The width of the related pulse
• 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 and write operations, the address or data
must remain stable during a read or write enable pulse and the setup and hold margins
around the pulse.
Figure 10-13 shows a no-change timing check between a constrained pin and its level-
sensitive related pin.
Figure 10-13 No-Change Timing Check
No-change setup period
Constrained pin
Related pin
No-change hold period
Entire no-change region
Timing Arcs
10-63
To model no-change timing constraints,

nochange_high_high
This value specifies a positive pulse on the constrained pin and a positive pulse
on the related pin.
nochange_high_low
This value specifies a positive pulse on the constrained pin and a negative pulse
on the related pin.
nochange_low_high
This value specifies a negative pulse on the constrained pin and a positive pulse
on the related pin.
nochange_low_low
This value specifies a negative pulse on the constrained pin and a negative pulse
on the related pin.
2. 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. The final _high or _low
designation in the timing_type attribute indicates which pulse of the related pin is
active for the setup or hold constraint.
3. Specify delay attribute values according to the delay model you use as shown in
Table 10-4.
Figure 10-14 shows the waveforms for these constraints.
Timing Arcs
10-64
Figure 10-14 No-Change Setup and Hold Constraint Waveforms
A B C D
Constrained pin
Related pin
E F G H
Setup Hold
nochange_high_high A E
nochange_high_low B F
nochange_low_high C G
nochange_low_low D H
Note: With no-change timing constraints, conditional timing constraints have

different interpretations than they do with other constraints. See “Setting
Conditional Timing Constraints” later in this chapter for more information.
Table 10-4 Delay Attributes for No-Change Constraints

No-Change Constraint Setup Attribute Hold Attribute
Linear Delay / Nonlinear Delay Linear Delay / Nonlinear Delay
nochange_high_high intrinsic_rise / rise_constraint intrinsic_fall / fall_constraint
nochange_high_low intrinsic_rise / rise_constraint intrinsic_fall / fall_constraint
nochange_low_high intrinsic_fall / fall_constraint intrinsic_rise / rise_constraint
nochange_low_low intrinsic_fall / fall_constraint intrinsic_rise / rise_constraint
In the CMOS Linear Delay Model

In the CMOS linear delay model, specify setup time with intrinsic_rise and hold time with
intrinsic_fall.
Timing Arcs
10-65
This is the syntax for the no-change timing check in the CMOS linear delay model:
timing () {
timing_type : nochange_high_high | nochange_high_low |
nochange_low_high | nochange_low_low;
related_pin : name;
intrinsic_rise : float;
intrinsic_fall : float;
}

In the CMOS nonlinear delay model, specify setup time with rise_constraint and hold
time with fall_constraint.
This is the syntax for the no-change timing check in the CMOS nonlinear delay model:
timing () {
timing_type : nochange_high_high | nochange_high_low |
nochange_low_high | nochange_low_low;
related_pin : related_pinname;
rise_constraint (template) { /* constrained signal rising */
values (float, ..., float);
}
fall_constraint (template) { /* constrained signal falling */
values (float, ..., float);
}
}
This is an example of a no-change timing check in a technology library using the CMOS
nonlinear delay model:
library (the_lib) {
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;
related_pin : CLK;
rise_constraint (scalar) { /* setup time */
values (2.98);
Timing Arcs
10-66
}
fall_constraint (scalar) { /* hold time */
values (0.98);
}
...
}
...
}
...
}
...
}
Setting Skew Constraints
Skew constraints define the maximum separation time allowed between two clock
signals.
Figure 10-15 is a timing diagram showing skew constraint.
Figure 10-15 Timing Diagram for Skew Constraint
CK1
(ref)
CK2
CK1 fall to CK2 CK1 fall to CK2

rise skew fall skew
To set skew constraints,
1. Assign one of the following values to the timing_type attribute:
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.
Timing Arcs
10-67
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.
2. Define only one of these attributes in the timing group:
intrinsic_rise
When used with skew_rising, this value is the maximum skew time between
the reference pin rising to the parent pin rising. When used with skew_falling,
this value is the maximum skew time between the reference pin falling to the
parent pin rising.
intrinsic_fall
When used with skew_rising, this value is the maximum skew time between
the reference pin rising to the parent pin falling. When used with skew_falling,
this value is the maximum skew time between the reference pin falling to the
parent pin falling.
3. Use the related_pin attribute in the timing group to specify a reference clock pin.
Note: Only the timing_type, intrinsic_rise, intrinsic_fall, and related_pin

attributes belong in a skew timing group (all others are ignored).
This example shows how to model constraint CK1 rise to CK2 rise skew:
pin (CK2) {
....
timing() {
timing_type : skew_rising;
related_pin : ” CK1 ”;
}
}
Setting Conditional Timing Constraints
A conditional timing constraint describes a timing check that should be made 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:
• when attribute
• sdf_cond attribute
Timing Arcs
10-68
• when_start attribute
• sdf_cond_start attribute
• when_end attribute
• sdf_cond_end attribute
• sdf_edges attribute
• min_pulse_width group
• minimum_period group
when and sdf_cond Attributes

The when attribute defines enabling conditions for timing checks such as setup, hold,
and recovery.
Note: If you define when, you must define sdf_cond.
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.
The “Describing State-Dependent Delays” section earlier in this chapter describes the
sdf_cond and when attributes in defining state-dependent timing arcs.
when_start Attribute
In a timing group, when_start defines a timing check condition specific to a start event.
The expression in this attribute can contain any pin, including input, output, inout, and
internal pins. You must use real pin names. Bus and bundle names are not allowed.
Syntax:
when_start : ”Boolean expression” ;
Boolean expression
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
not when_end.
Timing Arcs
10-69
sdf_cond_start Attribute
In a timing group, sdf_cond_start defines a timing check condition specific to a start
event in OVI SDF 2.1 syntax.
Syntax:
sdf_cond_start : ”SDF expression” ;
SDF expression
An SDF expression containing names of input, output, inout, and internal pins.
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 not sdf_cond_end.
when_end Attribute
In a timing group, when_end defines a timing check condition specific to an end event.
The expression in this attribute can contain any pin, including input, output, inout, and
internal pins. You must use real pin names. Bus and bundle names are not allowed.
Syntax:
when_end : ”Boolean expression” ;
Boolean expression
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
not when_start.
Timing Arcs
10-70
sdf_cond_end Attribute
In a timing group, sdf_cond_end defines a timing check condition specific to an end
event in OVI SDF 2.1 syntax.
Syntax:
sdf_cond_end : ”SDF expression” ;
SDF expression
An SDF expression containing names of input, output, inout, and internal pins.
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 not sdf_cond_start.
sdf_edges Attribute
The sdf_edges attribute defines edge-specific information for both start pins and end
pins.
Syntax:
sdf_edges : sdf_edge_type;
sdf_edge_type
One of these four edge types: noedge, start_edge, end_edge, or both_edges. The
default is noedge.
Example:
sdf_edges : both_edges;
min_pulse_width Group
In a pin, bus, or bundle group, min_pulse_width models the enabling conditional
minimum pulse width check. The attributes in this group are constraint_high,
constraint_low, when, and sdf_cond.
Timing Arcs
10-71
Syntax:
pin() {
. . .
min_pulse_width() {
constraint_high : value ;
constraint_low : value ;
when : ”Boolean expression” ; /* enabling condition */
sdf_cond : ”Boolean expression” ; /* in SDF syntax */
}
}
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 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.
Syntax:
constraint_high : value ;
constraint_low : value ;
value
A nonnegative number.

These attributes define the enabling condition for the check.The sdf_cond is expressed
in OVI SDF 2.1 syntax. Both attributes are required in this group. All pins of the cell
(input, output, inout, or internal) can be used with the when attribute.
Timing Arcs
10-72
minimum_period Group
In a pin, bus, or bundle group, minimum_period models the enabling conditional
minimum period check. The attributes in this group are constraint, when, and sdf_cond.
Syntax:
minimum_period() {
constraint : value ; /* min_period */
when : ”Boolean expression” ; /* enabling condition */
sdf_cond : ”Boolean expression” ;
}
Example:
minimum_period() {
constraint : 9.5; /* min_period */
when : ”SE”;
sdf_cond : ”SE == 1’B1”;
}
constraint Attribute
The constraint attribute defines the minimum clock period required for the pin. This
attribute is required.

These attributes define the enabling condition for the check. The sdf_cond is expressed
in OVI SDF 2.1 syntax. Both attributes are required in this group. All pins of the cell
(input, output, inout, or internal) can be used with the when attribute.
Using Conditional Attributes with No-Change Constraints

Conditional timing check attributes have different interpretations when you use them
with no-change timing constraints, as shown in Table 10-5. See “Setting No-Change
Timing Constraints” earlier in this chapter for a description of no-change timing constraint
values.
Timing Arcs
10-73
Table 10-5 Conditional Timing Attributes with No-Change Constraints
Conditional Attributes With No-Change Constraints
when Defines both constrained and related signal-enabling condition.
sdf_cond
when_start Defines the constrained signal-enabling condition.
sdf_cond_start
when_end Defines the related signal-enabling condition.
sdf_cond_end
sdf_edges start_edge adds edge specification to the constrained signal, end_edge
adds edge specification to the related signal, both_edges specifies edges
to both signals, noedge specifies edges to neither signal.
Figure 10-16 shows the different interpretation of setup and hold conditions when used
with a no-change timing constraint.
Figure 10-16 Interpretation of Conditional Timing Constraints with No-Change
Start condition Setup Hold

start condition end condition
Constrained pin Data pin
Related pin Clock pin
End condition Setup Hold

end condition start condition
Examples of Libraries Using Delay Models
This section contains examples of libraries using these delay models: CMOS linear
delay, CMOS piecewise linear delay, and CMOS nonlinear delay.

In the CMOS D flip-flop description in Example 10-22, pin D contains setup and hold
constraints; pins Q and QN contain preset, clear, and edge-sensitive arcs.
Timing Arcs
10-74
Example 10-22 D Flip-Flop Description
library (example){
delay_model : generic_cmos;
technology (cmos);
cell( DFLOP_CLR_PRE ) {
area : 11 ;
ff ( IQ , IQN ) {
clocked_on : ” CLK ”;
next_state : ” D ”;
clear : ” CLR’ ” ;
preset : ” PRE’ ” ;
}
pin ( D ){
direction : input;
capacitance : 1 ;
timing () {
}
timing (){
}
}
pin ( CLK ){
direction : input;
capacitance : 1 ;
}
pin ( PRE ) {
direction : input ;
capacitance : 2 ;
}
pin ( CLR ){
direction : input ;
capacitance : 2 ;
}
pin ( Q ) {
direction : output;
timing () {
Timing Arcs
10-75
slope_rise : 1.0 ;
}
timing (){
slope_fall : 0.8 ;
}
timing (){
}
}
pin ( QN ){
timing (){
slope_fall : 1.2 ;
}
timing (){
slope_rise : 1.0 ;
}
timing (){
}
}
}
}
Timing Arcs
10-76
In the CMOS piecewise linear D flip-flop description shown in Example 10-23, pin D
contains setup and hold constraints; pins Q and QN contain preset, clear, and edge-
sensitive arcs.
Example 10-23 D Flip-Flop Description (Piecewise Linear Delay Model)

library (example){
delay_model : generic_cmos;
technology (cmos);
piece_define(”0,15,40”);
area : 11 ;
ff ( IQ , IQN ) {
}
pin ( D ){
direction : input;
capacitance : 1 ;
timing () {
}
timing (){
}
}
pin ( CLK ){
direction : input;
capacitance : 1 ;
}
pin ( PRE ) {
direction : input ;
capacitance : 2 ;
}
pin ( CLR ){
direction : input ;
capacitance : 2 ;
}
Timing Arcs
10-77
pin ( Q ) {
direction : output;
timing () {
rise_delay_intercept (0,0.054); /* piece 0 */
rise_delay_intercept (2,-0.062); /* piece 2 */
rise_pin_resistance (0,0.25); /* piece 0 */
rise_pin_resistance(1,0.50); /* piece 1 */
}
timing (){
fall_delay_intercept (0,1.0); /* piece 0 */
fall_delay_intercept (2,-1.0); /* piece 2 */
fall_pin_resistance (0,0.25); /* piece 0 */
}
timing (){
}
}
pin ( QN ){
timing (){
fall_delay_intercept (2,-1.0); /* piece 2 */
Timing Arcs
10-78
}
timing (){
rise_delay_intercept (2,-0.062); /* piece 2 */
rise_pin_resistance(1,0.50); /* piece 1 */
}
timing (){
}
}
}
CMOS Nonlinear Delay Model

In the nonlinear library description in Example 10-24, pin D contains setup and hold
constraints; pins Q and QN contain preset, clear, and edge-sensitive arcs.
Example 10-24 D Flip-Flop Description (CMOS Nonlinear Delay Model)

library (NLDM){
technology (cmos);
/* Define template of size 2 x 2*/
lu_table_template(cell_template) {
index_1 (”0.0, 1.5”);
index_2 (”0.0, 4.0”);
}
Timing Arcs
10-79
/* Define one-dimensional lu_table of size 4 */
lu_table_template(tran_template) {
index_1 (”0.0, 0.5, 1.5, 2.0”);
}
area : 11 ;
ff ( IQ , IQN ) {
}
pin ( D ){
direction : input;
capacitance : 1 ;
timing () {
rise_constraint(scalar) {
values(”0.12”);
}
fall_constraint(scalar) {
values(”0.29”);
}
}
timing (){
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 ;
}
Timing Arcs
10-80
pin ( Q ) {
direction : output;
timing () {
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 (){
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 (){
values(”0.00, 0.25”, ”0.11, 0.28”);
}
values(”0.01, 0.08, 0.15, 0.40”);
}
values(”0.00, 0.33”, ”0.11, 0.38”);
}
values(”0.01, 0.11, 0.18, 0.40”);
}
}
}
pin ( QN ){
timing (){
values(”0.00, 0.23”, ”0.11, 0.28”);
}
Timing Arcs
10-81
values(”0.01, 0.12, 0.15, 0.40”);
}
}
timing (){
values(”0.00, 0.23”, ”0.11, 0.28”);
}
values(”0.01, 0.12, 0.15, 0.40”);
}
}
timing (){
values(”0.00, 0.25”, ”0.11, 0.28”);
}
values(”0.01, 0.08, 0.15, 0.40”);
}
values(”0.00, 0.33”, ”0.11, 0.38”);
}
values(”0.01, 0.11, 0.18, 0.40”);
}
}
}
}
}
Timing Arcs
10-82
11
Interface Timing of Complex Sequential
Blocks 1
This chapter describes the procedure and the methodology for specifying the static
timing of complex sequential blocks modeled as black boxes in a design.
Interface timing specification (ITS) applies only to ASIC libraries containing sequential
blocks that are modeled as black boxes. It does not apply to combinational cells or simple
sequential cells such as latches and flip-flops.
These interface timing concepts are described in this chapter:
• Interface timing specification

• Describing blocks with interface timing
Interface Timing Specification
The ITS of a sequential block describes the static timing of a block as seen from the
outside. Because the block is treated as a black box, internal structures need not be
specified. The ITS does not include the timing of the internal paths of the block, which
are assumed to have been verified when the block was built.
Interface Timing of Complex Sequential Blocks

11-1
A complex sequential block contains more than one sequential device. Example blocks
include RAMs and hard macros, such as the TAP controller circuit in JTAG. The block
can have more than one driving clock for which you specify input constraints and output
delays.
Figure 11-1 is an example of the interface timing of a complex block.
Figure 11-1 Interface Timing of a Complex Block
clock
tI1s tI1h
I1
tI2s
tI2h
I2
tdout1
dout1
tdout2
dout2
In Figure 11-1,
• Input I1 has a setup constraint with respect to the falling edge of the clock and a
hold constraint with respect to the rising edge of the clock.
• The setup constraints for inputs I1 and I2 are specified with respect to different
edges of the clock.
• Output data dout1 is propagated on the rising edge of the clock. Output data dout2
is propagated on the falling edge of the clock.

11-2
Sequential Cell Timing without ITS
In static timing, a sequential cell contains one or more edge-triggered flip-flops (rising
or falling edge) or level-sensitive latches (negative or positive level). When functional
information is not available during synthesis, the function is inferred from the timing
relationships specified in the cell description. Cells are classified as follows:
• As a simple edge-triggered device if the setup arc and the output delay arc are
specified for the same clock edge
• As a master-slave device if the setup arc and the output delay arc are specified for
different edges of the clock
• As a level-sensitive device if the cell has at least one output that combines a
combinational arc from a data input and a sequential arc from a clock
With these classifications, some of the timing information specified in the library is
ignored. For example, if a cell is classified as a rising edge-triggered device, the hold
constraint on the rising edge is checked even if this constraint is specified for the falling
edge of the clock.
Specifying Interface Timing

The interface timing capability supports the timing of complex sequential blocks without
any assumptions about their underlying structure. During synthesis, timing relationships
are interpreted according to a well-defined set of rules, in which each relationship is
interpreted independently of other relationships.
Note: Interface timing is not used for complex combinational blocks, whose
timing is described by pin-to-pin delays.
With interface timing, the following rules apply:
• Functionality must be a black box.

Cells with interface timing are strictly black boxes in terms of functionality. In other
words, the function attribute must not be specified for any output pin of the cell. In
addition, the cell group cannot contain an ff group.
• Cells with interface timing must have at least one clock pin.
Multiple clock signals are supported. A block can have one or more clock inputs
with different waveforms for each clock.

11-3
• An input pin can have at most one setup arc and one hold arc with respect to any
given clock pin.
You can specify the setup and hold relationships with respect to either the rising
edge or the falling edge of the clock. Note that an input pin can have setup or hold
constraints specified with respect to several clock pins.
• Clock-to-output timing arcs must have the timing_type attribute set to rising_edge
or falling_edge.
• For input-to-output arcs, the timing_type attribute must be set to combinational,
preset, or clear. These arcs can be specified with respect to nonclock inputs only.
Note that an output pin can combine several arcs from clock pins, data input pins,
or asynchronous set or clear inputs.
• For input-to-clock arcs, the following timing_type values are valid:
- recovery_rising or recovery_falling
- removal_rising or removal_falling
- setup_rising or setup_falling
- hold_rising or hold_falling
• A control input can have recovery or removal arcs specified with respect to one or
more clocks.
• You can specify propagation delays with respect to the rising or falling edges of one
or more clocks.
An output pin can have a propagation delay specified with respect to the falling or
rising edge of any clock. One output can have several propagation delays specified
with respect to several clock inputs.
• Combinational delay can be specified with respect to one or more data inputs.
An output pin can have a delay arc from one or more inputs. This arc can coexist
with other arcs from clock inputs and can be a regular delay arc, an asynchronous
reset, or a clear arc. Regular delay arcs include combinational arcs.
• Timing properties of clocks, such as minimum period and minimum pulse width,
can be specified in the same way that they are specified for regular library cells.
Using the interface timing capability for complex sequential blocks provides these
benefits:
• Higher quality results from synthesis, because timing is more accurate.

• Abstraction and information hiding (because the block is treated as a black box and
function information is not required in the cell description)

11-4
Describing Blocks with Interface Timing
This section describes how to use Liberty syntax to specify the interface timing of
complex blocks.
To specify the interface timing of complex sequential blocks in Liberty syntax:
1. Describe the block as a cell in the library and use timing group syntax to describe
the timing arcs.
2. Add this attribute and value to the cell group:
interface_timing : true;
This indicates that the timing arcs must be interpreted according to ITS semantics.
If this attribute is missing or its value is false, the timing relationships are interpreted
as those of a regular cell rather than according to ITS semantics.
3. Set the clock attribute in the pin group to true for all the clock pins for the cell.
4. Follow the rules for specifying interface timing relationships using Liberty syntax
(as outlined in the previous section, “Specifying Interface Timing”). These rules are
enforced for all library cells in which the interface_timing attribute is set to true.
5. Associate the block with a library.
6. Use the same delay model for interface timing of a block as the one defined in its
associated library. For example, associate a block that uses the linear delay model
to specify timing arcs with a library using the linear model. Similarly, associate a
block using the nonlinear delay model with a library using the nonlinear model.
7. Use the same timing arc syntax for describing regular cells to specify the timing
arcs that describe the interface timing relationships.
Examples of Interface Timing Relationships

This section describes the various timing relationships supported by ITS. It includes an
example of a fairly complex sequential block with two clocks, four data inputs, and two
data outputs.

11-5
Input Setup and Hold
A data input can have a setup or hold constraint specified with respect to the rising or
falling edge of any clock input. Figure 11-2 shows a data input with the setup constraint
specified with respect to the rising edge of the clock and the hold constraint specified
with respect to the falling edge of the clock.
Figure 11-2 Data Input with Specified Setup Constraint
clock
tds tdh
data
Example 11-1 shows the description of these relationships in Liberty syntax.
Example 11-1 Description of Timing Relationships in Figure 11-2

pin (I2) {
timing () {
intrinsic_rise : 2.20; /* tds */
related_pin : “clock”;
}
timing () {
intrinsic_rise : 0.95; /* tdh */
related_pin : “clock”;
}
}
Output Propagation
Output delay can be specified with respect to the rising or falling edge of the clock. Figure
11-3 shows the output section of a block. Output O1 is propagated on the rising edge
of the clock, while output O2 is propagated on the falling edge.

11-6
Figure 11-3 Output Section of a Macro Block
comb Q comb O1
clk
comb
Q comb O2
clock clk
Figure 11-4 shows the interface timing relationships for the two outputs.
Figure 11-4 Output Timing Relationships for the Block in Figure 11-3
clock
tO2d
O2
tO1d
O1
Example 11-2 shows the Liberty description of the relationships in Figure 11-4.
Example 11-2 Description of Relationships in Figure 11-4

pin(O1){
direction : output;
timing () {
timing_type : rising_edge; /*sequential delay arc */
intrinsic_rise : 2.25; /* tO1d */
related_pin : ”clock”;
}
}

11-7
pin(O2){
direction : output;
timing () {
timing_type : falling_edge; /*sequential delay arc */
intrinsic_rise : 3.15; /* tO2d */
related_pin : ”clock”;
}
}
Through Combinational Paths

An output of a sequential block can have a propagation delay specified with respect to
a nonclock input. This relationship indicates the existence of a direct combinational path
between the output and the input. The output will always change (after some delay)
when the input changes. Figure 11-5 shows such a case.
Figure 11-5 Timing Relationships for Through Combinational Paths
address
tacc
data
Example11-3 shows the Liberty description of the relationships in Figure 11-5.
Example 11-3 Description of Relationships in Figure 11-5

bus(address){
direction : input;
}
bus(data){
direction : output;
timing () {
intrinsic_rise : 8.15; /* tacc */
related_pin : ”address”;
}
}

11-8
Interface Timing of a Complex Sequential Block
Figure 11-6 shows the internal structure of a complex block containing sequential and
combinational logic. Note that the input constraints for the sequential elements in the
circuit are specified with respect to both edges of the clock.
Figure 11-6 Complex Sequential Block Supported by ITS
I1 comb O1
logic
I2
comb D Q
I3
clk
clk1 O2
D Q
comb
I3 D Q
comb clk
I4
clk
clk2
Figure 11-7 is the timing diagram illustrating the various interface relationships of this
block.

11-9
Figure 11-7 Timing Relationships for the Circuit in Figure 11-6
clk1
tI2s tI2h
I2
tI3s
tI3h
I3
tI3h1
O2 tI3s1
tclk2d
clk2
tI4h
tI4s
I4
I1
tclk1d
tI1d
O1
In Figure 11-7,
• The block has two clock pins, clk1 and clk2.

• Input I2 has a setup constraint with respect to the rising edge of clk1 and a hold
constraint with respect to the falling edge of the same clock.
• Input I3 has setup and hold constraints specified with respect to both clocks (rising
for clk2 and falling for clk1).
• Output O1 is propagated on the falling edge of clk1, while output O2 is propagated
on the rising edge of clk2.
• Output O1 combines a combinational path from I1 and a sequential path from clk1.

11-10
Example 11-4 shows the library description of interface timing specification of the block
shown in Figure 11-6. The CMOS delay model is used for this cell.
Example 11-4 Description of the Interface Timing in Figure 11-7

cell (XR_2120) {
area : 100.000000;
pin (I1) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
}
pin (I2) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
intrinsic_rise : 2.20; /* tI2s */
related_pin : “clk1”;
}
timing () {
intrinsic_rise : 0.95; /* tI2h */
}
}
pin (I3) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
timing () {
intrinsic_rise : 0.70; /* tI3s1 */
}

11-11
timing () {
intrinsic_rise : 2.95; /* tI3h1 */
}
}
pin (I4) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
pin (clk1) {
direction : input;
capacitance : 1.13;
fanout_load : 1.13;
clock : true; /* clock pins must be labeled as such */
}
pin (clk2) {
direction : input;
capacitance : 1.13;
fanout_load : 1.13;
clock : true; /* clock pins must be labeled as such */
}
pin (O1){
direction : output;
timing () {
timing_sense : non_unate;/* comb. delay arc */
intrinsic_rise : 3.25; /* tI1d */
related_pin : “I1”;
}
timing () {

11-12
timing_type : falling_edge;/* sequential delay arc */
intrinsic_rise : 1.25; /* tclk1d */
}
}
pin (O2){
direction : output;
timing () {
timing_type : rising_edge; /*sequential delay arc */
intrinsic_rise : 2.25; /* tclk2d */
}
}
} /* end cell */
RAM Example Using ITS
This example shows how to specify the interface timing of a typical RAM using ITS.
Figure 11-8 and Figure 11-9 show the timing relationships of the read and write cycles
of the RAM.
Figure 11-8 Read Cycle Timing of the RAM (WR = 1)
address
tacc
data_out

11-13
Figure 11-9 Write Cycle Timing of the RAM (WR = 0)
WR
tads tadh
address
tdins
tdinh
data_in
Example 11-5 describes the Liberty model of the RAM. Note that the delay between the
output data and the address in the read cycle is modeled as a combinational delay, and
that the WR signal is labeled as a clock.
Example 11-5 Liberty Model of RAM in Figure 11-8 and Figure 11-9
cell (RAM_10_8) {
area : 2300.000000;
interface_timing : TRUE; /* Apply interface timing semantics */
bus (address) {
bus_type : ”bus10”; /* defined in the library */
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
}
timing () {
}
}
bus (data_in) {
direction : input;
capacitance : 1.46;
fanout_load : 1.46;
timing () {
intrinsic_rise : 1.50; /* tdis */

11-14
}
timing () {
intrinsic_rise : 0.65; /* tdih */
}
}
pin (WR) {
direction : input;
capacitance : 1.13;
fanout_load : 1.13;
clock : true; /* WR pulse is modeled as a clock */
}
bus(data_out){
direction : output;
timing () {
related_bus_pin : ”address”;
}
}
} /* end cell */

11-15
11-16
A
Technology Library Attributes 1
Appendix A is a table containing an alphabetized list of all the attributes in a technology
library. Some attributes are considered reserved words and are denoted by an asterisk
(*). Reserved words are defined in the Synopsys Library Compiler tool and can be used
to pass information to other Synopsys tools.
Note: This manual does not provide syntax or examples for reserved words.
How to Use the Table

Information in the table includes, from left to right,
• Attribute name (reserved words are preceded by an asterisk)

• Attribute type
- S = Simple. In syntax and examples, the attribute name and values are separated
by a colon (:) with a space on either side of the colon.
- C = Complex. Values are enclosed in parentheses, and there is no colon between
the attribute name and values.
- G = Group statement. A group contains other attributes, which can be simple,
complex, or other groups.
Technology Library Attributes

A-1
• Group in which the attribute is defined.
• Level at which the attribute is defined—at the library level (L) or
within a cell (C).
• CMOS delay models that use the attribute.
- SDM = CMOS Standard (Linear) Delay Model
- PWL = CMOS Piecewise Linear Delay Model
- NLDM = CMOS Nonlinear Delay Model
- CMOS = CMOS2 Delay Model
Table A -1 Technology Library Attributes

Attribute T Group L CMOS Delay Models
y e
p v
e e
l
SDM PWL NLDM CMOS
A
address S memory_read C X X X X
address S memory_write C X X X X
address_width S memory C X X X X
area S cell C X X X X
area S scaled_cell L X X X X
area S wire_load L X X X X
auxiliary_pad_cell S cell C X X X X
auxiliary_pad_cell S scaled_cell L X X X X
B
base_type S type C X X X X
base_type S type L X X X X
bit_from S type C X X X X
bit_from S type L X X X X
bit_to S type C X X X X
bit_to S type L X X X X
bit_width S type C X X X X
bit_width S type L X X X X
bit_width S pin C X X X X
bundle G cell C X X X X
bundle G scaled_cell L X X X X

A-2
y e
p v
e e
l
SDM PWL NLDM CMOS
bus G cell C X X X X
bus G scaled_cell L X X X X
bus_naming_style S cell C X X X X
bus_naming_style S library L X X X X
bus_naming_style S scaled_cell L X X X X
bus_type S bus C X X X X
C
capacitance S bundle C X X X X
capacitance S bus C X X X X
capacitance S pin C X X X X
capacitance S wire_load L X X X X
capacitive_load_unit C library L X X X X
cell G library L X X X X
cell_degradation G timing C X
cell_fall G timing C X
*cell_footprint S cell C X X X X
*cell_footprint S scaled_cell L X X X X
cell_leakage_power S cell C X X X X
cell_leakage_power S scaled_cell L X X X X
cell_rise G timing C X
clear S ff C X X X X
clear S ff_bank C X X X X
clear S latch C X X X X
clear S latch_bank C X X X X
clear_preset_var1 S ff C X X X X
clear_preset_var1 S ff_bank C X X X X
clear_preset_var1 S latch C X X X X
clear_preset_var1 S latch_bank C X X X X
clear_preset_var2 S ff C X X X X
clear_preset_var2 S ff_bank C X X X X
clear_preset_var2 S latch C X X X X
clear_preset_var2 S latch_bank C X X X X
clock S bundle C X X X X
clock S bus C X X X X

A-3
y e
p v
e e
l
SDM PWL NLDM CMOS
clock S pin C X X X X
clock_gate_enable_pin S pin C X X X X
clocked_on S ff C X X X X
clocked_on S ff_bank C X X X X
clocked_on S memory_write C X X X X
clocked_on_also S ff C X X X X
clocked_on_also S ff_bank C X X X X
column_address S memory C X X X X
*comment S library L X X X X
*connection_class S bundle C X X X X
*connection_class S bus C X X X X
*connection_class S pin C X X X X
constraint S minimum_period C X X X X
constraint_high S min_pulse_width C X X X X
constraint_low S min_pulse_width C X X X X
contention_condition S cell C X X X X
current_unit S library L X X X X
D
data_in S latch C X X X X
data_in S latch_bank C X X X X
data_type S type C X X X X
data_type S type L X X X X
date S library L X X X X
default_cell_leakage_power S library L X X X X
*default_connection_class S library L X X X X
default_edge_rate_breakpoint_f0 S library L X
default_edge_rate_breakpoint_f1 S library L X
default_edge_rate_breakpoint_r0 S library L X
default_edge_rate_breakpoint_r1 S library L X
default_fall_delay_intercept S library L X
default_fall_pin_resistance S library L X
default_fanout_load S library L X X X X
default_hold_coefficient S library L X

A-4
y e
p v
e e
l
SDM PWL NLDM CMOS
default_inout_pin_cap S library L X X X X
default_inout_pin_fall_res S library L X X X
default_inout_pin_rise_res S library L X X X
default_input_pin_cap S library L X X X X
default_intrinsic_fall S library L X X X
default_intrinsic_rise S library L X X X
default_max_capacitance S library L X X X X
default_max_fanout S library L X X X X
default_max_transition S library L X X X X
default_max_utilization S library L X X X X
*default_min_porosity S library L X X X X
default_operating_conditions S library L X X X X
default_output_pin_cap S library L X X X X
default_output_pin_fall_res S library L X X X
default_output_pin_rise_res S library L X X X
default_power_rail S power_supply L X X X X
default_rc_fall_coefficient S library L X
default_rc_rise_coefficient S library L X
default_reference_capacitance S library L X
default_rise_delay_intercept S library L X
default_rise_pin_resistance S library L X
default_setup_coefficient S library L X
default_slope_fall S library L X X
default_slope_rise S library L X X
default_wire_load S library L X X X X
default_wire_load_area S library L X X X X
default_wire_load_capacitance S library L X X X X
*default_wire_load_mode S library L X X X X
default_wire_load_resistance S library L X X X X
default_wire_load_selection S library L X X X X
define_cell_area C library L X X X X
delay_model S library L X X X X
direction S bundle C X X X X
direction S bus C X X X X

A-5
y e
p v
e e
l
SDM PWL NLDM CMOS
direction S pin C X X X X
*dont_fault S bundle C X X X X
*dont_fault S bus C X X X X
*dont_fault S cell C X X X X
*dont_fault S pin C X X X X
*dont_fault S scaled_cell L X X X X
*dont_touch S cell C X X X X
*dont_touch S scaled_cell L X X X X
*dont_use S cell C X X X X
*dont_use G scaled_cell L X X X X
downto S type L X X X X
drive_current S bundle C X X X X
drive_current S bus C X X X X
drive_current S pin C X X X X
driver_type S bundle C X X X X
driver_type S bus C X X X X
driver_type S pin C X X X X
E
edge_rate_breakpoint_f0 S bundle C X
edge_rate_breakpoint_f0 S bus C X
edge_rate_breakpoint_f0 S pin C X
edge_rate_breakpoint_f1 S bundle C X
edge_rate_breakpoint_f1 S bus C X
edge_rate_breakpoint_f1 S pin C X
edge_rate_breakpoint_r0 S bundle C X
edge_rate_breakpoint_r0 S bus C X
edge_rate_breakpoint_r0 S pin C X
edge_rate_breakpoint_r1 S bundle C X
edge_rate_breakpoint_r1 S bus C X
edge_rate_breakpoint_r1 S pin C X
edge_rate_fall S bundle C X
edge_rate_fall S bus C X

A-6
y e
p v
e e
l
SDM PWL NLDM CMOS
edge_rate_fall S pin C X
edge_rate_load_fall S bundle C X
edge_rate_load_fall S bus C X
edge_rate_load_fall S pin C X
edge_rate_load_rise S bundle C X
edge_rate_load_rise S bus C X
edge_rate_load_rise S pin C X
edge_rate_rise S bundle C X
edge_rate_rise S bus C X
edge_rate_rise S pin C X
edge_rate_sensitivity_f0 S timing C X
edge_rate_sensitivity_f1 S timing C X
edge_rate_sensitivity_r0 S timing C X
edge_rate_sensitivity_r1 S timing C X
enable S latch C X X X X
enable S latch_bank C X X X X
enable S memory_write C X X X X
enable_also S latch C X X X X
enable_also S latch_bank C X X X X
equal_or_opposite_output S internal_power C X X X X
F
fall_constraint G timing C X
fall_current_slope_after_threshold S bundle C X X X X
fall_current_slope_after_threshold S bus C X X X X
fall_current_slope_after_threshold S pin C X X X X
fall_current_slope_before_threshold S bundle C X X X X
fall_current_slope_before_threshold S bus C X X X X
fall_current_slope_before_threshold S pin C X X X X
fall_delay_intercept C timing C X
fall_pin_resistance C timing C X
fall_power G internal_power C X X X X

A-7
y e
p v
e e
l
SDM PWL NLDM CMOS
fall_propagation G timing C X
fall_resistance S timing X X X
fall_time_after_threshold S bundle C X X X X
fall_time_after_threshold S bus C X X X X
fall_time_after_threshold S pin C X X X X
fall_time_before_threshold S bundle C X X X X
fall_time_before_threshold S bus C X X X X
fall_time_before_threshold S pin C X X X X
fall_transition G timing C X
fall_transition_degradation G library L X
fanout_area C wire_load_table L X X X X
fanout_capacitance C wire_load_table L X X X X
fanout_length C wire_load L X X X X
fanout_length C wire_load_table L X X X X
fanout_load S bundle C X X X X
fanout_load S bus C X X X X
fanout_load S pin C X X X X
fanout_resistance C wire_load_table L X X X X
faster_factor S timing_range L X X X X
ff G cell C X X X X
ff G scaled_cell L X X X X
ff G test_cell C X X X X
ff_bank G cell C X X X X
ff_bank G scaled_cell L X X X X
ff_bank G test_cell C X X X X
function S bundle C X X X X
function S bus C X X X X
function S pin C X X X X
G
*geometry_print S cell C X X X X

A-8
y e
p v
e e
l
SDM PWL NLDM CMOS
H
handle_negative_constraint S cell C X X X X
handle_negative_constraint S scaled_cell L X X X X
hysteresis S bundle C X X X X
hysteresis S bus C X X X X
hysteresis S pin C X X X X
I
*in_place_swap_mode S library L X X X X
index_1 C cell_fall C X
index_1 C cell_rise C X
index_1 C cell_degradation C
index_1 C fall_constraint C X
index_1 C fall_power C X X X X
index_1 C fall_propagation C X
index_1 C fall_transition C X
index_1 C fall_transition_ C X
degradation
index_1 C lu_table_template L X
index_1 C power C X X X X
index_1 C power_lut_ L X X X X
template
index_1 C rise_constraint C X
index_1 C rise_power C X X X X
index_1 C rise_propagation C X
index_1 C rise_transition C X
index_1 C rise_transition_ C X
degradation

A-9
y e
p v
e e
l
SDM PWL NLDM CMOS
index_2 C fall_transition_ C X
degradation
index_2 C power_lut_ L X X X X
template
index_2 C rise_propagation C X
index_2 C rise_transition C X
index_2 C rise_transition_ C X
degradation
index_3 C fall_transition_ L X
degradation
index_3 C power_lut_ L X
template
input_map S bundle C X X X X
input_map S bus C X X X X
input_map S pin C X X X X
input_pins S lut L
input_signal_level S bundle C X X X X
input_signal_level S bus C X X X X
input_signal_level S pin C X X X X
input_voltage S bundle C X X X X

A-10
y e
p v
e e
l
SDM PWL NLDM CMOS
input_voltage S bus C X X X X
input_voltage G library L X X X X
input_voltage S pin C X X X X
interface_timing S cell C X X X X
interface_timing S scaled_cell L X X X X
internal_node S bundle C X X X X
internal_node S bus C X X X X
internal_node S pin C X X X X
internal_power G pin C X X X X
internal_power G scaled_cell L X X X X
intrinsic_fall S timing C X X X X
intrinsic_rise S timing C X X X X
inverted_output S bundle C X X X X
inverted_output S bus C X X X X
inverted_output S pin C X X X X
is_clock_gating_cell S cell C X X X X
is_pad S bundle C X X X X
is_pad S bus C X X X X
is_pad S pin C X X X X
K
Scaling factors (k_...) appear as simple attributes at the library-group level and as simple
attributes in the scaling_factors group, also at the library level.
k_process_cell_fall S library L X
k_process_cell_fall S scaling_factors L X
k_process_cell_leakage_power S library L X X X X
k_process_cell_leakage_power S scaling_factors L X X X X
k_process_cell_rise S library L X
k_process_cell_rise S scaling_factors L X
k_process_drive_current S library L X X X X
k_process_drive_current S scaling_factors L X X X X
k_process_drive_fall S library L X X X

A-11
y e
p v
e e
l
SDM PWL NLDM CMOS
k_process_drive_fall S scaling_factors L X X X
k_process_drive_rise S library L X X X
k_process_drive_rise S scaling_factors L X X X
k_process_fall_delay_intercept S library L X
k_process_fall_delay_intercept S scaling_factors L X
k_process_fall_pin_resistance S library L X
k_process_fall_pin_resistance S scaling_factors L X
k_process_fall_propagation S library L X
k_process_fall_propagation S scaling_factors L X
k_process_fall_transition S library L X
k_process_fall_transition S scaling_factors L X
k_process_hold_fall S library L X X X X
k_process_hold_fall S scaling_factors L X X X X
k_process_hold_rise S library L X X X X
k_process_hold_rise S scaling_factors L X X X X
k_process_internal_power S library L X X X X
k_process_internal_power S scaling_factors L X X X X
k_process_intrinsic_fall S library L X X X
k_process_intrinsic_fall S scaling_factors L X X X
k_process_intrinsic_rise S library L X X X
k_process_intrinsic_rise S scaling_factors L X X X
k_process_min_period S library L X X X X
k_process_min_period S scaling_factors L X X X X
k_process_min_pulse_width_high S library L X X X X
k_process_min_pulse_width_high S scaling_factors L X X X X
k_process_min_pulse_width_low S library L X X X X
k_process_min_pulse_width_low S scaling_factors L X X X X
k_process_nochange_fall S library L X X
k_process_nochange_fall S scaling_factors L X X
k_process_nochange_rise S library L X X
k_process_nochange_rise S scaling_factors L X X
k_process_pin_cap S library L X X X X
k_process_pin_cap S scaling_factors L X X X X

A-12
y e
p v
e e
l
SDM PWL NLDM CMOS
k_process_recovery_fall S library L X X X X
k_process_recovery_fall S scaling_factors L X X X X
k_process_recovery_rise S library L X X X X
k_process_recovery_rise S scaling_factors L X X X X
k_process_removal_fall S library L X X X X
k_process_removal_fall S scaling_factors L X X X X
k_process_removal_rise S library L X X X X
k_process_removal_rise S scaling_factors L X X X X
k_process_rise_delay_intercept S library L X
k_process_rise_delay_intercept S scaling_factors L X
k_process_rise_pin_resistance S library L X
k_process_rise_pin_resistance S scaling_factors L X
k_process_rise_propagation S library L X
k_process_rise_propagation S scaling_factors L X
k_process_rise_transition S library L X
k_process_rise_transition S scaling_factors L X
k_process_setup_fall S library L X X X X
k_process_setup_fall S scaling_factors L X X X X
k_process_setup_rise S library L X X X X
k_process_setup_rise S scaling_factors L X X X X
k_process_skew_fall S library L X X X X
k_process_skew_fall S scaling_factors L X X X X
k_process_skew_rise S library L X X X X
k_process_skew_rise S scaling_factors L X X X X
k_process_slope_fall S library L X X
k_process_slope_fall S scaling_factors L X X
k_process_slope_rise S library L X X
k_process_slope_rise S scaling_factors L X X
k_process_wire_cap S library L X X X X
k_process_wire_res S library L X X X X
k_process_wire_res S scaling_factors L X X X X
k_temp_cell_fall S library L X
k_temp_cell_fall S scaling_factors L X
k_temp_cell_leakage_power S library L X X X X

A-13
y e
p v
e e
l
SDM PWL NLDM CMOS
k_temp_cell_leakage_power S scaling_factors L X X X X
k_temp_cell_rise S library L X
k_temp_cell_rise S scaling_factors L X
k_temp_drive_current S library L X X X X
k_temp_drive_current S scaling_factors L X X X X
k_temp_drive_fall S library L X X X
k_temp_drive_fall S scaling_factors L X X X
k_temp_drive_rise S library L X X X
k_temp_drive_rise S scaling_factors L X X X
k_temp_fall_delay_intercept S library L X
k_temp_fall_delay_intercept S scaling_factors L X
k_temp_fall_pin_resistance S library L X
k_temp_fall_pin_resistance S scaling_factors L X
k_temp_fall_propagation S library L X
k_temp_fall_propagation S scaling_factors L X
k_temp_fall_transition S library L X
k_temp_fall_transition S scaling_factors L X
k_temp_hold_fall S library L X X X X
k_temp_hold_fall S scaling_factors L X X X X
k_temp_hold_rise S library L X X X X
k_temp_hold_rise S scaling_factors L X X X X
k_temp_internal_power S library L X X X X
k_temp_internal_power S scaling_factors L X X X X
k_temp_intrinsic_fall S library L X X X
k_temp_intrinsic_fall S scaling_factors L X X X
k_temp_intrinsic_rise S library L X X X
k_temp_intrinsic_rise S scaling_factors L X X X
k_temp_min_period S library L X X X X
k_temp_min_period S scaling_factors L X X X X
k_temp_min_pulse_width_high S library L X X X X
k_temp_min_pulse_width_high S scaling_factors L X X X X
k_temp_min_pulse_width_low S library L X X X X
k_temp_min_pulse_width_low S scaling_factors L X X X X

A-14
y e
p v
e e
l
SDM PWL NLDM CMOS
k_temp_nochange_fall S library L X X
k_temp_nochange_fall S scaling_factors L X X
k_temp_nochange_rise S library L X X
k_temp_nochange_rise S scaling_factors L X X
k_temp_pin_cap S library L X X X X
k_temp_pin_cap S scaling_factors L X X X X
k_temp_recovery_fall S library L X X X X
k_temp_recovery_fall S scaling_factors L X X X X
k_temp_recovery_rise S library L X X X X
k_temp_recovery_rise S scaling_factors L X X X X
k_temp_removal_fall S library L X X X X
k_temp_removal_fall S scaling_factors L X X X X
k_temp_removal_rise S library L X X X X
k_temp_removal_rise S scaling_factors L X X X X
k_temp_rise_delay_intercept S library L X
k_temp_rise_delay_intercept S scaling_factors L X
k_temp_rise_pin_resistance S library L X
k_temp_rise_pin_resistance S scaling_factors L X
k_temp_rise_propagation S library L X
k_temp_rise_propagation S scaling_factors L X
k_temp_rise_transition S library L X
k_temp_rise_transition S scaling_factors L X
k_temp_setup_fall S library L X X X X
k_temp_setup_fall S scaling_factors L X X X X
k_temp_setup_rise S library L X X X X
k_temp_setup_rise S scaling_factors L X X X X
k_temp_skew_fall S library L X X X X
k_temp_skew_fall S scaling_factors L X X X X
k_temp_skew_rise S library L X X X X
k_temp_skew_rise S scaling_factors L X X X X
k_temp_slope_fall S library L X X
k_temp_slope_fall S scaling_factors L X X
k_temp_slope_rise S library L X X

A-15
y e
p v
e e
l
SDM PWL NLDM CMOS
k_temp_slope_rise S scaling_factors L X X
k_temp_wire_cap S library L X X X X
k_temp_wire_res S library L X X X X
k_volt_cell_fall S library L X
k_volt_cell_fall S scaling_factors L X
k_volt_cell_leakage_power S library L X X X X
k_volt_cell_leakage_power S scaling_factors L X X X X
k_volt_cell_rise S library L X
k_volt_cell_rise S scaling_factors L X
k_volt_drive_current S library L X X X X
k_volt_drive_current S scaling_factors L X X X X
k_volt_drive_fall S library L X X X
k_volt_drive_fall S scaling_factors L X X X
k_volt_drive_rise S library L X X X
k_volt_drive_rise S scaling_factors L X X X
k_volt_fall_delay_intercept S library L X
k_volt_fall_delay_intercept S scaling_factors L X
k_volt_fall_pin_resistance S library L X
k_volt_fall_pin_resistance S scaling_factors L X
k_volt_fall_propagation S library L X
k_volt_fall_propagation S scaling_factors L X
k_volt_fall_transition S library L X
k_volt_fall_transition S scaling_factors L X
k_volt_hold_fall S library L X X X X
k_volt_hold_fall S scaling_factors L X X X X
k_volt_hold_rise S library L X X X X
k_volt_hold_rise S scaling_factors L X X X X
k_volt_internal_power S library L X X X X
k_volt_internal_power S scaling_factors L X X X X
k_volt_intrinsic_fall S library L X X X
k_volt_intrinsic_fall S scaling_factors L X X X
k_volt_intrinsic_rise S library L X X X
k_volt_intrinsic_rise S scaling_factors L X X X

A-16
y e
p v
e e
l
SDM PWL NLDM CMOS
k_volt_min_period S library L X X X X
k_volt_min_period S scaling_factors L X X X X
k_volt_min_pulse_width_high S library L X X X X
k_volt_min_pulse_width_high S scaling_factors L X X X X
k_volt_min_pulse_width_low S library L X X X X
k_volt_min_pulse_width_low S scaling_factors L X X X X
k_volt_nochange_fall S library L X X
k_volt_nochange_fall S scaling_factors L X X
k_volt_nochange_rise S library L X X
k_volt_nochange_rise S scaling_factors L X X
k_volt_pin_cap S library L X X X X
k_volt_pin_cap S scaling_factors L X X X X
k_volt_recovery_fall S library L X X X X
k_volt_recovery_fall S scaling_factors L X X X X
k_volt_recovery_rise S library L X X X X
k_volt_recovery_rise S scaling_factors L X X X X
k_volt_removal_fall S library L X X X X
k_volt_removal_fall S scaling_factors L X X X X
k_volt_removal_rise S library L X X X X
k_volt_removal_rise S scaling_factors L X X X X
k_volt_rise_delay_intercept S library L X
k_volt_rise_delay_intercept S scaling_factors L X
k_volt_rise_pin_resistance S library L X
k_volt_rise_pin_resistance S scaling_factors L X
k_volt_rise_propagation S library L X
k_volt_rise_propagation S scaling_factors L X
k_volt_rise_transition S library L X
k_volt_rise_transition S scaling_factors L X
k_volt_setup_fall S library L X X X X
k_volt_setup_fall S scaling_factors L X X X X
k_volt_setup_rise S library L X X X X
k_volt_setup_rise S scaling_factors L X X X X
k_volt_skew_fall S library L X X X X
k_volt_skew_fall S scaling_factors L X X X X

A-17
y e
p v
e e
l
SDM PWL NLDM CMOS
k_volt_skew_rise S library L X X X X
k_volt_skew_rise S scaling_factors L X X X X
k_volt_slope_fall S library L X X
k_volt_slope_fall S scaling_factors L X X
k_volt_slope_rise S library L X X
k_volt_slope_rise S scaling_factors L X X
k_volt_wire_cap S library L X X X X
k_volt_wire_cap S scaling_factors L X X X X
k_volt_wire_res S library L X X X X
k_volt_wire_res S scaling_factors L X X X X
L
latch G cell C X X X X
latch G scaled_cell L X X X X
latch G test_cell C X X X X
latch_bank G cell C X X X X
latch_bank G scaled_cell L X X X X
latch_bank G test_cell C X X X X
leakage_power G cell C X X X X
leakage_power_unit S library L X X X X
*library_features C library L X X X X
lu_table_template G library L X
lut G cell C
lut G scaled_cell L
M
map_only S cell C X X X X
map_only S scaled_cell L X X X X
max_capacitance S bundle C X X X X
max_capacitance S bus C X X X X
max_capacitance S pin C X X X X
max_fanout S bundle C X X X X
max_fanout S bus C X X X X
max_fanout S pin C X X X X

A-18
y e
p v
e e
l
SDM PWL NLDM CMOS
max_transition S bundle C X X X X
max_transition S bus C X X X X
max_transition S pin C X X X X
members C bundle C X X X X
memory G cell C X X X X
memory G scaled_cell L X X X X
memory_read G bundle C X X X X
memory_read G bus C X X X X
memory_read G pin C X X X X
memory_write G bundle C X X X X
memory_write G bus C X X X X
memory_write G pin C X X X X
min_capacitance S bundle C X X X X
min_capacitance S bus C X X X X
min_capacitance S pin C X X X X
min_fanout S bundle C X X X X
min_fanout S bus C X X X X
min_fanout S pin C X X X X
min_period S bundle C X X X X
min_period S bus C X X X X
min_period S pin C X X X X
min_pulse_width G bundle C X X X X
min_pulse_width G bus C X X X X
min_pulse_width G pin C X X X X
min_pulse_width_high S bundle C X X X X
min_pulse_width_high S bus C X X X X
min_pulse_width_high S pin C X X X X
min_pulse_width_low S bundle C X X X X
min_pulse_width_low S bus C X X X X
min_pulse_width_low S pin C X X X X
min_transition S bundle C X X X X
min_transition S bus C X X X X
min_transition S pin C X X X X
minimum_period G bundle C X X X X
minimum_period G bus C X X X X

A-19
y e
p v
e e
l
SDM PWL NLDM CMOS
minimum_period G pin C X X X X
*multicell_pad_pin S bundle C X X X X
*multicell_pad_pin S bus C X X X X
*multicell_pad_pin S pin C X X X X
N
next_state S ff C X X X X
next_state S ff_bank C X X X X
nextstate_type S bundle C X X X X
nextstate_type S bus C X X X X
nextstate_type S pin C X X X X
nom_process S library L X X X X
nom_temperature S library L X X X X
nom_voltage S library L X X X X
O
operating_conditions G library L X X X X
output_signal_level S bundle C X X X X
output_signal_level S bus C X X X X
output_signal_level S pin C X X X X
output_voltage S bundle C X X X X
output_voltage S bus C X X X X
output_voltage G library L X X X X
output_voltage S pin C X X X X
P
pad_cell S cell C X X X X
pad_cell S scaled_cell L X X X X
pad_type S cell C X X X X
pad_type S scaled_cell L X X X X
piece_define C library L X X
piece_type S library L X
pin G bundle C X X X X
pin G bus C X X X X

A-20
y e
p v
e e
l
SDM PWL NLDM CMOS
pin G cell C X X X X
pin G scaled_cell L X X X X
pin G test_cell C X X X X
pin_equal C bundle C X X X X
pin_equal C bus C X X X X
pin_equal C cell C X X X X
pin_equal C scaled_cell L X X X X
pin_func_type S bundle C X X X X
pin_func_type S bus C X X X X
pin_func_type S pin C X X X X
pin_opposite C bundle C X X X X
pin_opposite C bus C X X X X
pin_opposite C cell C X X X X
pin_opposite C scaled_cell L X X X X
power G internal_power C X X X X
power_level S internal_power C X X X X
power_lut_template G library L X X X X
power_rail C operating_ L X X X X
conditions
power_rail C power_supply L X X X X
power_supply G library L X X X X
prefer_tied S bundle C X X X X
prefer_tied S bus C X X X X
prefer_tied S pin C X X X X
preferred S cell C X X X X
preferred S scaled_cell L X X X X
preferred_input_pad_voltage S library L X X X X
preferred_output_pad_slew_rate_ S library L X X X X
control
preferred_output_pad_voltage S library L X X X X
preset S ff C X X X X
preset S ff_bank C X X X X
preset S latch C X X X X
preset S latch_bank C X X X X
primary_output S bundle C X X X X
primary_output S bus C X X X X

A-21
y e
p v
e e
l
SDM PWL NLDM CMOS
primary_output S pin C X X X X
process S operating_ L X X X X
conditions
pulling_current S bundle C X X X X
pulling_current S bus C X X X X
pulling_current S pin C X X X X
pulling_resistance S bundle C X X X X
pulling_resistance S bus C X X X X
pulling_resistance S pin C X X X X
pulling_resistance_unit S library L X X X X
R
rail_connection C cell C X X X X
reference_capacitance S bundle C X
reference_capacitance S bus C X
reference_capacitance S library L X
reference_capacitance S pin C X
related_bus_pins S timing C X X X X
related_output_pin S timing C X
related_pin S internal_power C X X X X
related_pin S power C X X X X
related_pin S timing C X X X X
resistance S wire_load L X X X X
*revision S library L X X X X
rise_constraint G timing C X
rise_current_slope_after_threshold S bundle C X X X X
rise_current_slope_after_threshold S bus C X X X X
rise_current_slope_after_threshold S pin C X X X X
rise_current_slope_before_threshold S bundle C X X X X
rise_current_slope_before_threshold S bus C X X X X
rise_current_slope_before_threshold S pin C X X X X
rise_delay_intercept C timing C X
rise_pin_resistance C timing C X
rise_power G internal_power C X X X X

A-22
y e
p v
e e
l
SDM PWL NLDM CMOS
rise_propagation G timing C X
rise_resistance S timing C X X X
rise_time_after_threshold S bundle C X X X X
rise_time_after_threshold S bus C X X X X
rise_time_after_threshold S pin C X X X X
rise_time_before_threshold S bundle C X X X X
rise_time_before_threshold S bus C X X X X
rise_time_before_threshold S pin C X X X X
rise_transition G timing C X
rise_transition_degradation G library L X
routing_layers C library L X X X X
routing_track G cell C X X X X
row_address S memory C X X X X
S
scaled_cell G library L X X X
scaling_factors S cell C X X X X
scaling_factors G library L X X X X
scaling_factors S scaled_cell L X X X X
*scan_group S cell C X X X X
*scan_group S scaled_cell L X X X X
sdf_cond S min_pulse_width C X X X X
sdf_cond S minimum_period C X X X X
sdf_cond S timing C X X X X
sdf_cond_end S timing C X X X X
sdf_cond_start S timing C X X X X
sdf_edges S timing C X X X X
setup_coefficient S timing C X
signal_type S bundle C X X X X
signal_type S bus C X X X X
signal_type S pin C X X X X
simulation S library L X X X X
*single_bit_degenerate S cell C X X X X
slew_control S bundle C X X X X

A-23
y e
p v
e e
l
SDM PWL NLDM CMOS
slew_control S bus C X X X X
slew_control S pin C X X X X
slope S wire_load L X X X X
slope_fall S timing C X X
slope_rise S timing C X X
slower_factor S timing_range L X X X X
state_function S bundle C X X X X
state_function S bus C X X X X
state_function S pin C X X X X
statetable G cell C X X X X
statetable G scaled_cell L X X X X
statetable G test_cell C X X X X
T
table S statetable C X X X X
technology C library L X X X X
temperature S operating_ L X X X X
conditions
test_cell G cell C X X X X
test_cell G scaled_cell L X X X X
test_output_only S bundle C X X X X
test_output_only S bus C X X X X
test_output_only S pin C X X X X
three_state S bundle C X X X X
three_state S bus C X X X X
three_state S pin C X X X X
time_unit S library L X X X X
timing G bundle C X X X X
timing G bus C X X X X
timing G pin C X X X X
timing_range G library L X X X X
timing_report S library L X X X X
timing_sense S timing C X X X X
timing_type S timing C X X X X

A-24
y e
p v
e e
l
SDM PWL NLDM CMOS
total_track_area S routing_track C X X X X
tracks S routing_track C X X X X
tree_type S operating_conditions L X X X X
type G bus C X X X X
type G cell C X X X X
type G library L X X X X
type S memory C X X X X
type G scaled_cell L X X X X
V
values C cell_fall C X
values C cell_rise C X
values C cell_degradation C X
values C fall_constraint C X
values C fall_power C X X X X
values C fall_propagation C X
values C fall_transition C X
values C fall_transition_ L X
degradation
values C leakage_power C X
values G power C X X X X
values C rise_constraint C X
values C rise_power C X X X X
values C rise_propagation C X
values C rise_transition C X
values C rise_transition_ L X
degradation
variable_1 S lu_table_template L X
variable_1 S power_lut_ L X X X X
template
template

A-25
y e
p v
e e
l
SDM PWL NLDM CMOS
template
vhdl_name S bundle C X X X X
vhdl_name S bus C X X X X
vhdl_name S cell C X X X X
vhdl_name S pin C X X X X
vhdl_name S scaled_cell L X X X X
vih S input_voltage L X X X X
vil S input_voltage L X X X X
vimax S input_voltage L X X X X
vimin S input_voltage L X X X X
voh S output_voltage L X X X X
vol S output_voltage L X X X X
voltage S operating_ L X X X X
conditions
voltage_unit S library L X X X X
vomax S output_voltage L X X X X
vomin S output_voltage L X X X X
W
when S internal_power C X X X X
when S leakage_power C X X X X
when S min_pulse_width C X X X X
when S minimum_period C X X X X
when S timing C X X X X
when_end S timing C X X X X
when_start S timing C X X X X
wire_load G library L X X X X
wire_load_from_area C wire_load_selection L X X X X
wire_load_selection G library L X X X X
wire_load_table G library L X X X X
word_width S memory C X X X X
X
x_function S pin C X X X X

A-26
Index
Symbols pin group 4-14

unit attributes 2-4
(continuation character) 1-3 auxiliary pad cells
{ } (group contents) 1-3 when to use 4-5
auxiliary_pad_cell attribute 7-2
A
address attribute B
in memory_read group 6-6 backslash, as escape character 4-28
in memory_write group 6-7
balanced_tree value of tree_type 3-10
address_width attribute
best_case_tree value of tree_type 3-10
in memory group 6-4
bit width of multi-bit cell 5-11
area
wire attribute 3-13 bit_from attribute
in type group 4-8, 4-33
area attribute
in cell group 4-3 bit_to attribute
area attribute, cell group 4-3
bit_width attribute 4-35
array value, of base_type 4-8, 4-33
attribute statement
blocks
complex 1-4
complex interface timing 11-2, 11-9
definition 1-4
describing with interface timing 11-5
simple 1-4
Boolean operators 9-6
attributes
defining new 1-5 braces ({ }) in group statements 1-3
attributes, technology library buffers
cell group 4-2 bidirectional pad example 7-23
cell internal power attributes 9-13 clock buffer example 7-21
cell routability attributes 4-13 input buffer example 7-19
pad attributes 7-2 input buffer with hysteresis example 7-20
piecewise linear attributes 2-7 output buffer example 7-22
IN-1
bundle group capacitance attribute
direction attribute 5-34 definition 4-17
members attribute 4-41 capacitance, pin attribute 3-2
pin attributes 4-41 scaling 3-18
uses of 4-41 setting default 3-4
bus capacitive_load_unit attribute 2-6, 7-6
sample description 4-37 cell degradation
bus group defined 4-23
bus_type attribute 4-36 in nonlinear delay models 4-24
definition 4-35 cell group
direction attribute 5-34 area attribute 4-3
in multi-bit flip-flop registers 5-11 bundle group 4-41
in multi-bit latch registers 5-18 bus group 4-35
sample bus description 4-37 cell_footprint attribute 4-3
bus pin defined 4-2
defining 4-32 example 4-10
defining with type group 4-35 handle_negative_constraint attribute 4-4
function attribute 4-27 internal_power group 9-13
in function attribute 4-32 is_pad attribute 4-4
naming convention 4-36 naming 4-2
overriding default attributes 4-36 pad_cell attribute 4-4
specifying default attributes 4-36 pad_type attribute 4-5, 7-3
bus pin group pin group 4-15
example 4-37 pin_equal attribute 4-5
range of bus members 4-37 pin_opposite attribute 4-6
bus_hold pin 7-5 routing_track group 4-13
bus_naming_style attribute 2-3 scaling_factors attribute 4-6
characters in 2-3 type group attribute 4-7
symbols in 2-3 vhdl_name attribute 4-9
bus_type attribute 4-36 cell_degradation group
bused-pin ranges defined 4-23
in function statements 4-28 cell_fall group
defined 10-25
defining delay arcs 10-38
C in nonlinear delay models 10-13
cell_footprint attribute 4-3
capacitance
defining range for indexed variables 2-8 cell_leakage_power attribute 3-2
load units 2-6, 7-6 cell_rise group
max_capacitance attribute 4-22 defined 10-25
min_capacitance attribute 4-23 defining delay arcs 10-38
pin attribute 4-17 in nonlinear delay models 10-13
scaling 3-18 cells
wire attribute 3-13 defining internal power 9-13
wire length 2-8, 10-8 scaled attributes 4-6
IN-2
sequential timing 11-2 conditional timing constraints
timing, interpreting 11-2 attributes and groups 10-68
clear connect delay 10-7
nextstate_type attribute 5-4 constrained_pin_transition
clear attribute value for transition constraint 10-54
for flip-flops 5-5 constraint attribute
for latches 5-16 defined 10-73
clear timing arc constraint_high attribute
definition 10-33 defined 10-72
use of 10-31 constraint_low attribute
clock attribute defined 10-72
definition 4-25 continuation character () 1-3
clock buffer 7-21 control signals in multi-bit register 5-11, 5-18
clock pads 7-3 current, units of measure 2-5
clock pin current_unit attribute 2-5, 7-7, 7-12
active edge 5-3
min_period attribute 4-26
min_pulse_width attributes 4-26 D
setup and hold checks 10-51
D flip-flop
clock_gate_enable attribute 4-17
auxiliary clock modeling example 8-29
clocked_on attribute 5-3, 5-4, 5-6, 5-7 CMOS piecewise linear delay model 10-77
in memory_write group 6-7 CMOS standard delay model 10-75, 10-79
clocked_on_also attribute 5-3, 5-4 ff group example 5-6
in master-slave flip-flop 5-8 positive edge-triggered example 5-9
clocked-scan methodology single-stage example 5-8
test cell modeling example 8-26 test cell modeling example 8-13, 8-15
CMOS pin group example 4-31 timing arcs 10-60
CMOS technology library 2-1 data
colon ( nextstate_type attribute 5-4
) in range of bus members 4-37 data_in attribute for latches 5-15
column_address attribute default_cell_leakage_power 3-3
memory group 6-4, 6-5 default_cell_leakage_power attribute 3-2
combinational path default_fall_delay_intercept attribute 3-2, 3-5
output propogation delay 11-8 default_fall_pin_resistance attribute 3-2, 3-6
combinational timing arc default_fanout_load attribute 3-2, 3-4
definition 10-3 default_inout_pin_cap attribute 3-2, 3-4
combinational value default_inout_pin_fall_res attribute 3-2, 3-4
in timing_type_attribute
default_inout_pin_rise_res attribute 3-2, 3-5
in timing group 10-17
default_input_pin_cap attribute 3-2, 3-4
complex attribute
default_intrinsic_fall attribute 3-2, 3-5, 3-6
syntax of statement 1-4
default_intrinsic_rise attribute 3-2, 3-5, 3-6
complex sequential block
interface timing 11-9 default_max_capacitance attribute 3-2
IN-3
default_max_fanout attribute 3-2, 3-4 delay, interconnect 3-13
default_max_transition attribute 3-2, 3-4 delay_model attribute 2-3, 10-6
default_max_utilization attribute 3-2, 3-7 design rule checking attributes 4-19
default_operating_conditions attribute 3-2, 3-8 design rule constraints
default_output_pin_cap attribute 3-2, 3-4 max_capacitance 4-22
default_output_pin_fall_res attribute 3-2, 3-3, max_transition 4-21
3-5 min_capacitance 4-23
default_output_pin_rise_res attribute 3-2, 3-3, min_transition 4-22
3-5 direction attribute 5-34
default_rc_fall_coefficient attribute 3-2 definition 4-18
default_rc_rise_coefficient attribute 3-2 of bus pin 4-36
of test pin 8-3
default_reference capacitance 3-2
values 5-34
default_rise_delay_intercept attribute 3-2, 3-3,
3-5 double-latch LSSD methodology
test cell modeling example 8-21
default_rise_pin_resistance attribute 3-2, 3-6
downto attribute 4-34
default_slope_fall attribute 3-2, 3-3, 3-5
drive capability 10-20
default_slope_rise attribute 3-2, 3-3, 3-5
drive_current attribute 2-5, 7-7, 7-12, 7-13
default_wire_load attribute 3-6
driver_type attribute
default_wire_load_resistance 3-7
multiple attributes 7-13
define statement
defined 1-5
degradation tables E
for transition delay 10-42
variables 10-42 edge-sensitive timing arcs 10-31
delay edge-triggered
connect 10-7 flip-flops 5-2
intrinsic 10-7 enable attribute
slope 10-7 in memory_write group 6-7
transition 10-7 enable attribute for latches 5-17
delay model enable pin identification of test cell 8-4
piecewise linear 3-5 enable pin of three-state function 10-28
standard 3-4 endpoint
supported 10-5 timing arc 10-2
timing group attributes 10-12 environment
use of 10-5 describing 3-1
delay propagation equal_or_opposite_output attribute 9-13
defined 10-24
delay scaling
example factors 3-25 F
intrinsic delay 3-15 fall_constraint group
pin capacitance 3-18 modeling load dependency 10-56
slope-sensitivity 3-16 no change constraint hold time 10-66
wire capacitance 3-18 setup and hold constraints 10-53
IN-4
fall_current_slope_after_threshold attribute 7- specifying minimum 4-21
14 fanout_area attribute 3-14
fall_current_slope_before_threshold attribute fanout_capacitance attribute 3-14
7-14 fanout_length attribute 3-13, 3-14
fall_delay_intercept attribute 3-2, 10-22 fanout_load attribute 3-2, 4-20
definition 10-22 specifying default value 3-4
in piecewise linear delay models 10-13
fanout_resistance attribute 3-14
scaling 3-19
faster_factor attribute 3-11
specifying default value 3-5
ff group 5-2
fall_pin_resistance attribute 3-2, 10-21
master-slave flip-flop 5-8
definition 10-21
single-stage D flip-flop 5-8
scaling 3-19 ff_bank group 5-10
specifying default value 3-6 flip-flop
fall_power group D 5-6, 5-8, 5-9
index_1 attribute 9-16 describing 5-2
index_2 attribute 9-16 JK 5-7
index_3 attribute 9-16 JK with scan 5-8
internal_power group 9-16 master-slave 5-8
values attribute 9-17 single-stage 5-7
state declaration examples 5-35
fall_propagation group
defined 10-24 flip-flops and latches 5-1
defining delay arcs 10-39 function attribute
in nonlinear delay models 10-13 bus variables in, example 4-37
fall_resistance attribute 3-2 defined 4-27
definition 10-20 of flip-flop bank 5-11
in linear delay models 10-13, 10-20 of grouped pins 4-28
specifying default value 3-4, 3-5 of latch bank 5-18
use of 7-7 of test pin 8-3
required for storage devices 5-9
fall_time_after_threshold attribute 7-14
valid Boolean operators 4-27
fall_time_before_threshold attribute 7-14
fall_transition group
defined 10-23
defining delay arcs 10-38, 10-39
G
in nonlinear delay models 10-13 group statements
bundle 4-41
fall_transition_degration group
bus 4-35
defined 10-42
cell 4-2
falling_edge
definition 1-3
value for timing_type attribute 10-31
internal power 9-13
falling_edge value, of timing_type 10-17 naming 1-3
fanout operating_conditions 3-9
and wire length estimation 3-13 pin 4-14
control signals in multi-bit register 5-11, 5-18 in test_cell group 8-3
specifying maximum 4-21 technology library 2-2
IN-5
test_cell 8-13 index_3 attribute
timing 10-12 fall_power group 9-16
power_lut_template group 9-11
rise_power group 9-17
H input
handle_negative_constraint attribute 4-4 hold constraint 11-6
high-active clock signal 5-4 setup constraint 11-6
high-impedance state input pads 7-8, 7-10
three_state attribute 4-29 input_map attribute
hold constraints and internal_node attribute 4-31, 5-31
defined 10-49 delayed outputs 5-32
hold_falling value 10-52 sequential cell network 5-32
hold_rising value 10-52 input_net_transition 10-9
in linear delay models 10-52 input_transition_time 9-11
in nonlinear delay models 10-53 input_voltage group 7-7, 7-8
related_pin attribute 10-52 input_voltage simple attribute 7-9
hold_falling value interconnect delay
defined 10-52 and wire_load group 3-13
value for timing_type attribute 10-54 interconnect model
hold_falling value of timing_type defining 3-10
definition 10-17 interface timing of a complex block 11-2
hold_rising value Interface Timing Specification
defined 10-52 benefits 11-3
value for timing_type attribute 10-54 defined 11-1
hold_rising value of timing_type describing blocks with 11-5
definition 10-17 examples 11-13
hysteresis attribute interface timing relationships
example 7-20 examples 11-5
using 7-10 internal pin type 5-34
internal power
calculating 9-19
I defined 9-8
implementing 3-11 internal_node attribute 4-31, 5-31
index variables input_map attribute 5-31
defining range for 2-8 internal_power group
index_1 attribute definition 9-13
fall_power group 9-16 equal_or_opposite_output attribute 9-13
power_lut_template group 9-11 fall_power attribute 9-16
rise_power group 9-17 one-dimensional table 9-18
index_2 attribute power group attribute 9-15
fall_power group 9-16 related_pin attribute 9-14
power_lut_template group 9-11 rise_power attribute 9-17
rise_power group 9-17 three-dimensional table 9-19
IN-6
two-dimensional table 9-18 hold rise/fall constraints 3-21
when attribute 9-14 internal power 3-20
intrinsic delay 10-7 intrinsic fall/rise delay 3-15
defined 10-34 minimum period 3-24
for input pin 10-34 minimum pulse width 3-23
for output pin 10-34 pin capacitance 3-18
in linear delay models 10-35 recovery rise/fall constraints 3-23
in nonlinear delay models 10-35 rise delay intercept 3-19
scaling factors 3-15 rise pin resistance 3-19
intrinsic_fall attribute 3-2 setup rise constraints 3-28
in linear delay models 10-13 setup rise/fall constraints 3-22, 3-23
specifying default value 3-5, 3-6 slope fall/rise 3-16
timing group 10-20 wire capacitance 3-18
intrinsic_rise attribute 3-2 wire resistance 3-18
in linear delay models 10-13 slope-sensitivity 3-16
specifying default value 3-5, 3-6 temperature attributes
timing group 10-19 cell leakage power 3-20
with preset and clear timing arcs 10-32, 10-34 drive fall/rise 3-17
fall delay intercept 3-20
inverted_output attribute 4-18
fall pin resistance 3-19
non-inverted output 4-18, 5-33
hold rise/fall constraints 3-22
statetable format 5-33
internal power 3-20
inverter with three-state output 10-30 intrinsic fall/rise delay 3-15
IO_PAD_SCALING 4-7 minimum period 3-24
is_pad attribute 4-4, 7-2, 7-3 minimum pulse width 3-23
ITS 11-1 pin capacitance 3-18
recovery rise/fall constraints 3-23
rise pin resistance 3-19
J setup rise constraints 3-28
JK flip-flop 5-8 setup rise/fall constraints 3-22, 3-23
example 5-8, 10-31 slope fall/rise 3-16
ff group declaration 5-7 wire capacitance 3-18
wire resistance 3-18
voltage attributes
K cell leakage power 3-20
drive fall/rise 3-17
k-factors
defined 3-14
fall pin resistance 3-19
example of 3-25
hold rise/fall constraints 3-22
intrinsic delay 3-15
internal power 3-20
pin capacitance 3-18
intrinsic fall/rise delay 3-16
pin resistance 3-19, 3-20
minimum period 3-24
process attributes
minimum pulse width 3-24
cell power 3-20
pin capacitance 3-18
drive fall/rise 3-17
recovery rise/fall constraints 3-23
IN-7
rise pin resistance 3-19 input_voltage group 7-8
setup rise/fall constraints 3-22, 3-23, 3-28 leakage_power_unit attribute 2-7
slope fall/rise 3-16 pad attributes 7-2
wire capacitance 3-18 piece_define attribute 2-8
wire resistance 3-18 piece_type attribute 2-7
wire capacitance 3-18 pulling_resistance_unit attribute 2-6
routing_layers attribute 2-4
technology attribute 2-2
L time_unit attribute 2-5
latch 5-1 voltage_unit attribute 2-5, 7-7
with signal bundles 4-42 load
latch group 5-15 nexstate_type attribute 5-5
latch_bank group 5-17 load dependency
modeling 10-56
leakage power
related_output_pin attribute 10-28
defined 9-4
lookup tables 10-6
leakage_power_unit attribute 2-7
for modeling load dependency 10-56
level-sensitive memory devices 5-15
for timing arcs 10-6
libraries power
routability 4-14 one-dimensional table 9-18
library group (technology library) three-dimensional table 9-19
default pin attributes 3-4 two-dimensional table 9-18
default timing attributes 3-4, 3-5 rules for defining 10-10
default_operating_conditions attribute 3-8 syntax for lookup table group 10-10
default_wire_load attribute 3-6 low-active
input_voltage group 7-8 clear signal 10-60
intercept delay scaling factors 3-19 clock signal 5-4
intrinsic delay scaling factors 3-15
LSSD
piece_define attribute 10-7
double-latch mode 8-21
pin resistance scaling factors 3-19
single-latch mode 8-21
slope-sensitivity scaling factors 3-16
LSSD cell
technology attribute 2-2
modeling 8-21
library group statements
LSSD methodology
multiple power supplies
pin identification 8-5
example 9-29
power_supply 9-24 LSSD test element
example 9-28 modeling example 8-21
library group, technology library lu_table_template 10-26
bus_naming_style attribute 2-3 lu_table_template group
capacitive_load_unit attribute 2-6 breakpoints 9-11, 10-10
current_unit attribute 2-5, 7-7, 7-12 for device degradation constraints 4-24
delay_model attribute 2-3 modeling load dependency 10-56
group statement 2-2 syntax 10-9
variables 10-9
IN-8
M modeling timing arcs 10-3, 10-11
multibit registers
master-slave flip-flop 5-10
clocks 5-3 latch 5-17
flip-flop 5-8
multiple paths 10-15
max_capacitance attribute
multiple power supplies
definition 4-22
at cell level 9-25
max_fanout attribute 3-2 example library 9-29
definition 4-21
max_transition attribute 3-2
definition 4-21
N
specifying default value 3-4 n-channel open drain 7-4
members attribute 4-41 negative_unate value
in clear arc 10-33
memory group
in preset arc 10-32
components 6-3
value for timing_sense attribute 10-32, 10-33
memory modules
negative_unate value, of timing_sense 10-15
examples 6-8
modeling 6-1 negative-edge-triggered devices 5-4
memory_read group next_state attribute 5-3, 5-6, 5-7
components 6-5 nextstate_type attribute 5-4
memory_write group no change constraints
components 6-6 and conditional attributes 10-73
min_capacitance attribute defined 10-63
definition 4-23 in linear delay models 10-65
in nonlinear delay models 10-66
min_fanout attribute
definition 4-21 non_seq_hold_falling value
defined 10-58
min_period attribute
definition 4-26
non_seq_hold_rising value
min_pulse_width attributes
defined 10-58
definition 4-26
min_pulse_width group
non_seq_setup_falling value
defined 10-71
defined 10-58
min_transition attribute value for timing_type attribute 10-54
definition 4-22
non_seq_setup_rising value
minimum_period group defined 10-58
defined 10-73 value for timing_type attribute 10-54
modeling non_unate value
capacitance in clear arc 10-33
total pin 10-8 in preset arc 10-32
total pin and wire 10-8 value for timing_sense attribute 10-32, 10-33
wire 10-8
non_unate value, of timing_sense 10-16
modeling memory modules 6-1
NOR gate example 10-37
IN-9
O pad_cell attribute 4-4
pad_driver_sites 7-19
open_drain pin 7-4
pad_input_driver_sites 7-19
open_source pin 7-4
pad_output_driver_sites 7-19
operating conditions
pad_slots 7-19
and scaled cells 4-44
pad_type attribute 4-5, 7-3
operating conditions group 4-45
power_rail 3-10 pads
bidirectional pad example 7-23
operating_conditions group
clock 7-3
effect on input voltage groups 7-9
clock buffer example 7-21
effect on output voltage groups 7-11
defined 7-1
group statement 3-9
drive current 7-12
process attribute 3-10
drive current strength attribute 7-13
setting default group 3-8
hysteresis 7-10
temperature attribute 3-10
identifying 7-2
tree_type attribute 3-10
input buffer example 7-19
voltage attribute 3-10
input buffer with hysteresis example 7-20
voltage_unit attribute 7-7
input pads 7-8, 7-10
operating_conditions group statement input voltage levels 7-8
in scaled_cell group 4-45 output buffer example 7-22
operator output voltage levels 7-11, 7-12
precedence of 4-27 pad_cell attribute 4-5
output pads 7-10 pad_type attribute 4-5
describing 7-10 requirements 7-1
output pin group slew-rate control 7-13
internal_node attribute 5-30 units for 7-6
state_function attribute 5-30, 5-33 wire load 7-18
three_state attribute 5-30 parallel single-bit sequential cells 5-10
output propagation 11-6 path tracing
output_net_length 10-9 defining multiple paths 10-15
output_net_pin_cap 10-9 edge-sensitive timing arcs 10-31
output_net_wire_cap 10-9 timing groups 10-11
output_voltage group 7-7, 7-12 p-channel open drain 7-4
output_voltage simple attribute 7-12 physical time unit in library 2-5
piece_define attribute 2-8, 10-7
piece_type attribute 2-7, 10-8
P piecewise linear delay model
pad cells attributes 2-7
auxiliary_pad_cell attribute 7-2 default timing attributes 3-5
examples 7-18 piece_define attribute 2-8, 10-7
is_pad attribute 7-2 pin group
pad_cell attribute 7-2 bundle group, pin attributes in 4-41
pad slots, defining number of 7-19 capacitance attribute 4-17
clock atttribute 4-25
IN-10
clock_gate_enable_pin attribute 4-17 when attribute 9-14
defined 4-14 vhdl_name attribute 4-9
design rule checking attributes 4-19 pin names starting with numerals 4-28
direction attribute 4-18, 5-34 pin_equal attribute
drive_current attribute 7-13 bus variables in 4-37
example 4-31 definition 4-5
fall_current_slope_after_threshold attribute pin_func_type attribute 4-18
7-14
pin_opposite attribute
fall_current_slope_before_threshold
attribute 7-14 bus variables in, example 4-37
fall_time_after_threshhold attribute 7-14 definition 4-6
fall_time_before_threshold attribute 7-14 pins
fanout_load attribute 4-20 capacitance 3-18
function attribute 4-27 cell group 4-5
in a test_cell group 8-3 comparison of bused and single formats 4-37
inverted_output attribute 4-18 defining 4-16
is_pad attribute 7-3 defining function 4-27
max_capacitance attribute 4-22 describing functionality 4-18
max_fanout attribute 4-21 logical inverse 4-6
max_transition attribute 4-21 multiple pins in a group 4-15
min_capacitance attribute 4-23 name of test cell pin 8-3
min_fanout attribute 4-21 naming test pins 8-3
min_period attribute 4-26 pin group 4-15
min_pulse_width attributes 4-26 pin_equal attribute 4-5
min_transition attribute 4-22 pin_opposite attribute 4-6
pin_func_type attribute 4-18 resistance scaling factor 3-19
pulling_current attribute 7-17 with common attributes 4-15
pulling_resistance attribute 7-17 positive_unate value
rise_current_slope_after_threshold attribute in clear arc 10-33
7-14 in preset arc 10-32
rise_current_slope_before_threshold value for timing_sense attribute 10-32, 10-33
attribute 7-13 positive_unate value, of timing_sense 10-15
rise_time_after_threshold attribute 7-14 power
rise_time_before_threshold attribute 7-14 internal power, calculating 9-19
slew_control attribute 7-13 leakage power defined 9-4
state_function attribute 4-31 lookup template variables 9-11
three_state attribute 4-29 input_transition_time 9-11
threshold-related attributes 7-13 total_output_net_capacitance 9-11
pin group statement total_output2_net_capacitance 9-11
internal_power group power_lut_template group 9-10
equal_or_opposite_output attribute 9-13 scaling factors 3-20
fall_power attribute 9-16 power group
power group 9-15 in internal_power group 9-15
related_pin attribute 9-14 values attribute 9-16
rise_power attribute 9-17 power lookup table template
IN-11
example 9-12 ranges of wire length 2-8, 10-7
power lookup tables recovery constraints 10-59
one-dimensional table 9-18, 9-20 defined 10-59
three-dimensional table 9-19, 9-22 recovery_falling 10-18
two-dimensional table 9-18, 9-21 recovery_falling value
power supplies using 10-60
defining multiple supplies at cell level 9-25 value for timing_type attribute 10-54
power_lut_template group recovery_rising 10-18
defining 9-10 recovery_rising value
power_supply group statement 9-24 using 10-60
example 9-28 value for timing_type attribute 10-54
preset registers 5-10, 5-17
nextstate_type attribute 5-4 defining signal bundles 4-41
preset attribute related_bus_pins attribute 10-15
for flip-flops 5-5 defined 10-15
for latches 5-16 in all delay models 10-13
preset timing arc related_output_pin attribute
defined 10-32 defined 10-28
use of 10-31 in nonlinear delay models 10-13
process attribute 3-10 related_pin attribute 10-13
pull_down bus variables in 4-37
auxiliary pad cell 7-3 defined 10-13
pull_down cell 7-4 in all delay models 10-13
pull_up in hold arcs 10-52
auxiliary pad cell 7-3 in setup arcs 10-51
pull_up cell 7-4 internal_power group 9-14
pull-down cell related_pin_transition
auxiliary pad cell 4-5 value for transition constraint 10-54
resistance unit 2-6 removal constraints
pulling_current attribute 2-5, 7-7, 7-17 defined 10-61
pulling_resistance attribute 7-7, 7-17 removal_falling 10-18
pulling_resistance_unit attribute 2-6, 7-7 removal_falling value
using 10-62
pull-up cell
auxiliary pad cell 4-5
resistance unit 2-6 removal_rising 10-18
removal_rising value
using 10-62
R value for timing_type attribute 10-54
resistance
rail_connection attribute 9-25
RAM, specifying with interface timing 11-13
wire attribute 3-13
range of bus members
rise_constraint group
in related_pin 10-14
modeling load dependency 10-56
specifying 4-37
IN-12
no change constraint setup time 10-66 allowed information 4-14
setup and hold constraints 10-53 routing_track group 4-13
rise_current_slope_after_threshold attribute 7- routing_layers attribute 2-4, 4-13
14 routing_track group 4-13
rise_current_slope_before_threshold attribute total_track_area attribute 4-13
7-13 tracks attribute 4-13
rise_delay_intercept attribute 3-2 rule
defined 10-22 in statetable format 5-26
scaling 3-19
specifying default value 3-5 S
rise_pin_resistance attribute 3-2, 10-21 Scalar power_lut_template Group 9-12
defined 10-21
scaled_cell group 7-10
example 4-45
scaling 3-19
use of 4-45
scaling factors
rise_power group
for nonlinear delay model 3-27
index_1 attribute 9-17
intrinsic delay 3-15
pin resistance 3-19, 3-20
power 3-20
internal_power group 9-17
slope-sensitivity 3-16
values attribute 9-17
scaling_factors attribute 3-26, 4-6
rise_propagation group
IO_PAD_SCALING 4-7
defined 10-24
scaling_factors group 3-26
defining delay arcs 10-39
in nonlinear delay models 10-13 scan input on JK flip-flop 5-8
rise_resistance attribute 3-2 scan_enable
defined 10-20 nextstate_type attribute 5-5
in linear delay models 10-13, 10-20 scan_in
specifying default value 3-5 nextstate_type attribute 5-5
use of 7-7 scan-in pin
with preset and clear timing arcs 10-32, 10-34 in pin group
rise_time_after_threshold attribute 7-14 in test cells 8-4
rise_time_before_threshold attribute 7-14 scan-in pin, inverted
rise_transition group in pin group
defined 10-23 in test cells 8-4
defining delay arcs 10-38, 10-39 scan-out pin 8-4
in nonlinear delay models 10-13 in pin group
rise_transition_degration group in test cells 8-4
defined 10-42 scan-out pin, inverted
rising_edge in pin group
value for timing_type attribute 10-31 in test cells 8-4
rising_edge value, of timing_type 10-17 sdf_cond attribute 10-45, 10-47
conditional timing constraint 10-69
routability
IN-13
defined 10-69 single-latch LSSD methodology
in min_pulse_width group 10-72 pin identification 8-5
in minimum_period group 10-73 test cell modeling example 8-21
state-dependent timing constraint 10-47 skew constraints 10-67
with no change constraints 10-74 defined 10-67
sdf_cond_end attribute skew_falling 10-18
defined 10-71 skew_falling value
with no change constraints 10-74 defined 10-68
sdf_cond_start attribute value for timing_type attribute 10-54, 10-68
defined 10-70 skew_rising 10-18
with no change constraints 10-74 skew_rising value
sdf_edges attribute defined 10-67
defined 10-71 value for timing_type attribute 10-54, 10-67
with no change constraints 10-74 slave clock 5-3
sequential cells slew_control attribute 7-13
output pin group 5-30
slew-rate control
output port 5-23
attributes example 7-16
statetable group 5-24
definition 7-13
sequential timing arc
slope
defined 10-4
describing sensitivity 10-44
types 10-4
slope attribute 3-13
setup constraints
slope delay 10-7
defined 10-49
in linear delay models 10-51 slope_fall 10-27
in nonlinear delay models 10-53 slope_fall attribute 3-2, 10-27
related_pin attribute 10-51 in linear delay models 10-13
setup_falling value 10-51 in piecewise linear delay models 10-13
setup_rising value 10-51 slope_rise attribute 3-2, 10-27
setup_falling value in linear delay models 10-13
defining setup constraint 10-51 in piecewise linear delay models 10-13
value for timing_type attribute 10-51, 10-54 with preset and clear timing arcs 10-32, 10-34
setup_falling value of timing_type slope-sensitivity scaling factors 3-16
in setup arc 10-17 SR latch 5-17
setup_rising value standard delay model
defining setup constraint 10-51 default timing attributes 3-4
value for timing_type attribute 10-51, 10-54 startpoint
setup_rising value of timing_type timing arc 10-2
in setup arc 10-17 state declaration
short-circuit power 9-8 clocked_on attribute 5-3
defined 9-8 clocked_on_also attribute 5-3
signal bundles, defining 4-41 state variables
signal_type attribute 5-4, 8-3 for flip-flops 5-3, 5-6
of test pin 8-3 for latches 5-18
simple attribute statement 1-4 for master-slave flip-flops 5-9
IN-14
with function attribute 5-9, 5-11 three_state_disable 10-28
state_function attribute 4-31 three_state_disable value
state-dependent timing attributes 10-45 in timing_type_attribute
statement in timing group 10-17
attribute 1-4 three_state_enable 10-29
define 1-5 three_state_enable value
group 1-3 in timing_type_attribute
types of 1-3 in timing group 10-17
statetable format three-state cell
inverted_output attribute 5-33 modeling example 4-30, 10-30
statetable group timing_sense attribute 10-15
sequential cells 5-24 threshold-related attributes 7-13
statetable group conventions 5-26 time_unit attribute 2-5
switching activity timing
and power dissipation 9-2 describing delay 10-1
sequential 11-2
setting constraints 10-2
T static 11-2
technology attribute 2-2 timing arc
temperature attribute 3-10 clear 10-33
constraint arc defined 10-4
template
defined 10-2
for nonlinear delay models 10-8
defining identical 10-14
test pin attributes
delay arc defined 10-4
function 8-3
diagram 10-2
signal_type 5-4, 8-3
edge-sensitive 10-31
test_cell group endpoint 10-2
naming test cell pins 8-3 modeling 10-3, 10-11
statement 8-13 preset 10-32
test_clock value of signal_type 8-5 startpoint 10-2
test_output_only attribute 8-3 timing group
test_scan_clock value of signal type 8-4 attributes in the delay models 10-13
test_scan_clock_a defined 10-11
signal_type attribute 8-5 fall_delay_intercept attribute 10-22
test_scan_clock_b fall_pin_resistance attribute 10-21
signal_type attribute 8-4, 8-5 fall_resistance attribute 10-20
test_scan_enable value of signal_type 8-4 intrinsic_fall attribute 10-20
test_scan_enable_inverted value of signal type intrinsic_rise attribute 10-19
8-4 related_pin attribute 10-13
test_scan_out value of signal_type 8-4 rise_delay_intercept attribute 10-22
rise_pin_resistance attribute 10-21
test_scan_out_inverted value of signal type 8-4
rise_resistance attribute 10-20
three_state attribute 4-29 slope_fall attribute 10-27
in multi-bit flip-flop registers 5-11 slope_rise attribute 10-27
in multi-bit latch registers 5-18
IN-15
syntax 10-12 lu_table_template group 10-9
timing_sense attribute 10-15 rise_resistance attribute 10-20
timing_type attribute 10-16 transition time
values 10-17 max_transition attribute 4-21
timing group attributes min_transition attribute 4-22
for delay models 10-12 thresholds for pads 7-13
timing model tree_type attribute 3-10
piecewise linear 3-5 type attribute
standard 3-4 in memory group 6-3
timing ranges 3-11 type group 4-35
timing, interface base_type attribute 4-8, 4-33
benefits 11-3 downto attribute 4-34
timing_range group example 4-34
example 3-11 group statement 4-32
faster_factor attribute 3-11 sample bus description 4-37
timing_sense attribute 10-15 type group attribute 4-7
defined 10-15 type group statement
in all delay models 10-13 base_type attribute 4-8, 4-33
values 10-15, 10-16 bit_from attribute 4-8, 4-33
timing_type attribute bit_to attribute 4-8, 4-33
defined 10-16 bit_width attribute 4-9, 4-34
defining preset and clear arcs 10-32, 10-33 data_type attribute 4-9, 4-34
in all delay models 10-13 example 4-9
in load dependency modeling 10-56
no change constraint values 10-64
non-sequential constraint values 10-58 U
recovery time constraint values 10-60 unate, defined 10-16
removal constraint values 10-62 units
setup and hold arc values 10-51, 10-52 capacitive load 2-6, 7-6
skew constraint values 10-67 current 2-5, 7-7
total delay 10-7 leakage power 2-7
total_output_net_capacitance 9-11, 10-9 pads 7-6
total_output2_net_capacitance 9-11 pulling resistance 2-6
total_track_area attribute resistance 7-7
routing_track group 4-13 time 2-5
tracks attribute voltage 2-5, 7-7
routing_track group 4-13
transition delay 10-7, 10-21, 10-22, 10-38
defined 10-35 V
degradation 10-42 values attribute
fall_resistance attribute 10-20 definition 9-16, 9-17
in linear delay models 10-36 VDD
in nonlinear delay models 10-38 voltage levels
in piecewise linear delay models 10-36 output_voltage group 7-11
IN-16
VHDL with no change constraints 10-74
vhdl_name attribute 4-9 when_end attribute
vhdl_name attribute 4-9 defined 10-70
vih voltage range 7-8 with no change constraints 10-74
vil voltage range 7-8 when_start attribute
vimax voltage range 7-9 defined 10-69
vimin voltage range 7-8 with no change constraints 10-74
voltage 2-5 wire
attribute 7-7 capacitance 3-18
input and output levels 7-8 interconnect delay 3-13
input voltage group 7-8 length estimation 3-13
units of measure 2-4 wire_load group 7-18
voltage attribute 3-10 area attribute 3-13
capacitance attribute 3-13
voltage ranges
fanout_length attribute 3-13
output_voltage group 7-11
group statement 3-12
voltage_unit attribute 2-5, 7-7, 7-9, 7-11
resistance attribute 3-13
VSS slope attribute 3-13
voltage levels
wire_load group syntax 3-13
output_voltage group 7-11
wire_load_selection group 3-6, 3-12
wire_load_table group
W fanout_area attribute 3-14
fanout_capacitance attribute 3-14
when attribute 10-46 fanout_length attribute 3-14
conditional timing constraint 10-69 fanout_resistance attribute 3-14
defined 10-46, 10-69
word_width attribute
in min_pulse_width group 10-72
in memory group 6-4
in minimum_period group 10-73
worst_case_tree value of tree_type 3-10
internal_power group 9-14
IN-17
IN-18

Liberty

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Liberty

Transféré par

Droits d'auteur :

Formats disponibles

Liberty User Guide

Version 1998, October 1998

Liberty User Guide, Version 1998

1 Sample Library Description

4 Defining Core Cells

5 Defining Sequential Cells

6 Modeling Memory Modules

7 Defining Input and Output Pads

8 Defining Test Cells

11 Interface Timing of Complex Sequential Blocks

A Technology Library Attributes

Sample Library Description

Sample Library Description

Example 1-2 defines pin group A.

Example 1-2 Group Statement Specification

Sample Library Description

Example 1-3 Simple Attribute Specification

Example 1-4 adds the function X + Y to the pin example.

Example 1-4 Defining the Function of a Pin

attribute_name (parameter1 [, parameter2, parameter3 ...] );

Sample Library Description

line (1, 2, 6, 8);

define (bork, pin, string) ;

Sample Library Description

• Naming the Library Group

General Library Attributes

The following attributes apply generally to the technology library:

The default style for the bus_naming_style attribute is:

Each library can have only one routing_layers complex attribute.

Use these library-level attributes to define units:

The capacitive_load_unit attribute has no default value.

Using Piecewise Linear Attributes

For example, in the following piece_define specification, a wire of length 5 is referred to

The following types of environment attributes are discussed in this chapter:

• Library-level default attributes

Library-Level Default Attributes

Table 3-1 CMOS Default Attributes

Setting Default Cell Attributes

Setting Default Pin Attributes

• CMOS linear (standard) delay model

Example 3-1 shows default pin attributes in a CMOS library:

Example 3-1 Default Pin Attributes for a CMOS Library

CMOS Linear Delay Model

Example 3-2 Setting Standard Timing Default Attributes

CMOS Piecewise Linear Delay Model

Example 3-3 Setting Piecewise Linear Default Timing Attributes

Setting Wire Load Defaults

Setting Other Environment Defaults

Examples of Library-Level Default Attributes

Example 3-4 Setting Library-Level Defaults for a CMOS Library

/* default pin attributes */

/* default timing attributes */

Defining Operating Conditions

Example 3-5 describes the SLOW_RANGE and FAST_RANGE timing ranges.

Example 3-5 Defining Timing Ranges

Defining Power Supply Groups

The power_supply group is defined at the library level.

Defining Wire Load Groups

Define the wire_load group at the library level.

You can define the following attributes in a wire_load group:

fanout_length (fanout, length, average_capacitance, standard_deviation,

Unlike in the wire_load group, fanout_capacitance, fanout_resistance, and fanout_area

Specifying Delay Scaling Factors

• Intrinsic delay factors