>> the Synopsys Legal department just told me they're unsure about
>> covering what happened the day before the Boston SNUG meeting.
>> they said they've never had to deal with something like this before.
>>
>> - vito
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Vito J. Mazzarino, Director vito@synopsys.com
>> Synopsys North American Support Center phone: 650-584-1969
>
>
> Editor's Note: If you want to know what Vito is talking about, click on
> http://www.DeepChip.com and you'll discover the rest of the story! :^)
>
> - John Cooley
> the ESNUG guy
From: Drew Sher <drew@magicknot.com>
Hi John,
I've never had any over-riding urge to email you before on a personal
level, but after reading about your little prank on Vito, if in fact you
caused him to spend a night in jail, I just had to ask what the hell
gave you the impression anyone would consider that acceptable behavior?!
Some cute pictures of Vito feeding the sheep with interesting titles,
that's a prank. Feeding him deep fried sheep nuts, that's a prank.
Setting the man up and putting him in jail is not just warped, childish,
and petty, but just plain mean.
If the police don't charge you with anything, I sure hope either Vito or
Synopsys publicly humiliates you to the extent you deserve (a lot).
- Drew Sher
Magic Knot
( ESNUG 333 Subjects ) ------------------------------------------- [10/99]
Item 1: ( ESNUG 331 #6 ) Start-Up Verplex Tramples Chrysalis & Formality
Item 2: ( ESNUG 330 #1 ) Users Warn That Cheaper Ambit Really Quite Costly
Item 3: ( ESNUG 324 #2 329 #2 ) Simplex Founder Addresses "Eleven Flaws"
Item 4: ( ESNUG 317 #5 330 #7 331 #4 ) Scan Insertion Name Change Issues
Item 5: ( ESNUG 321 #9 ) Maybe This Variable Removes Dead Flip-flops?
Item 6: Need Suggestions For Verilog-To-CDL Translators For Dracula LVS
Item 7: ( ESNUG 330 #8 331 #7 ) Have Cadence Pearl & DC Play Nice Together
The complete, searchable ESNUG Archive Site is at <http://www.DeepChip.com>
( ESNUG 333 Item 1 ) --------------------------------------------- [10/99]
Subject: ( ESNUG 331 #6 ) Start-Up Verplex Tramples Chrysalis & Formality
> I saw this posting on ESNUG about problems with Chrysalis. Have you
> looked at Verplex? <http://www.verplex.com> Using it, we've found it
> runs at least 10x faster and handles greater than 300K gate comparisons.
> The key to getting equivalency checks working are:
>
> 1. pre-mapping all gate-vs-RTL state points (flip-flops) before
> comparison
> 2. matching RTL hierarchy with gate hierarchy
> 3. correctly modelling your flip-flops (gate often sees them as two
> latches)
>
> We've eliminated gate-simulation with Verplex. Good luck with your
> million gate designs and please keep me anonymous.
>
> - [ To Have And Have Not ]
From: [ Big Brother Is Watching ]
Hi, John,
Anonymous, please, big brother is watching.
In regards to the discussion going on regarding equivalency checking, I have
some direct inputs. I have been evaluating EC tools for 4-5 years for 2
different companies.
I started out looking at Chrysalis on 50-60k gate ASICs and immediately
found a synopsys introduced logic bug. That really turned me on (especially
since gate level verification usually fell in my lap). I always hated the
fact that Chrysalis choked on blocks greater than about 10k for RTL2GATE
compares. It has always seemed that they are behind the current block
synthesis curves during each subsequent release of their tool. I also
thought that their UI was "lame". It had too many options, holes, and
commands for a tool that was supposed to save so much time. Also, I found
that when I wrote a script to do say RTL2GATEs on 1 block, it was useless
for another block or for GATE2GATE runs on the same block.
I then looked at Formality. It seemed to have a pretty nice frontend (but I
hate GUIs... give me an xterm and emacs and I can design the world). The
local support center basically had no expertise on the tool or even EC
techniques for that matter, so they were of no help. I also had a block
that I wanted to do RTL2GATEs on to compare to Chrysalis. The block was in
the 300k range but the gates were flattened. Chrysalis bombed. Formality
bombed. I gave the RTL to the local support center and after 7 months still
no word.
I thought to myself that it must be an impossible task. I would have to
break the problem up. So I fast synthesized the RTL with hierarchy, ran a
hierarchical EC with Chrysalis, and then ran a GATE2GATE with Chrysalis
(A=B; B=C; so A=C) and got that to finish (with the exception of 1 block)
after alot of work. (note this is a 300k block out of a 6.5M ASIC). My
sweet dreams of easy verification of this chip suddenly turned to
nightmares ...
Then, I was introduced to Verplex. Within 2 hours of getting the tool
installed (and no design center support), I had an RTL to Flat Gates
comparison completed on the 300k block. Of over 6k key points in the block,
I had almost all equivalent with the exception of 16 aborted points. I then
talked to the AEs for Verplex, and had a new release in no time that took
care of the abort points (interesting to note that the aborted points were
logic cones in the module that chrysalis could never do!). All of this with
only 10-15 lines of scripting (definitely not like the Chrysalis tool!). I
then tried the same block targeted to another vendor...BANG! a synopsys bug
found with critical state points dropped. I have found that Verplex does a
great job on RTL2FLATGATES and RTL2HIERGATES on blocks <350k. Either 10x
performance over the competitors or it completes and they don't. Also, the
memory usage seems to be about 1/2 to 2/3 of the competitors. For post
layout/test-insertion/ECO, I can do my 6.5M gate design in less than 1.5
hours.
I also hacked dc_perl (you remember this don't you) to form lec_perl. It is
beautiful for parsing and analyzing a design in Verplex. I can take a block
with test inserted, find the key control signals and force them to
functional mode with 1 command now rather than searching for them. It
really helps when I don't know squat about the block I am verifying. As for
the flop->Master/Slave issue, Verplex can identify and fold the MS latches
back into flops (no cruddy library prep step like Chrysalis). My vendor's
SEs (a large.. did I say copper interconnect.. ASIC vendor) couldn't believe
the results I was getting for GATE2GATE versus their runs with Chrysalis.
Their runs take 24 hours, mine takes 1.5 hours.
On the downside, their tool is new, so there are a few "issues" once in a
while. But, for the results I am getting, I don't mind helping them debug
and enhance their tool! They are suprisingly fast at turnaround time to for
new releases to fix issues. (Guess that's a small hungry company for you.)
- [ Big Brother Is Watching ]
[ Editor's Note: As with *ALL* anon letters that give strong opinions, I do
background checks to ensure they are legitimate. I know who wrote this.
He's a chip designer. He's posted here before. It's legit. - John ]
( ESNUG 333 Item 2 ) --------------------------------------------- [10/99]
Subject: ( ESNUG 330 #1 ) Users Warn That Cheaper Ambit Really Quite Costly
> We are a small company just starting an ASIC design group. Most of us
> have lots of experience in using Synopsys (I have used it since the early
> 90's). We had Cadence in a couple of days ago and I must say that they
> caught our ear with Ambit. It is hard for us to ignore the price -- but
> I am really scared about leaving Synopsys. Can you give us some advice
> please? An EDA mistake for this company could result in a disaster -- and
> I am scared.
>
> - Paul Borsetti, Lead ASIC Design Engineer
> Enikia Corporation Piscataway, NJ
From: Kelly Fromm <kellyf@packetengines.com>
John,
We went through the same decision pains after many successful ASICs using
Synopsys. I too have been using Synopsys since the late 1980's and version
3.4b, so it is definitely my comfort zone tool.
Our current designs are close to 3-million gates and had we stuck with
Synopsys, we would've been dead in the water. Your design size will have
some influence on your decision, but their are other considerations. (1)
does your ASIC vendor support Ambit, i.e. is there an Ambit library of
cells? (2) what about ATPG? You need a Test-Compiler replacement if you
are all Synopsys. (3) insure that your output format is available (edif,
verilog, vhdl...)
Other than that, we have had tremendous AE support from Cadence on use of
Ambit. The tool works, the logic it builds is functional, the tool runs
incredibly fast, and the scripting is very workable. Scan insertion works
fine, SDF backannotation is a bit slower, but it works, timing analysis is
quick. I still use Design Analyzer to look at logic, but others here tell
me the graphical tool Ambit has works just fine, and has some path tracing
features that are very nice. On the whole, the tool is becoming quite
mature and I expect that we will stick with it. We still hedge a bit by
keeping Synopsys available as a fallback for really tough timing problems.
I haven't had to go back to it yet, however, since Ambit has no problem with
my tough logic at 125Mhz. Synopsys couldn't build an 18-bit subtract in
line with an 18x18 multiply in one clock. At least not without an
additional group of DesignWare. Ambit handled it easily. Hope this helps
with your decision making.
- Kelly Fromm, Design Engineer
Packet Engines
---- ---- ---- ---- ---- ---- ----
From: "Joe Kryzak" <jkryz@rocketchips.com>
Hi John,
Last year, because we really need to save money as a start-up, we intially
decided to use Ambit.
Boy, was that a mistake.
Ambit was very aggressive with their price. But without having used the
tool, it was my opinion that we should test drive Ambit, and see what it
could do. I told Ambit that I wanted to have an evaluation copy, and they
were hesitant (and resistive) at first, but finally they gave in and issued
a license.
I created a small state machine that mimicked a typical design here.
I made a Moore machine, with 16 states, created next and present state
logic, outputs, etc. I ran it through Ambit and the output area was larger.
Inspecting the schematics generated by Ambit and DC was the first mistake
for Ambit. Ambit's output was a mess. Nothing was optimized, amature raw
sum-of-products 8-input AND gates stuff all over the place. The DC output
was crisp, clean, and reduced. I added another state machine, and some
counters, and some typical digital designs. Once again, the Ambit tool had
a larger area. I put the screens up next to each other and showed our vice
president the difference, and it was unmistakable. One black mark against
Ambit.
The second black mark on Ambit, and in my opinion the one that killed it,
was the support. Their support staff was bi-polar; some guys were good and
a lot were quite bad. It was random who I'd get on each call.
For example, we ran into the obvious situation that our cell provider didn't
have the Ambit libs. Ambit provided them with a their version of a library
compiler and after 4 months I got Ambit libraries. This wasn't 4 months
waiting; it was 4 months of many emails back and forth. (This is how I
discovered that the Ambit support staff, one the sale is done, is not as
conscientious as Synopsys.) It sucked trying to clean up Ambit's mistakes.
An example problem: one of the Ambit symlibs ( symlib was the name of the
symbol lib) I was sent contained bogus info -- it was tarred incorrectly.
But yet, they insisted that it worked on their side. When I found what the
error actually was (note *I* had to find the error (which took 4 working
days!)) they finally had to admit that the problem was theirs, and finally
I got the corrected lib. Another problem was that the library didn't read
in correctly. I had to download a new version of the Ambit tool to get it
to work. Then there's my horror story of having to debug Ambit vs. Ambit.
The Ambit support staff and I both using the same version, same netlist,
same script -- we got very different results. I gave them a 2,000 gate FSM.
The Ambit support guy said, "I only see 17 inverters in your design." I
spent two weeks on that issue and then had to just drop it because I happen
to design chips for a living, not debug Ambit for a living.
These were slap-in-your face problems, and it took 3.5 months. What if I
discovered a subtle problem, how long would it take? This was my breaking
point. I decided against Ambit, because of the massive time loss in
dealing with any problem that came up.
However, some things I liked about Ambit was its interface. I believe it's
better than Synopsys. Ambit's documentation is also less verbose, which I
prefer. I'm hoping Ambit will force Synopsys to eventually lower their
prices. ( And hopefully, my Design Analyzer licence will still work after
that comment! :^) )
If there are any "die hard" Ambit fans out there, I'm sorry to disappoint
you. I call them like I see them, and I gave Ambit too much of my time.
- Joe Kryzak, Project Engineer
RocketChips, Inc. Minneapolis, MN
---- ---- ---- ---- ---- ---- ----
From: "Gregg Lahti" <gregg.d.lahti@intel.com>
Hi, John,
It scares me to think that cost-conscious CAD managers with almost no
accountability to a project schedule can affect my job so much. When you
buy an EDA tool, it's not just the purchase of the tool that makes it work
-- it's the bug fixes, AE support, and new revisions that mean the most.
In my experience this is where the rubber meets the road when you need to
get your project done and the tool is blowing chunks. In comparison of
Synopsys to Ambit, I'd much rather pay more for a tool that I KNOW works
95% of the time and comes with decent support. (Granted, DC is expensive
and competition for Synposys hopefully will keep the price down and out of
the anti-trust/monopoly courts).
I've also had great success on the last two projects I worked on when we
decided to use new Synopsys tools (BC, MC, PrimeTime). Our local AE support
was above anything I've seen stumble out of Cadence. Sometimes the tools
broke (doesn't all EDA?), but the fixes/work-arounds were quick which didn't
impact schedule.
Price isn't everything, or we'd all be driving Yugos.
- Gregg Lahti
Intel Corp Chandler, AZ
---- ---- ---- ---- ---- ---- ----
From: "Mangesh Pimpalkhare" <mpimpalk@wharton.upenn.edu>
Hi, John,
While at NeoMagic, we evaluated Synopsys and Ambit head-to-head in a large
design, and finally chose Synopsys. I worked as a design manager and
our group was faced with the challenge of planning for our next generation
laptop graphics chip that was going to be much larger (about 2.5x) than our
previous chip. We wanted a reliable synthesis solution, which could give
us the best quality of results. We wanted to compare Synopsys' quality
of results with Ambit's, making sure it was as close to an "apple-to-apple"
comparison as possible.
People often compare synthesis results in a quick and dirty fashion, missing
details like wire load models, synthesis scripting methodologies (top-down
vs. bottom-up, or a mixture of the two), total negative slack vs. worst path
slack, design rule violations, etc. We also used this opportunity to
overhaul our somewhat outdated synthesis methodology. This helped us
realize significant area savings with better timing.
Choosing Ambit would just have introduced significant risk with no
commensurate benefits.
I would also like to point out that switching EDA tools, especially unproven
tools, has significant risks associated a with an impact on the layout
methodology, timing convergence, library development, QA, and training.
Each of these could cascade and eventually impact project schedule and
time-to-market. Living with known bugs is one thing, getting surprised with
the unknown is something else. Synopsys certainly isn't without bugs, but
we had a good understanding of how to get around them, having put several
designs that were synthesized using Synopsys into volume production.
The bottom line is, if Ambit would have been measurably superior in timing
and/or area relative to Synopsys, we would have weighed those benefits
against the risks of going with an unproven (compared to Synopsys, Ambit
has negligible amount of silicon in volume production) tool. In the end,
we got better results with Synopsys, so sticking with Synopsys was a real
no-brainer.
My final warning to anyone doing synthesis comparisons: the devil is in the
details! Make sure you are comparing apples with apples!
- Mangesh Pimpalkhare, MBA Candidate
The Wharton School of Management University of Pennsylvania
---- ---- ---- ---- ---- ---- ----
From: "Gene K. Chui" <gchui@cisco.com>
John,
We evaluated both Ambit and DC and we decided to go with DC. From the
technical point of view, DC had about a %15-20 faster runtime with both
tools meeting timing. We were also concerned about the risks of using a
new tool that did not have many tape-outs, while DC has done thousands of
tape-outs. The Synopsys support was also much better than Cadence's
post-sales support and we liked their future roadmap of integrating
synthesis with the physical tools.
While Ambit did have some nice features, it was clear that DC was better
technically with far less risk then Ambit.
- Gene Chui
Cisco Systems San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: [ Microprocessor Slave ]
John:
Please keep my absolutely anonymous as [ Microprocessor Slave ]. This is
in reference to Paul Borsetti's question in ESNUG 330 #1.
We looked at Synopsys & Ambit sometime back, and decided to pick Synopsys.
We already had an existing flow with Synopsys, and wanted to look at Ambit
because of the promise of significantly better results.
The initial Ambit results looked good, and were better than our previous
Synopsys results. But once we got in touch with the Synopsys AE and
switched to a more recent version (98) of Synopsys, the Quality of
Results were better than Ambit's both in terms of runtime and area.
However the performance of the tool wasn't the only aspect we considered.
Methodology issues, training, reliability, and risk are also important
things to be considered. For example, we have working links from synthesis
to layout and backend tools, as well as ECO flows etc. There are standard
interfaces, and we also have lots of custom scripts. The current Synopsys
flow we have is proven and tested ... moving to another tool would
potentially be a huge time-sink in engineering time with uncertain results.
We concluded that unless Ambit had significant gains, it would not be worth
the risk since design cycles are very tight.
While as a solution Synopsys was better, there was one aspect to Ambit that
was somewhat interesting to us then, which was that Ambit was a startup. We
thought that they might be more responsive to our requests, and turnaround
custom changes faster. When Cadence acquired them, that stopped being a
plus for them !
- [ Microprocessor Slave ]
---- ---- ---- ---- ---- ---- ----
From: Mike Davoudi <mdavoudi@picoturbo.com>
John,
We develop both high speed (300 MHz) and low power (less than 0.4mW/MHz)
synthesizable micorprocessors. Synopsys synthesis is critical during both
pre-layout and post-layout design. The convenience of an all-in-one
synthesis tool allows us to dedicate more time on the design-implementation
phase and less on the back-end flow. Once our RTL is complete the rest is
push-button. DC allows a simple script to run over night and prepares a
netlist and information about the netlist for the designer the next morning.
Synopsys has the right idea of creating an all-in-one design tool. It
eliminates complications and saves us time.
- Mike Davoudi, ASIC Design Engineer
PicoTurbo, Inc. Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: [ Echoing From Within Texas Instruments ]
John,
I would like to submit this article for ESNUG. I would request to be
anonymous on this posting. Thanks.
Texas Instruments has gone through two major evaluations of the DC and AMBIT
synthesis tools, in the last one year or so. In both the evals, the DC
results are more promising. Looking at the benchmark results, I've found
improvements in both run-time as well as the quality of the synthesized
netlist (area reduction and faster circuits) for DC.
Additionally, a common integrated tool set for critical steps like datapath
synthesis (Module Compiler), static timing analysis (PrimeTime), timing
closure (links-to-layout), and equivalence checking (Formality) helped our
designers a lot.
- [ Echoing From Within Texas Instruments ]
---- ---- ---- ---- ---- ---- ----
From: sriram@neomagic.com (Sriram Ramamurthy)
Hi, John,
I'm a design manager in NeoMagic, and our company had looked at synthesis
alternatives seriously sometime back and decided to stay with Synopsys.
The point tool comparison between DC and Ambit should be just one aspect to
be considered. As a point tool, DC did give us better Area and better
Timing for the same designs. (For someone doing a high volume part, these
can translate to significant savings that directly affect the bottomline.)
There are also other more important factors to be considered.
Flow issues are very important, and we have working flows with Synopsys with
our back-end tools, verification tools etc. We know that if we need to add
other tools to the flow, they will support Synopsys tools, and that's very
important. It's also a lot easier to find engineers conversant with
Synopsys tools, otherwise we run into training issues with any new tool.
We have enough risk in our projects. It helps to know that the synthesis
tool has been tested extensively by others over the years, and is going to
be tested by thousands of others currently.
This minimizes the chance of us finding bugs ourselves the hard way.
One other suggestion: if you are already a Synopsys user, consider giving
your methodology and scripts a "tune-up" from time to time. We did that
with the Synopsys AE's help, and realized significant improvements in the
performance and Quality of Results.
- Sriram Ramamurthy
NeoMagic Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: [ Intel Inside ]
John,
I wanted to give you some feedback on the abmit discussions. Please keep
me anonymous.
When CAD mgrs pick point tools based mainly on cost, the results are
sometimes a hodge-podge of cheap point tools strung together with Perl
scripts to make a design flow. This is not always the best way to get
a best-in-class design methodology.
Ambit may have a decent synthesis tool that is worth looking at, and maybe
SYNOPSYS will be forced to discount DC a little more. But just having a
good cheap synthesis tool does not make a good design flow.
Synthesis is not a simple part of design, and knowledge of DC scripting will
hinder Ambit's acceptance -- but cutting the price won't really help them.
Our engineering costs far outweight EDA tool costs.
You need the other tools in the flow to work together and you need customer
support. I've found that Synopsys gives first-class customer support to us
at Intel. Their AE's are first rate & they are responsive to bugs we find.
Also, Synopsys has a very complete set of tools from behavioral/datapath
synthesis through static timing and layout ECO flows that has a proven track
record of working well with DC. Ambit is new stuff with absolutely no
track record of even passably working with any these other EDA tools. Saving
$50 K up front doesn't make up for the hundreds of thousands of dollars in
engineering costs and delays, I'd pay trying to make Ambit work.
- [ Intel Inside ]
---- ---- ---- ---- ---- ---- ----
To: kegger@morphics.com <kegger@morphics.com>
John,
I am a ASIC design manager at a start-up. We are also in the process of
building an ASIC team for implementation of our early products. Like most
other start-ups, finances are extremely important. With EDA tools consuming
a significant portion of our overall budget, we must make our decisions
wisely because there is no second chance for us. Because of this, I you
need to review the fundamentals when making a decision on key implementation
tools such as synthesis. I tend to go straight to the bottom line:
BOTTOM LINE: Get a quality product out the door in a timely fashion.
This means:
A. Proven tools with proven flows
B. Available IP (both synthesizable and target library)
C. Available expertise (i.e. people who know how to use it)
D. Proven foundry libraries
While Synopsys isn't exactly cheap, the loss of revenue associated with a
slipped schedule is far more important. It can sometime even be fatal.
Paying more for tools which will *definitely* deliver and are widely
supported (both by people you need to hire as well as with vendors whom
you need to work) is not a bad decision in my book.
Having said this, however, I like to encourage competition. Thus, if
you are not in the critical path to your company's overall success, then
evaluating any new technology is a reasonable thing to do.
We don't have that luxary. Our designs have to work the first time around.
Best of luck on your decision,
- Keith Rieken, VLSI Manager
Morphics Technology Inc. Campbell, CA
( ESNUG 333 Item 3 ) --------------------------------------------- [10/99]
Subject: ( ESNUG 324 #2 329 #2 ) Simplex Founder Addresses "Eleven Flaws"
> I saw there were couple of references to Simplex's Power analysis tools
> 'Thunder & Lightning' in your DAC'99 Trip Report. I have been working
> with them for around an year now and I couldn't resist from commenting.
>
> ... [ the 11 Simplex Fundamental Flaws snipped for brevity ] ...
>
> You will need lot of hand-holding from Simplex's support to work with
> their 'Thunder & Lightning' power tools.
>
> - Anil Kumar
> Vitesse Semiconductor Corp. Camarillo, CA
From: "David Overhauser" <ovee@simplex.com>
Hi, John,
My interpretation of the nature of Anil's 11 concerns suggest that ver 1.2.3
was his frame of reference. My responses below address where our product is
currently. Here's a point-by-point reply to Anil's 11 concerns:
> 1) The Simplex flow has too many commands/scripts.
Agreed. This has been improved significantly from ver 1.2.3 in ver 3.0.0.
Given the flexibility needed to accomodate most major design styles and
output formats, some customization will always be needed. But, our goal
is to provide users with selectable default environments where it is
possible to significantly reduce this amount of effort. Our latest
product, Fire & Ice QX 3.0.0, has a push-button flow with a single command
line, compact command file, and no scripts.
> 2) The Simplex scripts/commands are hard to understand.
Agreed. This has been simplified and the documentation improved with
ver 2.0.0. Our past focus has been on flexibility, capacity, accuracy,
and speed. This resulted in hard to use tools. With ver 2.0.0 we
significantly simplified our command language by 2-5X while increasing its
robustness. Ver 3.0.0's gate-level option takes an even greater step
forward.
> 3 & 4) Simplex doesn't do power consumption analysis.
This is true. Our focus today is in power distribution analysis and not
power consumption analysis; we support open standards and have worked with
other tools vendors to support customer's desire to integrate our tools.
> 5) Simplex flows requires a lot of RAM/CPU/disk.
Agreed. We started in a market of high-end users who were unwilling to
give up performance, cycle times, and accuracy for RAM/CPU and disk
space. But, we've improved: ver 2.0.1 provided a 5-10X reduction in
CPU time required for extraction. ver 3.0.0 gate-level option achieves
an additional 10-15X reduction in CPU time as well as elimination of
intermediate disk files and an order of magnitude reduction in RAM usage.
> 6) Run times are long.
We agree, run times are too long! Although run times have been reduced
by 5X-10X from ver 1.2.3. to ver 2.0.1 (which normally meets or beats the
competition), clearly something better is needed. ver 3.0.0's gate-level
option incorporates a revolutionary technology to address the need
for faster cycle times, larger capacity and better accuracy. Our customers
have seen additional 10-15X performance improvement, even over 2.0.1, with
ver 3.0.0
> 7) Simplex doesn't support multi-voltage design.
Simplex does support multi-voltage design. It is common to have a power
supply for internal logic using a different voltage than I/O pads. Our
tools make no assumptions as to the number of power supplies on a chip or
their voltage. Our users often have chips with 3 or more power supplies
at 3 voltage levels.
> 8) Simplex does not have functionality to support multi-clock designs.
We support multi-clock designs and have since ClockStorm was introduced
in 1998. We analyze each clock separately for delay and skew. We do not
support analyses between different clock domains today, but we consider
that in the realm of where customer input can help advance products for
the future.
> 9) Ipeak analysis is not a real peak current.
We have many power grid analysis flows available to permit tradeoffs in
speed and precision of the analysis. Generally the method used is a
balance of the users need for quick information, the availability of
quality information (on the design), the design type and the specific
requirements for the design-low power, speed, reliability etc. Our Ipeak
analysis has been very successful in finding power distribution problems
independent of the precise accuracy of the IR drop estimate. Other flows
in VoltageStorm permit more precise measurement of IR drops in designs.
> 10) Thunder does not support analog circuitry.
Ver 3.0.0 includes new functionality to provide static PGS capabilities for
designs that include small analog blocks.
> 11) The Simplex flow needs a better user interface.
Agreed. We recognize that this is an area where we need to focus
improvement and we are working hard to do that with customer input.
John, we recognized that our initial focus on technical capability resulted
in clumsy usability, and we have been working to address these issues in the
past two years. Our latest product, gate-level Fire & Ice QX, squarely
addresses this. Gate-level Fire & Ice QX represents a significant milestone
in speed and usability. The gate-level option is a push button flow -- a
single command line is used, and there are no large intermediate databases.
In addition, its performance is between 10X and 15X improvement over even our
2.0.0 release in speed -- on a single CPU -- and it has the same accuracy
our customers expect.
- David Overhauser, Co-Founder
Simplex Solutions, Inc. Sunnyvale, CA
( ESNUG 333 Item 4 ) --------------------------------------------- [10/99]
Subject: ( ESNUG 317 #5 330 #7 331 #4 ) Scan Insertion Name Change Issues
> I just did a compare between the two designs... (in my case let's use
> Xcounter as the name). Xcounter scan inserts with no problem. When I go
> up one level and try to connect the scan chains up, Xcounter is replicated
> and called Xcounter_test_1. Xcounter contains the scan flops, BUT the
> design Xcounter_test_1 is a PRE-SCAN version and is NOW whats being linked
> to in the design.
>
> I have NO idea why it does this other than something to do with the scan
> violations concerning reset signals gated with internal flop outputs.
>
> - Gzim Derti
> Intrinsix Corp. Rochester, NY
From: [ A Synopsys DC-XP CAE ]
Hi, John,
Hi! I believe that I understand what's going on here. Essentially Gzim is
correct when he says that his observation of seeing a block with no scan
cells called xcounter_test_1 is "something to do with the resets".
You need to realize three things:
1) If you do scan insertion on a hierarchical design, then whenever
insert_scan modifies sub blocks its gives each new design a new
name: say sub_block goes to sub_block_test_1. This is so we can
keep your design properly linked.
2) However, insert_scan does not change the name of the current_design;
since it doesn't need to. So, if you do scan insertion on a single
module xcounter, with no sub-blocks, then the post-scan design will
still be called xcounter.
3) If insert_scan finds a sub-block that it has already scan replaced
(and routed?) but which has a serious test design rule violation then
it will "unscan" the scan cells.
By serious test design rule violation I mean something like an uncontrolled
asynchronous reset which means that insert_scan would create a non-
functioning scan chain if it included the sub-chain on a scan chain. If the
asynchronous reset is changing during the scan shift operation then some of
the the scan cells will be constantly reset -- not very useful for scanning
data in and out!
You may ask why the asynchronous reset wasn't flagged as an issue when you
first inserted scan. Well, if the asynchronous reset comes from a design
port then DC-XP can hold it at a safe value during a scan shift. But if the
reset is driven from a scan cell in another block then you get a violation.
By "unscan" I mean that insert_scan maps the scan cell back to a non-scan
flip-flop.
If we can't put the scan cells on a scan chain then there is no point in
wasting area and keeping them as scan cells.
Apply these observations to Gzim's case and we'll see what happend. In
this description I'll assume that it was just an asynchronous reset that
causes the problems he saw.
A) He ran insert_scan on the current_design of xcounter. There is an
asynchronous reset signal driven from a port which check-test reports
as an asynchronous signal but allows scan insertion to proceed.
insert_scan scan replaces and routes the design without any problems.
Since xcounter is the top level of the design insert_scan doesn't
change its name. So xcounter is still xcounter.
B) He changed the current_design to, say "top". Within top the
asynchronous reset on xcounter is driven from another block and so
check_test reports severe problems, Gzim ran insert_scan which
unscanned the block xcounter. However, since this unscanned block
is a new design created by insert_scan insert_scan gives it a new
name xcounter_test_1.
There you are! Very logical, but if you don't follow through the steps
counter intuitive since the xcounter_test_1 contains no test logic.
- [ A Synopsys DC-XP CAE ]
( ESNUG 333 Item 5 ) --------------------------------------------- [10/99]
Subject: ( ESNUG 321 #9 ) Maybe This Variable Removes Dead Flip-flops?
> Design Compiler never removes storage elements. I've tried connecting
> set, reset, clock, or data to force FFs or latches to constant values,
> and DC always kept them in the design.
>
> - William Liao
> MMC Networks
From: dbudell@us.ibm.com ( Della J. Budell )
John,
Way back in ESNUG 321 ( OK, so I'm a little behind in reading ESNUGs ),
there was a discussion about Synopsys not removing unloaded latches. Just
recently I found out there is a variable called
compile_delete_unloaded_sequential_cells
which in our setup seems to default to "true." Now, this variable may not
apply in the case being discussed, but I thought I'd throw it out there.
- Della J. Budell
IBM Corp. Essex Junction, VT
( ESNUG 333 Item 6 ) --------------------------------------------- [10/99]
From: Andrew Frazer <Andy.Frazer@idt.com>
Subject: Need Suggestions For Verilog-To-CDL Translators For Dracula LVS
Hi, John,
This question pertains to users who are doing their own synthesis and use
Cadence Dracula for post-layout LVS...
My company has its own fab and, unlike an ASIC customer, after synthesizing
a chip with Design Compiler and laying it out with our place-and-route tool,
we use Dracula to run LVS. Now, Design Compiler writes out Verilog (not
CDL/spice). LVS usually requires a CDL/Spice netlist (CDL is 99% identical
to Spice):
Design Compiler -> (Verilog netlist) -> Translator -> (CDL) -> Dracula
For the past few years we've been using a Verilog2CDL/Spice translator from
a vendor who is not fully committed to supporting and upgrading it. Our
current solution has lots of problems and we're more than ready to find a
better solution. Although many of our new products will use Avanti's
Hercules instead of Dracula (Hercules readily accepts Verilog input), most
of our projects will still use Dracula this year.
Can anyone tell me either (1) how they get Design Compiler output into
CDL/Spice, or (2) a different solution to this problem? Are there other
Verilog2CDL/Spice translators available on the market?
- Andy Frazer
Integrated Device Technology Santa Clara, CA
( ESNUG 333 Item 7 ) --------------------------------------------- [10/99]
Subject: ( ESNUG 330 #8 331 #7 ) Have Cadence Pearl & DC Play Nice Together
> We are now in the process of developing a layout flow that is using Timing
> Driven Q-place placement software from Cadence. Being timing-driven, the
> software reads constraint files produced by, you guessed it -- Synopsys.
> The tool that reads and converts the constraint file is: Pearl (Cadence
> static timing analysis tool). We are receiving Synopsys constraint files
> from various Synopsys versions. Almost each time we use Pearl there are
> statements that are not recognised by the tool, and causes it to produce
> erroneous output. ...
>
> - Eran Rotem
> Chip Express (Israel) Ltd. Haifa, Israel
From: "Ed Martinage" <ejm@cadence.com>
Dear John et al:
I'd like to respond "briefly" to some of the issues raised in regard to
providing/translating Synopsys timing constraints into the Cadence
timing-driven design flow.
o Path constraints that utilize the Design Compiler -through construct
As mentioned by your readers, -through is not yet supported in the
timing-driven flow. Cadence is working to provide compatible support
in the flow for this functionality in an upcoming release.
As far as we know, the semantics of -through are only a compatibility
issue for pre-1998.02 versions of PrimeTime. All versions of Design
Compiler and post-1998.02 versions of PrimeTime all interpret:
-through {a b c} -through {x y z}
to be a path
through "any of {a b c}" and "any of {x y z}"
We do not currently see a need to have compatibility switches to support
pre 1998.02 PrimeTime.
GCF 1.3 is the current constraint version standard for the released flow.
This version of the standard does not provide the required syntax to
support a constraint similar to the one above. When the timing-driven
design flow is rev'ed to support -through pins, GCF 1.4 will be deployed
with a new syntax:
(PATHS
(THRU_ALL
(THRU_ANY a b c)
(THRU_ANY x y z)
)
)
Today, for designs with large amounts of -through pin constraints, Cadence
advocates driving our flow with SDF path constraints ( also a suggestion
by one of your readers).
o Lots of warnings from the translator
The goal of the translator is to provide a GCF construct for a specific
Design Compiler constraint that maintains the exact interpretation of the
original constraint. Warnings are issued if the _exact_ interpretation
cannot be achieved. In practice, many "problem" constraints are due to:
- A hierarchical port reference could not be transformed into a leaf
cell reference(s) that maintained the same semantics as the original
constraint (flat references are a requirement in DEF-based P&R
flows). Upcoming support of -through pins should help remedy the
current corner cases.
- Constraints that are "illegal" and end up Design Compiler's ignored
list must also be ignored by the translator. It just makes a bigger
fuss about it.
As you can imagine, making all these determinations is not a simple
problem and requires a "smart" translator (i.e. Pearl with the "a").
o "I've got my GCF file, but I'm still getting lots of warnings ..."
The Cadence flow automatically runs the equivalent of the Synopsys
check_timing command to alert the user to parts of the design that are
not adequately constrained. In practice, this has been due in large part
to insufficient clocking information in the constraint file.
The handoff of a "clean" constraint file is critical to the success of a
timing-driven backend flow. Use the following to examine the ignored
constraints list and the (timing) unconstrained areas of the design:
Design Compiler: report_timing_requirements -ignored
PrimeTime: report_exceptions -ignored
PrimeTime/Design Compiler: check_timing
There still may be some differences between what Pearl sees vs the Synopsys
tools, but doing some up-front sanity checking on the constraints with any
Static Timing Analysis tool can be a big win.
We are committed to providing a smooth path for Design Compiler constraints
into the Cadence timing-driven flow.
- Ed Martinage
DSM Timing Engineering Group
Cadence Design Systems San Jose, CA
|
|
