I’m not quite sure if this question has been asked before but I’d like to hear what the opinion of the user group is. For verification of a SoC design, what are the pros and cons of using a C++/SystemC based method as opposed to SystemVerilog? I have about equal experience in C programming and VHDL so it’s going to require a certain amount of learning to get either approach up and running. But what I’m looking for is some opinions as to what people have found to work for them, what industry seems to be gravitating to, and perhaps additional resources that would give me a better defined reasons to pick one over the other.
Thanks,
Brian
#1 by robert on May 27, 2008 - 12:44 pm
Brian,
You ask an interesting if political question. Should one use SystemVerilog or C++?
In my mind it depends on many things. Personal preference/skill level. Team preference and experience, language choices of previous projects and the ammount of SW interaction with the system.
If I could build a team from scratch for a new project I would vote for Native C++ or (the upcomming) Teal/Truss SystemC port. I would not use SystemC by itself (for verification). My third alternative would be system verilog.
There are several reason for my preference including:
*) C++ is a much more powerful language compared to SystemVerilog. SystemVerilog lacks method and operator overload which QUICKLY gets tiresome when using OOP. It lacks multiple inheritance making class structures much clmusier and harder to define well.
*) SystemVerilog is an immature language and it’s not maturing very fast as the language is HUGE! Things that are compile errors or at least warnings in C++ passes in SystemVerilog which in turn means you spend MUCH more time debugging “simple” mistakes
*) To me it’s not clear that the additional features of SystemVerilog not found in C++ ( Constrained Randomization and Coverage )are well implemented. Both are ONE way of solving the problem and not necessarily the best way.
*) Native C++ and SystemC both provides better ways of integrating SW aspects of a SoC design. Something that is, in my experience, important.
The downside of C++ is that it’s a complex language (comes from being powerful) and that no-one had put together a good example on how to use C++ for verification. If you use the wrong aspects of C++ (templating as an example) you quickly end-up with a hard to understand jumble of code. It doesn’t have to be that way and this is what Mike and I tried to address with our C++ book.
To me SystemC has done tremendous harm to C++ in the verification field. SystemC is more then convoluted to use, slow to run and beyond cryptic to debug. SystemC gives the impression that C++ has to be hard to use when it’s far from the case. SystemC was meant to be a RTL modeling language (I’m not convinced it’s even that good at that). Using SystemC gives you very little when it comes to verification, but adds a lot of problems. Mike’s port of Teal to SystemC will solve most of these problems ( I hope ).
That all said I’m working in SystemVerilog today and I’m reasonable happy even if we’ve hit the boundaries of the language already. SystemVerilog can serve as a good introduction to Object Oriented Programming for a mainly HW oriented teams. It’s less threatening then C++ (even if SystemVerilog OOP code is at least as hard as C++ to read). This is why I use it at my current company as we are mostly HW oriented guys. That said we’re already missing being able to integrate our SW into the verification flow which leads us looking at C++ solutions…
Hope that helps highlight some of the things to consider when picking a language. If you describe your project/team a bit more I’ll give you a more direct advice.
In the end it’s just a language choice. More important is having a good code structure and writing reasonable code. Otherwise any team will quickly be bogged down in any language.
/Robert
#2 by mike on May 27, 2008 - 2:22 pm
Hi Brian,
Robert does a pretty good job at summing up the arguments.
For some more info, take a look at the verification guild (www.verificationguild.com) and search for systemVerilog or c++. Just be aware that there are serious political interests at play there.
As far as I can tell, there is no industry general direction. There are still large amounts of straight HDL verification, vera and specman in legacy systems.
You might also consider picking up Chris Spear’s book on SystemVerilog (SystemVerilog for Verification: A Guide to Learning the Testbench Language Features, on amazon). It does a good job of explaining the syntax of the language (as of the SV 2005/2007 revision).
Finally, you might want to chat with Doulos (www.doulos.com). They are a training company and really know their stuff.
I also agree with Robert that the main thing is to learn how to use OOP to make the code more understandable. I can send you a few chapters from our book if you want. We make only about $3 from the book, so believe me, we are not in this for the money.
We are also here to help in any way we can. Robert and I both know C++ and SystemVerilog fairly well.
Take care,
Mike
#3 by btm on May 28, 2008 - 10:48 am
Hi guys,
First off, thanks for replying.
Here’s some more information about what I’m trying to do. I’ve developed a custom processor to perform various DSP functions. This DSP core is similar to a general purpose CPU in that it has an instruction set and interprets programs, although the instruction set is heavily geared towards DSP functionality. In addition to this core, there are others to perform A/D captures, memory block copies, and rice compression. All of these cores are connected to one another using a wishbone bus. All of these have been written in VHDL and poorly verified, in terms of a automated testbench verification process. I would like to remedy this by figuring out what the best approach is then implementing it. So far, from what I’ve read and heard my plan is this:
1) Add PSL assertion & coverage statements through out the cores
2) Top level testbench will be implemented using verilog
3) Verilog testbench will interface with C++ version of teal & truss to create test scenarios
4) Implement a DSP core emulator in C/C++ for two reaons; allow other engineers to create programs for the DSP core without hardware & to create a more complete verification process
5) Possibly add a matlab interface (most likely through truss) to generate waves to be captures by simulated A/Ds and to verify DSP core programs.
Any suggestions on this plan is greatly appreciated.
What will the teal&truss systemC version bring to the table in regards to the C++ version? I know that whatever choice I make isn’t going to be future proof, but I’d like to choose something that will achieve my objectives but also be relevant for a number of years to come.
And yes, I would appreciate a few chapters of your C++ book!
Thanks again,
Brian
#4 by mike on May 28, 2008 - 1:14 pm
Hi Brian,
Ahh DSPs, fun. My specialty back (OK way back) in college was DSPs.
>Any suggestions on this plan is greatly appreciated.
I’d say that was a darn good system plan!
>What will the teal&truss systemC version bring to the table in regards to the C++ version?
A few things. One is VHDL interconnection. Another is the possibility of stand-alone operation (without a simulator). Also, yhe SystemC kernal/threading is built in to the simulator instead of pthreads. Finally, people claim the SystemC interconnect is far faster than pli (not that I have any evidence of that).
On the downside, the compiles will be slower (for some files) and will use the version of gcc that the simulator company wants (usually more than 5 years old). Also, the systemC world is darn huge, about 3000 files and you might follow the teal code down there.
As for book chapters, ping me mike <> trusster com as to what chapters you would like. My suggestion would be the intro chapter and one or two of the verification architecture ones. If you go to the download section of the web, there is the OOP chapters available there.
Take care,
Mike