( ESNUG 432 Item 6 ) -------------------------------------------- [08/25/04]
Subject: ( ESNUG 431 #6 ) Magma Rebutts the Broadcom Review of Blast Fusion
> In order to meet setup time goals, Magma will intentionally skew the
> clock. It creates a clock balance problem, although this is okay for
> our design philosophy. However, we have questions as to whether Magma
> guarantees it will work for blocks that are 20 to 50 million gates, as
> it potentially requires a large hold time margin. The largest block
> we have successfully implemented so far is over 2 M gates, and Magma
> claims that other customers have verified it up to 5 M gates flat in
> their new version 4.0. We must still evaluate if this is true for
> ourselves though.
>
> - JC Wang
> Broadcom San Jose, CA
From: Anthony Galdes <galdes=user domain=magma-da spot calm>
Hi John,
I'm Magma's Account Technical Manager for Broadcom. I'd like to expand on
some of the "gotchas" and "features" JC pointed out.
Users have the ability to build a balanced clock tree or use useful skew to
help close timing. In 4.2 we have the ability to introduce useful skew
early in physical synthesis flow. The "run timing adjust skew $m $l" can
command be used as early as after initial global placement. This command
will estimate the actual skew that will be seen much later in the flow. As
a result, the physical optimization works hardest on paths that will see the
least benefit from useful skew.
> Some PrimeTime compatibility issues. Our designs are hierarchical, and
> for hierarchical nets, Blast Fusion inserts a backslash so that PrimeTime
> doesn't understand it. This could perhaps be a PrimeTime bug.
> Additionally, Blast Fusion's design output couldn't feed to all PrimeTime
> versions. PrimeTime is the industry standard and Magma must support it.
> Magma claims full correlation with PrimeTime in 4.0; our analysis team
> needs to verify if there are any remaining issues.
We continue to emphasize accurate extraction, delay calculation and static
timing analysis. With our acquisition of Random Logic Corporation (makers
of QuickCap), we continue to push our extraction flow towards sign-off
quality. In our Magma 4.2 release, users can characterize their process
using QuickCap rather than Space3D. When the process is characterized with
QuickCap we correlation very well to QuickCap for large capacitance, we are
ultimately looking for +/- 1 FF correlation to QuickCap for capacitance in
the 4-8 FF range. This level of accuracy is absolutely necessary for high
frequency blocks.
In addition to higher accuracy extraction, 4.2 uses a new current source
model for delay calculation that correlates w/in 5% of SPICE. Accurate
extraction combined with our new delay model and enhanced SDC support makes
Blast Fusion's timing sign-off quality.
If you still want to compare timing between Blast Fusion and PrimeTime,
there is a little known command called "report timing correlation". This
command is used to automatically compare timing end points between Magma's
and PrimeTime.
First you'll need to generate the list of timing endpoints in PrimeTime and
save them into a file. Here are the pt_shell commands that should do the
trick:
pt_shell> set endpoints [add_to_collection [all_registers -data_pins]
[all_outputs]]
pt_shell> report_timing -to $endpoints -max_paths [sizeof_collection
$endpoints] -path_type
summary -nosplit -significant_digits 3 > pt_time
With the timing endpoints stored in a file named "pt_time" now issue "report
timing correlation $m pt_time" in Blast Fusion to see how well Blast Fusion
and PrimeTime correlate.
> Their router is not yet mature. Being a relatively new tool, their router
> still has problems. For example, compared to the Astro router, Magma's
> router still has some problems dealing with spacing and it always leaves
> some DRC errors. We must interactively do manual fixes. As the Magma
> router matures more, we expect that it will produce better results with
> respect to DRC.
Over the last year Magma has focused substantial efforts on router runtime
and quality of results. In 3.2 and 4.0 our router was optimized to
maximize yield by limiting the total number of vias. While this approach
is great for yield, it did make DRC closure and sometimes timing closure
more difficult. Starting in 4.2 users have the ability to directly control
how hard Blast Fusion works on via minimization. Using the new option to
the global router "run route global $m -crosstalk" we do see more vias but
we inherit two nice side effects: DRC closure is improved and total coupling
cap is reduced.
> For Magma's version 3.2, their clock tree power was 100% greater than
> that in Magma 4.0 based on what Sente reported. Magma 3.2 used only H
> trees, compared to Magma 4.0, which also supports cluster clock trees.
> When we estimate power using version Magma 3.2 layout results, Magma had
> 20-25% worse power than our estimation, which was based on our Apollo
> experience. This was fixed in 4.0, and Blast Fusion's power results are
> now reasonable. With Blast Fusion 4.0, we have validated that Blast
> Fusion's power results are actually 20% better than Apollo. Again, this
> is based on Sente analysis.
In older revs of Blast Fusion we used an H-tree clock topology. Starting
in 4.0 we've moved to a bottom-up clustering approach. As JC points out
the new CTS approach reduces clock switching power substantially.
In the 4.2 release, the same CTS technology is also used to manage non-clock
high fanout nets. A new option has been added to "run gate buffer wire"
called "balance_hfn". We expect to see additional area and power savings
using this approach.
> Verilog out issue. Blast Fusion had trouble outputting unique floating
> nets. Though the connectivity was correct in the layout database, there
> was a problem with outputting hierarchical Verilog correctly. We caught
> the problems through formal verification and fixed them by hand. It is
> critical that a physical design guarantees the functionality, and Magma's
> AEs and R&D engineers have told us that hierarchy maintenance has since
> been fixed in 4.0. We still need to verify this important fix.
Magma 3.2 and 4.0 did have issues with some versions of PrimeTime. There
are two areas we have been focusing on; SDC compatibility and Verilog
compatibility.
Verilog compatibility: While the Verilog written by Blast Fusion was
compatible with the IEEE standard, we updated our Verilog writer to work
around PrimeTime limitations.
SDC compatibility: We are trying to support 100% of the SDC commands. In
our 4.2 release we have almost all the commands covered; we are planning on
having full coverage in the next release. In cases where PT and Blast
Fusion do not agree, we work with the customer on a case by case basis to
determine the correct behavior.
- Anthony Galdes
Magma Design Automation Santa Clara, CA
|
|
