( ESNUG 443 Item 7 ) -------------------------------------------- [04/15/05]
Subject: ( DAC 04 #6 ) Synplify ASIC, DC, Get2chip, Formality, Verplex
> When I used Synplify ASIC, there were some bugs but they were very
> responsive to fix them. Our design was hierarchical with the largest
> blocks about 200K instances, 400K gates or so. Mixture of memory and
> standard cells. Since this data is so old, I won't spend too much
> time on it.
> Synplify ASIC Synopsys DC
> Compile time 3 hrs 24 hrs
> Performance 4.1 ns 4.2 ns
> Area ~same
>
> Synopsys DC was better (MHz) for blocks with ALU's and multipliers.
> Synplify ASIC was better for designs with MUXes and random logic.
>
> We actually got best results using a 1 - 2 method:
>
> Pass 1 use Synplify ASIC
> Pass 2 use compile -incremental on Synopsys DC.
>
> We were able to do clock gating and scan insertion correctly on
> Synplify ASIC.
>
> - Ralph Haines of Spans Logic, Inc.
From: [ The Invisible Man ]
Hi John!
Nice to meet you.
That's right, I'm a hand's on user of Synplify ASIC. We've been the first
team to use here in the [ European city name deleted ] site since October
2003. We've been past users of Synplify Certify.
They had bugs, but their support always managed to fix them so that we could
go on with the project. For that project, we were prototyping the very same
code on FPGA that the one going into the ASIC, and we had seen at several
times the case where Certify was able to simplify redundant FF or logic (and
where Design Compiler or Ambit did see nothing.) We've been using Certify
since 2001.
So last year we did a comparison between Design Compiler, Ambit, Cadence
Gate2chip/RC and Synplify ASIC on a timing critical block (ARM DMA IP).
Synplify ASIC won the first place at that time, with respect to runtime,
area, dft coverage and post-layout timing slack.
The situation may be different now that it's one year later, as all tools
but Ambit have progressed since then, and we are about to redo the same kind
of comparison on all latest releases of: DC, Get2chip, Synplify ASIC. Would
you be interested in our new benchmark?
Synplify ASIC Strengths & Weaknesses:
We do see today a very high quality of the VHDL elaborator of Synplify ASIC
as this was the only tool that has enable us to synthetize some IP written
in VHDL (with 3 dimensional arrays, records, ...) and still be able to run
the formal proof.
We had some miscompare when we did the formal proof, and each time it ends
up in a bug within the Verplex Conformal tool (that has been fixed now).
For poor VHDL style IP, we've tried 3 combinations:
Design Compiler plus Formality
Get2chip plus Verplex Conformal
Synplify ASIC plus Verplex Conformal
and we only had a working solution using Synplify ASIC plus Conformal.
May be the situation with Get2chip has becomes better in the meantime, so
again, we would need to redo the test on that particular topic, too.
The area given by Synplify ASIC is very good (but as I said we have to redo
a fair comparison now, and not rely on old results). The Synplify ASIC
runtime was much less than DC in Ultra mode. I also closely work at the
moment with DC plus Formality for another project, and I see that Synopsys
R&D are working hard to recover from that situation. Same thing on the
Cadence Get2chip plus Verplex side. The situation is obviously not black
and white, as things are changing so fast.
From a corporate point of view, we are strongly advised to use Synopsys DC,
or Cadence flow. For some projects, when we need a key enabler, we do use
Synplify ASIC, knowing like any Formula One Car, it may be very sensitive,
and need expert mechanics.
The last example we had is for a hard block for a GSM BaseBand chip. We
did the synthesis with Synplify ASIC (with some overconstraint), we did the
formal proof with Verplex Conformal and we did the final optimisation with
the right constraints within Ambit (to ensure the timing constraint
understanding, and also the netlist naming format.) At the moment, we do
develop our synthesis and formal proof scripts to easily be able to switch
from one tool to another, as there is no universal tool in those 3.
The weakness we do see is with the Synplify ASIC timing constraints: the
SDC is not natively supported. We have to translate our constraints into
their .sdc format, and some timing constraints we would like to have are
missing. (This is the reason why I've still not tested the capacity of
their tool Amplify ASIC, because it doesn't make sense to me to take
benefit of an optimisation based on placement if the timing constraints
are not all modeled.) It is also the reason why I would today recommend to
use Synplify ASIC at hard macro or chiplet level, but not at the top level
of a chip where you've got so many signals MUXed on I/O with completely
different timing constraints. In our case, we do take advantage of their
top-down synthesis capability to get fast and efficient netlist of hard
macros sizing between 400 K to 900 K gates. Those blocks have standard
buss interfaces where we can model nice and simple timing budgets, and as
there is no pad, we do not have a problem with generated clocks on
pads, ... different timing constraints on the same pad, depending on what
signal is MUXed on it, ...
Something that's for sure is that Synplicity's VHDL elaboration and mapper
(ASIC or FPGA) is able to detect optimizations that were never detected by
either Ambit nor Design Compiler. The problem we have is that some of the
Synplify optimization must be switched-off if we want to be able to run
the formal proof on the resulting netlist.
I apologize for my poor english, I hope you had enough courage to get to
the end of my mail. Please to have me be anonymous.
- [ The Invisible Man ]
Index
Next->Item
|
|
