Editor's Note: In the spirit of HDL International, Ron Collett and I are
exchanging "colorful" growls below in Item 16. Enjoy! - John
( ESNUG 316 Subjects ) --------------------------------------------- [4/8/99]
Item 1 : Concern That Valid Paths Get Defined As Bogus False Paths
Item 2 : (ESNUG 315 #7) hdlin_use_cin Works With Verilog But Not VHDL
Item 3 : Transmission Gates In Our Libs Ruin Our Fault coverage !!!
Item 4 : (ESNUG 313 #15) Need Olde VLSI Tech VGT350 Synopsys Libraries
Item 5 : Design Compiler 99.05 Tutorials Coming To A City Near You Now !
Item 6 : Gimicky Synopsys Support "Fatal Hunt" Searches Are Waste Of Time
Item 7 : Problem Needing Lots Of Temp FlexLM Licences For Y2K EDA Testing
Item 8 : (ESNUG 313 #13) Hidden Synopsys Variables Are Very Dangerous
Item 9 : CiscoFSM Not For Commercial Designs. Are There Any Similar Tools?
Item 10 : (ESNUG 313 #10) Analog Phase-Locked Loops In Verilog
Item 11 : Back-annotation On Verilog-XL Is Very Slow Compared To VCS
Item 12 : Where Can I Get Copies Of The SNUG'99 Conference Presentations?
Item 13 : (ESNUG 313 #14) Installing Synopsys 98.08 Messes Up 98.02 Access!
Item 14 : (ESNUG 313 #1) Wall Street Curious About Altera/Synopsys Deal
Item 15 : Problems Piping VCS Output -- STDout Is Not A Standard Output !
Item 16 : (ESNUG 315 #1) Collett Defends His VHDL Record; Cooley Rebutts
( ESNUG 316 Item 1 ) ----------------------------------------------- [4/8/99]
From: d_pinvidic@qlc.com (Dan Pinvidic)
Subject: Concern That Valid Paths Get Defined As Bogus False Paths
Hi John,
First off, I want to Thank You for your time & effort in running ESNUG.
I would like to raise a question for discussion relating to Static Timing
analysis and Synthesis.
Is anyone doing anything to "Verify" their "False_Path" defines are correct?
We are concerned that "Valid Paths" may get defined as "False" during timing
analysis and synthesis but may, in fact, be a valid path.
Proposed solution:
For each defined false path, the designer could create a "Path Check" block
for use during netlist simulation. These "Path Check" blocks could be
contained in a single module that is at the testbench level.
Rather than show the code, I'll describe the function of "Path Check"
ff1 ff2
----- invalid path --------- -----
|D Q|______________| |____________|D Q|
| | | | | |
CK __| | | MISC | CK __| |
----- | LOGIC | -----
| |
Valid Path ____| |
| |
---------
Verify that when ff1/Q changes state, that ff2/Q does NOT change
state on the following clock. Also verify that ff1/Q has toggled
to show that the test excited the source of the false path.
I am also curious of some companies simply add gates (synchronizers, staging
registers, etc) to remove the violations from these paths (they use the
simple rule of "No False paths - anywhere").
Thanks in advance to all who take the time to ponder this question.
- Dan Pinvidic
Qlogic Corp.
( ESNUG 316 Item 2 ) ----------------------------------------------- [4/8/99]
Subject: ( ESNUG 315 #7 ) hdlin_use_cin Works With Verilog But Not VHDL
> I read the post about using the switch hdlin_use_cin = true. Could you
> ask [ Kenny from South Park ] to post an example design that shows a
> post-synthesis failure? I've been teaching people in the Synopsys
> Advanced Verilog classes for the past 2 years to use this switch and to
> add it to their .synopsys_dc.setup file, because of the remarkable
> improvement that this switch causes to the size and speed of arithmetic
> logic designs. ... Looking at Kenny's description, I tried to recreate
> a failure but without success. ...
>
> - Cliff Cummings
> Sunburst Design Beaverton, OR
From: [ Kenny from South Park ]
John,
The "hdl_use_cin" bug is Synopsys "star" id 67812. I filed it under logid
78563 with Synopsys.
It appears to be a VHDL Compiler bug, because it does not exist in the
Verilog Compiler. (I noticed it when I was doing something "funky" with
variables in a VHDL process statment.)
I can e-mail you the test case I sent to Synopsys, but it's pretty involved
VHDL code.
- [ Kenny from South Park ]
( ESNUG 316 Item 3 ) ----------------------------------------------- [4/8/99]
From: NUKALA RAVIKANTH <ravikanth@msemi.com>
Subject: Transmission Gates In Our Libs Ruin Our Fault coverage !!!
Hello, John,
We're facing a Design-For-Test problem.
In our library we have some MUXes made of transmission gates. We manually
instantiate these cells in our datapath for fast timing. For example, we
have a cell DSEL4, which has 4 i/ps, 4 selects and 1 output. We always have
a decoder in front of such MUXes for the select lines. (Actually in our
design, the selects for the MUXes are not decoded. So using a decoder, we
generate fully decoded selects which drive the pass gate selects.)
So we assure that, ONE and ONLY ONE of the selects is ON at any given time.
Now my problem is the stuck-at faults at the select pins of these pass gates
are untestable. So, can I do something to make them testable??? I would
also like to know the best way to model them in Synopsys. Right now they're
modelled as bufif.
We have many such cells in the design and the fault coverage reduction is
required is huge. So, we can't neglect them.
Please, help!!!
- Nukala Ravikanth
Meridian semiconductor
( ESNUG 316 Item 4 ) ----------------------------------------------- [4/8/99]
Subject: ( ESNUG 313 #15 ) Need Olde VLSI Tech VGT350 Synopsys Libraries
> Does somebody have Synopsys lib (core + symbol) for VLSI 1um gate array
> technology(VGT350)? Actually, I have them but when I try to do a link
> it gives lots of LINK-1 and LINK-5 messages. It seems that the library &
> netlist have different names for every pin of every cell. I verified the
> netlist with the databook, it's correct. Then I made report_lib and I got
> the message that library is corrupted. If anybody can provide me working
> version of this libraries, it will help a lot.
>
> - Baris Aksoy
> Alcatel-USA
From: walter_strickler@stortek.com ( Walter Strickler )
John,
VLSI has never changed the name of "every pin of every cell" (at least
not in my 10 years of dealing with them). What they did do, 8 or 9 years
ago, was change from upper case pin names to lower case pin names. Synopsys
is complaining about this because it's case-sensitive. Even VLSI's latest
databooks show uppercase pin names, so yes, they'll agree with your netlist.
Baris' best bet would be to downcase the pin names in the netlist.
- Walt Strickler
Storage Technology Corp
( ESNUG 316 Item 5 ) ----------------------------------------------- [4/8/99]
Subject: Design Compiler 99.05 Tutorials Coming To A City Near You Now !
From: [ Synopsys DC Tech Support ]
John,
We're trying to promote attendance at this years DC'99 tutorials. Last year,
the DC'98 update was very popular with the customer base. I would appreciate
it if you could pass on the word. There should be a tutorial coming to a
city near you. IMPORTANT: YOU MUST SIGN UP *BEFORE* ATTENDING ANY OF THESE
TUTORIALS. (Seating is limited.) http://www.synopsys.com/dc99_tutorial1
All tutorials start at 8:30 AM.
Santa Clara, CA - April 6
The DC 99 Tutorial will be held in the Santa Clara Ballroom of the
Westin Hotel.
Westin Hotel
5101 Great America Parkway
Santa Clara, CA 95054
Irvine/Costa Mesa, CA - April 8
The DC 99 Tutorial will be held in the Santa Ana Room of the Westin
Hotel.
Westin Hotel
686 Anton Blvd.
Costa Mesa, CA
Denver, CO - April 13
The Inverness Hotel & Golf Club
200 Inverness Drive West, 1-25 & Dry Creek Road
Englewood, Colorado 80112
Dallas, TX - April 15
Hyatt Regency
300 Reunion Blvd.
Dallas, TX 75207
Mineapolis, MN - April 20
Doubletree Minneapolis Airport at the Mall
7901 24 th Ave South
Bloomington, MN 35425
Boston, MA - April 22
The DC 99 Tutorial will be held in the Westford Ballroom at the
Western Regency.
Westford Regency
219 Littleton Rd
Westford, MA 01886
Ottawa, Canada - April 27
Corel Centre
1000 Palladium Drive, Suite 1259
Kanata, Ontario K2V 1A4
Los Angeles, CA - May 4
Warner Center Marriott
21850 Oxnard Street
Woodland Hills, CA
Somerset, NJ - May 4
The DC 99 Tutorial will be held in the Salon A and B of the
Marriott Somerset.
Marriott Hotel in Somerset
110 Davidson Ave
Somerset, NJ 08873
San Diego, CA - May 6
Del Mar Hilton
15575 Jimmy Durante Blvd
Del Mar, CA
Orlando, FL - May 6
The DC 99 Tutorial will be held in the Lime Room of the Marriott
Orlando.
Marriott Orlando
8001 International Drive
Orlando, FL 32819
Austin, TX - May 11
The DC99 Tutorial will be held in the Oaks Room of the OMNI Austin
Hotel Southpark.
OMNI Austin Hotel Southpark
4140 Governor's Row
Austin, TX 78744
Atlanta, GA - May 11
Marriott Gwinnett Place
1775 Pleasant Hill Road
Duluth, GA 30096
Research Triangle Park, NC - May 13
Holiday Inn Page Road
RALEIGH-DURHAM ARPT, NC
4810 New Page Rd. PO Box 13816
Research Triangle Park, NC 27709
John, I remember your commenting on the fact that most customers are using
antiquated scripts and methodologies (not to mention versions) and this is
a great way to get a lot of information all at once.
- [ Synopsys DC Tech Support ]
( ESNUG 316 Item 6 ) ----------------------------------------------- [4/8/99]
From: busco@taec.toshiba.com (John Busco)
Subject: Gimicky Synopsys Support "Fatal Hunt" Searches Are Waste Of Time
Hi John,
I was wondering if it's just me, or does the DC Fatal Hunt search ever seem
to find anything?
When I'm using DC and it occasionally crashes, the program catches itself
and prints out several lines of cryptic debugging information. It instructs
me to mail this information into Synopsys Support Center, and a "fatal hunt
search mechanism" will see if it recognizes the problem and can send me a
solution.
I've tried this maybe ten times. Every time, I get back a response saying
"This is a new bug ... you need to send a testcase to support_center".
Most of the time, I've moved on and don't have the time and motivation to go
through all the hoops of creating a testcase. So, what I'm wondering is,
should I ever bother sending in the fatal search request unless I'm prepared
to follow it up with a testcase? Or have I just had bad luck, and others
get useful information back after sending in the fatal hunt data?
- John Busco
Toshiba
( ESNUG 316 Item 7 ) ----------------------------------------------- [4/8/99]
From: Andrew Frazer <Andy.Frazer@idt.com>
Subject: Problem Needing Lots Of Temp FlexLM Licences For Y2K EDA Testing
Hello John,
I'd like to hear what other EDA customers are doing about Y2K testing.
Here at IDT, we are being required to test every piece of software (both EDA
and non-EDA) under three conditions: 1999, 2000 & 2001. The problem that
I'm running in to is that in order to test software under these conditions
(i.e. resetting the system clock), I need temporary FlexLM license files
that are valid into 2000 and 2001.
That's not so bad, I just explain the problem to the vendor and ask for
a temporary license. The problem is that the EDA vendors are trying
to be helpful, but they claim that since no other customers are asking
for this, they don't have a system in place to fulfill this request, and
"we have to make a few calls", etc...
What is surprising to me is that all the other EDA customers don't seem
to be pushing for some basic level of Y2K testing. What's going on?
Is everyone else planning to trust that the vendor will take care of
it, or are you waiting until later in the year to do the testing?
- Andy Frazer
Integrated Device Technology Santa Clara, CA
( ESNUG 316 Item 8 ) ----------------------------------------------- [4/8/99]
Subject: ( ESNUG 313 #13 ) Hidden Synopsys Variables Are Very Dangerous
> Steve Hwang's post about finding hidden variables got me thinking. I went
> into mole mode and burrowed into dc_shell to see what I'd find. The
> result is the following list of undocumented variables and their default
> values, which might be useful. "Undocumented" here means that they exist
> when dc_shell starts up, but have no man page exists. ...
>
> - [ Bit Mole ]
From: [ A Senior Synopsys CAE ]
Hi John,
I am not going to reward the behavior of looking at strings by giving
detailed information about hidden variables. I just know some designers
like examples better than a general message saying hidden variables are
dangerous.
So lets take one of the LESS risky BC variables mentioned.
bc_use_old_group : false
Three years ago BC had a lot of problems with meeting timing after
compilation. After a lot of work and effort by the BC team we turned that
situation around about 1.5 years ago. Well one of the things we did was
fundamentally change how we group logic, internally to BC during timing
analysis, etc. By setting this variable to true you go back to the
previous grouping structure which will give you worse QOR, for most if
not all testcases. We kept this for backward compatibility but do not
recommend people to use it and hence it is hidden.
There are other switchs that may do worse things to your design than just
give you poor QOR.
- [ A Senior Synopsys CAE ]
( ESNUG 316 Item 9 ) ----------------------------------------------- [4/8/99]
From: Rajen Ramchandani <rajen@jaxom.eng.pko.dec.com>
Subject: CiscoFSM Not For Commercial Designs. Are There Any Similar Tools?
John,
I will be designing a couple of very big and complex state machines in our
next ASIC. I was planning on doing some paper design, i.e state diagrams
and then jumping in and coding Verilog. I was wondering if folks had any
suggestions for tools or techniques that can be used to ease the design
and especially the verification task.
I am aware of the free tool from Cisco that takes Cisco stylized Verilog and
generates bubble diagrams and helps in debug -- but the license agreement
says that this cannot be used for commercial products. Are there any other
tools that are worth looking into?
- Rajen Ramchandani
DEC / Compaq
( ESNUG 316 Item 10 ) ---------------------------------------------- [4/8/99]
Subject: ( ESNUG 313 #10 ) Analog Phase-Locked Loops In Verilog
> I am trying to build a Verilog model of an analog pll. Has anybody done
> this? It's suppose to have the same characteristics of a real analog pll
> including the loop-filter and Vco.
>
> My model is almost done, but I have control problems in some situations.
>
> Help is needed !!!
>
> - Doron Nisenbaum
> Chip Express (Israel) LTD. Haifa , Israel
From: "Bruce Loyer" <bloyer@bad.amd.com>
John,
I have worked with people trying to model an analog PLL in Verilog and
the results were not very good. Two problems come up besides the inherent
problems of doing analog in a digital situation.
One is that a true analog PLL will take quite a while (milliseconds) to
stabilize. You should see this if your doing an accurate simulation. No
one wants to wait a millisecond before beginning the rest of the system
simulating.
Second was that we had to make the timescale very small (much less than
one picosecond) to get good results. This slowed the entire system
simulation down to a crawl. We did not expect that with an event
simulator but it did happen.
This leads one to simulating the PLL separately and then feeding the results
(jitter, frequency wander, etc.) into the Verilog model. If you are going
to do this, you might as well simulate the PLL in spice and get more
accurate results. Good luck.
- Bruce Loyer
AMD
( ESNUG 316 Item 11 ) ---------------------------------------------- [4/8/99]
Subject: Back-annotation On Verilog-XL Is Very Slow Compared To VCS
> Has anyone found that for a given testbench, back-annotation an sdf file
> for a gate-level simulation in Verilog-XL takes MUCH longer than it does
> with VCS? (3-4 hours vs. 4 minutes respectively for one of my test
> benches). What's the reason for this? How does each tool perform back-
> annotation?
>
> At first, I thought that VCS wasn't performing back-annotation, but after
> throwing some deliberate "errors" in the netlist at VCS, it detected them.
>
> I changed the module type from a low-drive gate to a high-drive gate. I
> changed the instance name to something non-existent in the sdf file. Both
> changes were flagged by VCS. Can anyone offer any explanations?
>
> I'm using VCS v5.0 and Verilog v2.6.
>
> - Alfred Cheung
> Nortel Networks Ottawa, Ontario
From: Ashutosh Varma <ashu@axiscorp.com>
You may be using the compiled SDF feature of VCS, which may be default
now. In that case, the SDF file is read at compile time rather than at
run time.
- Ashutosh Varma
Axis Systems Sunnyvale, CA
---- ---- ---- ---- ---- ---- ----
From: Petter Gustad <pegu@dolphinics.no>
Also: Verilog-XL usually uses more memory than VCS. Maybe your XL
simulation exceed the amount of physical memory in your machine and
the VCS does not?
- Petter Gustad
Dolphinics Norway
( ESNUG 316 Item 12 ) ---------------------------------------------- [4/8/99]
From: Gary Conti <gconti@hns.com>
Subject: Where Can I Get Copies Of The SNUG'99 Conference Presentations?
John,
Are the presentations presented at SNUG avaiable in some form after
the conference?? I don't have time to go right now, but the three
presentations you pointed out sounded good!
"Automatic Clock Gating For Power Reduction"
by Zia Khan and Gaurav Mehta of Intel
"Power Optimization in the Real World: Do's and Don'ts for
System-On-Chip Designs"
by Mike Gladden of Motorola and Iandraneel Das of Synopsys
"New Clock Gating Feature in Power Compiler 1999.05"
by Roberto Zafalon of STMicroelectronics
Is this information available free, or at a cost from some contact?
I'd appreciate any information you have.
- Gary Conti
Hughes Network Systems
( ESNUG 316 Item 13 ) ---------------------------------------------- [4/8/99]
Subject: ( ESNUG 313 #14 ) Installing Synopsys 98.08 Messes Up 98.02 Access!
> we have a license server running on a unix host, currently 1998.02. we
> want to install 1998.08 software on a pc/nt system and have access to the
> unix license server over the network. we are told by our in-house people
> that upgrading the license server, on unix, to 1998.08 (necessary for pc/nt
> access) will disrupt 1998.02 software access. synopsys says it will work
> fine and suggests we do exactly that. does anyone have any experience that
> they can share?
>
> - Richard B. Katz
> NASA Goddard Space Flight Center Greenbelt, MD
From: Peter Kamphuis <kamphuis@hl.siemens.de>
John,
There shouldn't be a problem here. We've never seen problems since newer
licenses (higher version number) should always enable older software
(lower version number). Unless, of course, feature names change. Recently,
for example, we've received the 1999.05 licenses and we've noticed that
Designware-Developer now is called DW-Developer. We have two entries now
in our key file and we should not forget to request for both features
again when they would expire. So I would recommend to always check your
feature lines before installing new licenses.
- Peter Kamphuis
Siemens Semiconductor Group Munich, Germany
---- ---- ---- ---- ---- ---- ----
From: miller@symbol.com (Wayne Miller)
Hi John,
We're running versions from V3.5a to 1998.08 all from the same license
server. We also have a lone NT evaluator who pulls keys. We haven't
seen any problems, except for a wacky issue with the LM_LICENSE_FILE
variable and the order that the Synopsys and Xilinx keys are listed.
(Get it wrong, and 1998.08 won't pull keys.)
- Wayne Miller
Symbol Technologies, Inc.
---- ---- ---- ---- ---- ---- ----
From: Tom Hicks <thicks@fore.com>
John,
We seemed to have some trouble back in August when we installed 98.08.
However, we did a reinstallation (not sure whether we did this because of a
change in the update from Synopsys or because a sysadmin installed the
upgrade incorrectly), and we have been running fine with 99.5/98.08/98.02/97.
- Tom Hicks
FORE Systems Pittsburgh, PA
---- ---- ---- ---- ---- ---- ----
From: Rich Katz <rich.katz@gsfc.nasa.gov>
hi john,
here's the follow-up i got from synopsys on my problem.
From: [ The Synopsys R&D Licensing Team Manager ]
Dear Rich,
Thank you very much for your patience over the last six
months while we isolated and resolved the two licensing
environment variable issues reported in the 1998.08
release.
This letter is to inform you about these resolved issues with
the licensing variables used by Synopsys Design Tools Group's
products in release 1998.08 on all supported UNIX and Windows
NT platforms. These issues have been resolved in the
1998.08-B58544 release, the 1998.08 cluster release and the
1999.05 release and they have also been documented in detail
in the 1999.05 Release Notes and Installation User Guides,
the 1998.08-B58544 SOLV-IT! article (Sys_Admin-42.html),
and the 1998.08 cluster release notes.
In the 1998.08 release, Synopsys software looked for the license
key file(s) in the following order:
1. $LM_LICENSE_FILE,
2. $SYNOPSYS_KEY_FILE,
3. Synopsys default location ($SYNOPSYS/admin/license/key,
where $SYNOPSYS is set to the Synopsys root directory). In
addition, if $LM_LICENSE_FILE was defined, $SYNOPSYS_KEY_FILE and
the default license file were not acknowledged. With the solution
we implemented, the software now uses license files specified by
all 3 environment variables ($SYNOPSYS_KEY_FILE, $LM_LICENSE_FILE,
and $SYNOPSYS/admin/license/key) for the license keys.
In the 1998.08 release, there was a problem in our software
(STAR # 58944) that required the Synopsys key file to be
specified at the end of the list for either $SYNOPSYS_KEY_FILE
or $LM_LICENSE_FILE for customers who did not purchase the
DTG feature 'SNPS-CSL' for their license servers. With the
solution we implemented, the location of the Synopsys license
file within $SYNOPSYS_KEY_FILE or $LM_LICENSE_FILE is order
independent.
We apologize for the inconvenience caused by the licensing
issues in the 1998.08 release. We have addressed and resolved
these issues in the post-1998.08 releases and have implemented
new processes and improved testing to ensure that this type of
error does not occur again. We are excited about the licensing
infrastructure upgrades to our products that are planned for
release during the next 6 to 12 months.
- [ The Synopsys R&D Licensing Team Manager ]
hopes this helps any other esnug readers who ran into my bug, john.
- Richard B. Katz
NASA Goddard Space Flight Center Greenbelt, MD
( ESNUG 316 Item 14 ) ---------------------------------------------- [4/8/99]
Subject: ( ESNUG 313 #1 ) Wall Street Curious About Altera/Synopsys Deal
> I am a securities analyst covering semiconductors at J.P. Morgan, and I
> spend a fair bit of my time on Altera, Xilinx, Lattice, and LSI Logic.
> Somebody recently suggested to me that I would probably learn a lot from
> ESNUG. Is it as simple as just asking to be added to the mailing list?
> If so, please do. ... I'd like to develop some contacts among designers
> so that I have some live people that I can ask about things like ...
> Do you have any suggestions about how I might find such people?
>
> - Terry Ragsdale
> J.P. Morgan
From: miller@symbol.com (Wayne Miller)
Hi John,
I think this is a novel idea, but it scares me a little to think how much
impact a few negative words might have on a company's market capitalization.
Since ESNUG represents user feedback, I think the information should help
balance the sales and marketing pitches...
But keep on the lookout. This past year at the Cadence User's Conference
in Texas, I was surprised to see three Wall Street types sitting in on a
Deep Sub-Micron session. With buy/sell recommendations up for grabs, I
started to wonder how accurate and "investor unbiased" the information we
received really was. I applaud Cadence for keeping the marketing in check,
but now that Wall Street sits in on these conferences, I'm not sure there
is no "spit and polish" on more and more of what is being offered to the
customers.
- Wayne Miller
Symbol Technologies
---- ---- ---- ---- ---- ---- ----
From: "Terry Ragsdale" <ragsdale_terry@jpmorgan.com>
John,
First, thanks for the posting in ESNUG 313. I hadn't really expected to
see my words appear there verbatim, but I certainly like the results! The
response has been tremendous. In fact, I've been so buried that I haven't
even gotten around to responding to all of the people who contacted me
after seeing the post in ESNUG. This is called a high-class problem.
Second, Synopsys and Altera made an announcement a week or so ago that I
don't understand, and I wonder if you or others have a view on it. My
understanding is that Synopsys has agreed to add the PLD-specific synthesis
stuff in FPGA Express to its Design Compiler tool so that ASIC designers
can easily target PLDs without changing their normal design flow. I assume
that means that Altera PLDs (Flex 10K, Flex 6000, and APEX) appear as
target silicon choices (this may not be the term of art, but hopefully you
get the idea) within Design Compiler. This seems sensible and consistent
with the way that PLDs and synthesis tools have been headed for some time.
The part I don't understand is why Synopsys is doing this _exclusively_ for
Altera? Wouldn't it be wiser to keep Synopsys a general tool? Or tuned
for each of the FPGA vendors? Why an _exclusive_ deal w/ Altera?
- Terry Ragsdale
J.P. Morgan
( ESNUG 316 Item 15 ) ---------------------------------------------- [4/8/99]
From: Todd <todd@efi.com>
Subject: Problems Piping VCS Output -- STDout Is Not A Standard Output !
John,
I run vcs sim. Pipe it to tee. What do I get? Nothing output in the
shell!
Run any-other-program-in-the-history-of-unix. Pipe it to tee. You get?
Programs std output in shell.
How can I fix/work around this?
- Todd
Electronics For Imaging, Inc. Foster City, CA
( ESNUG 316 Item 16 ) ---------------------------------------------- [4/8/99]
Subject: ( ESNUG 315 #1 ) Collett Defends His VHDL Record; Cooley Rebutts
> Editor's Note: I just have one question, Cliff. I noticed you're citing
> Ron Collett in your letter. Is this the same Ron Collett who predicted
> the utter & grave demise of Verilog so many years ago? :) - John
From: Ron Collett <ronc@collett.com>
Hi John,
I write to you to clear up a misunderstanding regarding the issue of of
VHDL vs. Verilog. I periodically run across statements that you make that
are fundamentally inaccurate regarding projections that I made many years
ago regarding Verilog and VHDL. First, never did I predict the "demise"
of Verilog, as you have stated. This is well documented. I would be more
than happy to show you newsletters that I wrote in which I had predicted
co-existence, as well as my column in EE Times in May 1994 in which I
reiterated this. So it is patently false to say that I predicted VHDL would
displace Verilog. I would appreciate it if you would discontinue this
dissemination of false information.
Here is what actually occurred. I had always predicted that there would
be more VHDL users than Verilog users. This is absolutely true today.
That is, there are in fact more VHDL users than Verilog users -- however,
the revenue from EDA tools is heavily weighted toward Verilog (approx. 2:1).
Indeed, at one time I had thought that the revenue for VHDL-based tools
would significantly outstrip that of Verilog -- this was based on an
assumption that the average-selling prices of the VHDL-based tools would
parallel those of Verilog. This did not happen -- a half dozen EDA companies
ended up introducing VHDL simulators with practically no differentiation
among them, so the Average Selling Price of these products plunged. I
clearly missed this. It is always very challenging to predict the supply
side of the equation -- e.g. few people anticipated that today there would
be 10 physical library vendors offering similar libraries all competing for
the same business.
Anyway, the number of VHDL users worldwide today is in fact larger than
Verilog, but certainly not in the industry segments that were the first
users of Verilog (i.e. computer and semiconductor). For example, in the
communications industry it is split, and in most other industries it is
heavily weighted to VHDL (e.g. Defense/Aerospace, Industrial Control, Medical
Electronics, etc.). Europe of course is heavily VHDL. Part of our firm's
business is to have a firm quantatitive understanding of HDL language usage,
so we have collected enormous quantities of statistically valid data on
this.
In ESNUG 286 #1, Clay Degenhardt of System Science writes:
> Thought I'd pass along some thoughts after reading your article "From
> Beirut to Bosnia" posted on techweb.cmp.com as I was searching for
> references to Collett International (Ron Collett).
>
> Before coming to Systems Science, I worked for Zycad over 6 years. Ron
> was contracted and, as a stipulation, would speak to the company about his
> vision of the simulation-environment-of-the-future. Ron assuredly promoted
> the demise of Verilog in favor of the upcoming contender, VHDL. On that
> advice, Zycad's executives based the future of the company on a hardware
> engine (ViP) designed to digest raw VHDL in preparation to capture the VHDL
> market which was prophecized to take over by '96. Because of this huge R&D
> investment, Zycad was fatally crippled and by the time they backtracked to
> update the successful gate-level simulator (Paradigm XP, Lightspeed), they
> had already lost momentum and could no longer invest in the resources
> necessary to regain lost ground.
>
> After my first experience hearing Ron's presentation, I was always
> very skeptical of his market analysis. In 1996, it hit directly in my
> realm when he avoided the VHDL-versus-Verilog topic and began to harp on
> the demise of the workstation platform in favor of NT.
>
> - Clay Degenhardt
> Systems Science
As for the ex-Zycad guy last year that wrote to you regarding his opinion
about how I tanked Zycad because of my VHDL projection, it too was
completely inaccurate. I spoke to him about it. He apologized profusely.
I also mentioned it to a couple of ex-Zycad executives and they laughed.
They confirmed that if they were able to get their VHDL accelerator finished
on time and kept its performance 10X ahead of the general purpose
workstations, the product would have been very successful -- they would
have been able to sell it to ALL of the major VHDL user companies. I
believe this is true. The fact is that the problem was their inability to
create such a product. When I was providing Zycad with analyses, the
assumption was that they would be able to provide such a product.
Anyway, I will always accept responsiblity for the conclusions that I reach,
which is why my firm always provides our clients with all of the assumptions
in the models we develop. By doing this, our clients fully understand what
the models are based on, and they can formulate their own conclusions if
they wish. I would never represent that we are perfect, but having been
doing this now for quite some time, I have found most of our models and
analyses to yield accurate results.
Thank you for your consideration.
- Ron Collett
Collett International Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
Editor's Note: I'm going to do something I usually don't do, Ron. Since
we both buy ink by the barrel (i.e. we're both EE Times columnists and
we're both big boys capable of hearing public criticism of our ideas),
I'm going to rebut your letter here and now. Here goes.
Have you ever been involved in any political campaigns, Ron? You know,
writing catch phrases and doing spin control for your candidate when
they say a gaffe that loses votes?
When I read your letter above, to me, you appear to be attempting to put
a new spin on your role in the olde Verilog/VHDL wars. During the '91
to '95 timeframe, you were very active at many conferences and your
VHDL-Will-Beat-Verilog "data" was part of almost every non-Cadence EDA
vendor's presentation then. I remember sitting with Dan Pinvidic in the
first or second SNUG meeting eight or nine years ago wondering why in hell
we were seeing all the Synopsys synthesis examples given in VHDL. When
we balked, we were told your "data". I remember being at DACs, OVIs, and
VIUFs seeing your "data" in all sorts of EDA vendor pitches within that
timeframe. VIUF officers, like Hillel Ofek, would gleefully quote you.
And OVI officers, like Bill Fuchs, would very vociferously dispute your
"data", and how it was collected. Your VHDL-will-beat-Verilog prediction
was *everywhere*.
"Ofek, Smith and Collett agreed that Verilog is here to stay, but noted
that VHDL is growing much faster. Collett predicted that the VHDL and
Verilog simulation markets will be roughly equal in 1994, and that
toward the end of the decade, the HDL market will be around 60 percent
VHDL and 40 percent Verilog."
- from "Outsold by Verilog" by Richard Goering, EE Times, 5/2/94
"As a Dataquest analyst in 1991, Ron Collett, now president of Collett
International, predicted VHDL would overcome Verilog in revenues and
seats in 1992. Collett believes he's still right about seats, but he
said the revenue forecasts were thrown off by competitive price
pressures. "It would be a complete miscalculation to say Verilog is
eclipsing VHDL in terms of market adoption," Collett insisted."
- from "HDL Numbers In Dispute" by Richard Goering, EE Times, 2/5/96
NOTE: Goering says in 1991 you predicted "VHDL would overcome Verilog
in revenues and seats in 1992". *** THIS WAS MY KEY POINT. ***
When Gary Smith took your job at Dataquest, his initial essential "data"
(predictions) stayed the same with the moot point being exactly *when*
VHDL revenues would bypass Verilog revenues. (See pg. 41 of the 3/94
EE Times to see a revised Dataquest chart showing the "crossover point"
of VHDL sales beating Verilog sales "moved to 1995".)
You kept supporting the essence of your VHDL-will-prevail prediction even
when Viewlogic bought Chronologic.
"Viewlogic's acquisition is a good strategic move, in the view of
analyst Ron Collett, president of Collett Associates (Santa Clara,
Calif.). "All of our analyses indicate that the current Verilog user
base is remaining extremely loyal to Verilog," Collett said. "It makes
sense for an EDA vendor to offer a strong Verilog product portfolio."
Nonetheless, Collett said, "that doesn't change the fact that the vast
majority of new HDL adopters are going to VHDL at this point in time."
- from "Viewlogic To Acquire Chronologic" by Brian Fuller and Richard
Goering, EE Times, 4/4/94
I even quoted your VHDL-to-kill-Verilog prediction in an EE Times column.
"Back when he was a Dataquest analyst, Ron Collett of Collett
International made news by predicting that VHDL was going to beat
Verilog some time around 1992. Gary Smith of Dataquest also caused a
minor uproar when he claimed at the 1994 Design Automation Conference
that VHDL revenues were just starting to beat Verilog revenues and
that it would only get better for VHDL."
- from "From Beirut to Bosnia" by John Cooley, EE Times, 2/5/96
In my DAC'94 review that I wrote for EDN magazine, I even took a zing at
you for your VHDL-Uber-Verilog prediction.
"MOST PERSONALLY GRATIFYING DAC PANEL: The HDL Summit. Ron Collett
moderated six panelists ranging from Verilog bigots to people using
both to VHDL bigots. As usual, Collett tried to conclude the panel
with his spin that VHDL was where everyone was going, etc. Just to
annoy him, I pointed out how, years ago, a researcher at Dataquest had
made a now-embarrassing prediction that VHDL users would outnumber
Verilog in early '92; a prediction that turned out to be greatly
exaggerated. That Dataquest research-er was Ron Collett."
- from "DAC'94 & The Grateful Dead" by John Cooley, EDN, 7/7/94
The reason why I'm belaboring these points with public records, Ron, is
to show how you really were integral to the anti-Verilog movement at
that time. As an EDA user, your Verilog-Is-NOT-Where-It's-At "data" was
throw at us again and again and again in those years. While through some
legalist interpretation of your quotes and your letter above you may
*technically* be correct in that you did not predict the *absolute*
extinction of Verilog -- during that '91 to 94 timeframe, your quotes and
data gave me (and a lot of other engineers) the *impression* that we'd
be complete idiots to keep designing using Verilog.
A few days ago, Ron, I went through a McDonald's drive through. I ordered
two cheeseburgers and one hamburger at the speaker. When I drove to the
cashier (a pimply faced high school kid) I was given a Big Mac and fries.
When I told him about the mistake, he said: "Oops, I goofed! Got the
orders mixed up. Sorry, Sir. It's completely my mistake! Let me fix
that for you!". He completely owned his error.
And that kid probably makes a little over minimum wage.
How many millions are you worth, Ron? Multi-millions? And you're *now*
telling me: "First, never did I predict the 'demise' of Verilog, as you
have stated. This is well documented. ... So it is patently false to
say that I predicted VHDL would displace Verilog. I would appreciate it
if you would discontinue this dissemination of false information." Yet
all sorts of quotes clearly point out that "As a Dataquest analyst in
1991, Ron Collett, now president of Collett International, predicted VHDL
would overcome Verilog in revenues and seats in 1992." (Goering, 2/5/96)
And you won't simply just own this mistake. Instead it's equivocations,
very close legal readings ('demise' is not equal to 'overcome'), and the
likes.
This is sad, Ron, really sad.
- John Cooley
the ESNUG guy
|
|
