* 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
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.
So...
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?
