( ESNUG 339 Item 10 ) -------------------------------------------- [1/13/00]
Subject: Users Say Why Verisity's Specman Is Eating Synopsys VERA's Lunch
> "Brilliant" was the word that Dataquest analyst Gary Smith used. It was 18
> months ago and he was reacting to the news that Synopsys had just bought
> System Science for $26 million. ...
>
> VERA's biggest rival, a language called "e" from an in-your-face Israeli
> start-up named "Verisity", is eating Synopsys' lunch in that market.
> According to Dataquest, in 1997, Verisity had 84 percent and VERA had 16
> percent of that $7.5 million market. In 1998, after the world wide Synopsys
> marketing army had ownership of VERA, VERA grew to 19 percent of that now
> $13.5 million market. It's been 18 months now. We won't have the 1999
> Dataquest numbers for another 9 months, but as the ESNUG moderator I know
> should have been seeing all sorts of customer e-mails about VERA by now.
> Remember, we're talking 2 to 4 verification engineers for every chip
> designer. And I know there are quite a few verification engineers on ESNUG
> (you get a *lot* of different types when you have 10,000 subscribers) yet
> there's *no* discussion of VERA whatsoever??? What up here??? Yup, it's
> probably some world class Synopsys marketing incompetence at work here.
From: Miroslav Pokorni <mpokorni@camintonn.com>
Dear John:
What you are trying to do, embarrass Gary Smith? These analyst clowns
get tested for their reaction to being held accountable for past 'analyses';
if any sensitivity is found, a frontal lobotomy is performed to make the
individual a suitable employee of a market analyses company.
Way back in early 80s, when I began to get involved in ATE PCB testing, what
is arguably contemporary equivalent of today's ASICs, automatic test
generation was already a hot topic for several years. Everyone was talking
about doing it, but no one delivered. At one of ATE conferences, a well
respected consultant in ATE field, whose name escapes me now, asked why is
it that ATE industry is the last one to believe in Automatic Program
Generation. If you are old enough, you must remember that in 70s and 80s
there was lot of talk about computer generated code; nothing came out of it,
except for Microsoft's code and we do not want to dwell on that disaster.
- Miroslav Pokorni
Camintonn
---- ---- ---- ---- ---- ---- ----
From: Evyatar Hadar <ehadar@lucent.com>
Dear John,
My name is Evyatar Hadar. I work at Lucent Israel as an ASIC Verification
team leader. Our main tool is Verisity's Specman and we're working with it
since December 1995.
After seeing your "VERA Fiasco" article, I thought I'd forward you a letter
I sent ~2 years ago regarding the Verisity/Specman tool. The guy who sent
me the detailed questionnaire worked at Lucent. He sent the questions
before Lucent acquired us. Since then, all issues mentioned just got
better.
- Evyatar Hadar
ASIC Verification Team Leader
Lucent Technologies Tel-Aviv, Israel
From: [ Evyatar Hadar ]
To: [ Shrikant Nilakhe ]
Dear Shrikant Nilakhe,
Following are my responses to your inquiry regarding "Specman" and
"Verisity". All of it is my own private opinion. I'm working with
Specman for more than 2 years so I managed to gather quite a lot of
experience as our Specman's focal point.
> 1. What's your general opinion of SPECMAN?
SPECMAN is a great tool and platform to work with. Its capabilities and
its flexibility make it a powerful engine, by which you can pass your
verification environment through a steep step function successfully by
enhancing its performance and coverage dramatically.
> 2. Are you a VHDL or Verilog shop?
We're Verilog users.
> 3. How big are the device's you normally do?
Around 300 KGates (excluding SRAMs).
> 4. Did SPECMAN cut down on the time verification took?
SPECMAN cut down on the time verification took significantly. It can be
measured in various aspects:
- the time it took to ramp up a working verification environment in
terms of headcount and work weeks. It includes planning,
implementing and integrating of generators, drivers and verifiers.
- the time it took to debug it.
- the time it took to enhance it on the fly.
- the time it took to maintain it.
- the time it took to generate extraordinary test cases.
- the time it took to find coverage holes and cover them.
All the above should be compared to other alternatives. Comparing to
implementation with Verilog, C Code and PLI between them, the time it
took was reduced by 40-60% more or less.
> 5. Did it improve the quality of your verification?
Absolutely, since it enabled us to generate extraordinary test cases
relatively easily and fast. We managed to perform much more verification
checks at the given time, covering more "design corners" than we might
do otherwise.
> 6. Did it do BOTH?
As I wrote above - it did both.
> 7. Are you happy with the support you've gotten?
I was very happy with the support I got in the past. It was a pure "red
carpet" treatment. These days I have to share Verisity's experts time
with many other customers (some of them are stronger, bigger and more
eager for support than me), so I lost my unique position. The level of
support we get now is sufficient.
> 8. What's your opinion on the learning curve?
>
> i. experienced engineers?
It should be a fast steep learning curve.
> ii. not-so experienced?
It might be a slow learning curve due to the complexity of the platform.
> iii. pure hardware folks vs engineers w/ alot of software experience.
Engineers with a lot of software experience would probably have a faster
and steeper learning curve than pure hardware folks. Yet - the "pure
hardware folks" (as myself) would probably create a more Hardware oriented
code than the SW folks, thereby fitting it better to the Hardware
requirements, make it simpler and easier to debug and to port.
> iv. are the engineers getting into the object orientation?
It takes a while until the object orientation perception is well
understood, and then - it runs pretty fast.
> 9. How much of a problem was it for everyone on the team to embrace it?
At first the whole idea sounded like a huge overhead. Then, after getting
some "live shows" with examples and templates to adopt and modify, it was
embraced pretty fast.
It depends on your model of work to what extent the team should embrace
it. There are some models of work in which the levels of controlling this
tool and mastering its complex features might vary a lot between team
members. In these cases you need few experts, whereas all the rest might
be a low level Specman users.
> 10. After a month of use, did engineers perception change? How?
The engineers' perception changed a lot, since they saw directly the
impressive performance, capabilities and results of using the tool. As
they used it more and more, it became easier to control it and get more
out of it.
> 11. How many SPECMAN bugs have you found?
We were Beta site of SPECMAN (we started using it more than 2 years ago).
We found many bugs. All of them were fixed pretty fast. The platform
you see now is much more cleaner than the one we saw and used.
> 12. What it's the biggest advantage? What's your favorite feature?
The flexibility and the modular and dynamic built-up of the verification
environment is the biggest advantage I can see.
My favorite feature is the capability to create Verilog's internal full
path names using variables as part of the strings. You don't have this
feature in Verilog and it costs a lot of time, code length and readability
as well as debug time.
SPECMAN's people focuses on the RANDOM GENERATOR capabilities of the tool,
yet I personally focuses on the deterministic tests. In most cases it
depends on the design style and the type of application in which it should
work. So, in other cases this might be regarded as the biggest advantage.
In my case I see other advantages.
> 13. What it's biggest disadvantage? What would you change if you could?
The biggest disadvantage I can see is the complexity of the "e" language.
It takes its time to master it. Yet - if it wasn't this way - I wouldn't
use it at all, since it then wouldn't be rich enough in capabilities.
Paying this price for the benefits of the tool is quite reasonable.
In our case I would like to have more bit and byte manipulations.
> 14. How did you evaluate it? (maybe: How long did try it before buying)?
Due to a manpower shortage we allocated only 2 people for a few weeks. We
managed to finish the task within 3-4 weeks replacing existing Verilog
generator and verifier models with SPECMAN code and making sure we get the
same results.
> 15. Did you slowly phase the tool in or flash cut it. Are all your
> engineers using it or is there mix?
We slowly phased the tool in. It depends on maturity of current projects
within the company, since some of them might be in a point, where it might
be too late to use it.
Not all our engineers are using the tool. There's a mix and there are
many levels of expertise.
> 16. Is it used at all the different levels? (block, chip, multichip)
Absolutely !
> Any other things we should know about the Verisity ?
The people there are highly motivated. I really enjoy working with them!
---- ---- ---- ---- ---- ---- ----
From: [ STMicroelectronics ]
John,
We have a purchasing agreement with Synopsys for a package of tools which
happens to include Vera, however in the last six months the license has
been checked out a total of 12 times. Even though we have access to the
tool, the "marketing" of the product within our own company is nil. <anon>
- [ STMicroelectronics ]
---- ---- ---- ---- ---- ---- ----
From: "Ihab Mansour" <ihab.mansour@intel.com>
John, FYI,
We have been using Vera here for more than 2 years by now. At the time we
evaluated Verisity "e" also, and decided to go with Vera. Vera is doing a
great job for us with minor to negligible problems.
- Ihab Mansour
Intel San Diego, CA
---- ---- ---- ---- ---- ---- ----
> Functional testing is ugly, mind-numbing, labor-intensive work. At OVI'98,
> Jack Harding (then the CEO of Cadence) said in his keynote: "Our customers
> tell us 25 to 75 percent of their time is spent in verification." Another
> design engineer later e-mailed me: "Glen Dearth of Sun Microsystems said
> in his OVI paper that they have a 4:1 ratio of verifiers to designers. I
> heard another speaker claim a 2:1 ratio. A friend at Compaq said they were
> probably 1:1 but growing." Four months after that, Al Sibert of Nortel
> said at DAC'98: "Staffing is 2:1 of verification engineers to designers."
From: Jim Mott <James.Mott@Eng.Sun.COM>
Hi John,
You mis-spelled Glenn Dearth's first name. (It has two n's).
Our west coast ASIC group has a little over 3 to 1 for verification vs.
design engineers, but we'd like to have more verification. It's daunting to
realize after 18 months of 24/7 simulation on dozens of machines, that the
actual device has (potentially) run more cases than verification did within
the first few minutes after its initial power on.
- Jim Mott
Sun Microsystems
---- ---- ---- ---- ---- ---- ----
From: Glenn Dearth <gdearth@simplicity.East.Sun.COM>
Hi John,
I would like to make a small correction to your article. You have someone
quoting me as saying: "Glen Dearth of Sun Microsystems said in his OVI paper
that they have a 4:1 ratio of verifiers to designers..." This is not
correct. What I said was that there is perhaps a 3:1, maybe even as high
as 4:1 ratio of verification code to design code. This ratio takes into
account all environment code, test code and process scripts. Although, at
times I wish there was a 4:1 ratio of verifiers to designers I have not
seen this ratio in Sun. Thanks.
- Glenn Dearth
Sun Microsystems
---- ---- ---- ---- ---- ---- ----
From: Allan Silburt <asilburt@cisco.com>
For the record, its Allan Silburt. Formerly of Nortel. I left for a
startup last year and we were later acquired by Cisco. So, now I'm at Cisco.
And... we've used Vera on two projects in a row over the past 2 years at 3
companies. Good product. But if I had my choice, which I never seem to,
I'd still like to see a good industrial strength 'C' based environment. I
don't like proprietary languages.
- Allan Silburt
Cisco Systems Kanata, Ontario, Canada
---- ---- ---- ---- ---- ---- ----
From: Sean Ogle <sean@pixelcam.com>
John,
What are you talking about "Design Engineers" vs. "Verification Engineers".
I've never heard of a company where design engineers don't also do
verification. Most companies don't have the luxury of having purely
Verification people. System emulation is the only answer to verification.
Don't believe the fantasy that some software tool will magically take away
all the hard work.
- Sean Ogle
PixelCam Campbell, CA
---- ---- ---- ---- ---- ---- ----
From: [ Shaken, Not Stirred ]
John, Keep my name out of this...
I think it is simply that Sysnopsys does not understand verification as a
business. They may have a few switched on dudes in eng/apps, but at senior
level they have no idea. Take, for example, the Arkos fiasco. When they
dumped that technology they also dumped a number of verification savvy
people either by choice or by accident.
- [ Shaken, Not Stirred ]
---- ---- ---- ---- ---- ---- ----
From: [ Luck Favors The Ready ]
John,
Please keep me anonymous.
Man did you ever hit the nail on the head with that story. We contacted
Synopsys several times over the last year about working with Vera. We are
a large Synopsys customer and we get good-to-great support for most of
their tools, but they basically blew us off when it came to Vera. Guess
what tool we're ramping up on now?
- [ Luck Favors The Ready ]
|
|
