( ESNUG 498 Item 1 ) -------------------------------------------- [02/07/12]
Subject: Magma users stepping up in droves, asking Synopsys to keep Talus
GENUINELY HOPING: When I asked my readers exactly which Magma tools they
wanted to survive the LAVA-SNPS merger, I was surprised by the intensity
these Magma users had in their emails and phone calls. It wasn't just a
quick 2 or 3 throw away lines these engineers sent; instead they backed
their desire to keep certain LAVA tools alive with detailed hard data;
plus many went out of their way to add their own names and company names
(when they could) to their case. These Magma users are genuinely hoping
that Aart and his SNPS senior mgmt are listening here.
Due to so many responses, I'm running just the Talus/Hydra letters here.
I noticed the comments about how Talus 1.2 improved 3X over Talus 1.1.
(It would be ironic for it to improve that much and then be discontinued.)
"Assuming the Synopsys-Magma merger goes through, as a Magma user,
which specific Magma tools do you want to survive and why?"
---- ---- ---- ---- ---- ---- ----
From: [ Mighty Mouse ]
Hi, John,
Anon please.
We would definitely want to see Magma's place and route tools survive.
We have been using Magma since 2008 starting with BlastFusion and later
migrating to Talus. We have successfully taped out 3 designs at 90 nm,
and 65 nm along with development work in 40 nm.
Our designs are physically complex, embedded processors combining the
functionality of DSP, ASIC logic and FPGA. Designs are typically around
500K instances/core. Our current environment uses Talus Vortex for its
low power and multi-threading.
We recently migrated to Talus 1.2, primarily motivated by improved run
time, and enhanced QoR.
Initial trials show us that Talus 1.2 has been a significant improvement
over Talus 1.1 in the following areas:
1. Run time
2. Native SDC constraint support
3. MMMC configuration and optimization
Talus 1.2 optimization run time improved compared with Talus 1.1. For
example a recent 500K instance block ran from synthesized netlist to
the end of post-route optimization:
Talus 1.1 : ~72 hours (65nm)
Talus 1.2 : ~24 hours (65nm) approx. 3x improvement
Talus was running with 4 threads.
The switch to native SDC support has helped interop. It's reduced debug
time between constraints in differing tools. We aim to share the
constraints across tools allowing us a best-in-class EDA flow.
We find that congestion after global routing is much better correlated
to final route performance when compared to Talus 1.1.
The main upside Talus 1.2 over 1.1 is 3X turnaround-time and SDC support.
- [ Mighty Mouse ]
---- ---- ---- ---- ---- ---- ----
From: "Michael Lafferty" <mlafferty=user domain=availink got calm>
Hi, John,
As a hands-on Magma user in the place and route arena, the minimum tools
I would need to keep are Magma Talus, Quartz DRC/LVS and Tekton.
With full integration of the Tekton timer and the QCP extractor the
latest Talus version 1.2 yields faster extractions and timing. This
has greatly improved runtimes for post-route ECO timing optimizations.
Talus 1.2 for 6 corners, 4 modes, both setup-and-hold with xtalk and OCV
enabled has runtimes of 1/2 to 1/3 the previous Talus 1.1 release.
The runtime and memory increases to Talus 1.2 were minimal as corners
and modes were added.
The thought of going back to out of the Magma layout timing ECOs for
post-route timing closing is just too painful to get pulled into
again. The ability to remove the final timing closure churn and add
predictability to our tapeout schedules is too valuable to lose.
- Mike Lafferty of Availink
---- ---- ---- ---- ---- ---- ----
From: "Anand Bariya" <abariya=user domain=netlogicmicro got calm>
Hi, John,
Magma Talus should be saved because:
We have done multiple 40 nm tape-outs with Talus, with designs of close
to 2 million placeable instances done flat. The tool works for us.
We like the ability Talus provides designers to script highly customized
approaches in placement, clock tree synthesis and routing, enabling
quick closure of high instance count designs with challenging timing.
This is one of the most compelling aspects of Talus.
With PrimeTime compatibility in Talus 1.2, we get the ability to have
common scripts (with reusability) for implementation and STA.
Talus 1.2 has substantially better run times compared to earlier
versions of Talus, for the same QoR.
- Anand Bariya of NetLogic Microsystems
---- ---- ---- ---- ---- ---- ----
From: "Bharat Bisen" <bbisen=user domain=juniper.net>
Hi, John,
We have run Talus on a significant number of blocks and Talus has proved
to be very good in meeting and exceeding performance, power, area and
runtime requirements. It can handle large blocks.
Talus has in many cases given better results than a competing tool, and
the seamless integration with Magma's signoff tools (Quartz, QCP, and
Tekton) makes a compelling argument for the Talus platform as we move to
advanced process nodes like 28 nm and below.
Here are some specifics on Talus, based on our Block "P":
608 K instances
1 Ghz design
Met timing
Netlist-to-routed db in 45 hours
Having Talus as an alternative has often given us valuable insight into
a design. In a recent example, a competing PNR tool was struggling to
optimize a critical cone of logic, and we thought major changes in the
RTL might be needed. When we ran the same block through Talus, that
logic cone was optimized much better.
- Bharat Bisen of Juniper Networks
---- ---- ---- ---- ---- ---- ----
From: "Paul Dudek" <pdudek=user domain=esilicon not calm>
Hi, John,
My vote is for Synopsys to keep Magma's Talus/Hydra/GlassBox technology.
Magma's uses GlassBox (GB) abstracts, which are a logical and physical
shell to represent the external timing of a block as if the block were
being extracted and timed flat at the top level. Magma's Hydra design
planning tool now also generates 'Cached Delay' glassboxes, where the
cached delays (in SDF) and slew values are annotated on the cells in the
glassBox abstract. This saves us runtime later when timing the
top-level design in Talus - details below.
We compared our Talus runtimes on a tape out last year, using whiteboxes
(full models), structural glassboxes and cached-delay glassboxes. As
you can see from the table below, the cached-delay glass boxes gave us a
30x speedup over a full model and a greater than 5x speed up over the
traditional Structural Glassbox abstract.
- Talus 1.1.8 of code in single corner single mode analysis.
- Default was MCPU2 for blocks under 700 K cells. Critical
runs used 4 CPUs.
Approach # of cells Runtime Speed-up
Whitebox (No GB) 1.5 M 24 hours 1
Structural GB 413 K 4 hours 6x
Cached Delay GB 210 K 0.8 hours 30x
We used an older Talus 1.1.8 version for this benchmark. We are
currently adopting Talus 1.2 for our new design starts. We are seeing a
significant speedup with the Magma's MX timer in the flow; MX timer is
an implementation (not a sign-off) version of a Tekton timer. The MX
timer is new, and was not available in Talus 1.1 versions. I'm planning
on re-evaluating the cached delay glassboxes with the new timer in MMMC
mode.
If I'm not mistaken, Talus is the only tool that offers this Cached
Delay Glassbox option and it should definitely be included in the future
Synopsys P&R tools. The only limitation is that the cached delay
glassbox does not work in multi-mode timing scenarios. One can create a
delay cached glassbox for functional, scan, or mbist modes but not all
at the same time. But the majority of timing optimization happens in
functional mode and the runtime improvement is significant, as pointed
out below.
I also enjoy the ease of access of the Talus database structure using
TCL programming.
- Paul Dudek of eSilicon
---- ---- ---- ---- ---- ---- ----
From: "Roman Trogan" <roman=user domain=adapteva not calm>
Hi, John,
Thank you for posting this survey.
For a small startup company as ours Magma was definitely an important
part of the success. In the time frame of about two years we taped out
four products in the advanced technology nodes (65nm and 28nm) using
Magma tools. Here are the tools we use:
Regarding Talus Quality of Results
- Runtime: Blocks of about 100 K standard cell gates went through the
whole flow from RTL to GDSII in less than 12 hours.
- Timing: Our chip is running at 1 GHz. The logic includes among
other things a single precision floating point engine. I'm not
saying it was easy but using the right architecture and right
methodology for RTL coding one can expect to get very good timing
using Talus.
Talus/Hydra:
One of the most useful features in our case was the fact that we could
do the whole design implementation flow (RTL to GDSII) using these two
products. Magma offers a reference flow generator - Talus Flow Manager
(TFM) which makes life very easy for the inexperienced with the tools
user. The ease of use of the TFM allows you to start your design
implementation in no time.
- Roman Trogan of Adapteva
---- ---- ---- ---- ---- ---- ----
From: "Kai Harrekilde-Petersen" <khpetersen=user domain=gnresound.dk>
Hi, John,
I work at a hearing-aid company. Our hearing aids have very aggressive
power requirements (less than 2 mA sustained, all inclusive), and we
employ a number of exotic techniques to get tiny power figures.
We recently adopted the Talus platform after an evaluation project. Our
previous PNR flow was very divergent, and with each iteration taking 2-3
weeks it was never possible to optimize to the degree we would wish.
With the usual schedule, we basically had to take the power that the
tool could give us.
With Talus, we quickly found not only a convergent PNR flow, but
also that we can now run synthesis to post-route power-analysis (using
SDF and SPEF) in under 24 hours. This has proved a tremendous
productivity boost and has enabled us to run 6-8 iterations of
additional power and design optimizations.
In addition, we have been able to achieve 20% power reductions using
this flow AND keep management off our backs due to the predictability
we now have.
We have also taken advantage of Tekton, to resolve all our SI issues at
signoff (running at very low voltages can challenge the tools in weird
and unknown ways). So we would really hate if Talus & Tekton were
dropped as part of the merger.
In addition to the tools that have enabled us to manage our schedules
and improve our designs, we'd also like to highlight the excellent
support we have continued to receive from Magma AEs in the UK. They
have always been there for us - and have helped us throughout our
projects and pulled out all the stops when we hit tapeout deadlines
(even nights and weekends). We hope that this level of service will
survive the transition too.
- Kai Harrekilde-Petersen of GN ReSound
---- ---- ---- ---- ---- ---- ----
From: "Craig Farnsworth" <craig=user domain=asicfactory not calm>
Hi, John,
As to which Magma product should be saved, I would say Talus, Hydra,
Tekton at least. I adopted Magma 5-6 years ago.
I chose Magma's solution because of its signoff in the loop flow
(QuartzRC, QuartzTime, Talus). Magma's single database/model solution
was also particularly attractive as I was working for a startup with
limited resources. At the time ICC was not even available, so going for
a multiple tool solution was much less attractive with my limited team
size even though I had taped out a large chips with a PC/Astro flow
already.
I taped out many chips over the last 5-6 years very successfully using
Magma. All first time right. So Magma's solution did us proud. The
m-tcl interface allows the user to solve any issues you come up against
very quickly.
I am just ramping up the Tekton, Quartz LVS and DRC flows so cannot say
too much about them yet, and I have not used Synopsys DRC/LVS for years.
The most important flow for me is the signoff in the loop flow.
Maintaining a single set of timing constraints for signoff STA and P&R
has been incredibly useful for getting more done with a small team. I
hope to continue to do so with Tekton with faster runtimes and more
advanced features.
- Craig Farnsworth of ASIC Factory
---- ---- ---- ---- ---- ---- ----
From: "Dung Pham" <dung=user domain=algotochip got calm>
Hi, John,
Talus/Hydra Plays an important role in our Automatic Chip Design flow as
shown in the following. It's a fast and reliable front/back-end tool
and serves us well. We'd like to see Talus/Hydra survive in the
Synopsys acquisition.
Our Automatic Chip Design Flow using Talus/Hydra
- Chip design feed-FORWARD flow:
Algotochip Proprietary Architecture Optimizer => Algotochip
Proprietary Automatic RTL Generation ==> Talus netlist synthesis
==> Hydra P&R ==> Talus post layout processing
- Chip design feed-BACK flow:
1. Talus synthesis ==> Algotochip Proprietary Architecture
Optimizer: Delay, Power, Area (quick feedback without
floorplan details)
2. Hydra floorplan and P&R ==> Algotochip Proprietary Architecture
Optimizer: Delay, Power, Area, Congestion, Hot Spots (detail
feedback with floorplan consideration)
3. Talus post-layout processing ==> Algotochip Proprietary
Architecture Optimizer: Delay, Power, Area (detailed feedback
with completed P&R)
This flow gives us early feedback on estimated Power, Delay, and Area.
HYDRA RUN-TIME REPORT
For 41-um2 OFDM Based Receiver (incl. 30 Mbit-memory macros)
Partitions/Macros: 8/75
Design step Runtime
- Floor Planning 10 min
- Partitioning 1 min
- Shaping 15 min
- Power Planning (with VCD): 20 min
- Global Routing/Congestion: 10 min
- Boundary/Timing/Pin Assignment: 20 min
- Timing/Physical Push-Down for Partitions 5 min
- Partition Complete Implementation:
Single CPU 7.5 hr
Multiple CPU 2.3 hr
- Full Chip Detail Routing including CTS 8 hr
TALUS/HYDRA ACCURACY REPORT
- Area 10% larger than our estimation
- Critical paths Similar to our estimation
- Critical Path Delay 15-20% shorter than our estimation
(within expected range)
- Clock Frequency 15-20% faster than our estimation
(within expected range)
- Power Consumption 20% higher than Apache estimation
(within expected range)
- Congestion 80%-90%
Talus/Hydra provided us important feedback on estimated power, delay,
and area for our automatic chip design flow which includes architectural
and power gating optimization. Talus/Hydra also provided black boxes
for floorplan estimation during the early optimization phase. The data
base is detailed and accessible during optimization cycles. Hydra's
automatic P&R is fast and achieves good results as expected.
We need Talus/Hydra to support our killer in-house flow.
- Dung Pham/Pius Ng of Algotochip
---- ---- ---- ---- ---- ---- ----
From: "Roger Carpenter" <roger=user domain=wavesemi got calm>
Hi, John,
I would like to see perpetual support for Magma Talus so that we can
take advantage of the TCL access to the unified data model.
Talus' link between logical and physical information is beneficial to
developing new methodologies for more productive timing, noise, and
power closure flows. Talus lets us:
- quickly loop through all data model relations (i.e. data loop)
- modify the timing graph (i.e. cell_pin and query node)
- trace physical objects (i.e. model_box)
- mark objects (i.e. data create attribute)
This direct user access to all objects in the data model is paramount
when developing new methodologies in voltage control, asynchronous
timing, or voltage drop analysis. Talus has incremental timer and
voltage updates.
Design teams can use all these capabilities to extend automated design
methodologies for 20 nm and below, when unforeseen complexities arise.
- Roger Carpenter of Wave Semiconductor
---- ---- ---- ---- ---- ---- ----
From: [ Undercover Brother ]
Hi, John,
Anon please.
My company has been using Talus Vortex for more than 4 yrs now and we
have successfully taped-out at multiple nodes (90nm/65nm/55nm) and
currently using it for our 40 nm chips.
Some of our chips use high performance processor cores (800 MHz+) for
various applications and from various vendors and we have always been
able to meet our timing/power/area/density goals with Talus. Our chips
always have high utilization - more than 75% and some blocks are over
80% - and we never had any issue with Talus not able to place/route
with such high utilization number.
Magma's data model enabled us to quickly come up with solutions
(scripts) for any stuff which the standard commands will not do. The
ability to script using their data model to quickly WA the problems
during the crunch time without relying on the support channel is a plus.
The other help that data model gives us is while handling complex ECO's.
We started using Magma's Talus 1.2 lately and with their new sign-off
timer Tekton and QCP, we are seeing better utilization/area/TNS/run
times/correlation. More work has to be done, but I think this is good
start for Talus 1.2 and I wish post-acquisition that Synopsys keeps the
Talus platform alive.
- [ Undercover Brother ]
---- ---- ---- ---- ---- ---- ----
From: [ Secret Squirrel ]
Hi, John,
Please keep me anonymous.
Our 28 nm project is firming up and we have been evaluating Magma Talus
and their chip planning tool, Hydra. We are looking at networking
designs exceeding 100 M cells and looking to reduce sub-chips blocks of
2-3M cells each. Our blocks are highly utilized and we do semi-abutted
floorplanning style. For the 28nm chip, we are also looking into MM/MC
and low power. With that in mind, we have evaluated Magma tools on a
65nm design that we recently taped out.
Toplevel
To limit the scope of the evaluation, we focused on the ability to
manage fully/semi abutted floorplans. We took a 40 M instances toplevel
netlist and abstracted the original blocks to their periphery. We did
not change the original number of blocks (30) nor the toplevel logic.
Overall, the simplified version of the netlist included 1.2 M standard
cells and 630 macros. We kept the original DEF and froze the die size
as well as the PADS placement, but allowed freedom to move the internal
macros to test the abutment capabilities. We adopted a limited subset
of the standard solution and focused on a black box approach, where we
essentially fixed the number, shape and size of the blocks and simply
enabled the router to open the partitions and run through them, creating
feedthroughs. We then kicked off the toplevel router, 'coarse router'
in Hydra terminology.
Having partitions open, the router did the toplevel in less than 1 hour
with no congestion. Of course this was a simplified case, but we were
positively happy by the runtime and the quality of the resulting routing
topologies.
Blocks
On the block implementation we are evaluating block runtime, QoR
(timing, area, leakage and DFM features) and the MM-MC capabilities.
The initial setup phase was driven by Magma AE who helped setup the
library with the proper CCS models and extraction rules as well as the
magma standard design flow (TFM), based on a small pipe cleaner block.
TFM is a predefined flow which can be easily setup and adapted to the
design characteristics, such as technology, number of scenarios, power
domains etc.
Information is stored in a handful of files in the design_scripts
directory and the same flow can be run on any block by simply updating
a few variables in one file. For the signoff, after some initial setup
effort correlation with our signoff timer was in the range of 15-20 psec
over a 5 nsec path (0.4%) with crosstalk on.
Here is the correlation, runtime, and final timing stat for one of our
biggest block (800 K instances with 2 modes and 3 corners). The flow was
setup to run with all 6 scenarios enabled.
Signoff Correlation:
| Slack Range (nsec) | Count | Sum |
+----------------------+---------+----------+
| ( -0.250 ~ -0.200) | 2 | 2 |
| ( -0.200 ~ -0.100) | 42 | 44 |
| ( -0.100 ~ 0.000) | 1792 | 1836 |
Runtime (on 4 CPUs):
Talus: 27 hours
Reference flow: 40 hours
Final timing:
Talus
| Slack Range (ns) | Count | Sum |
+----------------------+---------+----------+
| ( -0.110 ~ -0.100) | 4 | 4 |
| ( -0.100 ~ 0.000) | 70 | 74 |
Talus:
Final timing (before metal fill)
Setup WNS : -0.110
Violating Paths : 74
Reference:
Final timing (before metal fill)
Setup WNS : -0.124
Violating Paths : 1094
Leakage (HVT/SVT ratio):
Talus: 70/30
Reference: 70/30
Area (utilization):
Talus: 70.0%
Reference: 69.4%
Summary
To summarize, we are very satisfied with the preliminary 28 nm results.
Magma Talus as well as the Hydra floor plan are powerful tools and we
hope that Synopsys-Magma merger will continue supporting on these tools.
- [ Secret Squirrel ]
---- ---- ---- ---- ---- ---- ----
From: [ Yosemite Sam ]
Hi, John,
I hope Talus is saved.
1. Talus' UI experience is uncanny. The GUI interface is extremely easy
to use which in turn makes floorplanning, visual checking and DRC
cleanup very efficient and quick.
2. Talus' timing driven cell placement and logic optimization are
excellent.
3. Most importantly is Magma's data model. The amount of data that is
accessible by the user is unlimited. It allows the user to make any
customization to the flow or to the database and allows seamless
methodology and design. It's very easy to understand and very easy to
make use of while scripting. The overall tool set is extremely easy to
use and our design engineers can to jump into the design process quickly
and efficiently. In other words, the learning curve is short.
4. Magma's TFM flow also provides our end users with a qualified P&R
flow to allow our designer to kick-off their designs quickly without
having to create a flow themselves. The ability to skip over commands
or add new commands or functions is very important. It gives our users
overall flexibility and control over the design rather than always
relying on the out-of-the-box flow.
5. Our designs are tapped out with smaller area, better timing, and
shorter TAT. Plus our implementation team is smaller.
- [ Yosemite Sam ]
---- ---- ---- ---- ---- ---- ----
From "Bob Patti" <rpatti=user domain=tezzaron got calm>
Hi, John,
The usefulness of Talus for 3D integrated circuits is simple. It is not
only a great tool, it is the only synthesis, place and route tool that
Tezzaron has ever been able to use for 3D-ICs. The TCL script interface
was essential to enabling Talus's power for 3D-IC technology.
While we have only scratch the surface of 3D logic-logic heterogeneous
integration, I can say this:
Talus full 3D-IC designs 2
All others 0
Talus has a built-in ability to handle massive databases that 3D demands,
and it can simultaneously deal with different technologies.
- Bob Patti of Tezzaron Semiconductor
Join
Index
Next->Item
|
|
