( DVcon 07 Item 9 ) --------------------------------------------- [ 04/24/07 ]
Subject: SystemC SCV and JEDA
SMALL POTATOES -- Back in the 2003 or 2004 time frame, Vera and "e" had two
upstart technical rivals that did close to what they did. The first was
something called JEDA and the second was SystemC SCV. Here's how they did.
2004 - "What about alternatives like JEDA or SystemC SCV?"
we use SystemC SCV : #### 9%
we use JEDA : # 1%
2005 - "How about alternatives like JEDA or SystemC SCV?"
SystemC SCV : ### 7%
JEDA : 0%
And here's the new 2007 data.
2007 - "Do you use alternatives like SystemC SCV? (Yes/No)"
Yes: ### 6.9%
No: ############################################### 93.1%
I didn't bother to ask about JEDA this time around because even the folks
from the old Jeda Technologies had bailed on their proprietary JEDA stuff
in order to promote their version of SystemC assertion tools.
Anyway, back to SystemC SCV -- judging from the numbers and comments, it
looks like it's still 6.9% small potatoes in the verification universe.
Yes, our testbenches are traditionally in SystemC. SCV is the
obvious choice for contrained random tests in a SystemC testbench.
- Greg Tumbush of AMI Semiconductor
Yes. Better integration with third party software such as Matlab.
- [ An Anon Engineer ]
No.
- Paul Davies of Cisco
Yes; Full flexibility, no license costs, easy SW integration
- [ An Anon Engineer ]
No. We have no need to system level modeling at this time.
- Dan Joyce of Hewlett-Packard
No
- Andreas Dieckmann of Siemens
no because designing small blocks
- [ An Anon Engineer ]
We used SystemC SCV on our last project, and we're using System Verilog
for verification on this project. We used these mostly because they
are free.
- Samir Patel of Tarari
No.
- Jonathon Rose of ATK
We decided to switch to SystemC/SCV a couple of years ago because
in the past we have been burned by vendors when we had our
verification IP stuck on a single vendor proprietary language.
With SystemC we have options that can allow us to switch EDA
vendors if they try to jack up the price.
- [ An Anon Engineer ]
Yes. It plays nicely with SystemC.
- Wilson Snyder of SiCortex
Yes, as Proof of concept, not production.
- [ An Anon Engineer ]
No. Have not seen the need.
- Premduth Vidyanandan of Xilinx
No. Specman is better known and has a bigger number (also inhouse)
of validation libraries.
- [ An Anon Engineer ]
We have legacy testbench built around C++.
- [ An Anon Engineer ]
No. We write many tests at system level in C++ using home grown
library routines.
- Marty Deneroff of D.E. Shaw
No. Our group is behind the curve in verification.
- [ An Anon Engineer ]
No. e fits our needs.
- Helmut Reinig of Infineon
No. Using Vera.
- [ An Anon Engineer ]
No, not convinced of it's usefulness.
- Bruce Meyer of L-3 Communications
No, no SystemC here.
- [ An Anon Engineer ]
No. Using System Verilog.
- Kishor Mistry of Gennum
No - We got used to using Vera after an in-house C++ dv tool,
and do not wish to go back. :)
- [ An Anon Engineer ]
No
- George Gorman of LSI
No, what we have works.
- [ An Anon Engineer ]
TestBuilder. Cost (free vs. $$$, also ability to fix any problem
ourselves since we have full source code).
- [ An Anon Engineer ]
Yes. Better widespread support from vendors. Free simulators if need
extra bandwidth. Fits in with system modeling (test harness can
be re-used). 'Really' object oriented (unlike SystemVerilog or 'e').
- [ An Anon Engineer ]
No. Why? Vera seems to do everything we want. Huge built up code
base internally ... hard to switch even if we wanted to.
- Andrew Peebles of Cortina Systems
We are looking at it since we are potentially going down the SystemC
path.
- [ An Anon Engineer ]
We looked at this, and felt it required too much infrastructure to get
to the same functionality that we had in "e". This may still be a good
option for groups that have dedicated tool groups.
- [ An Anon Engineer ]
No.
- Nathan Nipper of Harris
Yes - Jove (http://jove.sourceforge.net/)
SCV and alternatives will likely maintain their market share.
Wouldn't want to do a large, software intensive simulation
environment in System Verilog because of lack of software
development tools (e.g. Eclipse / GUI development environments),
and software libraries. Vera base will move to SV.
- Mark Davis of Newisys
Index
Next->Item
|
|
