( ESNUG 446 Item 12 ) ------------------------------------------- [09/01/05]
From: Sam Appleton <sam=user domain=azulsystems pot calm>
Subject: Sequence PhysicalStudio Saved Us When First Encounter Couldn't
Hi, John,
We taped out a very large SOC 14 months ago: big chip, fast clock, 0.13um
TSMC G-OD, 8LM, complex interfaces, lots of nasty IP.
Azul chose Cadence SOC Encounter coupled with Sequence PhysicalStudio
tools for the backend solution. We had a lot of varied experiences
in this environment. We spent about 6 months developing a way to try
to close timing because the optimization/placement engine in Encounter
sucked so badly in that timeframe we were using the tool (3.2 release
days). Cadence subsequently cleaned things up a lot in the post-4.1
releases. Our experience with PhysicalStudio was overwhelmingly positive.
Our "pre-route" optimization in this tapeout was seriously terrible. It
consumed most of our time and frustration. PhysicalStudio did help out
here but since we were battling upstream pretty hard it could only do
so much. It's an ugly story in this area, too many painful memories that
I don't want to revisit. But it all had nothing to do with PhysicalStudio
pre-route optimization, which was very good. Mostly it had to do with
all the Cadence pre-route engines not having a correlated view of parastics
compared to post-route, and in general poor optimization technology. Again
this was not a Sequence problem, though.
Where PhysicalStudio really, really stood out was post-route. It took about
3 months for us to cleanup our post-route flow. Some of our biggest issues
in post-route were:
1. Our signoff extractor, Cadence Fire&Ice/Cell, did not output the correct
SPEF attributes for PhysicalStudio to do a good job on Post-Route
Optimization (PRO). At that time, PRO really required the Sequence
Colmbus extractor to work well. It was only with Sequence's on-site
help that we figured this out. We did correlate Columbus to Fire&Ice,
but in general we want to use only a foundry-qualified extraction flow
and will try to use Fire&Ice going forwards.
2. Tuning the PRO algorithm for high-speed designs was pretty tricky.
Once we had it right it could do no wrong -- we found very little
need for hand ECOs for setup timing after PRO was done. It worked.
3. Glitch analysis/propagation was a total disaster in this generation of
PhysicalStudio because of model generation issues for the Sequence
tools. We had to turn glitch analysis off because we moved from
-30 psec slack to -2 nsec reported slack due to model errors! Bad.
They've fixed the problem now so we'll use it on the next tapeout, but
no good for that 130 nm design then.
PhysicalStudio's PRO wound up being so good that on one particularly nasty
block, we turned off almost all pre-route optimization and got the block
through to PRO and ran that twice. Not elegant but it got the job done.
In a couple of areas Sequence support and R&D totally saved us from abject
disaster, for which we will always be thankful. Our functional paths had
massive numbers of multicycle and false paths (I'm talking 1M line SDCs at
the block level) because our memory vendor's BIST engine was not designed
to run at our target frequency. Most optimization tools totally croaked
trying to run against those constraints. We wound up throwing out the
constraints and rewriting them as around 50 case analysis statements to turn
off the BIST engine in functional mode. However, at some point we had to
optimize against those 1M constraints. We tried and tried and tried and
totally wrecked the functional timing path every time we tried. Sequence
added a multimode optimization capability in PRO that allowed us to optimize
functional mode, rebuild the timing graph and optimize again against a
separate set of constraints with a crazy-good option called -no_damage. It
totally saved us, kept the functional path intact and optimized the pseudo-
functional BIST mode down to a reasonable slack acceptable for test.
Sequence's noise analysis and fixing (but not glitch) capability really
rocks. They support (but don't recommend) the more traditional min/max SI
modes that PT-SI and CeltIC uses. Instead, their main algorithm is a
discrete window approach that cuts down on false violations. Also, their
noise fixing is outstanding. We did some correlation work on our most
difficult timing block using combinations of route avoidance and
PhysicalStudio noise fixing
Mode #1 - NanoRoute no noise avoidance, PhysicalStudio reports
slack -500 psec, optimizes to -300 psec.
Mode #2 - NanoRoute in SI avoidance mode, PhsicalStudio reports
slack -300 psec, optimizes to 0 psec.
(In addition to appreciating PhyicalStudio for noise, we had a serious love
affair with NanoRoute once that baby was oiled up and running well.)
We ran post-noise fixed blocks through Cadence CeltIC as a check, and only
found a few corner cases worth fixing, even though we debated whether it
was worth the effort.
Hold fixing in PhysicalStudio was a total disaster the first time we tried
it. We had a ton of constraint and IP issues (some IP designers really
don't understand integration timing very well, and it makes the constraint
issues a lot of fun!) that we had to work through. In parallel, Sequence
R&D seriously upreved their hold fixing capability. It worked like magic
once they got done -- along with some help from their support.
After that was done, the only hold errors we had to fix were either due to
funky IP, constraint incompatability, minor parasitic differences (between
Columbus and Fire&Ice for signoff), and OCV. These only numbered in the
10-20 range per block.
A couple of gripes:
1. Sequence sold our managagement team on the idea that they could replace
PrimeTime as a signoff timer. This took about 6 weeks to recover from.
It was not a replacement for signoff, and we had to do a lot of
justification to explain why we needed PrimeTime after that (startups
these days are rightly not loose with the purse strings).
2. Sequence noise-aware ILM (called PNM) flow didn't really work. Signing
off noise at the full chip was a giant hack; we got all paths in PT that
had less than 500-700 psec of slack (a lot of them), then loaded
PhysicalStudio with just clock constraints and reported timing through
these 10,000's of paths and verified that noise pushout was not greater
than the reported slack. At least we could get it done somehow. In
general, their full-chip capabilites weren't well developed at the time.
I believe a lot of this is now fixed -- and we're about to find out.
3. PhysicalStudio's ECO placer needs work. You can say this about ECO
placers in Cadence Encounter or Synopsys Astro, too. With so much
timing variance possible depending on how the ECO placer works, it's
really important to get it right. Old approaches like hole-finding and
cell-shifting just suck in the 130 nm or less domain, because cell
timing is so, so, so sensitive to parasitics. All of these ECO placers
need to be more timing aware so they know what cells it can move (and by
how much) when inserting these noise/setup/glitch/hold fixes.
Summary: our experience with Sequence was overwhelmingly positive. Their
R&D and technical support was outstanding and "concise". (In other words,
they got the job done without a lot of arguing or finger pointing. A very
focussed support and development team.) Working with their business team
was not a hair-pulling experience. They are a very good company to engage
with in complex nanometer issues.
Our chip was core-functional first-pass. Our post-silicon issues were all
around the IP that was integrated with the design (a big problem for us and
others in the future). There can be no better stamp of approval for a tool
than that. Sequence rocked.
Ironically, after we taped out the chip, Cadence support was all over us
like a cheap suit to figure out why First Encounter 3.2 didn't work worth
squat on our project. (We threw all the test cases at them and told them
to fix it or we'd go to somewhere else.) After much gnashings of teeth,
they fixed everything and gave it back to us in FE 4.1. Now we're very
happy. That whole thing got totally solved but it was not for this chip.
Sequence was the one who saved us on this design. PhysicalStudio pulled
our nuts out of the fire on this one when First Encounter couldn't.
- Sam Appleton
Azul Systems Mountain View, CA
Index
Next->Item
|
|
