( ESNUG 464 Item 12 ) ------------------------------------------- [03/30/07]
From: Jason Ware <jware=user domain=cadence not palm>
Subject: Jason Ware -- I was away at the Cadence CPF Training last month
Hi, John,
Sorry I could not make DVCon last month. I was in AE training for the roll
out of tool support for Common Power Format. I have been reading some
articles about your "Troublemaker's Panel" and I see there was quite a bit
of discussion on power flows with Ted.
Thought I would bring you up to date on what I learned last month.
There were about 30 of my Core Comp App Engineer colleagues in our San Jose
headquarters for the CPF and Power Forward Initiative (PFI) training. As
you probably know Cadence announced the formation of the PFI with AMD,
Applied Materials, ARM, NXP, ATI, Freescale Semiconductor, Fujitsu, NEC,
and TSMC back in May of 2006. Since then we have been working on our
tools to develop a common power flow via support of CPF while at the same
time training our people to support the flows. So far, around 100 AE's
have been trained in 6 sessions worldwide.
Some of your readers may not be familiar with CPF; it's a file that can be
read by most of the tools in the Cadence flow. The format consists of
about 30 constructs that describes "power intent" throughout the flow.
For example...
### This creates two power domains
create_power_domain -name PDcore -default
create_power_domain -name PDmac1 \
-instances ethernet_mac_1 \
-shutoff_condition {pcm_inst/pse[0]}
### This creates an isolation rule between the domains
create_isolation_rule -name iso_rule1 -from PDmac1 -to PDcore \
-isolation_condition {!pcm_inst/pice[0]} \
-isolation_output high
What Ted said on the Troublemaker's Panel is true. It's important to note
that Cadence tools support and implement this TODAY. Our training last
month took us through labs and taught us how to present the Front End
Design Team/CPF Demo (which runs an entire frontend flow from planning
though simulation, top down MSV synthesis and logic verification.) Since
my group were mostly RTL Compiler and Conformal AE's, we did not go
through the SOC Encounter/GDS portion of the flow.
What I got from the training was:
- the customer does not need to have all of these tools to benefit
from CPF, *any* of our tools, run stand alone, can read the power
intent from CPF.
- vManager reads the CPF and then generates a vplan and a testbench
to measure all the power related control signals and power modes
of your design. The power intent gets added to the Power Section
of the vplan.
- NC-Sim will read CPF and do a Virtual Power Shutdown of PSO blocks.
Note that NO RTL MODIFICATION is needed. This means that 2 blocks
with the same RTL source can have different power and/or shutdown
requirements and be synthesized, simulated and implemented by
reading the power intent from CPF. No "hacking" of the RTL is
required anywhere.
- RTL Compiler will read CPF and insert clock gating, level shifters,
isolation logic, etc. TOP DOWN, automatically without the need to
spin off separate compiles, budget, etc. RTL Compiler will also
report power in all power modes reflecting the effect of shutting
down different power domains.
- Conformal Low Power will read the CPF and verify that power domains
are correctly implemented, level shifters and isolation cells are
inserted according to the power requirements.
- Encounter Test will read the CPF and generate ATPG patterns to test
the various power modes. The cool thing about this is that ET can
shut down various power domains so that excessive power is not
consumed (and chips burned up!) on the tester during scan testing.
ET will report cumulative coverage as each power mode is run
one-by-one.
John, I want to stress again what Ted was stressing on the panel that
these flows are available today. I hope to make your panel next year.
- Jason Ware
Cadence Design Systems Plano, TX
Index
Next->Item
|
|
