( ESNUG 447 Item 5 ) -------------------------------------------- [09/26/05]
Subject: ( ESNUG 445 #10 ) Hey! SE vs. Astro/PhysOpt == Apples vs. Oranges!
> Prior to PhysOpt, our previous timing-driven flow was based on Silicon
> Ensemble and our internal tools. The input for timing constraints was a
> SDF file (generated from Design Compiler) that contained constraints
> from register-to-register based on the clock frequency. ... Our old
> Silicon Ensemble flow suffered from a number of limitations:
>
> - the SDF was huge.
> - the SDF had to be re-generated each time the netlist was resynthed.
> - No way to check timing reports inside the SE environment confidently.
> - No easy way to check if a path was properly constrained and if a
> false path or multicycle path has been properly applied.
> - Several iterations were required between DC and the SE placer before
> getting timing closure.
>
> Then we changed to PhysOpt/Astro -- PhysOpt/Astro CTS/routing/post-CTS
> optimization in PhysOpt/ECO route.
>
> The several iterations required by our previous Silicon Ensemble
> methodology are no longer necessary with PhysOpt since it integrates the
> DC engine and has the global routing information. Timing results out of
> PhysOpt correlate well with what is seen when performing signoff timing
> analysis. Thus, no need to loop.
>
> - Raphael Bingert
> STmicroelectronics Longmont, CO
From: Wasim Altaf <altaf=user domain=innotechsystems spot calm>
Hi John,
I don't know whether to laugh at or pity the good folks at ST in Longmont,
for their old timing driven flow in SE. I mean they were trying to pass
timing constraints thru SDF from DC! This is not a legitimate debate about
the merits of SE vs PhysOpt/Astro. It can't be, given their misuse of SE
to begin with. I wonder what they meant by "Several iterations were
required between DC and the SE placer before getting timing closure". How
many iterations on average? I'm surprised that they even manage to get
out that loop at all!
Obviously they either didn't know of or cared much for the native SE timing
engine for timing driven P&R, IPO, CTS and ECO. Even if there is a large
difference in SE/Pearl and DC/PT delay calculators and/or tlf and lib
files, I'd imagine that sticking to the SE timing engine for the most part
would've saved many of their iterations. (I guess there isn't much point
in pointing out what they could've done in SE anymore.) Presumably they've
kept this flow all the way down to their 0.13um designs! Simply amazing!
I wonder if any Cadence AE was aware of this and what she/he tried doing
about it for the sake of the customer.
I'm not suggesting that SE is as capable as PhysOpt/Astro. (A more valid
comparison would be SE vs Apollo, but both SE and Apollo are EOL, anyway.)
- Wasim Altaf
Innotech Systems, Inc. Boston, MA
Index
Next->Item
|
|
