( ESNUG 390 Item 6 ) --------------------------------------------- [03/20/02]
Subject: Too Many Letters About The "Lies, Damn Lies, & Synplicity" Column
> First off, Synplify Pro has a 312-page user's manual and a 798-page
> reference manual. In those 1,110 pages you'll find documentation for
> 21 different directives, 63 attributes, 59 timing constraints, 23 ctrl
> shortcuts, 20 file commands, 7 header/footer variables, 34 edit commands,
> 10 Tcl commands, 41 view commands, plus a few "hundred" other menu tasks.
> Just one of these Tcl commands alone, set_option, sets 45 different
> options. You use all of this by wading through a maze of menus, making
> custom scripts and embedding lots of directives and attributes in your
> RTL source code. Clearly, Synplicity is not all that easy to use.
>
> Second, entrusting Synplicity to synthesize your ASIC is like having
> McDonald's cater your daughter's wedding. You may think you'll get the
> job done for less money, but you'll pay for it in the long run. Don't
> get me wrong. Synplicity's done quite well in FPGA synthesis. But you
> can't just "supersize" an FPGA tool and expect it to work as an ASIC
> synthesizer. Too many of the things that you fret over in ASIC design
> aren't in FPGA design.
>
> Synplicity lacks a good static timing-analysis tool. When was last time
> you stitched a scan chain or did ATPG for an FPGA? Clock tree design and
> skew are life or death for ASICs. Not in FPGAs. I don't care what
> Synplicity marketing says, you will have to partition that 500 K-instance
> ASIC. And your physical hierarchy will differ from your logical
> hierarchy. Power analysis is an ASIC issue; it's barely thought of in
> FPGAs. You don't deal with congestion issues in FPGAs like you have to
> with ASICs. Crosstalk, electromigration and signal integrity simply
> aren't FPGA issues. And how about this FPGA synthesizer doing in-place
> optimization? Oh. It's not there yet. Is this really a happy little
> seven-step cakewalk? Come on now! Do I honestly look that stupid?
>
> - from "Lies, Damn Lies, & Synplicity" (EE Times 3/11/02)
From: Chandra Moturu <Chandra.Moturu@compaq.com>
John,
For an apples to apples comparison, consider the following figures of DC:
Commands + Variables 1458
Error Codes 8745
You can derive an estimate for documentation of the above as well. FYI.
- Chandra Moturu
Compaq
---- ---- ---- ---- ---- ---- ----
From: [ Little Red Riding Hood ]
Whoa! Really going for the jugular in this one, John!
Better keep this anonymous. Politics.
Just for comparison, the printable docs under SOLD Core synthesis comprise
6,229 pages, plus of course man pages at 5,692 pages in length, totalling
11,921 pages. And you are saying that 1110 pages are a lot? I think you
may have asked for some derision on this one!
As for your points about Timing Analysis, fair point. (I am assuming that
you are correct in saying that it is not good in Synplicity: I haven't tried
the tool myself). On the other hand, it is not a physical synthesis tool,
so I wouldn't expect to see accurate timing. Wire load models are hopeless
anyway. Also, if it is not doing layout, why would worry about crosstalk,
signal integrity or electromigration? How can you design for those at the
netlist level? That's not the market Synplicity is aiming for, I believe,
but rather the lower end (to start with).
I do not know if Synplify ASIC is any good, having only seen their marketing
presentation; but it seems a fresh approach and if it can push Synopsys like
Ambit did when it first came out back in the mid-90s, then so much the
better for all designers, surely?
- [ Little Red Riding Hood ]
---- ---- ---- ---- ---- ---- ----
From: Tom Lai <thomas.lai@teradyne.com>
John,
I believe you are right. We have to listen to EDA marketing sale pitches
with all the critics that you can come up with. I always ask EDA vendors
to give me the data to back up their claims or in my next job I know I'll
be asking "Do you want fries with that?"
Thanks for the tip!
- Tom Lai
Teradyne
---- ---- ---- ---- ---- ---- ----
From: Ann Steffora <ann@ibsystems.com>
Well put John!
- Ann Steffora
Managing Editor, EDAVision www.EDAvision.com
---- ---- ---- ---- ---- ---- ----
From: Vladimir Orlt <Orlt.V@ems-t.ca>
Hi, John,
I guess it's: "Lies, Damn Lies, and Marketing" for Synplicity... :-)
- Vladimir Orlt
Lead ASIC engineer
EMS Technologies Ste. Anne de Bellevue, Quebec
---- ---- ---- ---- ---- ---- ----
From: Ted Boydston <tboydsto@harris.com>
Hi, John,
Interesting Synplicity attack, however, you *should* have stated that
"Entrusting EDA vendors to synthesize your *FPGA* is like having
McDonald's cater your daughter's wedding."
Note the removal of substitution of "ASIC" with "FPGA" and the removal of
any vendor specific name. IMHO, attacking the stereotypical FPGA
methodology flow as a bad ASIC flow is flawed, because the FPGA flow
itself is hosed.
I have never understood why FPGAs are treated differently than ASICs when
delivering to FPGAs to customers. It seems to me that the flows between
the two technologies should be as similar as possible. Differences, like
electromigration in ASICs, or dealing with architectural FPGA peculiarities,
should be taken as additions to the process. Instead, FPGAs, because they
are reprogrammable, are treated differently. They have no NRE, hence no
sense of failure. They are the software of the hardware world, encouraging
engineers to quickly get to lab, ignoring good design practice. I have
seen cases at many companies where a chip will spend months in the lab,
because of flawed FPGA design flow. What a waste of dollars and schedule,
but because there is no NRE looming its OK to continue with this flawed
flow. Here are some examples of the FPGA flaws:
1.) Static Timing. Did you know that Synplicity lacks a static timing
analyzer for their FPGA synthesizer? Synopsys FPGA Compiler II's
static timing analyzer, when compared to DC, is really a joke. So,
how are we supposed to check timing... in the back end, you dolt!
Yeah, exactly what I like: waste a bunch of time synthesizing only
to find out that your timing is 20% off. Hmmm...smells like
physical synthesis?
2.) Skew. This is also a life or death issue in FPGAs. Have you ever
done a low-volume telecom chip with 8 clocks on an FPGA that only
has 4 clock buffers? I guess those other clocks have no problems
with skew; heck why not just get rid of clock buffers all together,
they just generate a bunch of heat!
3.) Power analysis. You obviously have the luxury to put all of your
designs on ASICs. In my company 90% of our designs are done in
FPGAs. Note that this is not a few designs either. We typical do
hundreds of unique FPGAs a year. We always are worrying about power
and thermal issues in our applications. There are no tools to
address those issues, except in the back end with tools like Xilinx
X-Power, which is not mature.
4.) Congestion not an issue....oye! How about filling a Virtex II 6000
to 90% and have it run at 100 MHz? Have you ever bought up the Xilinx
floorplanner or chip editor on such a design? It's a mess. Maybe I
am wrong: 75% of path timing due to route and 25% due to logic has
nothing to do with congestion! Again, this smells a lot like physical
synthesis.
As you pointed out, no one is truly doing physical synthesis for FPGA.
There are some floorplanning tools (with some physical-synthesis-like
attributes) and IPO tools out there, but nothing mature. With chips
like Virtex II Pro and Stratix out there, you can now realistically
get to 1 million ASIC gates, running at 100+ Mhz. Gee, these specs
compare to specs 2 to 3 year ago, when physical synthesis was starting
to take off for ASIC!
5.) Verification. Once again, because its reprogrammable and no NRE is
involved, there seems to be less interest to get it right the first
time for FPGA designers. I am sick of hearing from Xilinx and Altera
telling designers to take it to lab. I kid you not, at DAC 2000, the
booth-boy at Altera was telling designers that simulation was a "waste
of time," because taking it to the lab was much quicker. Waste of
time... serenity now! Can you imagine trying to find a bug in a
1 million gate design on a 1024 BGA chip? Good Luck!
It seems to me that FPGAs are slowly encroaching on ASICs. It's our duty as
engineers to ask our EDA vendors to provide tools that work as well or better
than ASIC tools. I ask every time I see Synplicity, Synopsys, and Mentor.
- Ted Boydston
Harris Corp GCSD
---- ---- ---- ---- ---- ---- ----
From: Ron Waxman <r.waxman@computer.org>
John,
I love reading your in-depth, from the shoulder (or is it from the hip?),
down-to-earth analyses. You tell it "like it is." Much better than
Consumers' Report.
- Ronald Waxman
EDA Standards Consulting Reston, VA
---- ---- ---- ---- ---- ---- ----
From: Yaniv Ben-Haim <yanivbh@hywire.com>
Hi John.
I tried to search the site to find the DC synthesis checklist but I couldn't
find it. Is it possible to send the link to the checklist?
- Yaniv Ben-Haim
HyWire LTD. Israel
[ Editor's Note: See #2 at http://www.deepchip.com/downloadpage.fhtml ]
---- ---- ---- ---- ---- ---- ----
From: Mike Dini <mdini@dinigroup.com>
John,
What you are saying:
- I have done things this way for years.
- A 'new tool' has come along that doesn't do things this way.
- Therefore 'new tool' sucks.
You are really off-the-mark here.
- Mike Dini
The Dini Group
---- ---- ---- ---- ---- ---- ----
From: Ray Andraka <ray@andraka.com>
John,
I couldn't agree with you more. Synplicity's strength is in FPGA synthesis.
Because their tool was written for FPGAs without compromise for an ASIC
flow, it has been the best tool for synthesizing to an FPGA. Unfortunately,
they have been distracted by the grass is greener syndrome and as a result
their strong suit has been weakened without commeasurate gains in the rest
of their hand.
- Ray Andraka
Andraka Consulting
---- ---- ---- ---- ---- ---- ----
From: Muzaffer Kal <muzaffer@dspia.com>
Hi John,
I don't think you're being fair. In the last paragraph, all the features
except In-Place-Optimization are physical design tool issues not synthesis
issues. When was the last time you let DC do your clock tree? As a basic
synthesis tool Synplify ASIC is no worse than Ambit Buildgates and gives
you the results much faster.
- Muzaffer Kal
DSPIA
---- ---- ---- ---- ---- ---- ----
From: Tim Davis <timdavis@aspenlogic.com>
John,
You make some good points. It cuts both ways though. Do I look stupid
enough to think that an ASIC synthesis tool could do a good job at FPGA
synthesis? The Synopsys FPGA synthesis suite supplied to Xilinx for their
Foundation series was extraordinarily painful to use.
I agree with your bashing the Synplicity m-droid. Perhaps he will go off
and read his own manuals now. Complexity yields power and I would like to
have that in my back pocket when I need it. I like the idea of push-button
results as long as I can pop open the hood and tinker as I need to in the
database. You certainly get that with Exemplar Leonardo Level 3. We don't
have clock trees or skew problems to mess with but there are plenty of other
log jams available in FPGAs. That is why I can't see myself switching to
Synplicity for FPGA synthesis right now even if, on a rare occasion, their
push-button approach produced slighty better results.
As for ASIC design I haven't used any of the three for that purpose.
- Tim Davis
Aspen Logic, Inc.
---- ---- ---- ---- ---- ---- ----
From: Andre Gaytan <Andre.Gaytan@Sun.COM>
John,
You sound like the circuit designers who would have a fit with the ASIC
designers because they could have done the same job in less transistors.
The bottom line is that this stuff has got to become less complicated.
You are probably right about Synplicity ASIC not being less complicated
but at least they are trying.
- Andre Gaytan
Sun Microsystems, Inc.
---- ---- ---- ---- ---- ---- ----
From: Jim Dean <jdean@Catena.com>
John you asked:
"Do I honestly look that stupid?"
Much like beauty, I suspect it depends on the eye of the beholder. :-)
Cheers,
- Jim Dean
Catena Networks Ottawa, Ontario, Canada
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
[ Editor's Note: Overall, I recieved over 50 letters on this topic. The
above 14 letters came directly from people on the ESNUG mailing list. The
remaining letters were from Synplicity's response on their web site:
http://www.synplicity.com/synplicity_responds.html
plus the fact that they mass emailed the customer base saying "John
Cooley says Synplify is hard to use - What's your opinion?". I was
flooded with letters that read like:
From: Don Gunn <dgunn@kaytronics.com>
John,
I just saw a reference to your statement about Synplify not being
easy to use and I am quite puzzled as to why you would make a
statement like that.
The first time I opened Synplify, I had a design synthesizing within
about 5 minutes. I found it to be extremely intuitive and I am not
sure how they could make it easier to use. Everyone that I know who
has used Synplify has said the same thing. I am curious as to what
would have led you to make a statement like this. I have used
Synplify, Synplify Pro and Amplify all of which were extremely quick
to get up and running and I found them much more intuitive than
Leonardo Spectrum, and Synopsys FPGA Express (the results are
typically a fair bit better too!) As far as I am concerned Synplicity
probably didn't even need to bother with documentation for their
software because it is redundant.
- Don Gunn
Field Applications Engineer
Kaytronics Calgary Calgary, Alberta
The problem was that these letter writers hadn't read my column -- yet
they were commenting on it! So I replied to each of them with:
Have you read my column or are you just vouching for Synplicity
without having read it? I appreciate rebuttals to the column, not
blanket endorsements. It's at:
http://www.eedesign.com/columns/industry_gadfly/OEG20020311S0058
I'd appreciate your thoughts after reading it.
- John Cooley Holliston, MA
What follows next are the many responses I got back from people *after*
they had *actually* read that controversial EE Times column. - John ]
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
From: Michael Watson <michael_watson@ins.memec.com>
John,
It's understandable that you want rebuttals and not blanket endorsements.
The one rebuttal I have is that Synplify ASIC software does in fact include
static timing analysis -- some vendors have verified Synplicity's static
timing analysis capabilities. Synplify ASIC software has been used on some
big designs without requiring partitioning.
John, I do read your column and I think for the most part you are very good
and accurate. My concern is you are not being unbiased. I will continue to
read your column and I am grateful to you for the reply!
- Michael Watson, Xilinx Dedicated FAE
Insight Electronics, LLC. San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Karl Kaiser <karl.kaiser@resonext.com>
Although we use Synplicity for FPGA and like it, I think John has a
point on the ASIC synthesis!
- Karl Kaiser
Resonext
---- ---- ---- ---- ---- ---- ----
From: Myles Watson <watsonm@mouselemur.cs.byu.edu>
John,
You caught me. I only use Synplicity for FPGA synthesis, and hadn't read
the column.
Since I haven't used Synplicity for ASICs, my comments aren't relevant.
- Myles Watson
Brigham Young University
---- ---- ---- ---- ---- ---- ----
From: Craig Julian <cjulian@magisnetworks.com>
Hi, John,
You wrote quite a blistering commentary. Since I haven't used Synplicity's
ASIC synthesis tool, I can't make an informed response. You do bring up
valid issues, however, which they will need to address if they want to play
with the big boys. I'm just happy to see other companies out there
developing ASIC synthesis products. Synopsys needs some competition.
BTW, we are using Ambit (non-PKS version) for ASIC synthesis. So far it's
looking pretty good, although the datapath option (which costs $5k more than
the tool) is a must. I'll give you a final evaluation once we tape out.
- Craig Julian, Senior Staff Engineer
Magis Networks San Diego, CA
---- ---- ---- ---- ---- ---- ----
From: Micha Nisani <micha@mobilian.com>
Hi,
I just read your column. My e-mail intention was only regarding Synplicity
as excellent FPGA tools. (Regarding their vast amount of switching,
software directive etc., did you try other software? I must say that their
defaults values and default results are excellent point to start.)
I agree with you regarding the ASIC issue. The problem in this area are
quit different, and we have fight with them with the ASIC tools that we
use (Synopsys, Cadance).
- Micha Nisani
Mobilian Yoqneam, Israel
---- ---- ---- ---- ---- ---- ----
From: [ Tiny Tim ]
Hey John, long time no hear. I left [ an FPGA company ] and have landed at
[ another FPGA company ]. Been quite a fun ride these last 4 years.
I had not read your article prior to commenting on it. (My bad). But here
are my thoughts and experiences.
You talk about user's manuals and reference guides which cover about 1100
pages of which a fair bit is dedicated to graphical interface. GUI's tend
to get pretty wordy and graphical in documentation. So yeah, the docs can
get pretty long winded.
Of the directives and attributes, part of the reason there are so many is
that many of them are vendor specific. So, for every vendor you support,
you will have several overlapping ones as well as some specific ones just
for a particular vendor. So yeah, to explain each individual one for each
individual vendor can get long winded, even if sometimes you are repeating
yourself.
The Tcl commands are another thing that can get long winded as you are
taking all the graphical options and manually applying them to a scripted
environment. So yeah, you're kind of repeating you're graphical
documentation. Not to say that it is any better than Synopsys when run
in a scripted environment (which is what most of us do) either.
Of the directives and menus etc etc. Generally these aren't used as it
has been my experience that Synplify usually will make the "correct"
decision given just a few simple timing constraints. To this day I have
not had the need to use Amplify although I hear it does a very fine job.
Of the directives and attributes, many have overlap with similar ones
from Synopsys.
There was one thing that was not discussed in the article which I think
is important and that is customer service. Synplicity has a great level
of customer service in terms of support, addition of new features, quality
of release, timeliness of responses and overall communication with their
customers. That is something which is priceless when you are wrestling
timing closure to the ground or find a show stopping issue with a tool.
Synplify may have understated the "ease of use" in terms of deep sub
micron multi million gate ASIC synthesis requirements. And I'm sure
the first release of the tool will be lacking in some features required
for those types of designs. But there are an awfull lot of sub 4-5 million
gate .18 micron designs being done out there that the tool will perform
well on and be quite easy to use.
Synplify basically owns the FPGA synthesis market today, but 8 years ago
that was a very different story. It will be interesting to see what a
little new blood in the ASIC market can bring in the next 8 years.
I would please like to remain anonymous in regards to this discussion.
- [ Tiny Tim ]
---- ---- ---- ---- ---- ---- ----
From: Jim Tobias <jim@jrtobias.com>
Hello John,
You are correct in that I didn't read your article directly. Now that I
have I see why you are confused with my comment. We use Synplicity for FPGA
synthesis and not for very often for ASICs. We primarily use Ambit for
ASICs and Synopsis Design Compiler for special problematic cases or if our
client has a preference that we do use Synopsys.
In addition to building FPGA based systems, we use FPGA's to emulate our
ASICs before we release the designs to the fab. My comment about the
greatness of Synplicity applies to its use for FPGA's. I apologize for not
being more thorough in my research before commenting.
- Jim Tobias, President
White Eagle Systems Technology
---- ---- ---- ---- ---- ---- ----
From: Scott Tierno <fstierno@ms.cc.sunysb.edu>
Hi John,
I just read your article. It is concerned with ASIC synthesis, which is not
related to what we do with Synplify. In our courses, we use Synplify for
SPLD, CPLD, and FPGA synthesis. It is one of a number of VHDL related tools
that we use in our courses. And I must respectfully maintain my position
that the product is relatively easy to use.
Synplicity has designed Synplify with a simple and somewhat intuitive GUI,
and our students are using it and producing results very quickly.
To give you some background: All designs they write must be compiled,
simulated, synthesized, simulated, fitted, simulated, and programmed into
a device. Finally, once their design has been programmed or downloaded
into a device, the design/device is functionally tested in a 'test station'
in real time.
In addition, as a vendor, Synplicity has provided excellent pricing and
support services, again for our needs. Hope this clarifies my position.
- Scott Tierno
University at Stony Brook Stony Brook, NY
---- ---- ---- ---- ---- ---- ----
From: Frank de Bont <Frank.de.Bont@arcobel.nl>
Hi John,
We are using Synopsys tools since 1996. As an ASIC design house we use
Design Analyzer, DC Ultra, DC Expert, PrimeTime, DFT Compiler, TetraMax,
HDL Compiler Verilog, VHDL compiler, Floorplan Manager and other tools
unrelated to synthesis. As you can see a lot of tools just to synthesize
your design.
Resently we purchased Synplify ASIC. One tool covering all above mentioned
Synopsys tools except Tetramax and Floorplan Manager.
Reasons for purchasing Synplify ASIC:
* One tool for synthesis with static timing analysis and DFT capability.
The DFT Compiler capability is limited but sufficient. Synplify ASIC
replaces all your flipflops with scan equivalent flipflops. Synplify
ASIC cannot insert or create the scan chain itself. For this reason
you still need TetraMax or other tools.
* Compiling time is much shorter using Synplify ASIC. I will give you an
example: Design of approx: 230K gates @ 200 Mhz using LSI Logic LCBG12FP
- DC.2001.08-SP1 (Linux, 1G processor 4GB memory)
runtime 16,480 sec (4 hours and 34 minutes)
- Synplify ASIC 2.2 (Windows 2000 1.4G processor 1.5 GB memory)
runtime 1,890 sec (31.5 minutes)
We noticed that synthesis run times are significantly shorter w/ Synplify
ASIC. System memory usage is up to 1/6 compared to Synopsys DC. Of
course, everything is design related.
* The report files from the static timing analyzer of Synplify ASIC give
almost in all cases the same result as PrimeTime. We used our PrimeTime
scripts for comparison. As crosscheck we used the Verilog gatelevel
netlist of Synplify ASIC and put this in PrimeTime and also the other way
round. Results were almost equal. The biggest advantage is the
cross-probing capability in Synplify ASIC between your HDL source, timing
reports and the gate level netlist.
The design analysis capabilities are more powerful and advanced with
Synplify ASIC compared to Design Analyzer. In HDL Analyst you can view
your RTL code as well as your gate level netlists & perform crossprobing
between your HDL source and viewer.
* Quality of Result is excellent. Results are re-producable. Minor
changes in your HDL source, like swapping case statements or changing
signal names will not produce a different result. With Synopsys DC your
result is each time different due to a seed factor usage which is beyond
your control.
* Top Down Synthesis capability for designs up to 1.5 M gates. For bigger
designs you need the bottom-up flow due to limitation of the 32-bit
operation system. As soon as 64-bit archictectures are supported on Unix
and Linux a top down design flow can be used. To perform a top down flow
with DC is very hard due to the huge amount of system memory needed. We
noticed an average need of system memory of 12-14 KB/gate for Synopsys DC
compared to 1-3 KB/gate for Synplify ASIC.
John I do not understand your remark on crosstalk, electromigration & signal
integrity. Also clock tree design is not part of synthesis; it is a design
methodology. These design issues are not covered during synthesis but
should be solved during back-end, using different tools.
I sound like a sales guy but I am just an engineer using both Synopsys and
Synplicity tooling. I would not say that Synplify ASIC is an easy tool to
use, but it is less difficult compared to Synopsys DC or PrimeTime, whereas
it gives the same or even better results.
- Frank de Bont
Arcobel ASIC Design Centre BV Hertogenbosch, Netherlands
---- ---- ---- ---- ---- ---- ----
From: David Maguire <dmaguire@banderacom.com>
Pro Synplify ASIC:
Having experience with their Synplify Pro, I was able to get basic synthesis
running with Synplify ASIC in about an hour. I was able to synthesize
modules much larger than Synopsys could, but to get equivalent timing, I did
break up my modules into smaller blocks. Synthesis was also much faster.
One extreme case was a module that took 8 hours with Synopsys, only took
about 20 minutes with Synplify. This module had about 12K instances.
Con Synplify ASIC:
The main feature preventing Synplify ASIC from going mainstream is the
ability create groups and prioritize them. Synplify ASIC does not provide
good facilites for improving the timing outside of recoding RTL or working
in the physical domain.
- David Maguire
Banderacom
---- ---- ---- ---- ---- ---- ----
From: Dean Moss <Dean.Moss@xilinx.com>
Actually, what I read out of this was that John was saying that Synplicity
was not "hard" enough. What I mean by this is that John mentions things
(mostly physical design issues) in his write-up that seem to be difficult
to do in ASIC design which are completely absent in the design cycle of the
FPGA. I got the feeling that he was saying that a tool so simplistic could
never handle such difficult tasks (McDonald's analogy). Now it is all a
matter of opinion at this point since Synplicity has not established that
it can or can't do these "difficult" tasks. What is interesting to me is
that this challenges some core beliefs of the ASIC designer and with every
challenge of this sort, there will be significant resistance.
I have worked with enough ASIC design teams to know that there is a strong
tie between job security and how complex of a Design Compiler script that
you can write. If Synplicity can actually change the design paradigm for
ASICs then it will be interesting to see how hard the design community
pushes back before it caves in. What is a fact is that more ASIC designers
are learning FPGA synthesis tools because the FPGA vendors have been
successful in capturing more and more of the ASIC market every year. It
seems like an obvious business extension for Synplicity to extend its FPGA
synthesis to cover ASIC synthesis.
In his attempt to discount Synplify, he has opened the door on some very
interesting reasons to use FPGAs. I know that it was not his intent but,
he listed several things in his last paragraph that are "extremely
difficult in an ASIC" that you don't need to do with an FPGA. I like to
take the approach that he just explained why one day FPGAs with rule the
ASIC marketplace.
- Dean Moss
Xilinx
---- ---- ---- ---- ---- ---- ----
From: Juergen Dennerlein <Juergen.Dennerlein@eed.ericsson.se>
Hello John,
I work in Ericsson in the Core Radio Network Development division. I'm
resposible for the tools of the complete FPGA design flow.
Regarding your article from the 11th of March in the Industry Gadfly, I
would like to state that the experience I made with the Synplicity software
is a very positive one. Normally the engineers need only a 1 day intro to
the tool in order to be able to start with real project work. Compared with
the Synposys software, where the designers normally have to attend a 1 week
training, it's a big advantage!
Comparing the time that we need in order to set up a synthesis there's also
a big difference. Due to the very intuitive GUI of Synplify software it
normally takes less then half a day to setup a synthesis for a 500 k gate
design. In contrast we have to spend at least a week or two in order to
build up a similar synthesis environment for the Synopsys software.
In your article you refer to a "huge" number of attributes, directives,
constraints ... that are possible to use in the Synplify software. Only in
some cases they are needed. My experience is that in more than 90% of the
cases it's not necessary to apply extra switches. If we have to use
directives, attributes, ... than they are very well documented. That's also
in contrast to the Synposys software where the documentation doesn't reveal
that easily the needed information!
During the last weeks we had some very interesting bench marks that showed
very clearly some advantages of Synplify ASIC. For example, one of our
designs is highly parameterized using generic and loop statements. We also
use 3-dimensional arrays. The Synopsys software needs more than 30 hours
for the synthesis! In contrast the Synpliyf ASIC software needs only 40
minutes and achieves results of the same quality than the Synopsys software.
The setup of the Synopsys synthesis environment took more than a week. The
results from Synplify ASIC were achieved within a day.
So a clear statement from my side is that Synplicity software is far more
easy to handle and more efficient than the Synposys software!
- Juergen Dennerlein
Ericsson Eurolab Deutschland GmbH Nuremberg, Germany
---- ---- ---- ---- ---- ---- ----
From: Bill Cox <bill@viasic.com>
Hi, John,
Although my own stock in Synplicity got temporarily hammered when your
latest article about them was published, I actually got a real kick out
of it. I like to see someone with the guts to call marketing pukes on
their bull now and then. However, in Synplicity's defense, I would say:
- Having the switches and options doesn't make Synplify ASIC hard to
use. Most of the options are set automatically based on local
properties of the design using some pretty good heuristics. Most users
never need to learn about the vast majority of the options Synplify can
actually handle, but they are there for advanced users.
- Synplify Pro is targeted at users with simpler problems than those
many ESNUG enthusiasts deal with on a daily basis. There are a lot of
users out there that don't want to deal with clock tree synthesis, In
Place Optimization, or for that matter, any physical layout issues or
timing closure on the back-end. The fab does it for them with tools
that provide the capabilities, and staff with expertise in their use.
- As for synthesizing 500K gates all at once, I would ask the following:
What limits the size of blocks Physical Compiler can handle today?
I've asked that question a couple of times, and apparently the largest
single issue is compilation speed. I've talked to people who claim to
have used it on flat 200K gate circuits, and they rave about the
results. What would happen if you built Physical Compiler on top of
tools that ran 10x faster and used far less memory? I think you can bet
on the following: tools (from Synplicity and others) that can deal with
1 million gates at a time and achieve timing closure automatically are
coming.
Keep up the vigilance!
- Bill Cox
VI ASIC
---- ---- ---- ---- ---- ---- ----
From: Choo Leng <cllim@pixelmetrix.com>
Hi John,
I feel that there are definitely some areas that Synplicity still needs to
improve and they are as follows:
1) Timings
a) At times, Synplify generated much higher timings as compared
to actual Altera's Max+Plus2 timing. For example, 81.7 Mhz as
compared to only 47.9 MHz.
b) Synplify ignores Altera ESB and components timings, which I
feel that Synplify needs to consider these timings as to
whether using them will cause timings not meet due to the
complex design or whatever the case.
2) Synplify does not provide any features that locks the routing or
optimization of a particular design and port this optimised block
of design to another design.
3) I tried to constrain a path that has mutli-cycle paths using Synplify,
but, it seems that Altera does not understand that constraint and
ignores it. Is there any way to solve this problem?
That's about it.
- Lim Choo Leng
Pixel Metrix
---- ---- ---- ---- ---- ---- ----
From: [ A Little Bird ]
Hi John,
Please keep my name and company anonymous.
I'd like to share with you and with your column readers some of our
observations using Synplify ASIC. Part of our business is concentrated in
FPGA to ASIC conversion. Most of our customers use Synplify Pro as their
FPGA synthesis tool. We have been using Synplify ASIC mainly for logic
synthesis and the ease-of-use feature for this particular task comes from
the fact that our customers can provide us with their Synplify Pro scripts
for our usage in the ASIC tool, then the time spent preparing scripts is
minimum as opposed to if we took the Design Compiler way. At this stage
of our design flow we are not concerned yet with timing closure. In
addition, we make sure that the functionality in the RTL is equivalent to
the one after synthesis by formal verification means. Another important
observation is we always got faster runtimes, at least in our last 4
designs, using Synplify ASIC than Design Compiler.
- [ A Little Bird ]
---- ---- ---- ---- ---- ---- ----
From: [ I Wear My Sunglasses At Night ]
Hi John,
I would like to make a few comments in response to your posting about
Synplicity. If you decide to post it, please keep me anonymous.
I have been using Synopsys tools for a reasonable while and lately I have
been evaluating Synplify ASIC. Yes, it is not a solid tool yet like DC
because we know how long has been DC around and how much improvement has
it has gone through and Synplify ASIC has not produced an offical tapeout
yet. But the Synplify ASIC engine is certainly interesting and the results
that I have seen are better/comparable to DC in the blocks that I tested
with at a cheaper price. Then, will I rely on Synplicity's timing engine
to tapeout?? Certainly not. But are people trusting DC's timing results
to tapeout? When the whole industry is turning towards synthesis (with some
sort of valid physical info, not wireload models), I am not sure if I'll be
terribly worried about the accuracy of Synplify ASIC's timing engine.
But I would like to add that the timing reports given by Synplify ASIC are
very much inline with DC's timing reports for the same design with the same
wireload models, which is meaningless to me anyway. IMHO the quality of
logic produced and the time it takes to produce that logic is certainly
superior to DC's logic optimization, at least in the critical blocks that
I have tried it on, though there are issues that I have to deal with.
Speaking about the different switches for better synthesis; I would like to
have switches to control my synthesis results. I strongly believe that a
"one approach fits all" method is never achievable nor desirable and in that
aspect I have talked to the Synplicity folks many times to give me more
control over the design that I synthesize rather than the tool choosing its
options on the fly. I certainly would love to have the scenario where the
tool would do all the sensible optimizations that any engineer would desire
rather than making them explicit options (For instance optimizing circuit
for the fastest clock when a gated clock is encountered without a set case
analysis. This is not what DC does), but at the same time I should be given
the control to change the behavior (to optimize for the slow clock by
setting case analysis, which Synplicity did not have initially). So if
Synplicity thinks options are evil, I disagree; and if someone says DC is
better because it has more options, I doubly disagree. Hey Synopsys, cut
down the mundane options and you Synplicity, let me tune my design as I
wish with more options.
Clock Trees?? Hmm... Who builds clock trees during synthesis? Let one
company come out and say that they build clock trees when they synthesize
eliminating the "ideal clock" stuff; I would jump in right away to evaluate.
I know Synopsys has a road map to come out with a clock tree compiler, but
until then this is not a handicap for a synthesis engine. If I don't think
physical, then the concept of congestion is non-existent. But, scan is a
real good mismatch. Synplicity's scan is virtually non-existent.
- [ I Wear My Sunglasses At Night ]
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 12,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
