I dislike SystemVerilog.
The only thing I dislike more than SystemVerilog itself is that it is really the only choice for a hardware description language today. Nowadays there are two alternative, both horrible: VHDL, and SystemC. VHDL is a non-starter (it's based on Ada), and SystemC isn't even a real language—it's just a C library that uses tortured macros and data-types to imitate an HDL. After thirty years of advancement in hardware description languages, this is all we have? I am aware of some interesting alternatives such as BlueSpec, MyHDL, Lava, and Chisel—but nobody really uses them and the major EDA vendors don't support them.
Verilog is a classic example of a language designed by a committee. It was never very pretty to begin with, but as the standards starting stacking up it got bloated and ridiculous. First there was Verilog-XL, followed by 1364-1995 (V95), then 1364-2001 (V2K), then 1364-2005 (SystemVerilog), and most recently 1364-2009. The result is a complete nightmare only an EDA company could love. The complete SystemVerilog grammar is over fifty pages long, including several pages of footnotes. It is both imperative and declarative. You can write logic in a structural or behavioral style. It has confusing timing semantics. It contains mini languages for state-aware assertions, constraint solving, coverage collection, and random sequences. It has around 250 keywords, more system tasks than you could ever keep track of, and no less than three ways to extend with C/C++: PLI, VPI and DPI.
I didn't always dislike SystemVerilog. Several years ago my team was using Microsoft Word to do logic design. You did not mis-read that last sentence. I doubt my employer would approve if I described how it it all worked, but basically we used a script to translate formatted Word tables directly into Verilog. Needless to say, compared to that kind of garbage, using SystemVerilog felt like breaking out of prison—freedom! I even wrote a few stupid blog posts about it at http://svffap.blogspot.com.
But the more I learned about SystemVerilog, the more I thought it was all wrong. Designing hardware at a high level is mathematics—Boolean algebra, formal logic, queuing theory ... These things are beautiful! But SystemVerilog feels like C++; it can get the job done but it is ugly, inexact, unproductive, and error-prone. And I am only talking about using the HDL components of the language—don't even get me started on the whole VMM/OVM/UVM verification/validation nightmare!
Is high-level synthesis (HLS) the answer? At the very least, the promise of HLS is to 1) program at a higher level of abstraction, and 2) hide some of the grungy details of hardware implementation/timing. CtoS (Cadence), CatapultC (Mentor), and Synphony (Synopsys) are all very nice for pumping out pipelined multipliers and AES cores on a budget, but they all use C/C++.
So what am I going to do about this? I haven't really decided. At the very least I should write further blog posts detailing the various things I dislike about SystemVerilog. At the very most I should design a new HDL for my own usage that will never be used by anybody.