( ESNUG 348 Item 2 ) --------------------------------------------- [3/30/00]
Subject: ( ESNUG 344 #6 ) Well, We Found Verisity's Specman Worth Learning
> There is no question that the approach Vera and Specman pursue has quite
> a number of benefits depending on the application. However, testbench
> designers would have to undergo the painful process of learning a new
> language and mastering new semantics. Having managed this, one can't be
> sure of the alleged benefits for a reasonable amount of time. In the
> seemingly un-stoppable advent of high-level design and SoC, design
> verification methodology will very probably change quite soon causing the
> adoption effort not to pay off. Also, the semantics of those proprietary
> languages (Vera, Specman, QuickBench) are quite ambiguous w.r.t. timing
> compared to well understood HDLs like Verilog or VHDL.
>
> I'd be glad to hear in ESNUG from other designers their opinion about
> standard versus proprietary testbench languages. We don't think they're
> cost effective.
>
> - Ernst Bernard
> Siemens AG Munich, Germany
From: Onn Haran <onnh@ti.com>
Hi John,
I must disagree w/ Ernst. I can share some of my experience using Specman:
I have started using Specman one year ago, by managing the verification team
for a complex SoC design. Yes, I did fear from a new environment. I was
surprised to see that even at the ramp up period, with partial knowledge,
the test environment was built much faster than it would have been with VHDL
code.
What I discovered is that very fast you reach a level that passes the
coverage from the VHDL test bench. Now our effort is spent on system
testing. The level of testing that I have reached with Specman is
incomparable to anything I've done in the past, and in much less time.
I must mention that during the lab verification tests before production only
1% of the bugs were found from VHDL simulation, the remaining 99% were found
by the Specman. After production not a single bug was found.
I also used Specman for block level verification, and again the results were
amazing.
The benefit of Specman over VHDL is not the GUI. It is the flexible
language that allows high level description of the behavior of the DUT.
It's generation and analysis are very fast and efficient, much more than
anything that you can write with VHDL. You can do the comparison by
yourself: write and debug 100 lines of C++ code and write the same
functionality in VHDL. See for yourself what is faster and more efficient.
With one thing I agree with Ernst: the engineer that writes Specman should
be much better than the one that writes VHDL. With Specman, a high level
system view is required, and not every engineer is capable for that. But if
these engineers are available, then use them for Specman!
- Onn Haran
Texas Instruments Israel
---- ---- ---- ---- ---- ---- ----
From: Hans-Juergen Brand <hans-juergen.brand@amd.com>
Hi John,
Just some quick comments about the opinion Ernst raised in his email. I
have been using Specman for different projects (for communications and
more PC related applications) at AMD for around two years.
So far I have seen this to be a big time saver reducing the effort for
developing the RTL simulation environment and increasing the quality of
the design. What are the reasons for that?
If you use HDL testbenches you have to develop all functions for data
generation, checking and coverage by yourself. So basically every company
develops its own "Specman-tool". By using Specman you can really focus on
defining and coding of the test scenarios rather than worrying about basic
verification functions and let the verification engineers do what they were
hired for -- verifying the design and not to develop yet another proprietary
verification tool. So they have much more time left for understanding the
system functionality and writing more comprehensive test cases for improving
the functional coverage of your simulation.
Besides that, the e-language incorporates features you can not find in C or
any of the HDLs (like handling of parallel threads & temporal expressions).
Concerning the learning process for a new language/tool, I have not seen
any major issues so far -- as long as they take training (and having C
background is very helpful.) Within the last year, 6-7 people with varied
levels of experience (new-grad up to 10 years in industry) joined our
system-level verification team. Almost all of them started working and
coding with Specman already after 2-3 weeks before their first training.
Many of them had a VHDL background and we are working in Verilog. I would
expect that VHDL-to-Verilog transition to be more troubling for them.
In our current project we are moving to a unique environment for block and
system level verification. This improved the communication between the
design and the verification team. After seeing the benefits of Specman most
of the designers stopped writing their own Verilog testbenches and used
Specman based environments instead. Since Specman sits "on top" of our
conventional Verilog simulation environment and can handle C-models as well,
it provides a framework for all verification issues. Specmen incorporates
Verilog know-how instead of replacing it. Moreover we found the Specman
co-verification link (cvl) we very useful, too.
- Hans-Juergen Brand
AMD Saxony Manufacturing GmbH Dresden, Germany
---- ---- ---- ---- ---- ---- ----
From: Lior Storfer <slior@ti.com>
John,
Ernst's comments below take me be back in time around 2 years.
We had quite similar debates internally on the best means to verify complex
digital designs. After going through internal debates we decided to bet on
Verisity's Specman tool. We do not regret that decision for a minute.
But I absolutely agree with Ernst on the switching costs. It is not trivial
to switch. It is somewhat like switching from design using schematic capture
to using a HDL language. The learning curve is there. But, is there still
anyone desinging complex chips using schematic capture?
As to the pseudo-random based approach of the Verisity tool, it has proven
to be a winning approach for us. Though Specman is random based, you can
control the randomness as you wish. By using the Generators, Coverage tools
and Checkers one can easily direct the simulations to hit on the soft spots
of his design.
- Lior Storfer
Texas Instruments - Cable Broadband Communications
|
|
