( ELSE 06 Item 16 ) -------------------------------------------- [ 06/23/06 ]
Subject: Fishtail Focus/Refocus vs. Blue Pearl
WHERE'S WALDO? -- My congrats go to the Fishtail people, because for the 2nd
year in a row their technical rivals, Blue Pearl Software, was M.I.A. with
the users in my survey this year. I guess there aren't that many Indigo
users out there compared to Focus/Refocus users. Congrats Fishtail.
We benchmarked Fishtail Focus/Refocus on an eval version of a MIPS32
processor IP core. Our goal was to achieve the highest frequency with
this core using standard design flows, augmented with the Fishtail
post-processing tools. Our objective was to study whether the Focus
generated false-paths improved flop-to-flop timing on this IP. We set
a target clock period of 1.87 nsec (535 MHz) in 90 nm. We used DC for
RTL-to-gates and Magma for gates-to-GDS-II. We used "useful skew" in
Magma. We compared timing after place and route) for our baseline flow
and the Fishtail flow -- the only difference being the Fishtail flow
introduced register-to-register false paths after the fix-clock stage
(after clock-tree synthesis) in Magma. Our focus was on flop-to-flop
timing, so we ran both designs with and without IO delays. We
compared timing within Magma.
Fishtail generated 57 register-to-register false paths. We mapped these
over to the "fix-clock" netlist using Refocus. 35 false paths were
mapped over by Refocus -- the remaining 22 had been optimized out. We
verified the 35 false paths in PrimeTime (using the verify_false_paths
script provided by Fishtail). All the false paths passed verification
in PrimeTime.
We found that in the case where the MIPS core had overly-constrained IO
timing, *both* the Fishtail and Baseline flow did not meet timing by
~160 psec, there were about 2,100 violating endpoints and TNS was about
83 nsec. However, for the run *without* IO timing constraints we found
that the Fishtail flow was significantly better:
Baseline Fishtail
WNS 44 psec (522 MHz) 14 psec (530 MHz)
TNS 5,155 psec 134 psec
# Viol. 265 31
As our focus was on flop-to-flop timing, the timing improvement we saw
without IO constraints on the MIPS core was legitimate and meaningful.
The TNS improvement provided by the Fishtail exceptions is significant.
The conclusions we draw from this study:
If a design has a chance of meeting timing at the target clock speed
then the Fishtail exceptions will get it over "the hump" and save time
and effort that would need to be spent to manually get the design to
timing closure.
The Fishtail exceptions did not impact final area/power numbers, so
that isn't the reason to use Fishtail.
Contrary to conventional thinking it is better *not* to introduce
Fishtail exceptions during logic synthesis but instead to pull them
in at that stage in the P&R flow where the timing numbers are
realistic. In our Magma flow this was after clock-tree synthesis
(after fix-clock).
- Krish Subramanian of Toshiba America
I have been watching and evaluating Fishtail for some time. I am VERY
impressed with this technology and with this company. They are some
very bright folks, and they are dedicated to the success of their
customers. Due to circumstances out of their control, we have not
completed our evaluation and thus don't actually own a license, but as
soon as I get some spare cycles I intend to complete that work and push
my management to buy this tool. They have taken a very difficult
problem and provided a pragmatic solution. Anyone using timing
exceptions and not using Fishtail is playing with fire.
- [ An Anon Engineer ]
We use it in our flow and have found Fishtail's Focus tool is well worth
the money. In our last tapeout, it caught 6 user defined exceptions
which were wrongly declared, hence probably saving us a chip revision.
It identified a large number of false paths before layout and some
number of MCPs. We were able to get to a good quality netlist sooner,
and since we needed lesser number of iterations, we reduced the usage
of our expensive PD tools.
Conceptually, their flow seems to be a bit convoluted, but the Fishtail
folks have done a very good job of automating the flow of constraint
generation and constraint validation, and most of our designers get up
to speed in a few days.
- [ An Anon Engineer ]
We are using Fishtail on almost all of our chips and see significant
benefits in terms of speed improvements. We are consistently observing
reduction in negative slack when using FP's alone. Today, we are only
using the FP's in the flow and using PrimeTime to justify the FP's. So
far, we have not observed any incorrect FP's. In future, we do plan on
using the MCPs also, but we want to make the validation flow for MCP's
smoother before using them. Fishtail does have the ability to validate
user's constraints too, and this flow is also being tested.
Regarding your question of 'useful or a waste of time and money'; well,
all I can say is that anyone who is involved in timing closure must
realize the importance of good SDC file. Also, the fact that other
EDA companies are also chasing this technology is justification enough.
- Himanshu Bhatnagar of Conexant Systems
We have Fishtail but do not use it.
- [ An Anon Engineer ]
Recently I finished an evaluation of Fishtail's tools in our ASIC flow.
I picked a couple of large blocks (both were close to 1 million
instances) and ran Fishtails tools on them. I wanted to see the effect
Fishtail's tools had on synthesis, timing, and area.
On the first block, the major clock domain had 755 violations. After
applying Fishtail false-paths and multicycle paths, this clock domain
met timing constraints. Combinational area improved by 1.03% giving a
total area improvement of 0.26%. I started with 780 multicycle paths.
The tool found that 18 of these were incorrect when viewing this block
only. (It can check your false-path and multicycle paths.) We went
back and found in the context of the full chip, these too were good.
The run time of the tool took 28 hours to find 7706 false paths and
62 hours to find 296 proven multicycle paths. (The tool can produce
many more potential multicycle paths, but these need to be proven by
simulation or examination.)
On block 2, a clock domain had 134 violating paths. After applying
Fishtail false-path and multicycle paths I had 17 violations.
Combination area improved by 3.03% giving a total area improvement of
1.66%. I started with 219 multicycle paths. The tool found that two
of these were formally incorrect. The tool took 10.5 hours to find
3,096 false-paths and 51 hours to find 7,070 multicycle paths.
In my test of the tool, I generated false-path and multicycle paths
from the RTL, but did not apply them to initial synthesis. I tried
this, but found it hurt me -- area went up and timing degraded in
spots. Fishtail has a tool called Refocus that takes RTL constraints
and applies them to gate-level netlists. I used this tool. Running
the Refocus tool takes minutes. I then did an incremental compile.
This is where I saw benefit. Only about 2/3 of the constraints mapped
over. The points that did not map had been optimized out or into large
complex gates. Using the refocused constraints does not penalize area
by causing intermediate points to stick around. I might also point out
that final comparison values were generated from flows that did
incremental compiles, too. I believe the numbers were a true
apples-to-apples comparison.
I did not find much change in synthesis time. Time went down slightly,
but in general remained approximately the same. Both blocks take
several hours to compile. I would usually kick them off before going
home, and get new results sometime the next morning.
The tool writes out assertions to prove the potential multicycle paths
if you have a simulation environment that covers the RTL well. This was
not my case, and I only used multicycle paths that were formally 100%
proven. I had a large number of IP blocks that I did not have full
verification simulations available. I wish the technology of formally
verififying multicycle paths were more robust.
As I went through the evaluation, I ran into several problems with the
tool, but Fishtail promptly corrected them. I usually had fixes within
an hour or two. They are very responsive.
- Maynard Hammond of Scientific-Atlanta, Inc.
We ran Fishtail Focus on a 530 K cell instance design with 30 specific
defined clocks and 55 internal generated clocks. Focus runtime was
about 5 hours on a 32-bit Linux machine and it identified 15,085 false
paths. 1,636 of these were register-to-register false paths and we
applied these in our Magma flow at the fix-time (RTL Synthesis) stage.
Focus also generated 21 multicycle paths where 18 were proven valid
using NC-Sim simulation. We observed:
User Constraints
User Constraints + Focus false paths
Instance Count: 538 K 533 K
Total Negative Slack: -21,729 nsec -20,656 nsec
Violating endpoints: 17,500 16,313
So, by introducing Focus false paths we were able to reduce instance
count by 1%, reduce TNS by 4.9% and reduce the number of violating
endpoints by 6.8%.
I have found that the tool can be a little difficult to set up, but
once I became familiar with the format required setup became easier.
The most difficult part was setting up the clocking structure. One
thing that helped was that I was able to export my constraints from
Magma (clocks, etc.) in SDC and import them directly into Focus for
the required clocks in the setup.
- [ An Anon Engineer ]
We used Fishtail on our entire design which is about 2 million gates.
There were about 80,000 false paths identified and all of them were
truly false paths. It also identified about 8,000 Multicycle paths.
We confirmed all these MCP by running our complete regression to make
sure these are indeed MCPs.
We didn't take this feedback to layout as we were well into final stage
of tapeout. Next design I would use this tool in the beginning and
output from Fishtail will be used for synthesis and layout.
- [ An Anon Engineer ]
Index
Next->Item
|
|
