( ESNUG 422 Item 5 ) -------------------------------------------- [02/19/04]

Subject: ( DAC 03 #21 ) Synplicity ASIC vs. DC Gets Mixed User Reviews

> We are a "Structured ASIC" company so I may be a bit biased here, but
> after years of using Design Compiler I have been working with the
> Synplify-ASIC tool and I've been generally impressed.  The GUI interface
> was easy to pick up and it had no problems for an initial smaller design
> that I ran for comparison.
>
>     - from http://www.deepchip.com/items/dac03-21.html


From: Hatem Yazbek <hatem=user  domain=oplus spot calm>

Hi John, 

We used Synplify ASIC in three types of chips, small/medium versions
(400/900 K gates), and bigger version (1.5M gates).  The tool could not
handle the bigger version due to capacity, so we stopped evaluation until
Synplicity can upgrade their tool to handle the big capcacity.   The
smallest version was easy and we taped out the chip without problems.

Regarding the medium testcase see following issues:

  1. Fast engine, as it quickly finishes synthesis (within 2-3 hours) 
  2. Quality of netlist produced is not great, as it does not map well
     when doing formal verification (in our case LEC).  We had to do
     enormous amount of mapping to improve the hierarchical LEC.
     Synplicity has been able after a while to provide the mapping,
     and solve the problems. 
  3. User-friendly GUI with easy methods to run several project options.
  3. Hierarchy maintain was supported but had few bugs when we turned on
     this option.  We had to maintain it due to logic simulations and STA
     constraints verification.   Again, Synplicity has worked hard to fix
     this problem. 

Overall, the tool has a very powerful fast engine, and supports various
synthesis techniques especially for arithmetic functions.  But, it's still
not mature enough to work well with other tools and standard formats, and
can not handle big capacity yet.

    - Hatem Yazbek
      Oplus Technologies                         Yokneam, Israel

         ----    ----    ----    ----    ----    ----   ----

From: Darren Lasko <dlasko=user  domain=fcpa.fujitsu spot calm>

John,

I am currently evaluating Synplicity's Synplify ASIC.  For my eval, I'm
using the RTL from our most recent tapeout.  For that tapeout, we used
Design Compiler.  So in this report I will compare the results from SA
with the results from DC.  Here is the info on my setup:

  - Synplify ASIC version: 3.0.2d

  - Design Compiler version: U-2003.03-3 (we used this version for
    tapeout)

  - Platform:  Dual 3.06 GHz Xeon workstation w/ 4 GB of RAM running
    Red Hat Linux

  - Target technology: TSMC 0.15 um

Design stats: ~420 K gates, ~21.5 K flip-flops, ~145 K total leaf cells. 
Fastest clocks in the design are 233 MHz (~5% of FFs) and 185 MHz (~50%
of FFs).

I was very impressed with Synplify ASIC's performance.  It performs a 
top-down synthesis of our design in one hour flat.  Design Compiler, on 
the other hand, takes a little more than 6 hours to perform a top-down 
synthesis.  Iterating on synthesis is much less painful using SA because 
of the greatly reduced runtime.

I was also impressed with the cell area results.  The Synplify ASIC netlist
is 9% smaller in total cell area than the Design Compiler netlist. It also
contains 9% fewer leaf cells.

Both the DC and SA netlists meet timing using wireload models.  I verified
the timing results from Synplify ASIC by reading the design into PrimeTime,
just to make sure Synplify ASIC's timing analyzer wasn't cheating.  I found
that SA's timing analyzer correlates very closely to PrimeTime.

I also verified that the synthesized logic was functionally correct by 
using Cadence (Verplex) Conformal LEC.

Cadence First Encounter had no problems reading the SA netlist, and we 
were happy to discover that the congestion report was much better with the 
SA netlist than with the DC netlist.  After placement, First Encounter 
reported that the critical path was missing by about 600 ps, which is in 
the same ballpark as the first pass using the DC netlist.  Since we were 
just doing an evaluation experiment, we didn't try to fine tune any of the 
results.

I found Synplify ASIC fairly straightforward to use, although converting 
our constraints from DC was a bit tedious.  I haven't spent much time 
using their TCL interface, but my first impression is that they haven't 
added much in the way of additional commands for getting, querying, and 
modifying design objects (like you can do in DC).

During the evaluation I did find several bugs in the tool.  There were a 
couple of bugs that caused formal verification to fail.  There was another 
bug where multicycle constraints weren't being applied properly when using 
"-through" to specify the path.  However, Synplicity's technical support 
has been OUTSTANDING.  For the bugs that were causing the FV miscompares, 
Synplicity tech support provided a patch within just a few days.  The bug 
related to multicycle "-through" paths is still under investigation, but I 
know they are working on it diligently because of the e-mails they are 
sending me to get more info.

Working through these bugs took some time, but the effort was repaid by 
the reduced synthesis iteration time.

In addition to the bug fixes, they also incorporated a couple of enhancement
requests into the patches they provided me.  From my interactions with
Synplicity, it is apparent that they are eager to make Synplify ASIC a
world-class tool.

    - Darren Lasko
      Fujitsu                                    Longmont, CO


 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)