( ESNUG 445 Item 10 ) ------------------------------------------- [05/24/05]
Subject: ( ESNUG 402 #2 ) Ex-Silicon Ensemble User Happy with PhysOpt/Astro
> There should be no need to ungroup DesignWare components before reading
> the netlist into SE. SE flattens the design anyway after it has been
> read in.
>
> However you might want to ungroup the DesignWare components anyway, not
> because SE needs it, but because Design Compiler can optimise the logic
> further to possibly produce a better result after ungrouping the
> DesignWare (DW). Note that this means that information about DW is lost
> and any optimisations by changing DW components architectures is not
> possible.
>
> - Arvin Patel
> Chello Broadband Norway
From: Raphael Bingert <raphael.bingert=user company=st spot gone>
Hi, John,
Prior to using 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. The 0.13 um design we
worked on had 400 K instances, 25 mm2 in area, 15 clock domains with 200 MHz
maximum clock speed. An initial placement and global routing was performed.
Timing analysis inside PrimeTime was performed at this stage (with ideal
clock trees) and ECOs (LBO inside DC) were implemented to fix failing paths.
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 resynthesized.
- No way to check timing reports inside the SE environment w/ confidence.
- 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 PC/Astro flow -- 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.
The quality of results is very good in terms of timing. It is also very
important for us to have area and power recovery features that are placement
aware for better optimization.
The TCL timing constraints compatibility across DC, PhysOpt and PrimeTime is
a must for us.
We'd like to see a CTS tool like Astro-CTS which can handle our complex clock
tree structures integrated into the same environment. We also need to have
routing capability integrated in the same tool. Having one set of timing
constraints defined in TCL and one timing engine is a must for us.
In the final analysis, PhysOpt is a fast tool with good capacity and a good
physical synthesis engine.
We have been pleased PhysOpt integrates a synthesis engine along with
placement and routing estimation features. It has significantly reduced the
area and power and shortened our runtime schedule. We look forward to their
IC Compiler because it integrates CTS, routing, multi-corner/multi-mode
optimization and multiple voltage support.
- Raphael Bingert
STmicroelectronics Longmont, CO
Index
Next->Item
|
|
