( DAC 04 Item 24 ) --------------------------------------------- [ 02/09/05 ]
Subject: Fishtail Focus
DOWN THE GARDEN PATH -- One of the more frustating things in chip design is
to discover your DC runs chowing mondo runtime trying to fix timing problems
that don't really exist in real life. This is where Fishtail Focus steps
in to find all those misleading timing exceptions and false paths.
We use Fishtail Focus for almost all of our designs. We find that
the quality of the netlist improves dramatically when the exceptions
generated by Focus are used. For our latest design, the TNS reduced
from -3.0 nsec to -0.25 nsec. We've incorporated Fishtail in our
ASIC methodology and are using it on every project.
The main problem with this flow is that you really have to be careful
about how to use this tool. If you just let it rip, you may end up
with 10,000 exceptions. Fishtail provides several options that limit
the exceptions, giving the control to the users. In our last design,
by setting the -max_through to 2 (or something like that) we limited
the number of exceptions. Of course, this may not be optimal, but
there has to be balance between runtime and QoR that you're able to
live with.
Focus works on internal net names and when DC synthesizes the RTL, the
net names are lost. This is another problem that we constantly face.
We worked with Fishtail on this issue and they have introduced another
tool called ReFocus that remaps the netlist names to the RTL. We are
presently evaluating this new tool.
- Himanshu Bhatnagar of Conexant
FishTail can be very useful in updating constraints, or taking in an
IP with little knowledge. It helps to clean up constraints, and
identifying missing constraints. What is needed is a tool to help
verify the constraints generated by FishTail.
- [ An Anon Engineer ]
Fishtail Focus strengths:
- Focus can find thousands of false path & multicycle path exceptions.
This is great for helping to avoid iterations through timing
closure. Designs are way too large to try to manually generate these
exceptions, and I haven't looked at what Atrenta or Cadence has.
Most false path and multi-cycle paths that LSI finds manually are
through timing closure; the designer can't meet timing on a path,
looks at the netlist and concludes that it is a false path or
multi-cycle path.
- Focus is fairly easy to setup and run on a design, it just needs the
clocks defined and the synchronous resets.
- Many of the false paths and multi-cycle paths that Focus finds may be
in non-timing sensitive parts of the design, but Focus can accept a
list of timing critical endpoints. Focus will then only generate
false paths and multi-cycle paths for these critical endpoints.
Fishtail has a script that can easily generate the critical endpoints.
Fishtail Focus weaknesses:
- The major weakness of Focus is verification of the false paths and
multi-cycle paths generated. Sure it can generate tons of them, but
how do you know if it didn't mess up and is generating garbage?
Fishtail does generate assertions that can be checked either by a
property checking tool or in simulation. But if you use a property
checking tool, you need a good initialization sequence. If you make
a mistake in that, whole sections of the design can be disabled, and
the property checker will unwittingly conclude that many assertions
have been proven, even though the relevant logic wasn't exercised.
If you use simulation, you need a comprehensive simulation to ensure
that all scenarios are exercised. In the past Fishtail relied on
property checking to verify the assertions, and are just now starting
to consider the simulation flow. We discovered for example that
their assertions could not be read into NC-Verilog due to incorrect
delimiters and name conflicts.
- The software and technology is relatively new so we are concerned
about incorrect false paths and multi-cycle paths, and we have found
examples of both. In some cases these were inconsequential, some
false paths were not paths at all, and some multi-cycle paths were
really false paths. But Focus did find 2 false paths that were real
paths that did need to be timed, and several multi-cycle paths that
were incorrect.
Fishtail did fix the problem with the 2 incorrect false paths in
their latest release. We have also noticed that the number of
multi-cycle paths reported by Focus fluctuates wildly from one
version to the next.
We have run on smaller designs, and the runtime for finding false paths
is reasonable. But the runtime for multi-cycle paths can be over
2 days for a small design, so we are concerned that larger designs may
take over a week to run.
Here are the data from two designs that we have run Focus on:
Design #1
Size: 2M gates Clocks: 14
false paths: 9840 false path runtime: 3h 38m
multi-cycle paths: 3896 multi-cycle path runtime: 21h 58m
Design #2
Size: 1.2M gates Clocks: 30
false paths: 2661 false path runtime: 2h 54m
multi-cycle paths: 1554 multi-cycle path runtime: 65h 13m
False paths and multi-cycle paths are the number found by Focus. The
runtimes are the wall time for Focus to run on a 64 bit Linux machine.
- David Vinke of LSI Logic
I evaluated Fishtail for a few weeks over 6 months ago. My overall
impression was that it was very fast, incredibly simple to use
(scripted), and basically worked as advertised.
I used 2 portions of an existing design. The first being very small,
~10 K gates if I remember correctly, the second being a major block
of ~200 K gates. Both went through with no problems, what came out
though was a suprise. The first example had roughly 100 false paths,
a few of which were examined by the designer, and given a "hmm...
probably is a false path" diagnosis. The second example had over 70 K
false paths.... whoa, that's a whole lot of reconvergent paths among
other things.
The question at that point became "what can we do with all these timing
exceptions?", we certainly can't feed them into synthesis, physical
design, and backend timing analysis. Not only will the tools probably
choke, but the paths could possibly morph into new (non-false?) paths
based on physical synthesis in the backend.
Fishtail is good technology, but certainly requires a lot more thinking
about how it should be applied during the design cycle. The best
potential I see is at final signoff timing, where you could filter
through the existing timing violations and quickly determine if it is
a false path or not. That doesn't mean that you've saved any effort in
getting there, the physical synthesis, placement, etc... all had to try
and meet timing on all the paths. But it could save you from doing a
few pointless ECOs. They had some code to assist in this, but we
didn't get a chance to try it out.
Where Fishtail really belongs IMHO is embedded deep within the timing
analysis engines behind every optimization and signoff tool in the
flow, assuming that it could be verified through 3rd party formal
tools. They were working on this, but did not support our current
tool. They were eager to partner with us to make this work, but we
weren't quite ready to seal the deal. My company prides itself of
being frugal... this definitely puts new EDA tools low on the list.
Since working with Fishtail, I've become very busy with a design in
progress. I'll keep my eye on them.
- [ An Anon Engineer ]
Strength
- Only commercial tool at this moment.
- False path generation is effective for better slack distribution.
We got some results using sample design (near real design).
Weakness
- Validation of generated constraints is necessary.
- Lack of validation capability and generation quality.
- Can not handle partial gate level description in RTL in effect.
I am hands-on Focus user, but its purpose is mainly for evaluation
not for real design.
- Toshinori Inoshita of STARC
We did evaluate Fishtail Focus within Philips Semiconductors from
June to September last year. At that time the evaluation concluded
that the tool was not mature enough to be part of the Philips flow.
- Benoit Mazuyer of Philips Semiconductors
We're still evaluating Focus. We were interested in this tool
because at that time (September 2004) Fishtail was the only tool
that was able to generate constraints.
We have many manual constraints and some of them are conflicting
with the Focus generated constraints, but we're still in the
evaluation phase and developing a methodology that will best
utilize the strengths of this tool as well as our existing flow.
- Michael Lin of ATI
Fishtail's Focus tool quickly found all multi-cycle paths and false
paths built into my mixed-HDL evaluation test RTL. In addition, it
found an multi-cycle path that I had not considered, but after
examining further, found to be correct.
It did NOT, however, give any warnings or errors for a bad asynchronous
data crossings in a circuit topology that I intentionally designed to
fail, i.e. high frequency sequential logic feeding low-frequency
sequential logic with no synchros.
The point here is that Focus is a pure constraints generation tool and
not a CDC analysis tool - if you define async domains, it assumes you
know what you're doing and acts in kind. The output SDC and assertions
files were accurate and useful.
Fishtail is command-line or batch-mode only and is simple to use and set
up. It incorporates Tcshell-like command line functions and makes
command-line work a real breeze, although working with variables and
multiple scripts gets complicated when trying to call a read-design
script from the main constraint analysis/generation command known as
write-gtc. Some improvement here could make scripting a bit more
flexible and flow-ready. I've gotten around it by creating a mess of
environment variables to pass between parent/child processes. That
shouldn't be necessary, no matter what scripting flow a user selects!
Focus supports many DC Tcl script procs that would be found in any
designer's pre-existing Synopsys clock and I/O scripts. This is handy
when trying to get running with Focus, which itself is rather simple.
I am now running parallel Focus runs on a multi-million gate chip that
is mixed HDL in many places, although it is mostly a VHDL design.
Their front-end parser/interpreter is very, very new and many errors
were encountered parsing the many intricacies of VHDL. There are still
a few bugs to work out here, but for the most part, the tool allows you
to make great progress in most cases by easily accepting absent
hierarchy, telling you what's missing, and doing it's thing anyway.
Focus supports full-chip/sub-chip analysis or bottom-up builds to be
fed into a final top-level analysis. To date, I've not completed a
full bottom-up run.
Now for the roast beef: run-times. I'm seeing about 3 to 5 days when
analyzing a 600K instance design that has about 3 asynch clocks and
several derived clocks - a day or less for false path analysis. Multi-
cycle path & false path output is on the order of 100's to 1000's.
A method is provided for pairing this number down with critical endpoint
listings, but I've not attempted this yet. The tool analyzes each
state-space of the design in iterations and the number of iterations and
logic groupings. The user has control over the time spent on each
grouping and the number of full iterations, but this, like any analysis
tool, is where the magic happens on the part of the user. You've got to
find the sweet spot between too much run time and just the right amount
and this can take many hours/days to figure out for each major block of
your design (major read as 500K gate/instance type major).
Fishtail lacks built-in formal model checking, although the claim is
that all false paths and multi-cycle paths generated in a "unbounded"
run mode will be 100% accurate, whereas multi-cycle path's found in a
faster, "bounded" mode are "more-than-likely" accurate and must be
checked by a formal model checking tool or designer that knows the
design as well/better than any tool can know it. I don't know many
humans like that.
Unfortunately, the faster and more prolific multi-cycle path generation
mode is the bounded mode, leaving the user to the task of gaining
confidence and being sure that a deadly false false path or multi-cycle
path isn't getting through to the sign-off STA scripts! This could lead
to a 2 tool approach -- one to generate, one to check.
Last note, every design team really only cares about constraints that
cover true violations that slow/impede synthesis, P&R, or timing-
closure. If the list can be made in a few days, or just a few weeks,
for every block of the chip, then applied down against only the real
timing violators, then validated from there using mixed-HDL formal
model-checking or visual inspection, a LOT of time can be saved for
our team. Currently, that is how I see Fishtail fitting into a flow.
All in all, Fishtail isn't magic, but it's much faster and at least
as accurate as co-workers!
- [ An Anon Engineer ]
Fishtail Focus was run on 5 design, top-down (both Verilog and VHDL).
The design sizes ranged from few hundred thousand gates to about
5 million gates.
The following are the goods and the bads about the tool.
Goods
1. If you believe "Well beginning is half done", then this is one of
the tools that you need to have.
2. Fishtail does work and points out the correct false paths and
multicycle paths. These timing exceptions were validated in
STATIC Assertion Verification Flow
3. We have seen impressive results in synthesis stage as far as timing
is concerned. During Synthesis, the setup time was targeted. No
hold violations were fixed
4. Speaking in terms of numbers, total negative slack, in synthesis on
some designs went from 3 digits (hundreds) down to zero.
5. Number of setup violations decreased by as much as 70%.
6. Only a hand full of commands. Hence easy to learn and automate.
7. 32-bit executable for Focus can handle huge designs as big as
5 million gates.
8. Run times for false path generations are acceptable. Bigger designs
take a little longer.
9. Run times for multicyle path generation are comparatively long
Bads
1. The assertion based verification flow needs to be hammered out.
Assertion based tools are not smart enough to complete the task in
acceptable time. Our acceptable time is about 8-16 hours
2. The run time of Focus during multicycle path generation might be
unacceptable for bigger designs, ( > 500K gates) as it could take
more than 12 hours. Fishtail needs to address this problem by
providing support for distribution of jobs on multiple
processors/machines. This would cut the runtime on big designs.
3. One more minor problem - Users cannot use complete SDC constraints
for synthesis and Focus. One has to use a part of the SDC
constraints (Clocks, IO delays and case analysis) to drive Focus
and then club the output SDC from Focus to synthesis constraints.
Support from Fishtail has been excellent. Fishtail has been very
responsive about any issues that were put forward and resolved them in
timely manner.
- Vikram Somaiya of Oki Semiconductor
Index
Next->Item
|
|
