( ESNUG 345 Item 9 ) ---------------------------------------------- [3/1/00]
From: Kevin Campbell <kcampbell@avici.com>
Subject: Ouch! We Got Burned By Our Motive-To-Primetime Script Conversion!
Hi, John,
We decided to take the plunge and use PrimeTime instead of Motive for static
timing analysis on our latest chip. Using the documentation available (both
from AE's and available on SOLV-IT) we translated our Motive .ref and .mcp
files to PrimeTime Tcl scripts.
Upon completion of the initial analysis, we noticed more margin than
expected on chip outputs min delays. If you blindly copy the Motive to
PrimeTime translation suggestions, and you have positive hold Tsh
requirements, you will effectively relax your external hold requirements,
and have paths that would fail in Motive pass in PrimeTime.
Here's our example. In Motive .ref:
TSH NET sram_data_0..15 REF sram_clk EDGE R SETUP 5.0 5.0 HOLD 2.0 2.0
PrimeTime commands according to docs:
set_output_delay 5.0 -max -clock sram_clk [get_port sram_data_*]
set_output_delay 2.0 -min -clock sram_clk [get_port sram_data_*]
I would expect "set_output_delay -min" to subtract the 2 ns from the min
data delay and compare to clock edge for hold. Instead, 2 ns is subtracted
from the Clock which moves the hold check in the wrong direction. The
correct command should be:
set_output_delay -2.0 -min -clock sram_clk [get_port sram_data_*]
Same story as always -- never trust a blind translation between tools!
-Kevin Campbell
Avici Systems Billerica MA
|
|
