Everyone loves a good fight. Peace? Harmony? Teach the world to sing? Bah! That’s hippie talk! There’s no excitement (or money) in that! Drama, now that’s what we want! (Some of us even want our own drama, but that’s a separate topic.)
OK, so when it comes to tech, perhaps the drama is less, well, compelling. Yes, we can snicker and leer self-righteously, but when we hold our grandkids in the thrall of stories about how things used to be back when we used wires, I’m not sure we’ll keep their attention with rollicking tales of the wars between CPF and UPF, or of legendary rivalries like AMD vs. Intel or Altera vs. Xilinx. So at this point it’s probably fair to start ratcheting back expectations a little; I’ll ask that your pulses diminish ever so slightly, that you ease your bottoms back away from the edge of your seats, where I know they’re positioned with great anticipation.
Oh, and did I mention? Drama turns out to be less… well… dramatic when it turns out that perhaps there’s not as much drama there as expected. As turns out to be the case for our tale today. A tale that turns on initial misplaced expectations, a rival in the ascendancy, and then peace and harmony for all. OK now I wanna puke. You’ve been warned.
Our tale is one of two languages, and, listening to snippets of snarky hallway conversations, they would at first blush appear to be vicious rivals. One is SystemC, an early pretender to the “System” crown. The other is SystemVerilog, the big brash respondent whom you can practically hear booming in a loud cocky voice, “Now THIS is ‘ow it’s REALLY done!”
I must confess to have been somewhat skeptical of SystemC’s intentions early on. It sure seemed to want to be a design language. Yes, perhaps with the potential for a higher level of abstraction, and yet… I mean, what was it? Essentially it seemed to be a class library that allowed you to instantiate hardware using C++.
OK, show of hands… how many of you C programmers really understand C++ well? Hell, how many of you C++ programmers do? Oh, wait, most of you reading this probably aren’t C or C++ programmers. OK, how many of you designers are conversant in C? Yeah, not so many. How about C++? Anyone? Mmm hm… So you might guess that not much low-level design got done using SystemC. Having to learn abstraction is hard enough. Doing so along with an entire new language is even harder. And C++? Forget it.
So who does use C? Well, architects, system-level designers creating algorithms for eventual implementation in software and/or hardware… you know, the idea people. The ones that come up with plans for other people to implement. (Yeah, I know, they’re not as evil as the marketing people, but it’s all a matter of degree.) (Hey, I’ve already said there wasn’t as much drama to be had as it at first appears, so I need to stir up diversionary drama wherever I can.) So after an initial halting foray into the world of implementation, SystemC has been repositioned for higher-level system design and modeling.
OK, so if those who implement don’t use C, what do they use? OK, more specifically, what do RTL designers use? OK, anyone who couldn’t answer that is hereby banished to a special happy room that has been blessed by portraits of wood-nymphs on the wall, redolent of burnt sage and patchouli, with an endless loop of Kumbaya playing. Tie dye optional. They use <drum roll> RTL. Of course, which RTL, well, there may indeed be drama there. Bring on the VHDL vs. Verilog wars! And yet, even here we fail. For even though the name “SystemVerilog” suggests the triumphant pre-eminence of Verilog over its utterly vanquished rival, it has even been suggested that SystemVerilog represents the best of both Verilog and VHDL1.
So again our efforts to stir up controversy fail. Silicon Valley is clearly suffering from a dearth of good old-fashioned competitive spirit. Next thing you know people will be suggesting that software should be given away for free. (Not that they’ll work for free, but that’s another topic.)
Of course, as with all RTLs, the language does far more than provide a way to design hardware – the synthesizable subset is relatively small. Verification is where it’s at. All the way from standard old simulation to assertion-based verification. With object orientation to provide for higher levels of abstraction.
OK, so… so far, it seems that perhaps we have two different target audiences for the two different languages. That’s not helping. That doesn’t sound like much of a fight. Perhaps you’re still grasping at the hope that at least there’s a business difference here… that, rightly or wrongly, companies will have aligned themselves with one side or the other and will stubbornly go down with the ship. For instance, Synopsys was a HUGE supporter of SystemC early on. Surely they’ll stand up and denounce the evils of SystemVe… oh, wait… they support SystemVerilog too. Just as vociferously.
Bah, just an illusion, I’m sure. Clearly it’s an internal political war, with the SystemC division jousting to unseat the cheeky SystemVerilog division. A quick conversation at DAC, some obsequious comments to put them at ease, with some well-disguised trick questions designed to bring out candor and the vitriol that must surely be lurking under that slick happy corporate-message exterior; that will certainly bring to the surface that fight-to-the-death spirit we so love to watch. (As long as it’s not our own death.)
Or not.
Seems that pretty much they have a home for both languages. With a different niche for each. For the architect, the algorithm jockey, those that are comfortable with C and C++? SystemC. Useful for high-level modeling, tinkering with systems, figuring out what the RTL lackeys should scurry off and do.
And for the honest, hardworking designers that take on the thankless burden of implementing the harebrained schemes invented by those not responsible for bringing them to fruition? SystemVerilog provides a means more to their liking both for expressing the design and for verifying that the design works.
So, yeah… kinda disappointing. Each has a place. But… believe it or not… it gets worse. Not only can the two languages coexist, but they can even work together. Sort of. Either one can be used to develop transaction-level models, and so, given the right transactors and gaskets, they can all interact to validate a system. Thankfully, they don’t have the same transaction interface, so they can’t actually talk to each other. I know it’s not much, but hey, it’s something; at this point we’ll take whatever points of contention we can find. Of course, that may not last, folks, so enjoy it while you can. Accellera may take up the whole issue of verification IP interoperability, so the whole thing may end up being one happy lovefest. I know… sad…
I guess you just kinda have to chalk it up to the first and second laws of thermodynamics… We’re moving from a well-ordered world of this language vs. that language, with high energy stoking vigorous debate, to a blah low-energy state where you can randomly pick either language and it might actually work just fine if you use it for the right thing.
How boring is that?
