( ESNUG 490 Item 9 ) -------------------------------------------- [04/06/11]

Subject: Going Conformal UPF-to-CPF is doable but somewhat tricky business

> My local Cadence salesman says that Conformal Low Power has a UPF-to-CPF
> converter built into it.  Has anyone who's not trying to get me to buy
> the Conformal Low Power tool used it?  How well does it work?
>
>  1. Are the UPF-to-CPF conversions accurate/trustworthy?
>
>  2. If we design with a converted UPF will TSMC honor our design?
>     What specific processes and nodes?
>
>  3. What about STA?  Will we have to convert the already converted
>     CPF back to UPF for sign-off in PrimeTime?
>
>  4. What other verification issues will bite us with converted UPF's?
>
>  5. What key differences between UPF and CPF should we watch for?
>
> I'm sorry for all the questions, John.  We just don't want to get burned
> based on an EDA salesman's advice.  Can any *users* speak up on this?
>
>     - from http://www.deepchip.com/items/0490-02.html


From: [ All Hail Megatron! ]

Hello John,

I think I can put some comments on this.  However, please put me ANON.

I happen to finish a project using both UPF and CPF recently.  The flow was
Design Compiler and SoC Encounter.  So we have to use both UPF and CPF.

UPF is golden in the design flow.  We use it in DC, Formality and PrimeTime.
The golden LOW POWER sign-off tool is MVRC.  CPF only used in SoC Encounter
for P&R.  Before and after P&R, we use MVRC to check netlist against UPF.

One of my tasks is to translate UPF to CPF.  At the beginning, my perception
is that Conformal Low Power can do it automatically.  Soon I realize that it
is a must to post-process the generated CPF.  Finally, what I end up using
is a semi-auto-semi-manual flow.

   Semi-auto: I use Conformal Low Power to translate UPF to a raw CPF.
 Semi-manual: I do some editing to make the raw CPF work for SoC Encounter.
              (Could be realized by some scripts maybe.)

The auto part: Translation is done by "Power Intent Architect" (PIA).  It is
quite simple.  You read the libraries, the netlist and UPF; then use PIA to
write a CPF.  (Side note: PIA is able to write CPF from UPF as well).  My
company has built a wrapper on top of PIA.  After Conformal Low Power writes
the CPF, the wrapper will do some checks.  Then, the wrapper will merge some
prepared CPFs with the generated one to deliver a final CPF.  Those prepared
CPFs?  SoC Encounter flow requires CPF to have operating corner definition,
analysis view definition and library set definition.  These information are
not available in UPF.  User has to prepare and add them to the final CPF.

The manual part: Now there is a complete CPF available.  But my physical
implementation colleague cannot use it, maybe it is only for our case.

First of all.  In our UPF, we have a nested power domain structure.  We have
2 small always-on domains wrapped by a domain that can be shut down or
scaled down.  On top of it, we have another always-on domain.  In UPF, we
defined 4 power domains, according to the suggestion from Synopsys.  In CPF,
we merge 3 always-on domains into 1, to facilitate P&R flow.

Another part is the location of isolation cell and level shifter.  In UPF,
you can define it with self, parent, sibling, fanout or automatic.  In CPF,
you have two options: to or from.  I don't argue their pro and con, however,
there is a problem when sometimes you cannot map it exactly.  The docs from
my company says one location is not supported by the translation (I have
left the company, sorry I don't remember which combination).  In my case, I
will change location of isolation cell and level shifter in generated CPF.

The third hand change is the connect_supply_net to create_global_connection.
What is generated is like:

 create_global_connection -net VDD -pins {U_1/U_2/U_3/VDDA U_4/U_5/U_6/VDDB}

You have to change it to:

 create_global_connection -net VDD -pins VDDA -instance U_1/U_2/U_3
 create_global_connection -net VDD -pins VDDB -instance U_4/U_5/U_6

otherwise you get an error in SoC Encounter.

Baseline: if you have a big UPF file generated by Design Compiler, it is
definitely useful to translate it using Conformal Low Power PIA.  In my
case, because of the complicated nested power domain structure and domain
crossovers, I have 100's of boundary points with level shifters/isolation
cells and another 100's of boundary points without them.  For isolation
cells, some need clamp value 1 while some 0.  Using automatic translation
eases my life, though I have to do postprocessing.

Ideally my recommendation is to have a nice database of boundary points
that need or don't need level shifter/isolation cell and their clamp value
if any.  Write a script to generate corresponding UPF/CPF.  These things
are the most changeable ones during the entier development phase.

Above is my comment on 1st question. I have no idea for 2nd question.

For questions 3-5, my idea is you don't need to translate CPF back to UPF,
at least we don't do it.  My recommendation would be "maintain a golden UPF
across the entire design phase" if you use MVRC and PrimeTime for low power
and timing sign-off, respectively.  If your sign-off flow uses CPF, you also
don't need to translate it back.

UPF to CPF conversion is somewhat tricky, but patience and carefulness will
solve this problem.

I have left the company end of February and I cannot access the design data.
I wish my memory serve me correctly, and I am sorry if some details are not
100% accurate.

    - [ All Hail Megatron! ]

         ----    ----    ----    ----    ----    ----   ----

From: [ The Ghost of Christmas Past ]

Hi, John,

Please tell the UPF-to-CPF guy that translating between the two formats is
problematic because their concepts on overlap 90%.  A Perl script could do
it if it was only syntax differences.  What will bite you is those 10% core
differences in what each format encodes.  Despite what the Cadence salesman
promised with Conformal Low Power, this means you will have to hand code
parts of the translations, a doable but somewhat tricky business.

Every engineer knows that EDA salesmen lie, so you can't blame them when
you get burned.

You'd be better off if you could get your CPF lib fully certified from your
fab.  That way, if something goes wrong, the fab owns the problem.

    - [ The Ghost of Christmas Past ]

         ----    ----    ----    ----    ----    ----   ----

From: Bill Bayer <bayer=user domain=si2.org>

Hi, John,

I cannot comment on questions 1-4, but you may want to give people a copy
of this 70 page PDF that gives a detailed analysis of 1801 (UPF) and CPF.

Be forewarned, there are different versions of UPF being used!

    - Bill Bayer
      Silicon Integration Initiative, Inc (Si2)

 [ Editor's Note: This Si2 paper in #64 in the DeepChip Downloads. - John ]
Join    Index    Next->Item






   
 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)