( ESNUG 399 Item 7 ) --------------------------------------------- [08/08/02]
Subject: ( ESNUG 397 #2 ) Four Users Review Sequence's PhysicalStudio Tool
> We are looking at a tool named PhysicalStudio from Sequence for SI, xtalk,
> noise, and delay analyses. What are the advantages/disadvantages of using
> PhysicalStudio based delay calculation (lumped + coupled) with PrimeTime
> based STA in an Apollo P&R environment?
>
> - Chandrani Pal
> Intel
From: Wolfgang Roethig <wroethig@el.nec.com>
Hello John,
Before I can critique PhysicalStudio, I have to explain how it works.
PhysicalStudio has two modes of operation, pre-route and post-route
optimization. In post-route mode, PhysicalStudio works on exact parasitics
and on exact physical locations. ColumbusTurbo, their extraction tool, can
generate a SPEF file containing this information. If you prefer Avanti
tools, StarRC-XT can also generate a SPEF file compatible with
PhysicalStudio. We have tested both.
The SPEF file with coordinates enables PhysicalStudio to calculate crosstalk
-aware delay and noise and to make netlist and placement changes with
minimal disturbance of your layout. For example it could figure a timing
violation due to a large coupling capacitance on a net which can be fixed by
just putting a buffer in the middle of the net. It knows the location of
the wire segements associated with that capacitance, so it places the buffer
at a optimal location and rips out the wire segment. All my ECO router has
to do is to reconnect the segments and drop vias to the pins of the buffer.
Since the ECO route is tightly controlled, the parasitics after ECO route
are also tightly controlled. In our experience, the timing predicted by
PhysicalStudio and the timing after Cadence ECO route correlates very well.
Xtalk-based STA in PhysicalStudio
---------------------------------
Conventional xtalk timing analysis is based on the min-max time window
concept. (For example, PrimeTime-SI, Mantle, Pearl ...) A min-max time
window is the interval between the earliest and the latest possible
arrival time of a signal within a clock cycle. If the min-max time windows
of two signals overlap and there is a coupling cap between them, they are
subjected to crosstalk. In contrast, PhysicalStudio supports multiple time
windows within a clock cycle. For example, signal A may switch either very
early or very late, and signal B may switch in the middle. Therefore, the
min-max time windows of A and B do overlap, but the actual time windows
do not.
These high-resolution time windows enable a more accurate xtalk analysis.
Non-overlapping signals are ruled out, and the aggressor alignment for
overlapping signals is known with more certainty. On the other hand, any
analysis based on min-max time windows must make a pessimistic assumption
that the agressor alignment is always worst.
Another differentiatior for PhysicalStudio STA is it supports the Advanced
Library Format (ALF). ALF allows us to put more accurate data into our
timing and SI library than .lib, so that our STA results correlate much
better with our SPICE runs and our internal delay calculator. However,
the .lib version of PhysicalStudio is still reasonably accurate for design
optimization purposes. We published results at the Designer's Forum of the
DATE2002 conference.
You must test your timing constraints
-------------------------------------
We evaluated PhysicalStudio in a Synopsys/Cadence flow (PrimeTime, PhysOpt,
Silicon Ensemble, Nanoroute, NEC tools), but the following could also apply
in a Synopsys/Avanti flow:
1. You've got to test your timing constraints. PhysicalStudio STA
supports SDC natively. There is no translation involved. However,
there are some corner cases, where different tools interpret the
constraints slightly differently (which is annoying.)
Example 1:
set_multicycle -setup 5
If -hold is not specified, tool A assumes -hold 4, tool B assumes
-hold 0. If -hold is specified, say
set_multicycle -setup 5 -hold 4
Tool C counts 4 cycles backwards from 5, tool D counts 4 cycles
forward from 0.
This scenario gets a lot more complicated when the launching and the
receiving clock have different frequencies.
Example 2:
A constraint for a path appears in a file. Later in the same file
*another* constraint for the same path appears.
Tool E decides to pick the more severe constraint, tool F decides to
pick the constraint that appears later in the file.
A problem can also appear if the designer's intention and the tool's
interpretation do not match. The designer thinks that the tool
interprets the constraints one way, but the tool actually interprets
them another way. (The message here is that you should ALWAYS run a
sanity check of the timing constraints, especially if you are using
more than one STA tool in the flow.)
How do designers work around such a situation? Well, the vast majority
of paths are single-cycle paths, which do not exhibit this problem.
For multicycle paths there is always a workaround:
If the designer decides that the *intended* timing on the path is
already met, the path can be declared as a false path henceforth.
Every tool understands that. (Which tools have we looked at?
PrimeTime, Pearl, PKS-STA, Mantle, PhysicalStudio-STA, Sonar-STA.)
If the timing is not met, get rid of that multicycle constraint. Then
it becomes a single cycle path. Let the tool optimize until the
designer decides that the intended timing is met.
It is possible to tweak the constraints, until PrimeTime and Studio STA
give the same answer. If you have to, you can do this test with a zero
wireload model or with a dummy SDF file.
2. If you want to use PhysicalStudio for delay calculation and PrimeTime
for STA, you have to output an SDF file from PhysicalStudio.
Theoretically, PrimeTime should give the same result as PhysicalStudio
STA with the same SDF file.
3. Test your ECO router. We have used Cadence Wroute and NanoRoute. You
probably want to use Apollo/Astro. Other Sequence customers are also
using Apollo/Astro.
Issues we found
---------------
We tried PhysicalStudio on designs ranging from >1 M gates to 5+ M gates.
The issues we found.
1. Sequence needs their own ECO router
There is a strong dependency between PhysicalStudio and external tools,
and if either one breaks, the flow breaks. We used Cadence's Wroute
version in Silicon Ensemble 5.3.138, and Nanoroute version in 2.5.6.
The biggest enhancement I wish Sequence to consider is to integrate an
ECO router into PhysicalStudio, so that it can output a DRC-clean DEF
file. An external ECO router adds its own issues and always requires
some flow tweaking.
2. Only one level of clocks
Only one level of generated clocks are supported. Constraints with a
generated clock refering to another generated clock have to be modified
in a way that a generated clock refers only to a primary input clock.
Sequence is working on an enhancement.
3. Placement legalization didn't always work
This feature did not work in one of our designs. We had to do placement
legalization with Cadence Qplace. Sequence is working on a fix.
Meanwhile, use your favorite placer.
4. TCL commands
PhysicalStudio has around 500 commands and most of them are documented.
About 10 commands are cryptic, but documented. Example:
Phase1N This does net splitting
Phase1A This does driver upsizing
About 15 commands are intuitive, but undocumented. Example:
report_clock_delay This does, well, what it says.
This sometimes makes it difficult to deviate from a pre-scripted flow
and develop customizations.
5. SDF output sometimes misses a few nets
In one design with 800 K nets, the SDF annotation was missing for a
couple of nets. However, we did not investigate this issue very deeply,
since we do not depend on the SDF output from PhysicalStudio in our
design flow.
6. Not all software patches worked
Sequence has been pretty responsive in fixing bugs and issues, but not
all their patches did work right away. Using the officially released
software and sticking to workarounds until the next major release works
better than trying out every patch.
PhysicalStudio offers both analysis and optimization using the same engine.
It interfaces with Verilog, LEF/DEF and SDC. It requires an external router
to complete the ECOs. The accuracy of its timing and xtalk analysis is good
with .lib and excellent with ALF.
I recommend PhysicalStudio for post-route optimization of timing and signal
integrity issues.
- Wolfgang Roethig
NEC Electronics Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: Sudhanshu Jain <suds@broadcom.com>
Hi, John,
We've used PhysicalStudio to do extraction and delay calculations for two
large 0.13 um designs at Broadcom. One is back and working and the other is
still in fab.
Our previous standard flow was :
Star-RCXT -> Primetime -> Celtic -> PrimeTime -> hand fix SI problems
Often we would have to go through this multiple tools loop 3-7 times to
close timing and SI. We were excited when Sequence said that they could
handle all of these tasks within one tool and do automatic fixing of SI
problems. Our big concern was if we could trust their analyses versus
silicon since we already had a relatively successful (but painful) flow.
We spent a lot of time doing correlations of their extraction as well as
their delay calculator and timer.
We extracted with both Star-RCXT as well as Sequence's Columbus tool and
actually discovered that we were using the wrong Tech file for Star-RCXT
since the numbers weren't correlating. Once we fixed that, we got
correlation to within 5% between SPEF from Star-RCXT and Columbus (as
determined by using PrimeTime to do timing.)
Then we correlated Delay Calculators by taking SPF from Star-RCXT and
running it into ShowTime and into Primetime. This too correlated to
within 5%. While PrimeTime was our signoff delay calculator, we were
still constantly getting RC-009, RC-004, RC-008 warnings from PrimeTime
(due to the simplistic driver model used by PrimeTime and issues with
Broadcom libraries.) So we had some doubts about how much to trust and
to pad the PrimeTime results in the first place. But, since other
groups had successfully taped out 0.13 um chips with PrimeTime, we had
to consider those results to be "golden". So the answer to Chandrani's
question is that we found correlation to within 5% for ShowTime and
PrimeTime delay calc and timer.
We also did a correlation between SDF generated by PhysicalStudio into
PrimeTime versus SPF from PhysicalStudio into PrimeTime. We found they
correlated to within 2%.
- Sudhanshu Jain
Broadcom Corp. Milpitas, Ca
---- ---- ---- ---- ---- ---- ----
From: [ Call Me Ishmael ]
John,
I ask that you post my reply anonymously.
We have been using PhysicalStudio with NoiseIT for a number of designs.
The first thing you will notice is the PhysicalStudio is much faster
than PrimeTime. We do a lot of timing analysis with SPF file. PrimeTime
is dog slow, and capacity is very limited! PhysicalStudio can easily do
timing analysis on 1 million placed objects with full SPEF in under
15 minutes.
We found that PhysicalStudio's timing results matched PrimeTime within
+/- 1%. But Apollo's timing engine is really a piece of junk. We had
found a number of "features" in Apollo that makes it quite different
from PrimeTime and PhysicalStudio. In our flow, we use Apollo to do the
initial placement. It was not timing driven since its timing engine is
no good. It's too slow as well. We use PhysicalStudio to do in place
optimization, and then ECO the changes into Apollo. The final timing
check is done using PhysicalStudio with NoiseIT. We use the tools to
optimize for setup, hold, max cap, and max transition violations. The
tools fixes noise induced delay as well. Initially, we use PrimeTime
to double check the final timing results. But after a few successful
chips, we don't even bother to do that anymore.
It took us some time to integrate PhysicalStudio into our Apollo flow.
The tool has a very flexible TCL interface. The Sequence folks wrote
it in such a way that it can be customized in every possible ways. This
meant that it's not a simple tool to integrate into ones flow. We needed
it to work seamlessly between synthesis and P&R. Now that our flow is
finally in place, timing closure is a 95% automated process.
There were a number of limitations when we first got started more than 2
years back. They didn't support having both a slow and a fast library
residing in memory at the same time. So, it was bit of a pain to optimize
for setup using slow lib, get out of the tool, load in the design with the
fast lib then optimize for hold. They have fixed this about a year ago.
It was not building buffer trees that were timing optimal. That has been
fixed.
To handle scan and test logic embedded in your design, you have to "false
path" every scan path during your setup of PhysicalStudio and then optimize
for hold at both slow and fast corners.
PhysicalStudio doesn't know how to automatically handle clock dividers. You
have to define generated clocks. It has no problem with propagated clock.
One short coming: it doesn't have the ability to back annotate SDF.
Their 64-bit version doesn't seem to be as stable as the 32-bit version.
The 32-bit version can handle upto 1 million place-able objects; which is
good enough for us.
In the first few months, we were finding bugs at a rate of 2-3 a week.
They gave us hot fixes at a rate of every 1-2 weeks. Very fast turnaround
time. Basically, if we are dead in the water, they would jump right in to
help. How a startup should be. The tool is a lot more stable now. We are
have not found any bug in the past 3 months.
- [ Call Me Ishmael ]
---- ---- ---- ---- ---- ---- ----
From: Satish Bagalkotkar <Satish.Bagalkotkar@siliconaccess.com>
Hi John,
We've used PhysicalStudio in taping out 5 chips in 0.13 um over the past 14
months. Our flow integrated:
SPC-FirstEncounter (placement), PhysicalStudio (pre/post route
timing/noise), Plato/Apollo (route), PrimeTime (timing signoff)
& Verplex (equivalency check)
Our biggest chip was 333 Mhz, ~20 M gates, so we had to rely on EDA
tools to not only report but to also fix the problems. This design
had 32 seperate clocks. As with any other P&R tool, the SDC commands
supported are very limited compared to DC & Primetime. We have a list
of all the supported syntax from each vendor and we have a internal
scripts which converts the Synopsys constraint to SPC, PhysicalStudio,
Plato & Apollo format. To identify & understand how each vendor tool
handles SDC syntax slightly differs with each tool means you've got to
put in some effort integrating them together.
We haven't seen any new gotchas regarding data transfer between tools
because we spent lot of time to integrate these tools and ensured that
each transfer was clean before actually using it in production. This kind
of stuff cannot be done on-the-fly as each vendor tool has it's own minute
difference even if they claim they are fully compatible. Integrating
several vendor's tools is a task which takes time and resources.
So far all 5 chips have worked at speed in "first silicon" which is
icing on the cake.
Here are the pros/cons of PhysicalStudio in a nutshell.
Pros:
- Lots of switches which can be tuned to get very good results if you
know what you are doing
- Can do pre and post route timing/noise optimization
- Buffer insertion and timing/noise closure engines are good
- Post-route optimization adds buffers along the wire paths (which
is lot better than most tools where buffers are inserted and during
placement they can end up any place causing unnecessary iteration.)
- We have very good correlation with Primetime
- Timing and Noise analysis is extremely fast
- Columbus extraction seems to correlate well with Avanti StarXT (our
signoff tool)
- If the gate level netlist structure is good then the tool does a very
good job for timing closure
- Command set is very simple and you could write very neat scripts that
can run in batch mode. This was extremely useful as we have a fully
automated flow.
- Tool produced consistent results which is very important
Cons:
- Some of the post route optimizations which did area recovery caused
hold and setup problems. (We disabled it as area was not that critical
for us. They claimed to have fixed this problem.)
- Had problems with high fanout nets so we had to use Apollo (CTS) to fix
these nets
- If the constraints are not reasonable and achievable the PhysicalStudio
does lot of weird stuff
- The tool has problems optimizing paths with negative slack if the top
few path are not fixable. At times had to we to "false paths" these
and then it fixes the other paths. We have asked R&D to fix this.
- Optimization runtimes are very long and in few cases it added too many
weak buffers instead of few stronger driver
- Their GUI sucks!
- Buffer removal is not one of the strong features of PhysicalStudio
- We had several problems where tool used to core dump with no indication
and it used to take R&D lot of time to identify and fix the problem
- In some rare cases we had to guide the tool to close timing
- In previous version legalize command had problems. We saw some stdcell
getting placed on top of memories. This problem has been fixed.
- Doesn't run on Linux
The newer version pf PhysicalStudio claims to do glitch analysis but we have
not tried it. Overall, we are happy with the tool.
- Satish Bagalkotkar
Silicon Access Network San Jose, CA
|
|
