Is SystemVerilog the COBOL of Electronic Design?
Cross post of some comments from <a href="http:&#x2F;&#x2F;www.fivecomputers.com&#x2F;language-specification-length.html" rel="nofollow">http:&#x2F;&#x2F;www.fivecomputers.com&#x2F;language-specification-length.h...</a> which touched on this, but considered specification length rather than number of keywords as a proxy for complexity.<p>With VHDL, anybody could join the working group for free, attain voting rights simply by attending and voting, propose new features and contribute to discussions. There was a public mailing list and a Wiki, everything was open. Contrast that to SystemVerilog &#x2F; UVM and I think you&#x27;ll see why nobody was in the committee meetings. It feels as though Accellera aren&#x27;t really interested in contributions from interested users or smaller companies, so it&#x27;s not surprising that they aren&#x27;t involved.<p>Unfortunately once you have a dedicated group like Accellera it then becomes difficult to switch to something more open. By definition there&#x27;s a vested interest in maintaining the status quo, which doesn&#x27;t necessarily translate to the best arrangement for the end users or the industry as a whole. It would however be possible to at least move the code development of UVM to something like Github and accept patches - this would be a very welcome change.<p>Another problem that faces our industry is the market size - there aren&#x27;t enough users to commercially justify certain development efforts. Only the subset of the language features that are commonly used are implemented straight away, the remainder follows at leisure &#x2F; never. This means you very quickly find bugs if you stray off the beaten track and any &quot;exotic&quot; features are never implemented because there isn&#x27;t sufficient demand. Of course there will never be demand because everything breaks if you use a new feature - we have to develop to the lowest common denominator of our multi-vendor toolchain, which basically means nothing above some syntactic sugar on top of Verilog. So in effect, for synthesis, there hasn&#x27;t really been much in the way of advancement for decades; interfaces are about as good as it gets.<p>Compare this pace with the software world, where there were multiple complete implementations of C++11 available well before the standard was even ratified!<p>Unfortunately the high barriers to entry and the low number of users, coupled with the enforced conservatism of not being able to use any new features and the mindset that breeds, makes it very difficult for innovative companies to enter and gain traction. We therefore don&#x27;t have the natural selection that occurs in software, where new ideas gather momentum and stick around, while the older less efficient languages and processes gradually fade into obscurity.<p>The current mindset seems to be to try and design everything into the language up-front, which results in a very bloated feature-set which also falls over as soon you try to do something in a way not envisaged by the committee. Designing a language should be a case of trying to provide the minimum feature set possible that enables any capability - with SystemVerilog we&#x27;ve got it backwards where we&#x27;ve tried to think of every possibly capability and add a feature for it.<p>Obviously we can&#x27;t miraculously increase the EDA market size (although I&#x27;m still optimistic that FPGAs will gradually gather more software engineers into the fold), but we can make decisions based on this reality. In practice I would suggest this means that any new feature or new keyword would require very good justification for inclusion. We really need to be stripping parts of the language out, however unfortunately that can probably never happen now.<p>For example, interfaces are a good idea, but rather than introduce a completely new feature it would have been possible to facilitate the same functionality that interfaces provide by allowing module or package instances to be passed around as first class objects. This would have enabled other use cases without the committee having to think of them all up-front.<p>TL;DR: SystemVerilog is terrible for the industry - doesn&#x27;t solve the right problems for synthesis and doesn&#x27;t compete as as a good &quot;software&quot; language for verification.  It&#x27;s the worst of both worlds, and now EDA vendors need to spend a decade trying to re-coup their investment.