( ESNUG 499 Item 5 ) -------------------------------------------- [02/23/12]
Subject: And even more users voting to save Magma Talus
MORE STEPPING UP: More users wanting to save Talus, more benchmarks showing
Talus 1.2 improvements. Heck, even Qualcomm chimed in with their vote!
These letters below add to 14 users who spoke up for Talus in ESNUG 498 #1.
"Assuming the Synopsys-Magma merger goes through, as a Magma user,
which specific Magma tools do you want to survive and why?"
---- ---- ---- ---- ---- ---- ----
I would like Magma Talus to be saved. Talus 1.2 has improved over
Talus 1.1.9 in many ways:
1. 2X to 3X runtime improvement over the prior version
2. Congestion/DRC has improved. I reran the same block on Talus 1.2
that have had congestion/timing issues with Talus 1.1.9. The
block went through Talus 1.2 with good DRC and timing now.
3. Top-level clock tree (looking into blocks, lower hierarchical
blocks) finally works. Our previous version of Talus clock tree
did not do well at looking into hard macro blocks, and it did not
balance well between top level flops and flops inside lower level
blocks. Now it works much better.
4. Talus now has Native SDC and AOCV (Advanced OnChip Variation).
This is also part of Tekton. Tekton timing analysis is great and
uses commands very similar to PTSI.
5. MMMC is working much better in Talus 1.2 before. In particular,
the flow for MMMC is much simpler now.
For 28 nm, the Talus 1.2 router has improved a lot and it correlates well
with our Calibre checks. Below are some of our Talus 1.2 results.
Design 1
- 400 K cells, 28 nm, from netlist to GDS took 2 days.
- Results: Met 240 Mhz timing, with small number hold buffers
violations. 80% area utilization (odd shapes) (6 layers)
Design 2
- 1.4 M cells, 28 nm, from netlist to GDS took 4 days finished
- Results: Met 320 Mhz timing. 84% area utilization (6 layers)
Finally, Talus still is superior over other solutions in terms of TCL
support. Direct user access to all objects in the data model through
TCL is paramount when we develop new methodologies.
- Truong Hoang of Qualcomm
---- ---- ---- ---- ---- ---- ----
We have been using Talus for many years. Last year, we evaluated Talus
1.2 to help address our growing 28nm MMMC requirements.
Our chips are composed of many blocks and the design cycle is typically
quite aggressive. This requires a fast TAT from gate-level netlist to
GDS. Our full-flow closure includes many timing scenarios (the
combination of a timing mode and a PVT corner) to be optimized
simultaneously.
Talus 1.2 helped us meet this goal through significant improvements
(compared to Talus 1.1) on some key features:
1. Runtime: Significant runtime improvement through the entire flow
with the new timer. We noticed an average of about 3x improvement
in runtime across our blocks. Some runtime data is shown below.
2. Correlation to signoff timer-extractor: Significantly better than
Talus 1.1 which reduced our timing convergence cycle by days
3. Crosstalk: Better closure due to early estimation/calculation of
crosstalk in the flow based on track routing.
4. The new timer allowed us to be completely compatible with SDC
commands so we did not need to massage the incoming SDC in any
form, something we had to do with 1.1. This enabled a clean
handoff between the synthesis and P&R teams.
As an example of the throughput difference between the two tool versions
(using latest versions of each), in the following table I detail a
random sample of 6 blocks from the many that we ran.
Gate-level netlist to Post-route Optimization time (4 threads) MMMC
setup: 15 scenarios with SI
Block Size (k) Talus 1.1 (hrs) Talus 1.2 (hrs)
------- -------- --------------- ---------------
Block A 880 232 79
Block B 450 86 27
Block C 500 108 40
Block D 550 125 43
Block E 800 166 78
Block F 300 58 20
These are the features we are currently testing in Talus 1.2:
* AOCV based optimization for multi-mode, multi-corner scenarios
with independent AOCV settings across scenarios.
* Early hold fixing in the design flow.
Based on our testing, here are some of the improvements that we need to
see in Talus 1.2 to make for an easier transition from 1.1:
1. Repeatability is still a concern at fix clock_opt and fix wire_opt -
results were not consistent between runs on the same floorplan.
2. Native 1.1 timer-extractor commands need to have equivalent 1.2
commands. Converting 1.1 scripts to 1.2 can be non-trivial due to
lack of supported 1.2 commands.
3. Stability is actually better than 1.1 for a set flow but there's room
for improvement during interactive use, especially of timer commands.
4. New Feature Introduction in the timer needs better QA
Summary: Based on extensive evaluation, we adopted Talus 1.2 for all of
our tapeouts approximately eight months ago and are very satisfied with
the results we have so far.
- [ An Anon Engineer ]
---- ---- ---- ---- ---- ---- ----
When we evaluated Talus, we looked at Talus Flow Manager, necessary
technology and library support, PnR performance and QoR.
We definitely see value in Talus for our PnR needs. To keep the details
short, we evaluated the performance and QoR aspects using an ARM core
previously implemented with one of the other main PnR tools.
We looked at run time, TNS/WNS with SI, DRC and R/C correlation to our
sign off flow. In all of these areas Talus performed equally well or
better than our original PnR tool.
- [ An Anon Engineer ]
---- ---- ---- ---- ---- ---- ----
I used to do place and route with other EDA vendors' tools before I
join my current company. We did not have any back-end flow at that
time.
It did not take us long to develop our own place and route flow, do the
correlation for RC extraction with other RC extraction tools, build our
own timing closure flow, correlate timing between the Magma timing
engine and the other tape-out timing engine.
We taped out our first chip with this flow and we got working silicon.
Since then, we have taped out four 90 nm chips, 5 55 GP chips, plus are
about to tape out one 40 LP and lot of respins.
Things about Talus which I love:
1) scripts are easy to develop
2) run timing is shorter, like 30% compared with other EDA tools
3) lot of options for the user to control, use and take advance of the
tool
4) built-in timing engine is very close to our tape out timing engine,
so it help us time with timing closure
5) GUI is very user friendly and easy to use. I can do lot with the GUI
6) design flow is simple with some basic steps like only 3 steps
place/CTS/Route but very powerful
7) router is good, less crosstalk, good timing is good and the number
of DRC violations after routing is around 10-20, which is also very
good.
8) CTS is good
I would like to see this tool stay in the market so our physical design
engineers can have an easy time taping out our chips.
- [ An Anon Engineer ]
Join
Index
|
|
