( ESNUG 327 Item 6 ) ----------------------------------------------- [9/2/99]
Subject: ( ESNUG 325 #1 ) Avanti Timing-Driven P&R Clashes With Synopsys
> Currently, we just use the Timing Driven feature of Avanti P&R and it
> turned out to be a nightmare because our frontend designers love the path
> segmentation feature of Synopsys and they create a false path from any
> point to any point by just creating a hierarchy there. Then when you go to
> the Avanti backend tool you have to dig out each net, or cell Input/Output
> and tell it to disable timing through it. OK, it is similar to doing it
> in the front end, but then you have hierarchy in front end, and a flattened
> verilog netlist at the backend.
>
> I hope Avanti Static Timing Analysis can start supporting something more
> then just the CLK pins / input ports and D pin of FF / output ports for
> its start and end points.
>
> - Manish Shrivastava
From: "Paul.Zimmer" <paul.zimmer@cerent.com>
This is just the tip of the iceberg. I work on telecom chips with lots
of muxed clocks and multi-cycle paths. By extensive use of looping and
proc's in tcl, I've managed to keep the primetime script for the current
chip down to about 20 pages.
The timing-driven layout tool MUST understand all of this. If it doesn't
understand it, then it's optimizing with garbage.
Even with simpler chips, the timing-driven layout tool is going to have
to understand quite a lot. Do you really want it spending all of
its cycles, and hurt timing on your critical path, trying to optimize
all your multicycle processor read/write paths because it doesn't
know they're multicycle?
Even if the P&R static timer has all the hooks required, I'm really
not excited about trying to re-do all that PrimeTime code for
another static timer.
My opinion is that the placement tools will have to hooked
directly to the static timing tool. This obviously gives Synopsys
a big leg up, since it now virtually owns static timing.
Synopsys has already announced that it is headed this way. Aart made
it clear several years ago that he considers the common static timing
"backbone" to be a key component.
Unfortunately, the desired backbone is PrimeTime, but their current
backend tools only support DesignTime. If you have complex clocking
situations, the difference is very noticable. But, I'm sure they're
working on this (at least, I hope so!).
- Paul Zimmer
Cerent Corp.
|
|
