( ESNUG 393 Item 7 ) --------------------------------------------- [04/25/02]
Subject: ( ESNUG 387 #4 ) PhysOpt Runtimes Are Shorter With "insert_scan"
> So far we have not seen any such issues in-house or from other
> customers using "insert_dft -physical" concerning long run-times
> to fix DRCs or larger gate counts (as compared to using a combination
> of "insert_scan -physical" and "physopt -inc -eco" commands.)
>
> - Andrew Copper
> Synopsys, Inc. Mountain View, CA
From: Neel Das <neel.das@corrent.com>
Hello John,
this has been a somewhat long-standing discussion for us with Synopsys. I
first posted on ESNUG 385 #11 regarding long compile times with insert_dft,
wherein a PhysOpt run that followed it was taking significantly longer
than after insert_scan. Synopsys replied in ESNUG 387 #4 that they were
unable to replicate this. Subsequently, Synopsys sent me a series of
switches to try out. Based on their inputs, I set up and ran three
experiments:
Experiment #1:
insert_dft -physical -map_effort low
physopt -incremental -eco
Results:
a. Runtime(insertX) 20 min
b. Runtime(physopt) 4 hours 4 min
c. Orig/Final cellcounts from physopt : 23947/33164
d. Orig/Final Densities from physopt 21.1/42.2
e. Worst setup violation in 'clk' domain -1.35
f. Worst hold violation in 'clk' domain -0.04
Experiment #2:
insert_scan -physical -map_effort low
physopt -incremental -eco
Results:
a. Runtime(insertX) 8 min
b. Runtime(physopt) 15 min
c. Orig/Final cellcounts from physopt : 23416/26819
d. Orig/Final Densities from physopt 20.5/29.8
e. Worst setup violation in 'clk' domain NONE
f. Worst hold violation in 'clk' domain -0.05
Experiment #3:
insert_dft -physical -ignore_compiler_design_rules \
-dont_fix_constraint_violations
physopt -incremental -eco
Results:
a. Runtime(insertX) 15 min
b. Runtime(physopt) 3 hours 5 min
c. Orig/Final cellcounts from physopt : 23814/33105
d. Orig/Final Densities from physopt 20.8/42.1
e. Worst setup violation in 'clk' domain -2.11
f. Worst hold violation in 'clk' domain -0.03
We're seeing significantly better runtimes and overall QOR with the
'old' insert_scan approach. Once I sent in my results to Synopsys,
they've responded with more switches:
You may want to do the following before running insert_dft -phy
physopt
set_scan_element false <non-scan-flops>
set_dont_touch <non-scan-flops>
check_dft
report_test -state (the state reported should be test-ready)
insert_dft -physcial
physopt -inc -eco
Unfortunately, I haven't had the time or the need to try these additional
switches, since based on my results, I see no reason to switch from a
perfectly usable and faster flow!
We've submitted this block as a testcase to Synopsys, and they've been
able to replicate the long runtime 'effect' with insert_dft. I'll
certainly keep you posted if there are further developments, but as far
as I'm concerned, for now, it's insert_scan!!
- Neel Das
Corrent Corp. Tempe, AZ
|
|
