> "Last year the big news at the SNUG'01 gathering was that PrimeTime
> had added Signal Integrity to its analysis capabilities. It was
> very creatively named "PrimeTime-SI" by that ever imaginative
> Synopsys Marketing department. (These are probably the same Mensans
> who named that early Synopsys IPO tool "FloorPlan Manager". d'oh!)"
>
> - Cooley commentary from the DeepChip web site on 3/11/02
From: Ronald May <Ron.May@synopsys.com>
Good morning John. I apologize in advance for perhaps appearing
sensitive, but I'd appreciate it if you would not slam our marketing
people on your web site. I am making reference to the remarks on
DeepChip. I'd like to think that our Marketing department is indeed
"ever-imaginative." We launched a new corporate ad campaign last year
that received two consecutive EE Times #1 advertising audit ratings.
Every company has a message to get out, and that's the responsibility
of their marketing organization. How you position your site and
yourself is indeed your own personal marketing.
I believe that the marketing people on my team and in the company
would consider it acceptable if you tease us, but in a less than
abrasive manner.
With my thanks and personal regards,
- Ron May
VP of Synopsys Corporate Marketing Mountain View, CA
( ESNUG 390 Subjects ) ------------------------------------------- [03/20/02]
Item 1: ( ESNUG 389 #2 ) PhysOpt def2pdef Chokes On Already Routed DEF 5.3
Item 2: ( ESNUG 388 #8 ) Cadence CTGEN & CT-PKS Easily Meet This Skew Goal
Item 3: Alexandre's Easier To Use Vera Randomization/Semi-Random Functions
Item 4: ( ESNUG 389 #3 ) Speed, Business, & Legal Problems Hinder SystemC
Item 5: ( ESNUG 389 #12 ) PrimeTime/PrimeTime-SI Core Dump On Reduced SPEF
Item 6: Too Many Letters About The "Lies, Damn Lies, & Synplicity" Column
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 390 Item 1 ) --------------------------------------------- [03/20/02]
Subject: ( ESNUG 389 #2 ) PhysOpt def2pdef Chokes On Already Routed DEF 5.3
> I have this problem while trying to convert the routed DEF (from SE-Ultra,
> after CTgen and Wroute) to PDEF with the def2pdef I get the following:
>
> Warning: Detect syntax error near token '*' at line 415183. Continue to
> parse until the next correct rule can be applied. (DEFIN-16)
> Warning: Probably the special wiring continue point has incorrect
> syntax. (DEFIN-20)
>
> Those lines in the DEF are net routing information:
>
> - weim_lba_b ( PIN weim_lba_b ) ( z497 x )
> + ROUTED m1 ( 4329800 574150 ) via1 ( * * 500 ) ( 4351200 * 500 ) via2
> ( * * 550 ) ( * 576650 550 ) via3 ( * * 550 ) ( 4352600 * ) ;
>
> Any ideas anyone? The .DEF version is 5.3
>
> - Ofer Paperni
> Motorola Semiconductor Israel
From: [ This Little Piggy Ate Roast Beef ]
John, I work at a competitor of both Cadence and Synopsys. Please keep me
anon here because my boss doesn't like it when I tell the truth.
I am glad to see that Cadence continues to come up with variations of their
DEF syntax, despite any other EDA vendor's efforts to parse their already
ambiguous "standard". As the guy who writes our parser, it's always amusing
to see new variations come up, and new places where Cadence directly violate
either what they say is correct DEF or alternatively make version X of DEF
incompatible with version X-1. You can also detect deliberate attemtps to
make LEF/DEF impossible to parse with lex/yacc, although they haven't
defeated me yet!
What Ofer's problem wiring MEANS is as follows:
"Start on metal 1 at (x1,y1) place a via to metal 2 at that position
but a positive end extension on the track of 500 nm at that point,
then go on metal2 to (x2,y1) and end extend that segment by 500 nm in
the direction of travel, then put a via in up to metal 3 with an
extension of 550nm and route to (x2,y2) with an extension of 550 nm
then go to metal4 and route to (x3,y2)"
What I believe is barfing the PhysOpt def2pdef parser is Ofer's/SE-Ultra's
"viaM ( * * N )" syntax. Normally you only ever have "( x * N )" or
"( * y N )" statements to say the next point has the same x but different y
as the previous point, and to overshoot the end point by N so as to satisfy
end extension rules for via coverage (due to sub-wavelength effects).
Normally you don't give a position just after a via but this is needed here
in order to extend the start of the attached track.
The PhysOpt def2pdef converter may just not cope with end extensions. If it
CAN cope with the extensions but not with the ( * * N ) syntax, then use
your favorite language (Perl/Awk/Python/Tcl) to change each occurence to the
"NEW mP ( x y N )" syntax ( i.e. starting a new path with an extension at the
start.) Unfortunately this is a tad tricky because you need to know which
layer you are starting on and what the current coordinate is. I give below
the desired result, but I cannot guarantee that the script to do it is easy!
What was:
- weim_lba_b ( PIN weim_lba_b ) ( z497 x )
+ ROUTED m1 ( 4329800 574150 )
via1 ( * * 500 ) ( 4351200 * 500 )
via2 ( * * 550 ) ( * 576650 550 )
via3 ( * * 550 ) ( 4352600 * ) ;
Should become :
- weim_lba_b ( PIN weim_lba_b ) ( z497 x )
+ ROUTED m1 ( 4329800 574150 )
via1 NEW m2 ( 4329800 574150 500 ) ( 4351200 * 500 )
via2 NEW m3 ( 4351200 574150 550 ) ( * 576650 550 )
via3 NEW m4 ( 4351200 576650 550 ) ( 4352600 * ) ;
I hope this helps. Basically it comes down to:
1) get Synopsys to update def2pdef. (Good luck!)
2) get Cadence to be a little more open about the current syntax
for LEF/DEF. (Even harder!!)
Good luck.
- [ This Little Piggy Ate Roast Beef ]
---- ---- ---- ---- ---- ---- ----
From: Michael Stabenfeldt <stabie@stabie-soft.com>
Hi, John,
I believe the PhysOpt DEF 5.3 problem is the variable extension syntax. The
+ ROUTED m1 ( 4329800 574150 ) via1 ( * * 500 ) ( 4351200 * 500 ) via2
says extend the metal 2 500 database units before beginning and 500 database
units after 4351200 574150. The variable extension stuff is not used that
frequently. The reason I know this is I got bit by the same problem on the
Verilog reader in my software. Fortunately, my database supported variable
length extensions, so it was an easy fix. I wonder if Synopsys has that
notion...
- Mike Stabenfeldt
Stabie-Soft, Inc. Austin, TX
( ESNUG 390 Item 2 ) --------------------------------------------- [03/20/02]
Subject: ( ESNUG 388 #8 ) Cadence CTGEN & CT-PKS Easily Meet This Skew Goal
> I'm wondering if anyone in ESNUG has experience working with Cadence's
> CTGEN (clock tree synthesis tool) in Silicon Ensemble.
>
> I have a design with complexity of about 500 K gates, 0.25 um technology.
> The largest clock domain (100 MHz) has around 9,000 flip-flops connected
> to it, and clock skew requirement for that domain is 0.25 ns (this number
> was obtained from post-synthesis STA. Does anyone know if such a skew
> requirement is achievable by CTGEN?
>
> - Suttinan Chattong
> Centre For Wireless Communications Singapore
From: Satya Sridhar <satya.sridhar@wipro.com>
Hi, John,
In one of our designs, we could achieve a skew of 0.28 nsec using CT-PKS for
a 500 Kgate design with 9,121 flops. That skew value is from the clock tree
report from PKS.
- Satya Sridhar
Wipro Technologies Bangalore, India
---- ---- ---- ---- ---- ---- ----
From: Arvind Raghavan <arvindr@vitesse.com>
Hi, John,
We ran a design through CTGEN that has about 20,000 flops and we were able
to get a skew of about 750 psec. This was in 0.18 um design, so I think
you should be able to meet your skew requirements. Please note that CTGEN
allows you a lot of flexibility and you might have to run CTGEN a couple
of times to get the optimal skew. CTGEN uses a constraints file which
contains a structure for the clock tree. You can manipulate this to get
the optimal tree you want.
- Arvind Raghavan
Vitesse Semiconductor Camarillo, CA
( ESNUG 390 Item 3 ) --------------------------------------------- [03/20/02]
From: Alexandre Gnusin <alexandre.gnusin@tundra.com>
Subject: Alexandre's Easier To Use Vera Randomization/Semi-Random Functions
Hi John,
In my opinion, Vera is too object-oriented. This Vera obession on object
orientation means that some straightforward functions, built-in into
classes, are not available for straightforward procedural programming.
For example, there are no simple randomization functions that are easily
useable for random and semi-random tests. We had to overcome this problem
creating our own random functions:
class RL {
rand integer num;
integer low, high, flag;
constraint main {
num <= high;
num >= low;
num dist {low:low+(high-low)/3 :/80,
low+(high-low)/3:high-(high-low)/3:/15,
high-(high-low)/3:high :/5};
}
}
class RN {
rand integer num;
integer low, high, flag;
constraint main {
num <= high;
num >= low;
}
}
class RH {
rand integer num;
integer low, high, flag;
constraint main {
num <= high;
num >= low;
num dist {low:low+(high-low)/3 :/5,
low+(high-low)/3:high-(high-low)/3:/15,
high-(high-low)/3:high :/80};
}
}
function integer rl (integer low, integer high) {
RL p= new;
p.low = low;
p.high = high;
if(!p.randomize()) error("Randomization error") ;
rl = p.num;
}
function integer rn (integer low, integer high) {
RN p= new;
p.low = low;
p.high = high;
if(!p.randomize()) error("Randomization error") ;
rn = p.num;
}
function integer rh (integer low, integer high) {
RH p= new;
p.low = low;
p.high = high;
if(!p.randomize()) error("Randomization error") ;
rh = p.num;
}
Here is an example of random functions usage:
for (i=1; i<20;i=i+1) Send_NWRITE (rl(0,2), 64, 0, rn(0,2), 8*rl(1,31), 0);
Each of these functions, rl, rn, and rh returns a random integer between
our specified low and high limits. The difference between them is that
rl will return more likely a "small" number, rn - any number and rh - a
"high" number.
- Alexander Gnusin
Tundra Semiconductors Ottawa, Ontario, Canada
( ESNUG 390 Item 4 ) --------------------------------------------- [03/20/02]
Subject: ( ESNUG 389 #3 ) Speed, Business, & Legal Problems Hinder SystemC
> Our experience with C-Level was that the C-Level C++ HDL simulated so
> much faster than Verilog, that having ANY Verilog in the design reduced
> the simulation speed to nearly Verilog speeds.
>
> Let me be clear -- SystemC is NOT the answer. SystemC performance is
> around 1/1000 the performance we were getting with C-Level style C++.
> SystemC is not much better than VCS - if that. If you are going to
> create a new language, which Synopsys did with SystemC, why not address
> the simulation speed issue?
>
> - Dan Joyce
> Compaq Austin, TX
From: Bernard Deadman <bdeadman@sdvinc.com>
Hi, John,
I went back and read in detail Dan Joyce's comments on C-Level's Cycle-C in
ESNUG 386 #10. I have a different view.
C-Level's Cycle-C was regular C with bit slicing and concatenation macro's.
It doesn't take much to create something similar yourself, though it seems
the real point was by using the C-Level Cycle-C simulation coding style, you
were writing C in a style that fitted C-Level's synthesis technology.
Dan's correct about high speed, cycle-accurate, lack of kernel etc., all of
which work where the user really understands what he is doing. However,
like all cycle-accurate simulators, there are evaluation ordering issue
traps for the unwary. There were, as Dan hinted, other issues with C-Level
Cycle-C (at least in the form I saw it a year ago), including it's lousy
hierarchical component instantiation, its inability to accurately model
signals across two clock domains, its lack of tri-state signals, it's
inability to generate VCD files from inside the design hierarchy and the
lack of a testbench solution that would drive a model with multiple,
asynchronous clocks. It's true it could write Value Dump files, ie it
could output huge files with the value of every signal at every clock edge,
however it couldn't make Value Change Dump files because it didn't remember
the last values of signals. Fixing these issues would have slowed Cycle-C.
Where I think Dan is wrong is in declaring SystemC to be slow. I think you
should see SystemC as a not-yet-standardized and still unstable syntax,
just like Verilog & VHDL were at the outset. It's certainly true the
present reference implementation of SystemC is slow, indeed the kernel of
the latest 2.0 release is generally believed to be somewhat slower than the
previous 1.x releases which is not a positive step! It *IS* however
possible to make an implementation of SystemC (just as VCS was a fresh
implementation of Verilog) that will achieve near the same simulation
performance as Cycle-C would have achieved if the ugly issues had been
fixed. Most importantly this can be done while maintaining the SystemC
synthesis route to silicon.
The *BIG* problem IMHO is the business model. How does a vendor get a
return on investing a man year or more of effort in significantly improving
SystemC performance? If they open source the results they have to identify
and develop a complementary product reliant on the enhanced code to make
sense of the investment. Alternatively they have to figure a way to
license their version of the Open Source code, which would be a legal and
technical minefield given the models are built using standard C++
compilers. The closest comparison I can think of is Forte (previously
CynApps) with ESC. Does anyone know their progress?
I understand the theory of Open Source (enhancements for and by the user
community etc.) and I've wondered if one of the big users might make these
enhancements for their own use, and release the results back to the
community for maintenance but, since the SystemC discussion group contains
comments like "I'm not allowed to share how we did that" I fear commercial
secrecy is inhibiting a true exchange, in many cases to their ultimate
disadvantage. Because there's no such thing as a free lunch, one side
effect of Open Source is users are growing internal tools teams, with the
obvious risk of duplicating each other.
Why did Synopsys introduce SystemC? One possibility is C/C++ simulation
was going to happen anyway and they wanted to keep users buying Design
Compiler and related products, the bigger risk being rapid adoption of
CynApps or C-Level synthesis, though I don't imagine the Open Source
decision was cheered by the Cadence, Verisity or even the Synopsys Vera
marketing organizations!
Possibly by design, innovation in simulation performance is now being
stifled, for example, how can the next Chronologic grow up to challenge
Verilog-XL in this climate? And how many synthesis and other back-end tool
users realize they are cross subsidizing front end tools? And how much of
an incentive do Synopsys have to invest in significantly improving SystemC
performance?
In summary, it's technically possible to take big strides in SystemC
performance, but the distortion of the marketplace is restricting this
essential effort.
- Bernard Deadman
SDV, Inc. Austin, TX
P.S. Please warn your readers to beware of the Synopsys "SystemC Design
& Verification Seminar" -- it's a boring 2 hour GUI demonstration
that teaches you *NOTHING* about using SystemC for verification.
( ESNUG 390 Item 5 ) --------------------------------------------- [03/20/02]
Subject: ( ESNUG 389 #12 ) PrimeTime/PrimeTime-SI Core Dump On Reduced SPEF
> We spent the first half of the Mindy PrimeTime-SI evaluation debugging
> problems caused by the reduced SPEF from Star-RCXT. The runtime using
> this SPEF was very good; just a few hours. However, the timing results
> were sketchy. Some delays due to coupling were over 900 nsec! Further
> investigation revealed that PrimeTime-SI didn't fully support reduced
> SPEF (RSPEF) from Star-RCXT.
>
> - Ryan Hyma
> AMD Austin, TX
From: Khris Kofford <kkofford@amis.com>
Hi, John,
Just a note on ESNUG 389 #12 regarding problems Ryan had with Reduced
SPEF (RSPEF) in PrimeTime-SI.
I've had similar problems reading RSPEF into non-SI PrimeTime. In one
situation, I was working on a .25 um, 1 M gate design last May/June. I was
having some problems with timing convergence at post-layout. In one
testcase I had written RSPEF from Apollo. PrimeTime was coredumping with
the RSPEF! My guess is they both have the same parasitic parser (so
PrimeTime-SI probably also core dumps when reading the RSPEF) and the
general timing engines are the same. The corresponding DSPEF annotated
fine. Synopsys filed a STAR but I haven't heard anything from them since.
I have been using the DSPEF without any problems. The SDF generated from
DSPF and DSPEF correlates very well and DSPEF file sizes have been up to
about 65% smaller.
I guess what I'm saying is that RSPEF is evidently not handled very well
in either Synopsys tool, but they claim it's a supported format.
On a somewhat similar note, I just ran into a situation in PrimeTime 2001.08
when calculating delays using DSPEF with short nets having a resistance
value less than 0.1 ohms. Avanti Star-RCXT extracts short nets using a
shorting resistor w/ a default value of .001 ohms. PrimeTime 2001.08 blows
up when trying to use the .001 ohms during delay calculation. Two things
happen:
(1) When writing SDF in min/max mode, the min cell timing arc is about
the same as the max cell timing arc, which is INCORRECT.
(2) The min SDF value for the same cell arc is inconsistent with that
reported by report_delay_calculation.
For example, the SDF for a buffer driving a short net looks like:
(IOPATH I Z (3.021::3.030) (3.029::3.043))
The corresponding delays reported by report_delay_calculation are:
(-7259372.000000 ::3.030126) (-13308844.000000::3.042605)
Notice those huge negative numbers. Ugly.
The correct delays for this buffer should look something close to:
(IOPATH I Z (1.39::3.030) (1.42::3.043))
I had to write a script to post-process the DSPEF and change the .001 ohm
resistance values to .01 to clean up the delay calcuation in PrimeTime.
I filed a star on this issue (Star 137745).
Another problem I found with PrimeTime 2001.08 is writing SDF in min/max
mode. The min delay is incorrect. This is probably related to (1) above
but it doesn't fall into the short net issue. Here's an example. This is
what I get in min/max mode for a buffer after annotating the DSPEF:
(IOPATH I Z (0.121::0.477) (0.223::0.473))
This is what I get in min mode:
(IOPATH I Z (0.136:0.136:0.136) (0.203:0.203:0.203))
This is what I get in max mode:
(IOPATH I Z (0.477:0.477:0.477) (0.473:0.473:0.473))
Notice the max arcs are the same but the min arcs differ. It *should* be:
(IOPATH I Z (0.136::0.477) (0.203::0.473))
A star has also been filed on this issue (Star 138238).
If you are depending on the SDF for any type of verification, the safest
thing is to write two SDF files rather than a single SDF file containg both
min and max timing. And I wouldn't be too surprised if this same thing were
happening in PrimeTime-SI.
Bottom-line is RSPEF is difficult to work with using any flavor of PrimeTime
(SI or non-SI), SDF is tricky, & DSPF files are 3X larger than DSPEF files.
- Khris Kofford
AMI Semiconductor
( 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
|
|
