Tuesday, June 15, 2010

SystemVerilog is a Big Mistake

I think we dropped the ball with SystemVerilog.
* It's based on old tech (but at least it has garbage collection). Why is it not more Python-like, y'know easier.
* It's a mishmash of languages
* It's getting 'unattainable'. For example, if you want to plug away at it on your own, there's no free simulator that you can practice with.

Toward a Fully Featured Programming Language

The Verilog standard should've only been updated to make it more useful from a HARDWARE DESCRIPTION point of view. SystemVerilog is an effort to grow Verilog towards a more traditional OOP programming language - and that's what's back to front. We should've taken Python (yield) (or even Go - after all it's built around concurrency and it compiles PDQ (not TCL, please)) and grown it to include a Verilog DUT.
SV adds useful stuff like hashes and foreach loops that make it a lot more expressive - stuff that's empiricaly proven to increase productivity by 100.09%. But why not just start from a real programming language in that case? It's not like OOP testbenches do connectivity and timing like traditional RTL - SV testbenches expect you to call .run() on all your class instantiations and pass around handles to interfaces for connectivity. And since we're back to forking a load of .run() methods, why not start from a 'real' programming language, and allow it to twiddle the inputs of RTL descriptions of hardware?

Adding Broken Things

Since SV is a huge amalgamation of things by an amalgamation of vested interests, things were added to the SV standard that should not have been.

program Block Fail

Also, what's with the program blocks? That's a fail right there. And we still have problems with time -0 initialisation, still have possible race conditions at the start of a sim if you want a monitor module to have reasonable defaults, and then change them at the start of an initial block.

final Blocks

I don't get these. They're supposed to be able to let you do things at the end of the simulation. But like most Verilog procedural blocks, you've no visibility on the order that they'll execute. So say you want to open a file at the end of a simulation and have all your testbench monitors write their status to it. Yay, so put a final block in each of your monitor blocks to write to the file... uh, hold on, how do you know that file has been opened? How do you keep the order consistent? Ah, I know, call a .summary() function/method for each of your monitors. But now to call these functions you need to know what monitors you have, so monitors have to register themselves somewhere because SV has no introspection. So now you've a single final block calling a bunch of .summary() functions and if you've only one final block, what's the point? You may as well just have a function that you call at the end of your 'main()' initial procedure.

Open Verification? Hmmm...

SV testbench-building methodologies seem to be settling around the UVM - a nice 'open' standard that's being put together by the Accellera consortium. Yeah, you can download the code for free and have a peek at it, and maybe send some patches back to fix things that trouble you, but it ain't open, baby. If you have to pay loads of cash for a simulator to run this, I'm not sure that you can claim that it's open.
This is another good reason for going the {Real_Programming_Language, Verilog} route. With just a Verilog-2001 open source simulator, open source programming language and some tasty interfacing, you'd be able to run fancy testbenches on pre-existing RTL from the comfort of your own home. No expensive licenses needed. And more than that, you wouldn't have to limit the maximum concurrent jobs on the compute farm to 10 when doing regressions because co-workers write pleading e-mails to you not to hog the licenses...

Assertions, Coverage & Constrained Randomisation

I admit that I haven't used assertions, coverpoints or constrained randomisation in anger. And I suspect that this weakens my argument somewhat. But this could be done in a Python module instead of, y'know, bolting together several existing languages? I've a feeling I underestimate the amount of work needed to get all this stuff working. Yip, I admit it - this portion of my argument is weak.


Companies. Why would they do {Real_Programming_Language, Verilog} when they could build SystemVerilog to steer us away from the opensource verilog simulators that were somewhat catching up, and make us all move to something that we need to look on feature vs price matrices to see which portions of the bright new thing we can afford to run? Companies, I suppose I can have nothing against them, after all I do work for one! They have to make a buck, I suppose.


It's interesting to think about what a "Real Programming Language + Verilog 2001" SystemVerilog would look like. What Real Programming Language would we use? Would it actually improve productivity?


Gordon said...

It might well look something like http://pyhvl.sourceforge.net/

Scott Roland said...

I agree that SystemVerilog is broken by design. (Similar to [t]csh, which EDA seems to cling to as well.) But I think there are advantages to having a single kernel that would be lost by using another bolt on language.

Steve Brown said...

Maybe the effort was ahead of its time. Now we have a viable solution to leverage SystemC for design which may address the complaints you express.

Attend the #47DAC high level synthesis language panel to see if anyone believe SystemVerilog is the language of the future, or even the present.

Marty said...

@Gordon - thanks for the link. I saw MyHDL before, but not pyHVL.

@Scott - that's kinda my point. Instead of throwing loads of extra bits at verilog to make SystemVerilog, maybe we should've taken an existing programming language and gave it a Verilog-2001 'engine'.

@Steve - Thanks. I've been sniffing around c synthesis, it looks like the future. Now to convince my company to get me a trial license...

flyengine said...

I agree your opinion, SV is wrapped open, but it's simulator is very expensive.

Anonymous said...

I'm a bit late to the party, but...


Verilog's was horribly broken for anything other than gates or very low level RTL: no concept of iterations/delta cycles, just a load of different simulation regions that half of the engineers using Verilog did not have a firm grasp of.

They "fixed" this in SystemVerilog by adding a bunch of new regions, the full list is now: pre-poned, active, inactive, nonblocking, observed, reactive, re-inactive, postponed!!! (I may have missed a few)


Marty said...

@Matthew: Excellent point. One more huge reason to add to the pile.

Funny you should bring that up now. Got caught very recently with testbench problems that boiled down to one thing: I didn't understand verilog scheduling as well as I thought I did...

Here's an interesting (but only somewhat relevant) posting about Verilog vs VHDL scheduling...