Between Accellera and the IEEE, there have been seven revisions of the SystemVerilog Language Reference Manual (LRM) over the past 20 years. Five of those revisions were in the first decade. Many users continue to shun SystemVerilog because feature support from different tools and vendors of the rapidly changing LRM had been so inconsistent. To this day, people still stay with Verilog-1995 syntax and don’t use features added by Verilog-2001 (e.g. ANSI-style ports, power operator). So the brakes were put on the SystemVerilog LRM giving vendors a chance to catch up and giving users the stability they wanted. The end of 2016 was the last time any of the IEEE SystemVerilog technical committees met to add changes to the LRM.
But technology never stands still. Over the last 4 years, vendors have made extensions to their tools based on demands from customers, and the users are left with a hodgepodge of features with no or incomplete references (extending most built-in functions to be used in a constant function). Other users simply won’t wait for any extensions and begin working around language limitations by creating extra code packages or incorporating other languages into their flow (Chisel, Perl, Python, Ruby,…) . Now I don’t expect SystemVerilog to be the #1 language choice for every design and verification project out there, but all languages must evolve to stay relevant. And developers want to protect their investment in verification IP for as long as possible.
I think it’s time to start the revision process while keeping a delicate balance between stability and staying relevant. The good news is many feature proposals are already in place and tool vendors have already implemented a lot of them. There are a few features that were never completed in the LRM and always expected to be flushed out in the “next revision” (Real-number modeling, covergroup extensions, DPI). Also, there are lots of unnecessary restrictions in the language simply because the committee was worried about unintentional consequences, but tools have moved forward.
Stay tuned for an upcoming announcement about the start of the Working Group for the next revision of the 1800 standard. Late last year, the IEEE Standards Association approved a Project Authorization Request (PAR) to authorize a revision to the standard. Where do you think the Working Group should focus its efforts for the next revision? I’d love to hear your ideas in the comments below or in the Verification Academy’s SystemVerilog forums.