> Hi John,
>
> Does it cost anything to add Atrenta to the DeepChip EDA Jump Zone?
>
> - Philip George
> Atrenta, Inc.
Editor's Note: It costs nothing to put an EDA company link up on the
DeepChip Jump Zone page. The Jump Zone is meant to connect to all
known EDA vendors. Now if you're talking about a sponsored link or a
banner ad, contact David Blaza, dblaza@cmp.com or phone (415) 947-6929.
EE Times controls all the advertizing that goes up on DeepChip.
- John Cooley
the ESNUG guy
P.S. I'm looking forward to seeing some of ya'll at DAC next week! I'll
be getting into New Orleans early to see what adventures a chubby,
single white guy can get into on Bourbon St. on a Saturday night. :)
( ESNUG 394 Subjects ) ------------------------------------------- [05/29/02]
Item 1: ( SNUG 02 #15 ) Texas Instruments (Not TI ASIC) Invested In Magma
Item 2: The Kluwer Top Ten Best Selling Books At HDLcon'02 And SNUG'02
Item 3: ( SNUG 02 #15 ) Goering Sees 30 Monterey Tape-outs; Cooley Sees 3
Item 4: ( SNUG 02 #10 ) Two Evals Of Verplex Tuxedo vs. Synopsys Formality
Item 5: ( SNUG 02 #14 ) PrimeTime-SI, Celestry Nautilus-SI, Cadence SE-SI
Item 6: ( SNUG 02 #12 ) Synopsys Says Behavioral Compiler Is Alive & Well
Item 7: ( SNUG 02 #10 ) Three EDA Users Review Mentor's FormalPro EC Tool
Item 8: The Three Best User Papers of SNUG'02 As Voted By Attendee Ballot
Item 9: ( ESNUG 393 #12 ) How To Handle Hard & Soft Macros In Cadence PKS
Item 10: ( SNUG 02 #8 ) Hey! The Synopsys Ketchum Tool Is Not Dead Either!
Item 11: ( SNUG 02 #11 ) Makefiles, Automatic Chip Synthesis (ACS), and DC
Item 12: ( ESNUG 389 #12 ) Silicon Metrics 'Path' PrimeTime/SPICE Analysis
Item 13: ( SNUG 02 #7 ) It's Obvious SystemC Failed; Superlog Is The Future
Item 14: ( SNUG 02 #11 ) Three Customers Chime In On Incentia RTL Synthesis
Item 15: ( SNUG 02 #6 ) User Says Dataquest Vera Sales Numbers Are Inflated
Item 16: ( SNUG 02 #17 ) User Asks "Am I The Only One Left Using Arcadia?"
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 394 Item 1 ) --------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #15 ) Texas Instruments (Not TI ASIC) Invested In Magma
> Magma made the 'over 100 tape-outs' claim at the big press event they had
> 2 weeks ago. I called them on it and they said 50 of them were from TI.
> That kind of surprized me because I know that at least TI Dallas
> Broadband, TI Phoenix MSP, TI Houston DSP, TI India, TI France, and TI
> Japan Wireless are firm PhysOpt users -- not Magma users. It turns out
> that the only group I could find that's using Magma was TI ASIC.
>
> This complicated things because TI ASIC is an early Magma investor. It
> means they're under internal pressure to show that the investment in Magma
> was wise. That 50 could be real or political...
From: Milan Lazich <milan.lazich@Magma-DA.COM>
John,
In your SNUG Trip Report you used some incorrect facts to reach an erroneous
conclusion that impugns our tape-out number and a customer. Writing what
you did leaves a wrong impression with your readers. "TI ASIC" never made
an investment in Magma -- Texas Instruments did. So "TI ASIC" had no
greater incentive to use Magma than any other group within TI. And I
imagine NO group within TI could be influenced to use products from an EDA
vendor for any reason other than it helped them get their jobs done.
Can we please get something in your next posting to correct this?
As you well know, many companies make strategic investments in early-stage
companies such as Magma was, typically as a mechanism to gain insight into
the company. My understanding is that Sun made such an investment in
Synopsys at one time. It's not an uncommon practice.
Ironically, it's likely that much of the FUD being spread at that time via
comments posted to "DeepChip" and "ESNUG" contributed to the early interest
in investing in Magma -- so in an indirect way you may have assisted with
this, and for that we should probably thank you.
- Milan Lazich
Corporate Marketing
Magma Design Automation
( ESNUG 394 Item 2 ) --------------------------------------------- [05/29/02]
From: Carl Harris <Carl.Harris@wkap.com>
Subject: The Kluwer Top Ten Best Selling Books At HDLcon'02 And SNUG'02
Hi, John,
I thought your readers might be interested in the best selling books at the
recent HDLcon and SNUG gatherings:
HDLcon'02 Best Sellers
1. Verilog Quickstart, 3rd Ed. - Lee
2. The Verilog PLI Handbook, 2nd Ed. - Sutherland
3. Advanced ASIC Chip Synthesis, 2nd Ed. - Bhatnagar
4. Writing Testbenches - Bergeron
5. Principles of Verifiable RTL Design, 2nd Ed. - Bening and Foster
SNUG'02 Best Sellers
1. Advanced ASIC Chip Synthesis, 2nd Ed. - Bhatnagar
2. System Design With SystemC - Grotker, Ziao, Martin, and Swan
3. Writing Testbenches - Bergeron
4. The Verilog PLI Handbook, 2nd Ed. - Sutherland
5. Principles of Verifiable RTL Design, 2nd Ed. - Bening and Foster
See you at DAC.
- Carl Harris
Kluwer Academic Publishers
( ESNUG 394 Item 3 ) --------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #15 ) Goering Sees 30 Monterey Tape-outs; Cooley Sees 3
> The 3 Monterey tape-outs I counted myself: 2 at Infineon and 1 at Zoran.
> It must really suck to be Monterey. With 740 rival tape-outs ahead of
> them, this makes Monterey 248X behind everyone else! Ouch.
From: Gayatri Japa <Gayatri.Japa@indiatimes.com>
John,
Your colleague Goering reports 30 tape-outs by Monetery yet you report only
3 tape-outs. http://www.eedesign.com/columns/tool_talk/OEG20020513S0017
Why this discrepancy? Are you angry at Monterey for some reason?
- Gayatri Japa
Editor's Note: No, I'm not angry at Monterey at all, Gayatri. Why would
I be? I'm just being fair to all involved here. When Synopsys claimed
50 PhysOpt tape-outs back in December, 2000, I publically doubted that
claim until I had counted each tape-out with each customer personally.
http://www.deepchip.com/news/census.html In March, 2001, Cadence put out
a press release about its first customer PKS tape-out. They cleverly
implied PKS was used in a big tape-out. In truth, PKS was only used on
50 kgates of a MIPS core buried inside a 130 Mhz, 2.5 million gate design.
http://www.deepchip.com/items/0349-10.html When Magma made the claim back
in May, 2001 that they had 30 tape-outs, I also doubted them until I had
personally checked with each of their customers. In doing that check, I
discovered Magma had 36 tape-outs, but that 23 of them were done for/with
customers by Magma employees -- i.e. only 13 of the tape-outs were true
users-using-the-tool tape-outs. http://www.deepchip.com/items/0374-07.html
Last month Monterey claimed 30+ tape-outs. And Goering rightly reported
that Monterey "claims just over 30 tapeouts". I know of two customers
who've done 3 Monterey tape-outs -- therefore I'll only report 3 tape-outs
until I hear otherwise from the Monterey customers themselves. - John
( ESNUG 394 Item 4 ) --------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #10 ) Two Evals Of Verplex Tuxedo vs. Synopsys Formality
> We recently evaluated Verplex vs. Formality. Our conclusion was that both
> tools are equivalent, and we decided to go with Synopsys mostly for
> business reasons. We already taped out two designs with Formality and
> although we found some bugs and some limitations (mostly in the
> hierarchical RTL-to-flat-gates domain), we are very happy."
>
> - Nir Sever
> Zoran
From: Uwe Koenig <Uwe.Koenig@eed.ericsson.se>
Hi John,
Two years ago, I evaluated Verplex 'Tuxedo', Mentor 'FormalPro' and Synopsys
'Formality'. I tested RTL-to-gate as well as gate-to-gate. The outcome was
that we bought Verplex.
The main PROs of Tuxedo are that it is easy to learn and easy to use, and
that you really SEE what happens, or what the problem is. It's just
intuitive. You use the same tool for verifying and debugging, you can
switch the GUI on and off, you can even change the hierarchy level while
the tool runs, let the tool generate scripts for hierarchical comparison,
and you have shorter runtimes and memory usage than the other tools.
Another aspect is that it runs very stable, while Formality often crashed
(Synopsys probably they solved this problem now, this was 2 years ago I did
this eval.) Also, it was impressive that Verplex FAE needed only 20 min to
install the tool, then we could start working.
Today I also use Chrysalis 'Design Verifyer', and it works OK, but whenever
problems occur (and we had some with the VHDL reader) I switch to Verplex
'Conformal' which is the new version of Tuxedo, to understand better what
exactly the problem is. Design Verifyer has coding restrictions, since it
doesn't understand VHDL-93 or later. They announced it for the new version
in autumn. Mainly I have the impression that all suppliers of FV tools try
to get to the point where Verplex already is.
- Uwe Koenig
Ericsson Eurolab Deutschland GmbH Germany
---- ---- ---- ---- ---- ---- ----
From: [ A Bridge Too Far ]
Hi, John,
Here is our benchmark of Formality vs. Verplex LEC. Please keep me anon.
Formality version 2001.06 from Synopsys
Tuxedo - LEC version 3.0.1.a from Verplex
Test Cases:
1. VHDL to Verilog: (gate to gate)
Size: 110K Gates
CPU Time Memory Usage Compare Points Result
Formality 386.13 sec 92.09 MB 6828 Pass
Tuxedo-LEC 1373.05 sec 90.62 MB 6718 Pass
2. Pre-route to Post-route: (gate to gate)
Size: 750K Gates
CPU Time Memory Usage Compare Points Result
Formality 1800.64 sec 460.02 MB 37034 Pass
Tuxedo-LEC 2867.12 sec 463.12 MB 36585 Pass
3. Before/After Clock tree insertion: (gate to gate)
Size: 1M Gates
CPU Time Memory Usage Compare Points Result
Formality 1188.26 sec 379.18 MB 49849 Pass
Tuxedo-LEC 1526.73 sec 527.53 MB 49507 Pass
Comparing Tools:
In all cases Formality was faster than Tuxedo-LEC. Formality ranged from
3.5X to 1.3X faster than Tuxedo. Tuxedo matched or used more memory than
Formality. Tuxedo used 1.4X more memory than Formality on 1M gate design.
Both tools crashed several times for unknown reason. It happened to
Formality more often. For Tuxedo-LEC, it will generate some hidden files
that you can email back to Verplex to see what caused the crash, but for
Formality, you will only get message "segmentation fault" and a core file
when the tool crashed.
Formality accepts more formats including Synopsys .db & .lib (for library).
Tuxedo-LEC can reports more stuff like Black Box, Modules, etc. That could
be useful sometimes.
Formality relies on naming matching. If instance names are very different
between two netlists, very few compare points can be matched. Tuxedo has
better matching engine.
Formality cannot access netlist. Tuxedo uses Debussy as their debug system.
User can refer schematic and netlist easily. Debussy will break into the
macro. You will see dff_udp, and other and gate, or gate, etc. Formality
keeps the original cell in the schematic, for example, SDFERQ1.
Formality can remove/isolate any sub-cone from schematic to make it easier
to debug. Tuxedo cannot remove any part of schematic.
Formality can save design in binary format. So next time you use this
design again, you can just read in the binary format without doing
everything from scratch. Tuxedo needs to do everything from scratch.
Formality doesn't know which one is the top-level design, user has to
specify. Tuxedo will know the top-level design name.
Formality is one of Synopsys tools, if Design Compiler didn't synthesis
correctly, Formality will not be able to find out since they use the same
synthesis engine. Tuxedo is a third party tool. Better for design that
is synthesized by Synopsys.
- [ A Bridge Too Far ]
( ESNUG 394 Item 5 ) --------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #14 ) PrimeTime-SI, Celestry Nautilus-SI, Cadence SE-SI
> Hierarchical Physical Synthesis with ILM Models
>
> + Interface Logic Models (ILM) allow PrimeTime/DC/PhysOpt to run faster
> using less memory.
> + PrimeTime ILMs are flat with no phyiscal information, written out as
> flat Verilog netlist and support back annotation.
> + DC/PhysOpt ILMs contain original hierarchy and physical info, in DB
> format and support back annotation.
> + DC/PhysOpt ILMs will allow top-level optimizations/routing to be run
> on the full-chip without having to load entire design.
>
> Q: How well will ILMs interface with 3rd party tools?"
>
> - Kent Ng of Microsoft/XBox
From: Robert Wiegand <RWiegand@NxtWaveComm.com>
Hi, John,
Using ILMs and ETMs for hierarchical STA is supposed to improve memory and
runtime up to 4X. The suggested flow is to use ILMs (Interface Logic
Models) for in-house IP blocks, and use ETMs (Extracted Timing Models) for
3rd party IP. Paths between top-level blocks can be analyzed accurately
using ILMs while avoiding the overhead of a full chip netlist. Each top-
level block can then be analyzed independently to complete the picture.
PrimeTime 2002.03 adds validation for ETMs and ILMs. The procedure is to
use the write_interface_timing command to create interface timing files for
both the original gate level block and the ETM or ILM, and then use the
compare_interface_timing command to verify missing arcs, slack, output
transition input capacitance and design rules.
The overview of PrimeTime-SI at SNUG'02 gave me the Synopsys views about
crosstalk effects, and PrimeTime's capabilities to analyze them. The
Binary Parasitic Format feature is used to save runtime on subsequent runs
after the initial conversion to SBPF. This feature can be used in standard
PrimeTime as well.
Because I've worked with Celestry's Nautilus-SI and Millennium-SI tools, I
was particularly interested in comparing PrimeTime-SI's capabilities. It
seems that if I had both sets of tools I would have a complete solution.
While the Celestry tools were great with extraction, delay calculation, and
crosstalk magnitude calculation, they are lacking in timing window creation
and net selection capabilities. They had the mechanisms in place, but they
just weren't quite ready yet. As a result, I had to settle for overly
pessimistic crosstalk analysis with infinite timing windows where all
aggressors on a given net are assumed to act at once.
Based on what I saw at this SNUG'02, PrimeTime-SI has it all over Celestry
in the timing window department. I had read several articles in ISD a while
back talking about performing multiple iterations of STA to refine the
timing windows and successively increase accuracy, with 2-3 iterations being
optimal. The PrimeTime-SI SNUG session talked about this, and said that 2
iterations are typically sufficient. These iterations are performed with a
single update_timing command, and there is a variable to set the number of
iterations (trading off runtime for accuracy). PrimeTime-SI takes windowing
a step further with two cool features: Logical Correlation and Temporal (in
time) Correlation.
Once the timing window functionality has determined whether or not aggressor
nets switch close enough in time to the victim net switching to effect its
timing, logical correlation kicks in as well. Let's say aggressor net 1 is
attached to the input of an inverter, and the output of the inverter drives
aggressor net 2, and both of these nets switch within the timing window of
the victim net. Because the 2 aggressor nets switch in opposite directions,
their effects on the victim net effectively cancel each other out.
PrimeTime-SI is able to understand this and eliminate false pessimism. This
feature works with buffers and inverters only.
Temporal correlation has to do with partial overlapping switching windows
between victims and aggressors. With no overlap between the windows, the
aggressor has no contribution to the victims timing. With full overlap
between the windows, the aggressor has full contribution to the victim's
timing. With a partial overlap between the windows, only a portion of the
aggressors switching waveform will have an effect on the victim's timing.
PrimeTime-SI is able to recognize and handle this situation.
There is, however, a very important part two of the story. What happens
when an aggressor (or several aggressors) acts on a non-switching victim?
The result is a 'bump' or glitch on the victim. If that glitch crosses the
switching threshold of the gate input pin it drives, that glitch could get
through the gate. This produces a glitch on the net connected to the output
of the gate, making a new switching aggressor. My understanding is that
none of the available tools today (with the possible exception of Celtic by
CadMos/Cadence) can deal with this scenario. Therefore, in order to believe
any crosstalk related timing information you obtain from the tools, you must
first verify the prime directive has not been violated - that no glitches
get through any gates and become additional aggressors. This is
accomplished with a peak noise or glitch report.
Celestry's Millennium-SI was able to generate a very detailed peak noise
report, showing the total contribution of all aggressors on a given victim
in terms of a percentage of VDD, and the breakdown of each aggressor's
contribution. Due to the timing window difficulties, this report was
pessimistic. If five aggressors each caused a 10% VDD spike, it was assumed
they all happened at once to create a 50% VDD spike. It was up to us to
determine where the real problems were. It was also up to us to determine
if the glitch crossed a threshold to let the glitch through. Using .tlf
libraries that supported Cadence's SE-SI (Silicon Ensemble with Signal
Integrity), we were able to use the ct_tolerance values for this metric. At
the time, Millennium-SI did not compare its peak noise values against the
ct_tolerance values to determine violations, but my understanding is that
this capability is now supported, and some of my timing window issues may
have been addressed by now as well.
PrimeTime-SI presently does not support peak noise reporting capability, but
it is planned toward the end of the year. They are presently in discussions
with library vendors to come up with a standard metric in the library. How
about ct_tolerance? It exists today.
Of course, all this describes an analysis and repair type methodology, where
the ideal scenario is to build it right the first time. SNUG'02 indicated
that the PT-SI capabilities were also being merged into PhysOpt. Once peak
noise capability is integrated, this could be a sweet solution. Of course,
the Holy Grail would be to also have a timing driven crosstalk aware router.
- Bob Wiegand
NxtWave Communications Langhorne, PA
( ESNUG 394 Item 6 ) --------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #12 ) Synopsys Says Behavioral Compiler Is Alive & Well
> It's rumored that Behavioral Compiler is approaching its End-Of-Life
> notice. It appears that nobody will be crying at the funeral.
> "Behavioral Compiler? - yuck. Let's you exchange one set of arbitrary
> limitations on coding style with another. BC was overpromised and
> underdelivered." - Tom Heynemann of Compaq
From: Aaik van der Poel <aaik@synopsys.com>
Hi John,
I'd like to take the opportunity to comment on the rumor that BC has been
End-Of-Lifed. Your sources might just be a little mis-informed.
For the grounds of the rumor, recently we have undergone some efforts to
clean up the number of BC options on our price list, and consolidate them
to a single line item. Users of these consolidated packages might have run
into, or heard about, that those were no longer available for sale. Those
that thrive on rumor mills of course picked this up, without fully informing
themselves.
BC is alive and well, and I encourage those that state that "it does not
work" to take a look at it. As you can see from your respondents, most user
experience was gained 3 to 4 even 5 years ago. It has long since been
acknowledged that behavioral synthesis was somewhat overpromised as "the
next big thing", as Oren Rubinstein from Nvidia states correctly.
Behavioral synthesis is definitely not a cure-all, but it is very productive
for algorithm design and implementation, unless the designer has a very
clear insight in what the architecture of his or her algorithm should look
like, and the absolute minimum area and maximum performance is needed.
Otherwise BC users repeatedly come back to us saying how productive it is
especially for derivative products, and (slight) spec changes, cutting their
design cycle on those algorithms in more than half. And yes you will have
to learn to think "behavioral", as with most things you will have to seed,
water and nurture first, before you can harvest.
So just to put this issue to rest: BC is alive, it is staffed, and it is
continuously being improved, and those that want to try it should ask their
Synopsys sales rep for the "Behavioral Compiler" product.
- Aaik van der Poel
BC Product Marketing Manager
Synopsys, Inc. Mountain View, CA
( ESNUG 394 Item 7 ) --------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #10 ) Three EDA Users Review Mentor's FormalPro EC Tool
> Gee whiz, I didn't even realize that Mentor *had* an equivalence checker,
> despite the fact that we have other Mentor products in-house. They're
> definitely behind on mindshare, then. :-)
>
> - Natalie Overstreet Ramsey
> Vitesse Semiconductor
From: Rob Christy <rob.christy@jennic.com>
Hi John,
We've been using Mentors' FormalPro product for around a year now. It was
the first formal verification product that we had used in Jennic, although
we had previous experience of Formality and Chrysalis from previous lives.
Based on what we knew 12-15 months ago about the formal verification space,
we evaluated Verplex Tuxedo LEC and FormalPro as we wanted a next generation
product for some of the big SOCs that we had planned. I should say we knew
that FormalPro was still being heavily developed on and was probably at an
advanced beta release at that time. We have a fairly healthy relationship
with Mentor anyway as we use their test tools and they promised us factory
level support if we ran into difficulties.
Our evaluation of Verplex LEC vs FormalPro was run on a number of testcases
(mostly contrived), eg. 64-bit mutiplication, and at the time our only real
design was a 500K 0.18um TSMC device. I should say that both tools
completed all our testcases with relative ease and with similar runtimes
(initially Mentor had an issue with the 64-bit multiplication example, but
this was fixed within 1-2days). We considered RTL vs RTL, RTL vs Gate and
Gate to Gate, with RTL in both VHDL and Verilog.
We opted for FormalPro at the time because it had a significantly smaller
memory footprint, and a claim from Mentor which we have now verified to be
true that it could handle multi-million gate designs flat with RTL vs Gate
(we were skeptical at first)... Plus we knew we could have some input on
how we would like the tool to be improved.
A summary of our results is shown below (score of 1-5, 5 being the highest,
but not necessarily meaning its perfect, but based on previous experiences
of what we wanted or expected for a tool of this nature):
Ease of Use: Verplex LEC 5 FormalPro 5
RTL/RTL (compare): Verplex LEC 5 FormalPro 5
RTL/RTL (debug): Verplex LEC 5 FormalPro 4
RTL/Gate (compare): Verplex LEC 5 FormalPro 5
RTL/Gate (debug): Verplex LEC 4 FormalPro 5
Gate/Gate (compare): Verplex LEC 5 FormalPro 5
Gate/Gate (debug): Verplex LEC 3 FormalPro 5
We thought LEC's debugging was slightly easier for RTL vs Gate, just
because of better cross probing capability, and FormalPro was better at
Gate vs Gate debug. I guess because of the ATPG pattern technology it
has under the hood, it could more quickly identify the real candidate.
From a comparison point of view both tools were fine and there was little
in it. We also had one little plus with mentor in that you could use
Verilog, Synopsys lib and Mentors ATPG library formats as input, which
allowed us to compare these libraries against each other. We had a recent
case when the vendor Verilog supplied library had an an error - we
identified and fixed this very quickly.
Since then Mentor's general debugging/reporting has improved (some at our
request). However now we have run an additional 2 large designs through
the tool to review real capacity.
Design A - 3.2 Mgates 0.18um, Verilog, (macros: rams and ms blocks)
Design B - 2.2 Mgates 0.13um, VHDL, (macros: rams, arm cores, ms blocks)
Both designs can be run completely flat at RTL vs. Gate. I personally
have run through Design A on a Sun Blade (750Mhz, 8GB phys mem, 24GB swap)
in around 2 hours. In fact its memory footprint was only 700MB (so
comfortably within a 32bit OS which is good as we are migrating to a more
Linux related environment and FormalPro runs on this OS).
For us the fact that FormalPro can handle the design flat as opposed to
Verplex LEC which does a hierarchical type comparison, meant that we did
not have as much tool setup to perform for when the physical tools had
manipulated pins through clock tree (insertion and re-insertion), smashed
blocks together, or had other renaming problems. Synopsys DC change_names
and Mentor's default regexp for names rules have worked in all of our
design cases). You can still do a hierachical bottom up style if you like
by black boxing or similar (but for us there seems little point as runtimes
are acceptable).
So what problems did we have, apart from the 64-bit multiplier issue we
saw 12 months ago? We have had only one real error to do with ifdefs in
an always statement in Verilog:
always @(u_status or u_config or u_porten or isb_ad `ifdef UDP_SUPPORT
or udp_config `endif)
This caused the tool to fail with the Verilog reader, and was fixed within
a 1 week time frame. Before the fix we just recoded the failing blocks;
not that our RTL guys were too pleased. The rest of the issues fall into
just gathering experience of the tool ie. knowing which report files mean
anything when debugging and initial setup etc.
We had another instance (not really an error) when the graph matching
within FormalPro was making wrong comparison points - which was touch to
find from a debugging point of view. However turning it off fixed the
problem, but the real root of the issue was some redundant logic and/or
unreachable code had not been discovered with our linting and code
purification environment. Mentor fixed (within the next release) the
debugging of this type of problem, and of course we reviewed our other tools
as to why this was not picked up earlier.
Most of our wishlist for improvements with FormalPro were to do with the
reporting of text to be reduced and spat into side files (which was done),
and to add GUI capable operations (rather than just side files) for
constraining of pins etc. (just so occassional users could benefit, the
power users still wanted the side files). From the Verplex LEC side we
would have preferred reports to be generated in a predefined default
area, plus improve the gate level debugging (we ran one test case where
we inverted the scan mode signal deliberately and LEC identified every flop
in the design as a potential fail plus the inverter - FormalPro gives you
the inverter straight away). We thought this was a resonable test as there
are always a few gate level hacks performed in the final stages for a lot
of the chips we've worked on, and manual mistakes happen). We also wanted
LEC to improve its what-if capabilities eg. for gate swapping and re-running
the comparison.
We are currently using FormalPro version 3.1_4.3 and are waiting for version
4.x of the tool as there are many more improvements. My view is that
FormalPro is now perfectly competitive to any of the other offerings. When
we made our initial purchase there was perhaps some doubt that the tool
could deliver, but felt that the risk was worth it with the first release we
saw. It's been steadily improved since then.
- Rob Christy
Jennic Ltd. Sheffield, England
---- ---- ---- ---- ---- ---- ----
From: Raju Patel <RPatel@ciena.com>
Hi John,
We evaluated Verplex and FormalPro one-year back. For Chrysalis, we told
Avanti our design size and they did not response to us. FormalPro was the
only tool able to handle our 8 million Gate ASIC. When we evaluated
FormalPro it was able to handle only gate-to-gate formal verification. We
are getting good runtimes -- 6 million gate designs finished in about 2.5
hours on a Sun 700 Mhz machine.
In the early use there were several bugs in FormalPro that would not allow
it to do RTL-to-gate formal verification: parameter passing in RTL,
complementary matching problem on flip-flops with only XQ output, handing
Synopsys DesignWare resource comments, floating net handling etc... In
addition to these, there were problems with few switches which were not
working properly.
Mentor has fixed the majority of these in v3-4_0-5 and the only issue not
fixed (complimentary matching) has a workaround script that Mentor gave us
for modifying library cells which have XQ as a output. We are now running
RTL-to-gate formal verification on our latest design to verify that netlist
after ECO's is equivalent to modified RTL. The runtime for this is very
good -- about 3.5 hours for our 6 million gate design.
FormalPro's areas for improvement are:
- no incremental compile capability to further reduce runtime.
- In case of an error in RTL to gate translation, FormalPro reports
error in their internal database directory. It should report in
user log file.
- The complementary matching is not fixed in latest release and
still needs a workaround.
Overall we are happy with the FormalPro results and will continue using it
as a part of our ASIC Design flow.
- Raju Patel
Ciena Corporation Fremont, CA
---- ---- ---- ---- ---- ---- ----
From: Pierre Ragon <pragon@lucent.com>
Hi John,
We have been using FormalPro for almost 2 years to check designs that have a
complexity of up to 2 Mgates and 125,000 flip-flops. I haven't used
Chrysalis/Verplex/Formality. We used Vformal in the past. Then after
Vformal was taken over by Avanti, we stopped using it mainly because we
had no ASIC project at that time. We started cold with FormalPro and did
not evaluate competition. FormalPro works RTL-to-RTL, RTL-to-gates and
gates-to-gates.
We used the RTL-to-gates to verify that Design Compiler has not altered our
design functionality. Interestingly enough the problems that we caught were
not synthesis problems.
One was related with an array that was indexed in such way that the index
overflowed the array range by one:
my_array(idx + 1)
with idx varying within the array bound. FormalPro and DC had a different
interpretation of what the implementation should be when the index
overflowed. This issue had not been detected by the RTL simulations and
could have been missed because it was a very comples corner case.
The other one was related to a synthesis script error. A module was
instantiated several times in our design with some occurences of fixed
inputs. The module was synthesized once with the constant inputs propagated
and then the result of the synthesis was reused for other instances with a
different configuration. This would cause erroneous simulation at gate
level. But it would be difficult to find the cause because it originated in
deeply embedded modules. And it would have taken a lot more time to run the
gate level simulations to pinpoint the error than analyzing equivalency
check results.
Finally we use the gates-to-gates to verify the post-layout netlist with the
pre-layout netlist.
My experience so far is that FormalPro is easy to use (less than a day to
get started), fast (35 minutes to compare two 2-Mgates netlists) and does
not need a lot of memory (less than 512 Meg).
When a difference is found, FormalPro immediately reports both the registers
that do not contribute to both targets and the registers that must be set to
specific values to propagate the difference. That already helps a lot in
many cases to find what is happening. Besides that, schematics of the logic
clouds which features the difference and whatif analysis mode gives some
more help for the more complex cases.
Several FormalPro bugs were found and solved quite quickly thanks to the
support provided by Mentor graphics. Some bug examples:
- The most difficult bug they had to fix had to do with a constant in
VHDL code that was not propagated well by FormalPro synthesis engine.
- Another bug was that synthesis_on/off were not supported correctly.
- The absolute value operator was incorrectly supported: FormalPro removed
the case for the most negative integer in the 2's complement range.
- Using numeric_std library, I found a problem w/ the multiplication
operator used with an integer argument and a signed argument.
These have all been fixed by FormalPro v4-1_0-7.
The main improvment that I would like to see in FormalPro is for its
multiplier verification in RTL-to-gates. There are still cases where it
needs to blackbox the multipliers to complete the verification.
We usually remove the operator heirarchy during one optimization step and it
seems to make it more difficult for FormalPro to verify a multiplier that
has been optimized together with the surrounding logic.
Overall Mentor's synthesis technology is a bit less mature than Design
Compiler. But FormalPro is still very useful and the fact is that DC
results need to be compared to something that has been synthesised with a
different engine (at least for the RTL-to-gates comparison.)
We find FormalPro to be a valuable addition to our design flow and are very
satisfied with the results on the whole.
- Pierre Ragon
Lucent Le Plessis Robinson, France
( ESNUG 394 Item 8 ) --------------------------------------------- [05/29/02]
From: Joanne Wegener <Joanne.Wegener@synopsys.com>
Subject: The Three Best User Papers of SNUG'02 As Voted By Attendee Ballot
Hi, John,
You forgot to list the SNUG'02 Best Papers in your trip report.
First Place Best Paper (attendee scoring 4.588 out of 5.000):
"Simulation and Synthesis Techniques for Asynchronous FIFO Design
with Asynchronous Pointer Comparisons"
by Peter Alfke of Xilinx & Cliff Cummings of Sunburst Design
Second Place Best Paper (attendee scoring 4.500 out of 5.000):
"RTL Coding and Optimization Guide for use with Design Compiler"
by Jack Marshall of Tera Systems
Third Place Best Paper (attendee scoring 4.417 out of 5.000):
"Tricks of the Test Trade: ATPG Methods that Improve Fault Coverage
of SoC Devices"
by Michael Lewis & Leah Clark of Cypress Semiconductor
These papers are at http://www.snug-universal.org/papers/papers.htm
- Joanne Wegener
SNUG Program Manager
Synopsys, Inc. Mountain View, CA
( ESNUG 394 Item 9 ) --------------------------------------------- [05/29/02]
Subject: ( ESNUG 393 #12 ) How To Handle Hard & Soft Macros In Cadence PKS
> Yup, I get black box warnings (when I don't read in a Verilog shell).
> So PKS will not be happy until it gets a tlf or alf? I guess that's the
> problem. I've been trying to get away without doing that. I was hoping
> that it would intuit the info from a DEF and/or Verilog shell.
>
> - Albert Ma
> MIT Cambridge, MA
From: Glenn Gullikson <glenng@cadence.com>
Hi, John,
There are several ways to handle custom blocks within PKS -- either as soft
blocks or hard blocks. The hard block approach requires a physical model
(LEF) and timing model (TLF or ALF). Without the timing model, the hard
block will have no timing associated with it. If you access to PKS 5.0,
then the easiest thing to do is to use the do_extract_timing_model command
to generate a TLF. This can generate either a black box or grey box model
depending on what you are looking for. This is done by loading, at minimum,
the Verilog for the block and the timing constraints:
<load libraries>
read_verilog <verilog_file>
do_build_generic
source <constraints_files>
do_extract_model [-black_box] -cell_name <block_name>_model \
<block_name>.tlf
This will generate a timing model based on the available timing which is the
WLM from the library in this case. For more accurate timing, then load
either a placement (Steiner based timing), SPEF (annotated parasitics), or
SDF (annotated delays). The model will be generated for whatever timing is
loaded at the time.
Regarding the "physical information not found" message. That is happening
because there is no "cell" to bind the LEF to. LEFs are either for
"physical only" cells (instantiated in the DEF and not the Verilog) like
fillers, dcaps, etc. or for instances with timing models associated with
them.
With PKS 5.0, there is another way to deal with this situation and this is
through the creation of soft blocks. A soft block is an instance in the
design that does not have a timing model but has a physical hierarchy
associated with it. This is applicable in Albert Ma's case.
The way to handle this is:
<load libraries>
<load top level verilog design>
<load floorplan information>
read_verilog <verilog_for_the_datapath_block>
create_physical_cluster -name <cluster_name> \
-bbox <cluster_bounding_box> \
-location <cluster_location> \
-instance <logical_instance>
At this point, you can push into the cluster and load placement information
or SPEF/SDF information as discussed previously:
do_push -cluster <cluster_name>
[ read_def <cluster_placement> | read_spef <spef_file>
| read_sdf <sdf_file> ]
do_pull
At this point the design can be optimized and will use the timing for the
soft block during optimization and stitch that timing with the timing at the
top level. The contents of the soft block will not be touched and the top
level placement will in essence treat it like a hard block but since the
contents of the soft block are "visible" the top level optimization will be
able to see the drivers and loads in each of the soft blocks for accurate
incremental timing.
- Glenn Gullikson
Cadence San Jose, CA
( ESNUG 394 Item 10 ) -------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #8 ) Hey! The Synopsys Ketchum Tool Is Not Dead Either!
> This year, two Synopsys tools ('Ketchum' & 'Verification Analyst') that
> I had been tracking under the Synopsys NDA cloak have disappeared. They
> were verification tools similar to 0-in (SNUG 01 #23).
>
> Dataquest FY 2000 Formal Analysis Market (in $ Millions)
>
> 0-in # $1.1 (51%)
> Averant # $1.1 (49%)
>
> Total ## $2.2
>
> I know there have been layoffs at Synopsys over the past 8 months. Maybe
> Aart just decided that a miniscule $2.2 million market was small potatoes
> not worth chasing after.
From: [ Synopsys R&D ]
John,
Please keep me anon. Your rumors on Ketchum are completely false. The
technology is in active development. Functional verification is too
important of an area for the design market for Synopsys not to invest.
- [ Synopsys R&D ]
---- ---- ---- ---- ---- ---- ----
From: Umberto Rossi <umberto.rossi@st.com>
Hi John,
We are currently evaluating Ketchum and started seeing promising results.
I see Ketchum as a real opportunity to drive hybrid functional verification
to reveal more bugs by the usage of semi-formal techniques. Coverage driven
test pattern generation is the ambition of many products and may be very
challenging to position such a product in the market.
I guess that Synopsys takes great pains to mature a technology like this
before making announcements and unleashing new products.
- Umberto Rossi
STMicroelectronics Agrate Brianza, Italy
( ESNUG 394 Item 11 ) -------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #11 ) Makefiles, Automatic Chip Synthesis (ACS), and DC
> Automatic Chip Synthesis (ACS) is a tool in DC to:
>
> + Budget lower level partitions from top-level constraints
> + Provides Top-level synthesis commands
> + Manages parallel synthesis jobs on multiple CPUs
>
> Q: How does the ACS parallel job function compare to Makefiles?"
>
> - Kent Ng of Microsoft/XBox
From: Thomas Fairbairn <tomf@pdd.3com.com>
Hi John,
Thanks for the SNUG '02 report - vital reading as ever. I noticed that in
the DC/ACS section, Kent Ng of Microsoft/XBox asked "How does the ACS
parallel job function compare to Makefiles?"
Kent, ACS generates a makefile for you. ACS sorts out your dependancies,
spits out a makefile, and, if you want, can stop there. So, if you need
to, you can edit the makefile to incorporate any other trickery that you
want, then run "make". What's more, it's a Gnu makefile, where you can
control the number of jobs that run in parrallel. That's how we use it
here.
- Tom Fairbairn
3Com Europe Ltd. Hemel Hempstead, UK
( ESNUG 394 Item 12 ) -------------------------------------------- [05/29/02]
Subject: ( ESNUG 389 #12 ) Silicon Metrics 'Path' PrimeTime/SPICE Analysis
> We used Hspice to model the effects of crosstalk on a part of our design
> and a simple testcase from Synopsys. We first compared our Hspice results
> to our regular Primetime results (no crosstalk), and once those numbers
> were verified, we compared PrimeTime-SI and Hspice results.
>
> We used the new write_spice_deck command to write out a SPICE deck for a
> specific timing path in our design. This SPICE deck included all of the
> nets and cells in the timing path as well as the nets and drivers for the
> crosstalk aggressors affecting this path. Unfortunately, this testcase
> was much too complicated. There were too many aggressors on the same net,
> and a comparison with the PrimeTime-SI results would not be practical. A
> simpler testcase was needed.
>
> - Ryan Hyma
> AMD Austin, TX
From: Art Arizpe <aarizpe@banderacom.com>
Hi John,
I noticed that Ryan Hyma uses a manual process for comparing STA results
with SPICE. We use a tool from Silicon Metrics called Path that does the
same thing but it's automatic.
Path runs with Primetime. After I select my critical paths using PrimeTime
TCL, Path spits out SPICE decks, sends them to multiple machines for
simulation, and brings the results back into PrimeTime. It has reports to
compare STA to SPICE for delay and slew. I know PrimeTime has a
write_spice_deck command, but this is much better.
It's easy to use and the incremental and debug analysis capability really
helps during tapeout crunch. It's the first release, so it doesn't have
lots of bells and whistles. But it looks like the they are working on the
right set of features like SPICE level SI analysis.
One place we found it very useful was for catching a tricky hold problem.
In Primetime, several hold paths showed about +10 ps of slack. On the
other hand, SPICE analysis (which included IR drop) from Path show nearly
-150 ps hold slack.
Had we not caught these before tapeout, it would have been bad.
- Art Arizpe
Banderacom Austin, TX
( ESNUG 394 Item 13 ) -------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #7 ) It's Obvious SystemC Failed; Superlog Is The Future
> "I think that it's plain old Verilog up in front, with Superlog a length
> behind, and SystemC asleep at the starting gate."
>
> - Dave Chapman of Gold Mountain
From: Nick Skelton <nick.skelton@freehand.se>
Hi John,
I just read your SNUG trip report report. I had been thinking that you kept
mis-filing Superlog by lumping it into threads about SystemC. Surely
everyone has now seen that design in C is not going to fly. And you
shouldn't have been listing Superlog with the languages like E and Vera.
Maybe you were right after all. E and Vera are so entrenched in that space,
even if Superlog has all their verification features, and is easier to use,
it will still take ages to dislodge them.
In design and especially sub block verification however Superlog is good.
The subblock designers, who really want have have access to all the
verification features, don't want to have to learn a new weird language.
We at Freehand have been using the SystemSim Superlog simulator for 3 years
now. We like it. It's robust and fast. Superlog can't do VHDL, but it
does simulate C together with Verilog rather well. We use that a lot.
- Nick Skelton
Freehand DSP AB Sweden
( ESNUG 394 Item 14 ) -------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #11 ) Three Customers Chime In On Incentia RTL Synthesis
> And Incentia from Taiwan? I'll let Nvidia's Oren Rubinstein describe
> them: "Ambit had potential before being acquired by Cadence. Synplicity
> never got past the FPGAs (not seriously, anyway). I tried Get2chip about
> a year and a half ago. It wasn't there yet, but I don't know about its
> current state. What is Incentia?"
From: Clark Shuieh <clarks@ralinktech.com>
Hi John,
I have used Incentia products for two tape-outs. However, I have to be
honest our company did not perform performance comparisons directly between
Incentia and Synopsys.
Our blocks are between hundreds of gates to couple hundred kgates. We use
a bottom up approach, but with the flexibility to re-synthesize the critical
blocks from top level if timing is too far off or customer wireloads are not
good enough. With Incentia, the timing and synthesis is a tightly
integrated flow, and results with few lines of commands in the scripts.
- Clark Shuieh
Ralink Technology, Inc. Cupertino, CA
---- ---- ---- ---- ---- ---- ----
From: Benjamin Chiu <BenjaminChiu@via.com.tw>
Hi John,
We have used Incentia's STA (TimeCraft) and synthesis (DesignCraft) products
to tape-out some designs.
Under our design methodology, a sign-off STA tool must be fast and able to
handle our complicated design styles that contain latch-based data-paths
with sophisticated clocking schemes, timing constraints, and timing
exceptions. Incentia TimeCraft's fast CPU speed greatly cuts down our total
turnaround time.
We have also used Incentia DesignCraft in our logic and test synthesis. It
still needs to be improved in some cases and Incentia engineers are working
on it right now.
- Benjamin Chiu
VIA Tech, Inc. Taiwan
---- ---- ---- ---- ---- ---- ----
From: Becker Sze <becker@averlogic.com>
Hi John,
We have used Incentia logic synthesis and timing tools since January 2001.
Since then we have taped-out 5 designs using Incentia products. We are
quite satisfied to Incentia product offerings and strong technical supports.
Early this year, we were struggling with timing closure between pre-layout
and post-layout on one of our recent designs. We tried Incentia physical
synthesis (it's called DesignCraft Pro) and it did improve 2.5 ns (from
9.5 ns down to 7 ns) on our critical paths. We already taped out the
design using the result from DesignCraft Pro.
- Becker Sze
Averlogic Technologies, Inc.
( ESNUG 394 Item 15 ) -------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #6 ) User Says Dataquest Vera Sales Numbers Are Inflated
> STRUGGLING FOR MINDSHARE: When I asked about Vera/Specman/RAVE usage, the
> most common response I received was 'we don't use them' and 'we make our
> own test suites with C/Perl/Verilog' -- which means it's one small market.
>
> Dataquest FY 2000 Functional Test Simulator Market (in $ Millions)
>
> Synopsys Vera #### $12.0 (43%)
> Verisity Specman 'e' #### $12.0 (43%)
> Forte/Chrono RAVE # $3.6 (13%)
>
> Total ######### $28.0
>
From: Dave Chapman <dave@goldmountain.com>
I don't think the Dataquest numbers are accurate. While everybody says that
e and Vera have the exact same level of sales, my numbers for Vera are:
2000 2001
------ ------
# of Vera Users 5000 3300
Vera Revenue $100 M $66 M
Nicely demonstrating the 1/3 drop in revenue all over the valley. What I
think causes no end of confusion is that the pricing model used at Synopsys
often involves "all you can eat" site licenses. When Synopsys sells one of
these, who can say how much of the revenue was from VCS, or Vera, or
whatever? They use a formula... My guess is that the Dataquest numbers
are way low because they only count invoices which have a Vera line item.
- Dave Chapman
Gold Mountain
( ESNUG 394 Item 16 ) -------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #17 ) User Asks "Am I The Only One Left Using Arcadia?"
> Synopsys mentioned a few months ago in EE Times that they had created a
> new 2.5 RC extractor. This means they're not using their Arcadia
> extractor -- which makes sense because PhysOpt would need a screaming
> fast extractor for its crosstalk cost function in it's synth runs.
From: Eyal Landesberg <eyall@zoran.co.il>
Hi John,
I read your SNUG 02 Trip Report. Arcadia was mention there only once,
and not by a user. I participated in the E-SNUG in Paris (on March
2002), and there too, Arcadia wasn't mentioned. Am I the only remaining
Arcadia user? What about a user comparison of Arcadia, StarRC, xCalibre,
Fire&Ice, Columbus, Nautilus?
- Eyal Landesberg
Zoran Israel
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 13,958 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
|
|
