Atrenta's Experience with

Multiple Power Formats

DesignCon, February 2, 2009

Dave Allen
Introduction
What is the problem?

Examples of correspondence between CPF and UPF

Easy
Hard
Impossible(?)

Future directions

About Atrenta

2
What is the Problem?
What you (the end user)
want:
X RTL Bridge? IP
One common universal power Y
format, accepted by all tools
Point
Front-end Tools
What we (the EDA industry)
Design Bridge?
have delivered so far: Y
Two formats, at least five total X
dialects: CPF 1.0, CPF 1.0e, CPF
RTL Signoff
1.1, UPF 1.0, IEEE P1801 (“UPF
2.0”) This Problem
How Is a LOT more
Is it like “Blu-ray vs. HD bridge? Difficult
DVD”? Or like “VHDL vs. Back-end Than it looks!
Verilog”? Or like EDIF, Implement
where N companies And the target
required O(N2) translators? Y
Keeps moving!
3
Correspondence Between CPF and UPF

CPF and UPF overlap, but not

completely

For some easy situations, you can

convert between them with a
“perl” script or equivalent
Same ideas,
For some hard situations, you can completely
CPF different UPF
find a correspondence, but it is
syntax: >80%
very tricky of needs
In some cases one language does
not even have any way to
represent something in the other
language; this is “impossible”
without syntax additions

4
Easy Correspondence
CPF and UPF descriptions for a single switchable domain:
# 1. Domains
create_power_domain -name Vtop -default
create_power_domain -name V1 -instances u1
# 2, 3. Clamp values and isolation signal
create_isolation_rule -name V1_low \
-from V1 -isolation_condition iso \
-pins * -isolation_output low
create_isolation_rule -name V1_high \
-from V1 -isolation_condition iso \
-pins zn -isolation_output high
# 4. Location for isolation gates
update_isolation_rule -name V1_low \
-location from
update_isolation_rule -name V1_high \
-location from
No line by line correspondence, but you can see it
# 1. Domains Same name!
create_power_domain Vtop
create_power_domain V1 -elements u1
# 2. Clamp values
set_isolation V1_low -domain V1 \
-applies_to outputs \
-clamp_value 0 Same concept
set_isolation V1_high -domain V1 \
-applies_to outputs \
-elements zn -clamp_value 1
# 3, 4. Isolation signal and location
set_isolation_control V1_low \
-isolation_signal iso -location self
set_isolation_control V1_high \
-isolation_signal iso -location self
Different locations
5
Hard: Multi-domain Macros
UA Macros (I/O pad, memory) may
have pins which connect to
P1 different domains

P2
At RTL or gate level prelayout, no
power nets are present
wrong UB
CPF syntax:
P3 create_power_domain -name VA \
-default
P4
create_power_domain -name VB \
pad1 -elements UB \
-boundary_ports pad1/P4

P3 must not connect to UB

6
Multi-domain Macros in UPF
UPF requires reference UPF:
create_power_domain VA
through “artificial” supply create_power_domain -name VB \
nets and liberty. -elements UB
create_supply_net VDDA
VDDA set_domain_supply_net VA \
VDDB -primary_power_net VDDA
UA connect_supply_port VDDA \
VB VA … -ports pad1/VA
P1 create_supply_net VDDB
set_domain_supply_net VB \
-primary_power_net VDDB
P2 connect_supply_port VDDB \
-ports pad1/VB

UB Liberty:
… cell(inpad) {
pin(P1) { related_power_pin: VA; }
P3
pin(P2) { related_power_pin: VA; }
pin(P3) { related_power_pin: VA; }
P4 pin(P4) { related_power_pin: VB; }
}
pad1 (inpad)

7
Hard: Power Switches
UPF power switches can be very general
Any number of input supplies, any number of control states
create_power_switch PS1
–input_supply_port {V1 N1} Supply port name,
–input_supply_port {V2 N2} design net name
-control_port {E1 N3} … Control port, design net name
–on_state {S1 V1 {E1 & E2}}
–on_state {S2 V1 {E2 & E3}} State name, active port,
–on_state {S3 V2 {E1 & E3}} control expression
Corresponds to multiple CPF commands:
define_power_switch PS1A –power V1
–stage_1_enable {e1 & e2}
-stage_2_enable {e1 & e3} Two library components
define_power_switch PS1B –power V2
–stage_1_enable {e1 & e2}
create_power_switch_rule –name R1
-external_power_net V1 Multiple rules
update_power_switch_rule -name R1 (not enough room ☺)
–enable_condition_1 {N3 & N4}
8
Hard: Mixed Tcl Families
Example customer UPF file:
set_domain_supply_net -domain VB \
Vendor-specific
-primary_power_net [get_net vddb] \
design access
-primary_ground_net [get_net gnd]
compile -inc -scan
commands
write -f verilog -hier -out test.v Tool-specific
commands

UPF 2.0 has vendor-neutral design access commands; if you

must, please use these

Please keep UPF commands in a separate file from other types

of commands and use “source” to execute the UPF file

9
Syntax with no Correspondence
The scope of the two languages is
mostly related, but not 100%
The UPF designers did not consider
the “red zone” part of their scope
and vice-versa
Some design intent will be lost if
red or blue commands are used
CPF UPF
CPF examples:
Related to STA and activity
set_switching_activity –mode
create_analysis_view

UPF examples:
Related to simulation behavior
bind_checker
create_hdl2upf_vct
10
Future Directions
We (the EDA industry) could make this go away with one or two
press releases:
“Cadence now supports UPF!” or
“ (Magma, Mentor, Synopsys) now support CPF!”

In the absence of these press releases, what can be done?

User community: Push for these press releases!
CPF development team: add syntax where needed
• CPF 1.2 presentation earlier in session
UPF development team: add syntax where needed
• UPF 2.0 (IEEE P-1801) presentation earlier in session
IP developers: release files for each syntax with your IP
EDA developers: help designers manage this problem

11
About Atrenta
Vision is Early Design Closure®

Early feasibility analysis

Enhanced Methodologies
Architecture
Lint Efficient exploration
Timing
Power Early correction of RTL
Clocks 
Test
Early optimization of design
Area
Smooth implementation

No surprises

12
Products that Support the Vision

GuideWare Methodologies
1Team‐Genesis
SpyGlass SpyGlass®
SpyGlass‐Constraints
SpyGlass‐Power
SpyGlass‐CDC 
1Team®
SpyGlass‐DFT
1Team‐
Implement

GuideWare™

13
Atrenta Power Optimization & Verification
Spec Sheet Power planning & tradeoffs
or C/C++ Supports
Architecture-level to post-layout
Spec’s Auto-write CPF from spec tables
PD1 C/C++
PD2 Power domain planning
? V1 RTL Accurate RTL power estimation
V2
VCD Power design & optimization
SDC
FSDB Isolate & remove power hogs
RTL … SAIF SGDC Intelligent power reduction
Synth CPF UPF Integrated debug environment
Clock & DFT aware optimization
Netlists Includes sequential formal methods
Libraries Power verification
P&R
HDL/CPF Lint & syntax checks
Constraints
Correctness at all design steps
Timing
& DFT Find other reduction tool errors

GDSII
Atrenta ensures end optimized design == design intent
14
Conclusion

You want one common universal format; we

have not delivered it yet

Some intent can be easily written in either

format, some not so easily, and some does not
have any correspondence

There are some specific things we can do to get

closer to the “one format” goal

Atrenta can help manage this problem

15