( ESNUG 310 Item 7 ) ----------------------------------------------- [2/7/99]
Subject: ( ESNUG 309 #1 ) Interesting Benchmark Using Ambit *WITH* Synopsys
> Circuit3:
>
> Complete CPU, about 100K gates. Asking for 110Mhz with 78th percentile
> wire loads. Multiple path exceptions (both false and disabled paths)
> as well as several hundred latches used to guarantee hold times to an
> external RAM interface.
> BuildGates 2.0.4 DC 98.02
> total compile time 37hrs 29hrs
> area slack area slack
> stats at finish of compile 4900 -0.2 5395 -0.2
>
> Both results are from top down compiles from the behavioral code.
>
> Both circuits meet the clk->clk paths at 110Mhz (9.09ns period). With
> the -0.2 slack in CLK->Q paths that end at heavily loaded outputs.
>
>
> Summary
>
> The results are very similar. BuildGates does show a consistent area
> advantage of about 10% and a slightly longer compile time. It also
> looks like the capacity of BuildGates may be more limited than that
> of DC 98.02 as the compile time difference increased as the circuit gate
> count went up.
>
> - Jay McDougal
> Hewlett-Packard
From: Thomas Tomazin <thomas.tomazin@analog.com>
John,
I know of at least two comparisons where Ambit has a clear advantage -
static timing analysis and incremental optimizations. The design
I am working on is large (suffice it to say very large) and latch
based. There are multiple synchronous clock domains. There are
asynchronous clock domains. There are thousands of lines of multicycle
paths and timing exceptions. We compile all the subblocks in Synopsys,
then read all the gates for the entire chip into Ambit. Ambit reads
all the gates and produces a timing report in ~3 hours. It takes
Synopsys longer than that just to read the gates (I'm talking about
98.02) and after 48 hours didn't produce a timing report. After
the design is read into Ambit, I can do an incremental optimization
and get ~20% improvement in timing in about 2 days (Ultra 60 with 2G ram).
Of course, some of the improvement is probably due to poor constraints
in the original Synopsys runs. Area also improves by about 20%, but
the design is harder to place and route. So the real improvement is
with timing, area improvement is secondary.
By the way, we tried Primetime. It wasn't the right solution, and besides,
a superior timing engine is built into Build Gates (Ambit).
For smallish blocks, up to 10K gates, we haven't seen much difference
between Ambit and Synopsys. However, Ambit is an "enabling
technology" for very large incremental optimizations, and allows entire
chips to be statically timed without ever leaving the synthesis tool.
Important note:
When comparing negative slack between Ambit and Synopsys runs,
be aware that the 2 tools report slack very differently for latch
based designs.
Synopsys will report slack to some budget at each stage
(latch boundary), and propagate forward the ACTUAL arrival time
of the signal to downstream stages.
Ambit will report slack to some budget at each stage, but
only propagates forward the BUDGETed time, dividing the slack
across the stages.
Here's an example. Consider the following path:
lat1 ---- 6ns logic ---- lat0 ---- 4ns logic ---- Primary out(PO)
assume lat1 is transparent clock high, lat0 transparent clock low, and
an 8ns clock period. The PO is required at 8ns.
Synopsys will add the slack across the stages and report the total
negative slack for the entire path = -2ns at PO.
Ambit will divide the slack equally among the stages, and report
negative slack = -1ns at PO (and also at lat0).
The Ambit method of reporting slack indicates how much the 1/2 cycle
time needs to be increased to meet timing.
The Synopsys method indicates how much cumulative slack is in your worst
path. To get the equivalent Ambit number divide the Synopsys slack by
the total number of latch stages in the path (not always easy to figure!).
- Thomas Tomazin
Analog Devices Austin, TX
|
|
