> Looks like Denali's sponsoring the valley's first conference devoted
> to memories in 2 weeks. http://www.MemCon.com I wonder if they'll
> get a Barbara Streisand impersonator to sing "Memories" at it???
> (OK, so I'm allowed one really bad joke after getting that DAC Trip
> Report done, OK????)
>
> - John Cooley on DeepChip.com (10/2/02)
From: Chris North <Chris.North@pridepost.com>
Sir,
I am the San Francisco founding member of the Barbara Streisand
Fan Web Ring. Your "bad joke" reference to Ms. Streisand is
humorless and offensive. Barbara is not a joke. In view of your
insolence, I have put the word out so that none of the Bay Area
Streisand impersonators will work your conference. I shall be
contacting your sponsors to inform them of our boycott of their
products and services. Your hate speech shall not stand.
- Chris North, founder
Barbara Streisand Fan Web Ring San Francisco, CA
( ESNUG 400 Subjects ) ------------------------------------------- [10/10/02]
Item 1: PhysOpt 2002.05 Timing Bug Turns Out To Be Really A DC 2001.08 Bug
Item 2: A European Superlog Fan Worries About Synopsys Buying Co-Design
Item 3: Wall Street Asks About The Latest Physical Synopsys Tape-out Count
Item 4: ( DAC 02 #16 ) An Anon Magma Tapeout Becomes Publically Non-anon
Item 5: User Openly Wonders "Is This PhysOpt 2002.05 Laughing At Me?"
Item 6: ( DAC 02 #27 ) Six Users Spank Cooley For Not Covering Denali Well
Item 7: Huh? PrimeTime 2001.08-SP1 On HPUX Differs From Linux/Solaris??
Item 8: ( DAC 02 #24 ) Reason Behind Pallab's Neolinear Comments Questioned
Item 9: ( DAC 02 #15 ) User Claims Magma Picks Up Where Monterey Falls Off
Item 10: ( DAC 02 #16 ) User Claims Magma Picks Up Where PhysOpt Falls Off
Item 11: ( DAC 02 #9 ) Three Users Defend Innologic's ESP-CV Symbolic Tool
Item 12: ( DAC 02 #12 ) Tharas Rebutts The Anonymous User Comment About It
Item 13: How Can I Get UNIX-like Shell Capabilities Inside Synopsys Tools?
Item 14: Wall Street Analysts Should Read The Merrill Lynch SNPS Report
Item 15: Golson's Comparison Of Formality vs. Chrysalis Design VERIFYer
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 400 Item 1 ) --------------------------------------------- [10/10/02]
From: Jay Pragasam <jlk@brecis.com>
Subject: PhysOpt 2002.05 Timing Bug Turns Out To Be Really A DC 2001.08 Bug
Hi John,
I see in the ESNUG posts that people are migrating to the 2002.05 version of
PhysOpt. But I am wondering if anyone is seeing any kind of weird timing
issues just by switching to the new version. I am facing problems with
designs that meet timing with PhysOpt 2001.08 coming up with bizarre -ve
slacks with 2002.05 for the same floorplan, constraints and run scripts. I
am still sticking to the same way of specifying RC values using
set_delay_estimation_options
in 2002.05 just as we did in 2001.08 even though Synopsys recommends
switching to the 2.5-D extraction model of PhysOpt. Could this be a problem?
Just wondering if I am the only soul who is being tormented by 2002.05 or is
there a whole community out there? I am working with Synopsys folks on this,
but just wanted to know if people out there have had similar experiences.
- Jay Pragasam
Brecis Communications San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Jay Pragasam <jlk@brecis.com>
Hi John,
What started out as a problem with 2002.05 version of DC/PhysOpt turned out
to be a 2001.08 sythesis timing issue (as per Synopsys R&D). Funny that we
haven't had a chance to isolate it in earlier designs. I would appreciate
if someone else has comments about this.
The .lib for the synthesis libraries have "when" constructs in them which
specify different timing numbers for the cell outputs for different values
of the unrelated pin.
pin(Z) {
max_transition : 3.59518 ;
max_capacitance : 0.8 ;
function : "! ( A1 ^ A2 )" ;
direction : output ;
timing() {
timing_sense : positive_unate ;
when : "A1" ;
timing_label : A2_Z ;
....
related_pin : A2 ;
}
timing() {
timing_sense : negative_unate ;
when : "!A1" ;
timing_label : A2_Z_1 ;
...
}
related_pin : A2 ;
timing() {
timing_sense : positive_unate ;
timing_label : A2_Z_2 ;
...
}
With a timing model like this, A2->Z has three different models depending on
when A1 is 1 or 0 and a default case. Looks like 2001.08 does not respect
"when" clauses and uses the default all the time. This is not a problem
during normal runs, but when I force a value using set_case_analysis (1 or
0), then 2002.05 picks up the model associated with the value of A1 instead
of the default model which is picked by 2001.08. Also in the timing report,
the appropriate edges are chosen depending on the value of A1 and in some
cases you end up with half the clock cycle in lieu of the full cycle
resulting in real timing issues.
Anyone else seeing this??
- Jay Pragasam
Brecis Communications San Jose, CA
( ESNUG 400 Item 2 ) --------------------------------------------- [10/10/02]
From: Thomas Fairbairn <tomf@pdd.3com.com>
Subject: A European Superlog Fan Worries About Synopsys Buying Co-Design
Hi John,
I find this an interesting development - Synopsys are buying Co-Design,
developers of the Superlog language. (See EE Times web site
http://www.electronicstimes.com/story/OEG20020828S0018)
I'm a Superlog fan. From what I seen of the language (at DATE 98 - some
time ago, I'm well aware of that) it seemed to be the one "new design
language" that really seemed to address the problems we've been having
here. At the time the support for other tools, such as synthesis, was
weak, so I labelled it "interesting - wait for further developments".
On the surface, Synopsys acquiring Co-Design seems like good news.
Hopefully it will shortly be supported in DC. The problem is that
Co-Design was pushing hard for multi vendor support. They were a small
company in the Accellera standards organisation and I was hoping this
would help them push Superlog into a full standard. With Synopsys buying
it, I can't imagine Cadence/Mentor agreeing to that unless they
absolutely have to. And Synopsys is pushing SystemC too.
Synopsys say the two are complimentary. I agree in principle but I see
many ways in which they overlap -- for instance Superlog supports the
import of C functions "as is" into simulation. If I wanted to start
doing some algorithmic exploration, that's where I'd start, not going
straight to a new language like SystemC. Which one will Synopsys push
at Accellera? Will they be pushing for two standards?
Here's hoping Synopsys isn't just killing off a competitor!
- Tom Fairbairn
3Com Europe Ltd Hemel Hempstead, UK
( ESNUG 400 Item 3 ) --------------------------------------------- [10/10/02]
Subject: Wall Street Asks About The Latest Physical Synopsys Tape-out Count
> Anyway, here's my estimated tape-outs for May, 2002:
>
> Synopsys PhysOpt ######################################## 600 tape-outs
> Magma ####### 100
> Cadence PKS ## 36
> Monterey 3
>
> Synopsys reported 500 tape-outs at SNUG'02 and just this week they clamed
> 600 tape-outs in a press release. 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.
>
> - 5 months ago from SNUG 02 #15
From: Richard Ong <rong@eaglecap.com>
Hi, John,
I'm wondering if you have any updates on the comparitive physical synthesis
tape-outs since your histogram in SNUG 02 #15. You didn't make such a table
in your DAC Trip Report.
Synopsys had the early lead with Physical Compiler, but the we read about
some problems ESNUG 374 #7. Any updates? Also, any explanation why all of
the cited Magma tape-outs were gates-to-placed-gates, and why Magma
synthesis wasn't used? Has this changed with time? A follow-on to that
would be does the Magma sales pitch (single technology, single design flow)
come through in reality?
How important is a single data model (Magma pitch), and can Synopsys and
Avanti deliver a single data model database?
- Richard Ong
Eagle Capital Management New York, NY
---- ---- ---- ---- ---- ---- ----
From: John Cooley <jcooley@theworld.com>
You're right, Richard, my last DAC Trip Report didn't have a comparitive
histogram for physical synthesis tape-outs. Sorry. Here's where I *think*
they're at today (Oct. 10, 2002) from what I see.
PhysOpt ############################################### 1200 tape-outs
Magma #### 101
Cadence PKS ## 54
Monterey # 13
I had to estimate the PhysOpt tape-outs by simply graphing the known numbers
and extrapolating to now. Because there are so many, I have no way to count
them all directly any more. And besides, the user traffic I see on PhysOpt
confirms to me that it's widely used.
I had a problem with Magma because only one more user wrote me to say he did
a new tape-out. He was originally anon in DAC 02 #16 (at his request), but
in this issue of ESNUG Simon Matthews of Paxonet decided to become non-anon.
The additional 18 Cadence PKS tape-outs came directly from DAC 02 #14.
The 10 additional Monterey tape-outs came from DAC 02 #15 plus a detailed
Monterey tape-out you'll find in next week's ESNUG post.
I've pretty much stopped tracking tape-outs here in physical synthesis except
for Monterey & PKS. Once you get past around 100 tape-outs you've pretty
much shown that the technology works and then it becomes more of a Dataquest
marketshare issue than tape-out count issue.
Also, to be fair to Cadence, Monterey, and the old Avanti company, tracking
physical synthesis tape-outs is only *half* the picture here. There's still
the question of how many tape-outs various floorplanners have, too -- like
First Encounter vs. Jupiter vs. Floorplan Compiler vs. Aristo IC Wizard vs.
the standard older Cadence & Avanti tools used to floorplan before all these
new tools came on the market.
- John Cooley
the ESNUG guy
( ESNUG 400 Item 4 ) --------------------------------------------- [10/10/02]
Subject: ( DAC 02 #16 ) An Anon Magma Tapeout Becomes Publically Non-anon
> The first one wrote to say "add one more to the Magma tape-out count", but
> wouldn't let me publish his 2 sentence letter even anonymously.
>
> - from DAC 02 #16
From: Simon Matthews <simon@paxonet.com>
Hi, John,
You can now publish this -- including my name/company.
Add one more to the Magma tape-out count. Exclusively Magma from netlist to
GDS. 2M gates plus 1.2M bits of memory. 600K placeable instances. All run
flat -- either on Dual-Xeon Linux boxes or Sun Solaris (we ran 32-bit
programs on Sun, not 64-bit versions).
More info: we used Blast Fusion and Blast Noise. Most of the work was
performed by engineers who had never used P&R tools before. Our time from
final netlist to tapeout was 51 days, of which 18 days were DRC/LVS/IR drop.
Integration of noise analysis/repair into the router is a huge improvement
over the post-processing and repair techniques from other vendors. This
saved many weeks of time.
- Simon Matthews
Paxonet
( ESNUG 400 Item 5 ) --------------------------------------------- [10/10/02]
From: Joe Gilray <jg@cvs.agilent.com>
Subject: User Openly Wonders "Is This PhysOpt 2002.05 Laughing At Me?"
Hi, John,
For those PhysOpt 2002.05 users having a long day, on an empty design try
typing 'plot_design' at the psyn_shell prompt for some relief.
- Joe Gilray
Agilent Technologies Corvallis, OR
( ESNUG 400 Item 6 ) --------------------------------------------- [10/10/02]
Subject: ( DAC 02 #27 ) Six Users Spank Cooley For Not Covering Denali Well
> "Best: Denali's party again was a raging college bash. Pleasent change
> from the typical DAC parties... Everyone from CEO's to engineers were
> there out on the dance floor jamming to the 70's dance tunes of Disco
> Inferno. Gets better every year."
>
> - Sean W. Smith of Cisco Systems
From: Rakesh Mehta <rakesh_mehta@ltx.com>
John,
I'm curious as to why you didn't have much technical coverage on Denali.
- Rakesh Mehta
LTX
---- ---- ---- ---- ---- ---- ----
From: Neil Yang <neil.l.yang@intel.com>
Hi John,
I would be interested in more information on Denali. We're currently using
their memory modeling suite in our design project and have been successful
with their advanced verification sw. (We've taped out A0 silicon for about
5 months and still have not had any showstopper bugs.)
- Neil Yang
Intel
---- ---- ---- ---- ---- ---- ----
From: Yong Wang <yong.wang@artilemicro.com>
Hi, John,
Read your DAC report, outstanding job in provide information and user
experience/feedbacks on all these new tools.
Denali Software asked me to give you my feedback on their behavior. I
think Denali is providing valuable services and you should probably give
them some coverage on their IPs.
We are currently using Denali's memory models and DDR memory controller.
From our experience, their memory model provided a significant amount of
help for our verification effort by providing complete checks on memory
protocols while retaining good run-time performance. Their DDR controller
is one of the best among the ones we have evaluated, in terms of
performance, testablility and support.
Their customer support is outstanding. Integrating their IPs into our
design and system verification environment was a very good experience.
- Yong Wang
Artile Micro
---- ---- ---- ---- ---- ---- ----
From: King Luk <king.luk@hp.com>
John,
How about some coverage of Denali for their memory controller IP in the
DAC trip report?
We've been using the Denali's Databahn memory controller IP to interface
to a DDR SDRAM. Our current project will run the controller at 200 MHz
with DDR400 RAM at .13u process.
Here are my experiences with the Denali controller, having been using it
in two projects:
- responsive to enhancement requests. This has been an important
area for us as our application is based more on random memory
accesses (for table lookup) whereas the Denali controller initially
was optimized towards sequential accesses (for CPU centric
applications). So we've requested Denali to add auto-precharge
and other features to cut down on latency and improve upon
utilization. Our requests have been implemented since then.
- The web interface used to specify the controller is intuitive and
easy to use. The response time from specification to delivery
is generally quick (~1 week)
- There were some coding practices in their source code that we don't
quite feel comfortable with. Though they most likely will synthesize
fine, but might cause simulation/synthesis mismatches... Like the
use of #delay in synthesizable code... Some of the code has been
changed based on our feedback since then. But the #delay is still
in our current release. Good thing is that they make the #delay
as `define, so I usually just set it to empty to remove the #delay
when I run simulation.
To sum it up, though initially there are some shortcomings to the Denali
controller, it has since been fixed and we are very satisfied with Denali
as our supplier of memory controller IP based primarily on their flexible
and responsive support to our requests on enhancements and fixes.
- King Luk
HP Roseville
---- ---- ---- ---- ---- ---- ----
From: Daniel Abate <dabate@mc.com>
Hi, John,
I do not see any mention of Denali other than that they had the "Best
Party". You can do better than that! I would of like to hear your
impressions and that of DAC attendees on their products.
We use Denali memory models to verify our systems and they have found pretty
wide acceptance within our group. We use their backdoor mechanism on
"system defined memories" to close our verifications loop. We also like the
sparse memory model & the ability to inject errors to test our controllers.
The down side to their later NT releases (3.0) is that the System view
pureview GUI has a ways to go before I would consider it good. The
simulation database approach may be good in the long run but the performance
is not very good when you want to look at database files that are large.
I also do not care for how large the history file can get when doing long
simulations. In general I like the tool and it is easy to integrate.
- Dan Abate
Mercury Computers
---- ---- ---- ---- ---- ---- ----
From: Kaushik Patel <kaushik@azanda.com>
Hi John,
Great DAC report... you missed Denali though!
We are having great success with the Data Bahn controller in our optical
networking SAR & Traffic Manager product. Our chip using the Denali memory
controller is fully functional at speed in first silicon. We met our
performance target -- our memory interface runs at 200MHz 64 bits DDR. This
is an outstanding result for first silicon. Denali support started off slow
at the first, however, as our product development progressed, both quality
of technical support and turnaround time on issues was outstanding. Based
on the success with the 1st generation Data Bahn, we plan to use Denali
memory controllers in our next product.
- Kaushik Patel
Azanda Network Devices
( ESNUG 400 Item 7 ) --------------------------------------------- [10/10/02]
From: Craig Taniguchi <craig.taniguchi@trw.com>
Subject: Huh? PrimeTime 2001.08-SP1 On HPUX Differs From Linux/Solaris??
Hi John,
Our team is trying to close on timing analysis (using PrimeTime) with our
ASIC vendor on our post-route netlist. We are using PrimeTime 2001.08-SP1.
Our vendor is running Linux and Solaris and gettings the same results on
either platform. Here running on HPUX we get different violators from
the vendor using the same constraints and scripts. We also checked the
violators using the following commands:
1. report_analysis_coverage ......
2. report_timing -delay_type min ......
3. report_constraints -all_violators -verbose ....
All commands show that we have 34 hold violations and they are all the same.
But our ASIC vendor running the same scripts reports zero hold time
violations running under Linux and Solaris. Does anyone know of any reason
why there would be discreprencies across platforms?
- Craig Taniguchi
TRW
( ESNUG 400 Item 8 ) --------------------------------------------- [10/10/02]
Subject: ( DAC 02 #24 ) Reason Behind Pallab's Neolinear Comments Questioned
> "ADA's 'Genius' products seem to be far ahead of Neolinear's NeoCircuit.
> The Neolinear products are stuck with just the Cadence simulator, and
> ADA can use multiple 3rd party simulators; so you can plug in different
> engines like Silvaco/Mentor/etc in addition to Cadence. The Neolinear
> tool can not handle as many variables and process corneers as ADA's so
> their transistor sizer is a bit limited for trying to do design
> re-targeting to 130 nm and 90 nm flows with a lot of process options.
> ADA's tradeoff analyzer, I think it is called "IP Explorer" (do not
> quite remember) is a lot more robust and easier to use than the one in
> NeoCircuit -- since you can light up the tool and get around in it
> faster -- it is also faster to pick a good result from faster."
>
> - Pallab Chatterjee of SiliconMap
From: Jeff Flieder <jflieder@neolinear.com>
Hi, John,
I read your DAC report today and wanted to respond to Pallab Chatterjee's
review of ADA's Genius product vs. Neolinear's NeoCircuit product. It is
apparent to me that Pallab has not seen NeoCircuit in quite some time (and
never used NeoCircuit). Knowing you as well as I do, John, and your
insistence on accuracy, I'd like to post a response to Pallab Chatterjees's
posting. He is very closely connected with ADA, as you can see from the
"partners" section on ADA's web site. The information in his DAC report is
grossly inaccurate and obviously from ADA's marketing dept.
Pallab mentions that NeoCircuit is limited to only Cadence's simulators, and
this is simply not true. NeoCircuit supports Spectre from Cadence, but also
Synopsys' HSpice, Mentor's Eldo, and proprietary simulators. In addition,
our NeoCircuit-RF product, which is targeted to higher frequency RF design,
supports Cadence's SpectreRF and ADS from Agilent. It is also possible for a
customer to request support for their in-house simulation environment. For
example, NeoCircuit is integrated with Infineon's Titan simulator. These
are integrated with an API that is probably similar to ADA's approach.
Pallab also contends that ADA's tools can handle a design with more process
corners and variables that NeoCircuit. We have successfully sized designs
with upwards of 50 design variables, and there is no limit on the number of
corners that can be specified.
I'm not going to bother to comment on the robustness and ease of use issue
between the two tools other than to say that many companies use NeoCircuit
in production and find the UI extremely robust and intuitive to use.
We have, & continue to have, significant success at many types of companies
in various industries, including RF designs, that Pallab mentions at the end
his review.
- Jeff Flieder
Neolinear, Inc.
( ESNUG 400 Item 9 ) --------------------------------------------- [10/10/02]
Subject: ( DAC 02 #15 ) User Claims Magma Picks Up Where Monterey Falls Off
> Nobody took them seriously. Then about 3 months ago, I started receiving
> a number of detailed Monterey user letters. ESNUG 396 #2 and ESNUG 397 #6
> had 2 Infineon, 2 Canon, and 2 Zoran tape-outs. Below you'll find 5 more
> tape-outs or near tape-outs from users responding to my DAC survey.
>
> - from DAC 02 #15
From: [ A Known Magma User ]
John,
Keep me anon on this one.
Many of the issues for Monterey are resolved in Magma. Here are some items
from the Monterey section of your DAC report and my comments:
"I don't know any other tool which includes "useful
skew" except celestry's ClockWise other than Dolphin."
Magma does useful skew, very effectively.
"A lot of Dolphin steps (e.g. placement, max-trans optimization,
setup-opt, CTS, hold-opt etc.) are bundled in "macro-commands".
(For example, their all encompassing command: "run".)"
Magma includes "run" commands. But each one is a script that can be
modified, or individual commands run separately. In Magma, one can use TCL
to build up custom commands, tweak the database, etc. It is very flexible.
"Dolphin CTS does not provide a whole lot of control on insertion-
delay. We had a scenario where there was a block that received a
late clock, and CTS needed to really reduce the insertion delay,
even at the expense of worsening the skew a tiny bit. But we could
not find a way to do that."
One can control the insertion delay of clocks to individual FFs in Magma or
one can choose to control only the insertion delay of the boundary FFs and
let Magma use useful skew to meet all the internal FF-to-FF timings.
"Monterey does not have Linux port yet."
If you want to run on the fastest platforms, you have to be on Linux. Magma
mostly develops on Linux and ports to other platforms.
- [ A Known Magma User ]
( ESNUG 400 Item 10 ) -------------------------------------------- [10/10/02]
Subject: ( DAC 02 #16 ) User Claims Magma Picks Up Where PhysOpt Falls Off
> I went digging & found out that the last time anyone anywhere had written
> about Magma as a user (outside of the controlled environment of a press
> release) was 15 months ago in ESNUG 374 #7. Huh? I've found lots of
> PhysOpt/PKS/Dolphin chat going on in that timeframe. Even Incentia
> (ESNUG 394 #14) and Sequence (ESNUG 399 #7) have had more user discussion
> than Magma has over that past 15 months!
>
> - from DAC 02 #16
From: [ A Different Known Magma User ]
John,
Sorry, we Magma users don't have time to respond to you. We're busy using
their tool to get our chips out, and scripting everything up in their open
database -- rather than relying on a promise of a common, open database to
be available for "preferred customers" in Q2 next year and ready for general
release sometime in the Q4 timeframe. :)
I'm sorry if its a plus that PhysOpt users have so much free time on their
hands due to their long run times, to write nice DAC wrap ups, or if
Apollo/Astro users are so disappointed in their tool (or worried about
their tool's future) that they actually used DAC to go look around at the
competitors. I used my DAC to meet with Magma's R&D, and didn't have a need
to go look at other place and route tools or do a comparison.
Ok, I admit I didn't spend ALL DAC talking with Magma R&D. It was New
Orleans, and I had to take in the culture a little... in the form of
Hurricanes and Hand Grenades. BTW, if any of your readers could tell me
how to make my own Hand Grenade, it would be greatly appreciated for our
next tapeout party.
(Keep me anonymous if you quote me.)
- [ A Different Known Magma User ]
( ESNUG 400 Item 11 ) -------------------------------------------- [10/10/02]
Subject: ( DAC 02 #9 ) Three Users Defend Innologic's ESP-CV Symbolic Tool
> "Innologic sells a PLI that will turn your ordinary Verilog simulator
> into a symbolic simulator and can also add formal verification
> capability. In addition to signals taking on values of "0", "1", "X"
> or "Z" they can take on any arbitrary string as a value. If you have
> an AND gate and the inputs are "0" and "1", the output is "0", just
> like an ordinary simulator. If the inputs are "A" and "1", the output
> is "A". If the inputs are "A" and "B", the output is "A&B". If you
> have a lot of symbols, signal values can turn into big, ugly equations,
> which can get uglier with each new clock cycle. They say their formal
> verification tool will give you the simplest possible example of how
> an erroneous value can occur. They say they use very clever BDDs to
> allow signals to take on really big equations as values, but if you use
> enough different symbols for enough clocks the tool will run out of
> steam. Note however that since you are checking for all possible
> values of the pins with symbolic values on them, your simulation may be
> much shorter to effectively check your design."
>
> - John Weiland of Intrinsix
From: Mayank Gupta <mgupta@shromila.com>
Hi John,
We used the ESP-CV tool from Innologic quite extensively in my past company.
I wanted to offer a slightly different opinion of Innologic's ESP-CV tool
than what was said by John Weiland of Intrinsix:
1. ESP-CV does not turn your existing "Verilog simulator into a symbolic
simulator", but includes a symbolic simulator as part of the tool.
This is a plus as it does not "occupy" a typically constrained resource
such as Verilog simulator.
2. I agree, ESP-CV will run out of steam if you run "enough different
symbols for enough clocks". But the whole idea is to NOT run enough
clocks. Most datapath designs that we did were verifyable in 4
symbolic clocks + ~4 binary setup (fast). A few went to ~8 symbolic
cycles. In reality, I even had one design run ~1M cycle because it
had a unique sequential architecture.
3a. I used the Innologic ESP-CV tool for equivalency checking between
RTL (behavioral Verilog) and gate level (Verilog netlist) for full
custom 64-bit superscaler microprocessor with large on-chip caches.
We broke the design into ~12 functional datapaths and another ~12
associated control blocks. In our methodology, at the "floorplan"
block level the RTL (Verilog) implementation must match identically
to the "hand-drawn" custom logic (schematic capture). We verified
each of the above datapath blocks in both RTL and gate level netlist
using Innologic as a equivalency checker. We did the same for
synthesized control blocks, too. The only difference was that we
had to run more cycles to get adequate coverage. The control blocks
required more cycles due to sequential state machines while the
datapaths were generally straight forward.
3b. The other application for this tool was as a regression everytime
RTL or gate level changed for timing, resizing gates, LVS related
changes etc. etc. This regression was very effective as it would
pinpoint the erroneous change in minutes as opposed to hours of
functional vectors.
4. Usability: The tool is easy to use once you understand the purpose
and application of this tool. To start out we got a tutorial of the
tool. We used the default testbench generation feature to put together
the shell and that typically took care of ~75% of the manual tedious
work. For people who do cut and paste style editing it is quite easy
from that point to put together the rest of it. Next the designer
(knowledgeable person) goes in and puts the appropriate reset and
operating constraints. In reality, this should be very small for
properly coded RTL. The rest the tool takes care of it. In the final
stage, the circuit implementor simply generates a gatelevel netlist and
"checks-out" the RTL and testbench and types one command and gets
"Pass/Fail" indicator. I should also point out the "Failing Test
Vector" in binary verilog or VCD dump is produced for the failing case.
It literaly is a few cycles of simulation pinpointing the failure.
Personally, I am quite sold on the concept and simulation capability of this
tool as a equivalency checker. We found a number of bugs in the design at
block level that would have taken a lot longer to find on a full chip level.
Circuit designers actually prefer this tool for verifying initial design and
all changes. Also, since the setup and run is a lot simpler, it is even
preferred over formal verification.
- Mayank Gupta
Shromila
---- ---- ---- ---- ---- ---- ----
From: Jason Su <Jason_Su@pmc-sierra.com>
John,
As a circuit designer using Innologic's ESP for 2 years and recently having
a successful tapeout on a MIPS microprocessor, I see clearly what the
confusion and fear are in the mind of John Weiland of Intrinsix. Confusion
about what a symbolic simulator really is, and fear of new things. If you
first understand there are 4 basic types of verifications: SPICE, Verilog
or VHDL, Formal Verification (such as Chrysalis, Verplex, etc.), and
Symbolic; and what we do with each:
1. SPICE: analog simulation is accurate on devices but not on systems
due to drastic simplification often required to be made on the models;
its limited capacity and speed make it inappropriate for serving as a
logic verification tool for even a typical RAM design (even with the
most modification and simplification).
2. Verilog/VHDL: binary digital simulator for logic verification which
doesn't require high coverage, or CPU time isn't an issue.
3. Formal Verification: a tool to guarantee 100% coverage, if everything
in the design is straightforward like static logic; otherwise, like
SPICE, manipulations such as attribute labeling, black-boxing, etc.
are required. This is where you lose your coverage.
4. Symbolic: just like "2" having the coverage of "3" w/o manipulations.
So it does sound like what John Weiland said, "turn your ordinary Verilog
simulator into a symbolic simulator and can also add formal verification",
is not quite true. Symbolic simulation is no formal verification tool. It
is a simulator which makes covering all cases possible (especially with its
hierarchical compression).
- Jason Su
PMC-Sierra
---- ---- ---- ---- ---- ---- ----
From: Dennis Yau <dyau@t-ram.com>
Dear John,
It is quite interesting to read those comments on Innologic tools. From
my experience, I think it's more a front-end tool for the back-end
designers. I have been using ESP-CV from InnoLogic in my current company.
We used it for equivalence checking of our SPICE netlist against our RTL
model for the full custom design blocks including register files, memories,
caches and etc. ESP-CV requires very minimum logic modeling effort for
custom designed blocks. Most of the net-lists from schematic can just
directly go to the flow, for circuit designers who usually are
uncomfortable with modeling that is a big plus.
- Dennis Yau
T-Ram, Inc. San Jose, CA
( ESNUG 400 Item 12 ) -------------------------------------------- [10/10/02]
From: Rahm Shastry <rahm@tharas.com>
Subject: ( DAC 02 #12 ) Tharas Rebutts The Anonymous User Comment About It
Hello John,
Please allow me to respond to the statement made by "an Anon Engineer" in
DAC'02 Trip Report (http://www.deepchip.com/items/dac02-12.html): you
published last week. The comments were as follows
"Moving on to Tharas (a small upstart that seems to be teetering on
going under) they have a HW accelerator, but no SW simulator. Thus
they have to rely on VCS or NC-Verilog to run, and they have to use
the links to PLI through NC-Verilog and VCS. Seems akward. They
also have their own ASIC, and thus are stuck with re-design to improve
speed and scale and performance. Tharas cannot deal with certain
design constructs like latches, and they are also a cycle-based
simulator."
- [ An Anon Engineer ]
a) "a small upstart that seems to be teetering on going under":
Judging from our Q3 02 revenue, we are far from going under -- we have
booked record revenues this quarter and have added marquee customers such as
Sun, Adaptec, Matsushita, and Rohm among others in 2002 alone!
b) "they have a HW accelerator, but no SW simulator. Thus they have to rely
on VCS or NC-Verilog to run, and they have to use the links to PLI through
NC-Verilog and VCS. Seems akward.":
This is intentional, John! Think about it -- why should a startup develop
and offer its own s/w simulator when VCS and NC-Verilog together have 90+%
of marketshare. We believe offering a competing s/w simulator is a liability
to a startup, not necessarily an asset. We focus only on hardware
accelerators -- not emulators or s/w simulators.
c) "They also have their own ASIC, and thus are stuck with re-design to
improve speed and scale and performance":
Having your own ASIC means, you can now offer a price/performance that is
unmatched by FPGA-based implementations. This is why, our offering is 1/3rd
the cost of an equivalent FPGA-based system. No wonder in the current "Capex
crunch" environment, we are winning accounts over prohibitively priced
FPGA-based offerings. Not to mention the long compile times and capacity
constraints (due to Rent's rule), one experiences with FPGA-based systems.
This is why Quickturn, the pioneer in acceleration/emulation systems has
moved away from FPGA-based systems.
d) "Tharas cannot deal with certain design constructs like latches, and they
are also a cycle-based simulator".
Tharas handles latch-based designs. We are *not* a cycle-based simulator. We
handle gated clocks, multiple clocks, asynchronous cycles and system calls
(such as $display).
I look forward to the rebuttal in your next installment of ESNUG & DeepChip.
- Rahm Shastry
Tharas Systems Santa Clara, CA
( ESNUG 400 Item 13 ) -------------------------------------------- [10/10/02]
From: Milan Bhatt <milan.c.bhatt@intel.com>
Subject: How Can I Get UNIX-like Shell Capabilities Inside Synopsys Tools?
Hi John,
I've been working with Design Compiler for a while now and I've noticed
that the Synopsys shell is lacking all the great features that are usually
present in the UNIX shell (ie, command/path completion, up arrow/down arrow
history, etc.) I've found a lot of Perl/TCL wrappers that add these
features, but I'd like to find something that works directly inside the
tool. I'd like to avoid wrappers since they tend to get messy.
So mostly I'm looking for either a TCL script that allows UNIX shell like
features after its been sourced, or to have Synopsys support this natively
within the tool. Do you know of any scripts that can be sourced to give you
these capabilities or have you heard anything about when Synopsys is going
to have native support for this in the tool?
I found a tclreadline module that allows me to get those Shell capabilities.
The problem is that I can't read in the compiled module since Synopsys has
disabled the TCL "load" command.
Know of any way to turn on the TCL load command? :)
- Milan Bhatt
Intel
( ESNUG 400 Item 14 ) -------------------------------------------- [10/10/02]
Subject: Wall Street Analysts Should Read The Merrill Lynch SNPS Report
> If you have a couple minutes, I attended the Synopsys Wall St. analyst
> conference last week. It was rather boring, but would like to compare
> notes w/ you.
>
> - Cliff Conwell
> EnTrust Capital New York, NY
From: John Cooley <jcooley@theworld.com>
Cliff,
I generally have no problem talking with you Wall Street types, but I'd
like to suggest that you somehow get your hands on the Oct. 8th 2002
Merrill Lynch write up on the SNPS analyst's conference. It's by Jay
Vleeschhouwer. Out of all the summaries I've read, Jay's was the best
one around that summarized the issues facing Synopsys and Cadence, plus
he didn't have any of the usual glaring errors I typically find in
analyst's reports.
- John Cooley
the ESNUG guy
( ESNUG 400 Item 15 ) -------------------------------------------- [10/10/02]
From: Steve Golson <sgolson@trilobyte.com>
Subject: Golson's Comparison Of Formality vs. Chrysalis Design VERIFYer
Hi, John,
I've been using formal verification for about a year to verify some very
extensive ECOs being made to a multi-million gate netlist. (More on that
later; I plan on writing a SNUG paper about the methodology.)
We started out using Chrysalis Design VERIFYer, which was subsequently
acquired by Avanti and recently by Synopsys. I was able to use Synopsys' own
formal verification tool Formality to re-run some of this work. What follows
is a summary of my experience with the two tools. I've got some critical
comparisons, and some suggestions for improvements.
I used many versions of Design VERIFYer; most recently all my work has been
with the current version v2001.3.
All my Formality work has been with 2002.05.
1. Formality has much easier setup than Design VERIFYer. The GUI and "flow"
methodology was pretty intuitive and made it easy to get started.
(Caveat: it probably helped that I was already an experienced Design VERIFYer
user, and understood a lot of the fundamental issues with equivalence
checking.)
2. Formality has a *much* nicer schematic display. It looks similar to
Design Vision.
3. Formality has nicer Tcl scripting.
4. Formality matching uses syntax stolen from "sed" which allows you to
easily try it out before running the tool (and without consuming a license).
Nice!
5. Design VERIFYer schematic window splits vertically as well as
horizontally. Also there are buttons to turn off each A/B view
independently. Very nice when you are just poking around in one netlist.
6. In the Formality schematic, when you roll over an object, the pin name
should appear. (And when you click on it.)
7. When Formality shows a failing pattern, it doesn't do a very good job
showing equivalent nets. You need to show the mapping somehow. Design
VERIFYer does a good job displaying all the logically equivalent names for a
signal.
8. Formality set_equivalence should work on pins. Also need to allow
set_invert on pins and nets. I suppose I should just use
create_cutpoint_blackbox and turn all my pins into ports.
9. In Formality when you click the GUI button "3. Setup" button, you aren't
automatically in Setup mode. At first I thought this was a bug, but now I'm
convinced it's a feature. Here's a great explanation from a Formality
specialist at Synopsys:
This is designed to save new users (or harried experienced users, or user
who are just dumb as posts like me) from themselves. One of the really
nice things about Formality is that it allows the user to iterate through
the major steps without repeating a lot of computation. The best example
is the compare point matching stage. If Formality were unable to fully
match the designs and you needed to give it help, then after giving it that
help once you hit the run matching button the tool will only operate on the
subset of points that were unmatched.
The way Formality used to work and the way I think Design VERIFYer works
today, if you need to give the tool some help once you matched again the
tool would start the entire matching process from scratch. A waste of CPU
cycles for one thing. In some cases people got in trouble that way. Let's
say they were not as good with SED as they thought they were. The SED rule
they applied may have farther reaching affects than planned and caused some
points to misalign. The odds of that are greatly reduced if the rule only
impacts the subset of unmatched points. Another great benefit is that it
allows for optional automatic matching techniques to be applied with
greater success (greatly minimizing the need to ever write a SED rule).
There is an optional algorithm that matches based on the best subset set of
a name. Sometimes the best subset match is not the right match (that is
why it is optional). With the iterative approach this can be turned on
after the first matching has been attempted, therefor it is only working on
the subset of unmatched points, thus greatly improving the odds that the
best match is the right match.
OK so iterative matching is a cool thing, what does that have to do with
the setup button that won't put me in setup mode? Well, changing setup
variables changes the ground rules for matching, making the matching
results invalid. If you revert to setup mode we have to dump the matching
data and start from scratch again. Since you are throwing away good work
we want to be sure that is really what you want to do. Sometimes people
want to go to the setup screen just to check on the setup variables, not to
change them. By making you forcibly put us in set up mode (by typing setup
or punching the "revert to setup" button on the setup screen) we allow you
check without throwing away the matching info. Make sense? In a flow where
you end up going back to setup to change things this seems a bit clunky at
first, but it enables us to implement iterative steps that greatly
facilitate verification in the normal flow of things.
Did I use the word greatly enough in that explanation?
10. Formality sometimes takes several minutes to exit after the
"Thank you for using Formality (R)!"
message. This is weird. I can't figure out what it's doing. Formality
generates a work area and deletes it after its finished (the FM_WORK
subdirectory) so maybe that's what is going on. Very strange.
11. Formality uses signature analysis to help figure out signals that match
in the two netlists. This is cool! It can make matching very simple, as you
don't have to specify every little flop equivalence.
12. When Formality shows failing sim patterns, it should show the pin name as
well as the instance name. Sometimes it's QN rather than Q, and having the
pin name makes it much easier to understand what's going on.
13. Design VERIFYer displays a *VERY* nice comparison of internal nets in rtl
mode! For example, here's a snippet from a Design VERIFYer log_verify file:
Equivalence #3787 - The two groups are equivalent.
-> NSB +1 17258 A.$371
+1 17258 A.make_it_idle
+1 5324 B.n15216
-1 13346 B.n15221
-1 13346 B.X14130.Z
-> NSB +1 5324 B.X14251.Z
So now I know that my internal rtl signal "make_it_idle" appears on netlist
wire "n15216" and an inverted version on "n15221". This is great when you
are trying to hack in a gate-level ECO.
Formality doesn't seem to do this (at least I never figured out how).
Perhaps this is because VERIFYer often splits logic cones on non-state point
boundaries (NSB) while Formality mostly uses state points (i.e. flops). From
the Design VERIFYer manual:
Non-State Boundaries (NSBs) are intermediate pseudo-statepoints that are
occasionally used within a logic cone to help manage comparisons between
usually large logic cones.
My Synopsys specialist tells me:
On the topic of splitting things on non-state boundaries, Formality can do
that also. It happens under the hood sometimes for the same reason noted
in the Design VERIFYer manual (making large cones more manageable). As the
user you can also insert this points in the cone if you want to. What you
are doing is inserting a single input/single output black box in the logic
cone (create_cutpoint_blackbox is the command if memory serves). Perhaps
there is some additional reporting we can do in cases where we have done
this under the hood and therefor know something about the equivalence (or
non equivalence) of the various subcones.
It would be interesting to see if Design VERIFYer splits things into more
NSBs than Formality (i.e. does Formality tend to have larger logic cones).
14. Design VERIFYer requires separate "build" and "verify" steps. This
requires two different licenses (normally you get one of each). This allows
you to parallelize your work (you can build on one machine while you compare
on another). Very nice.
15. Formality allows you to quickly and easily check just one output, and
ignore all the rest. You can do this in Design VERIFYer, but it's painful.
16. Formality can read synthesis .db libraries directly, while Design
VERIFYer has to read your sim models. This adds some time and complexity to
the Design VERIFYer runs. "But wait!" you say. What if there is a bug in
the synth library? Well, simply do a comparison of the two libraries first,
then you know that both representations are equivalent. Or you can always
have Formality read the sim libs rather than the .db library. (Reading cell
models on demand can sometimes be more efficient than read in the whole lib
as you have to do with .db libs.) Formality has this cool "-vcs" option where
it can use the same command-line syntax as VCS for specifying files,
libraries, directories, etc.
This brings me to the old canard "Formality shares code with Design
Compiler". Maybe this was true a long time ago (back when the earth was
still cooling), but is no more. The *important* and *critical* code is
separate. Separate development, separate people.
Nevertheless I think that it is a *good* thing if *some* of the code is the
same: I like having the schematic display look like Design Vision, for
example. Also being able to read .db files is great. (The paranoid among us
can do a library verification against your sim models to be sure.)
Finally, here's a head-to-head comparison of both tools on a variety of
netlists. These are all gate-to-gate equivalence checks.
All runs were done with 32-bit executables under Solaris 8 running on a
750MHz Sun Blade 1000. The CPU time for Design VERIFYer is the sum of the
two build runs plus the verify run.
The following designs are all structurally identical. Design VERIFYer's
name-based compare mode was used. Even for rather large designs the runs
only take a few minutes. Design VERIFYer is consistently faster than
Formality, and also requires less memory. It appears that Design VERIFYer's
name-based algorithm is much more efficient than Formality's algorithm.
DV = Design VERIFYer
FM = Formality
CPU time memory swap
(hours) (Mbytes) (Mbytes)
Design Cells Flops DV FM DV FM DV FM
--------------------------------------------------------------
M5 100143 20261 0.1 0.2 411 938 449 964
M8 89507 13128 0.1 0.2 339 897 380 923
M9 86373 13989 0.1 0.2 369 1105 409 1131
M11 81557 11798 0.1 0.2 291 1116 314 1142
M12 75459 11751 0.1 0.1 261 896 291 921
M14 73636 7745 0.1 0.2 245 1076 273 1101
M18 58860 6891 0.1 0.1 223 879 263 904
M20 46704 10065 0.1 0.1 195 865 235 890
M21 46704 10065 0.1 0.2 202 1055 243 1080
M24 38041 6224 0.1 0.1 174 868 214 893
M26 35213 5111 0.1 0.1 155 859 196 884
M27 32116 5804 0.1 0.2 242 1064 252 1090
M28 31356 6422 0.1 0.1 160 858 201 883
M29 31258 5859 0.1 0.1 155 858 196 883
M34 27740 4120 0.0 0.2 76 1047 86 1072
M35 26894 5033 0.0 0.1 120 859 131 883
M39 26558 3079 0.1 0.1 169 1047 179 1072
M40 25834 2913 0.0 0.1 92 1047 102 1072
M41 25260 4146 0.1 0.1 130 1047 170 1072
M44 20754 4455 0.0 0.1 100 859 110 884
M45 20221 4877 0.0 0.1 71 1047 81 1072
M46 17341 3083 0.0 0.1 67 1048 77 1073
M47 16914 1259 0.0 0.1 53 1048 64 1073
M48 15467 2979 0.0 0.1 16 859 27 884
M49 15056 2977 0.0 0.1 69 859 79 884
M50 15056 2977 0.0 0.1 80 859 91 884
M51 11674 1783 0.0 0.1 16 859 27 884
M52 9767 1143 0.0 0.1 48 1048 58 1073
M53 7019 1293 0.0 0.1 16 859 27 884
M55 4330 864 0.0 0.1 29 1048 39 1073
M56 4189 575 0.0 0.1 16 860 27 884
M57 2883 388 0.0 0.1 16 860 27 884
M58 2529 428 0.0 0.1 16 1048 27 1073
M60 1178 205 0.0 0.1 16 1048 27 1073
M61 517 0 0.0 0.1 16 859 27 884
M62 510 0 0.0 0.1 16 1048 27 1073
M63 343 0 0.0 0.1 16 1048 27 1073
The following designs are structurally different, requiring much more
computation. Design VERIFYer was run in "rtl" mode.
CPU time memory swap
(hours) (Mbytes) (Mbytes)
Design Cells Flops DV FM DV FM DV FM
--------------------------------------------------------------
M1 1282859 165728 --- 3.9 -- 2287 -- 2622
M2 1026971 157077 --- 1.4 -- 1670 -- 1819
M3 108025 16890 202.2* 0.6 1036 1286 1088 1315
M4 104761 10388 3.0 0.3 1153 1188 1192 1216
M6 91340 7403 12.9 0.4 1132 1073 1170 1105
M7 90412 13862 19.5 1.0 1259 1178 1303 1207
M10 84832 9167 0.8 0.2 943 1152 983 1181
M13 73829 5920 0.2 0.2 445 1123 485 1148
M15 71201 9339 3.8 0.2 611 917 651 943
M16 66820 5927 3.7 0.3 1021 1254 1058 1283
M17 64583 7592 4.9 0.1 828 883 867 908
M19 47202 7346 0.1 0.2 297 1060 335 1085
M22 43428 6569 0.2 0.2 392 1058 432 1083
M23 38342 5785 1.0 0.2 1241 1068 1281 1093
M25 35337 4748 2.9 0.5 736 1126 775 1154
M30 30390 2811 0.2 0.1 233 898 272 922
M31 29165 4298 0.4 0.2 356 867 394 892
M32 28405 5275 0.1 0.1 262 887 300 912
M33 28281 3911 0.6 0.2 348 920 387 946
M36 26878 2652 1.1 0.2 986 1047 1025 1072
M37 26780 0 --- 0.6 -- 1145 -- 1174
M38 26780 0 --- 0.7 -- 1145 -- 1174
M42 21116 3833 0.1 0.1 268 860 307 884
M43 20768 2967 0.1 0.1 146 859 187 884
M54 5912 729 0.0 0.1 17 859 27 884
M59 1423 393 0.0 0.1 16 1048 27 1073
* Design M3 did not successfully complete when run under Design VERIFYer
(some endpoints had "timeouts"). I was unable to resolve this problem. Note
that Formality was able to complete this design in under an hour.
Designs M37 and M38 never completed when run under Design VERIFYer (I killed
it after 531 hours). Designs M1 and M2 were not attempted under Design
VERIFYer.
However Formality had no problem with any of the designs, even the largest
which has over 1.2 million instances. The Formality run time is much much
less than Design VERIFYer, with all runs (except the largest) taking under an
hour.
In short, Formality capacity is outstanding. It handles multi-million gate
designs with ease.
Memory usage is similar betweeen the two tools.
Notice that the size of the design (number of cells, number of flops) is
*not* a perfect predictor of how long the run will take. As always, your
mileage may vary. The underlying complexity of the design has a huge impact
on the ability of the tool to successfully complete.
My hope is that now that Synopsys owns both Design VERIFYer and Formality,
the strengths of each will be combined into one really outstanding formal
verification tool.
- Steve Golson
Trilobyte Systems Carlisle, MA
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 14,488 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
|
|
