Is SystemVerilog the COBOL of Electronic Design? | Hacker News Reader

Is SystemVerilog the COBOL of Electronic Design?

www10.edacafe.com

16 pointsBooneJS15 comments

COBOL made things easier for developers, saw widespread deployment, and still runs much of our backend. If anything, it was too easy to use as much of the code was written by amateurs and is too large/complex to port w/out risk of breaking it. SystemVerilog, based on what its users write, is much worse than that. They say it barely does what it seeks to accomplish and imply it's really used just because it's what tools support and people know.

So, developing alternatives is a worthwhile thing so long as there's tools developed to make them useful. A comment on that page references ParC as one of those:

http://parallel.cc/cgi-bin/bfx.cgi/index1.html

The presentation on the site does a good job showing why existing approaches suck to varying degrees. Curious, anyone else in this field or researching it have a short list of other alternatives that show promise for this level of things? Especially verification.

Chisel (https://chisel.eecs.berkeley.edu) is an HDL built on Scala. It does hardware design and verification. Notably Chisel has been used by RISC-V to create an implementation of their ISA called Rocket.

MyHDL (http://www.myhdl.org) is an HDL build on Pyhton. It supports hardware design and verification.

Cocotb (http://cocotb.readthedocs.org/en/latest/introduction.html) is another project in Python but is purely for verification. I use Cocotb to for test benches and it is really does make HDL verification easier. As one would expect having the power the full power of language like Python available can make many tasks much easier to do. However communication overhead between Python and HDL simulator become a limiting factor for more involved test benches.

Appreciate the list. The Chisel and MyHDL work are impressive. The Cocotb is new to me. I'll have to check it out.

Btw, what do you think of this one which I haven't seen anyone report on:

http://cx-lang.org/

Need to see someone experienced in hardware design try it with some realistic components and see how well it does. Especially ease of use and practical value compared to established alternatives like Chisel or MyHDL.

TL; DR: The author seems to use "COBOL" as a negative example of language reserved word complexity. Specifically, he points out ANSI COBOL 85 seems to have the most: 357 reserved words. He contrasts this with SystemVerilog, which seems to have 250 + 73 reserved system functions = 323.

He spends the remainder of the article describing thoughts arising, on said language complexity, from conversations at a “10 Years of IEEE 1800™ SystemVerilog Celebration” lunch, at an IEEE Standard Association symposium. The author uses anonymous hallway and table conversations with SystemVerilog luminaries as a platform for critical analysis of not only the current SystemVerilog language standard, but the IEEE process and committee by which it was formed and ratified.

Its been 10 years since standardization and the eda vendors are still whining about SystemVerilog implementation...

Interfaces was a great addition it serves more uses that simple structs (which were not available before SystemVerilog either). The primary use he doesn't seem to get is that it is a great place to put your interface assertions so all the intent of the interface end up in one place. The way this is typically done when SystemVerilog is only used for testbench/assertions is to put them in a separate file anyway so they don't have to be included in both the sender and receiver.

So use a class or a module instead of a struct. We probably could have solved multiple problems by simply allowing modules to be dynamic (like classes are), referance-able (like interfaces and classes are), and to support inheritance (like classes do) and saved ourselves at least three reserved words and the associated complexity and ambiguity of purpose and use.

Has this guy ever written a test bench? One might not see the usefulness of interfaces (wire bundle kind) if they just do design. But they are very helpful in verification.

The thing is (that he didn't really take the time to explain), we could have accomplished the same thing without introducing yet another reserved word. Modules could take structs or classes as ports and you'd have the same benefit as interfaces. interfaces are redundant and introduce unnecessary complexity and confusion.

In my experience designers love the idea of interfaces too. Far easier to replicate signals down through a module hierarchy if all modules can use the same interface. Designers too get frustrated that interfaces are not just modules or structs though.

But an interface isolates timing. Assuming you use it ( I do ).

How so?

clock blocks

Which is yet another SystemVerilog feature that doesn't necessarily need to be tied to the interface language feature.

Cross post of some comments from http://www.fivecomputers.com/language-specification-length.h... which touched on this, but considered specification length rather than number of keywords as a proxy for complexity.

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 / UVM and I think you'll see why nobody was in the committee meetings. It feels as though Accellera aren't really interested in contributions from interested users or smaller companies, so it's not surprising that they aren't involved.

Unfortunately once you have a dedicated group like Accellera it then becomes difficult to switch to something more open. By definition there's a vested interest in maintaining the status quo, which doesn'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.

Another problem that faces our industry is the market size - there aren'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 / never. This means you very quickly find bugs if you stray off the beaten track and any "exotic" features are never implemented because there isn'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't really been much in the way of advancement for decades; interfaces are about as good as it gets.

Compare this pace with the software world, where there were multiple complete implementations of C++11 available well before the standard was even ratified!

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'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.

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've got it backwards where we've tried to think of every possibly capability and add a feature for it.

Obviously we can't miraculously increase the EDA market size (although I'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.

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.

TL;DR: SystemVerilog is terrible for the industry - doesn't solve the right problems for synthesis and doesn't compete as as a good "software" language for verification. It's the worst of both worlds, and now EDA vendors need to spend a decade trying to re-coup their investment.

I'm still optimistic that FPGAs will gradually gather more software engineers into the fold

That would require a lot of retraining, at least that's my personal experience. Before I wrote any Verilog, I had a software background. I wrote lots of code in asm and C. I also did hardware board design and ASIC design (using schematic capture).

The problem is that Verilog tempts people with software experience into using techniques they're familiar with. E.g. some of my first Verilog looked like this (not proper syntax):

   if condition-expression1
      do something block
   else if condition-expression2
      do something block
   else if condition-expression3
      do something block
   else
      do something block

That's easy to understand software, but it synthesizes into horrible hardware. The problem is that the sequential tests are, necessarily, synthesized into a priority encoder. Which means that the comparison chain becomes a critical timing path. There are lots of traps like that which await software people.

Good hardware design requires a lot more parallelism than what software engineers are typically used to.

"I'm still optimistic that FPGAs will gradually gather more software engineers into the fold."

I'm really hopeful that Open Source software will one day be the norm for EDA tools as it is for software development tools. How do we get there? One thought is that you need more software engineers to start designing hardware and then they will scratch their own itch for better tools and the rest will be history (similar to how we got Open Source compilers, OS's, etc.).

I don't see that happening. More likely the software developers who are already in the field will see the light and start sharing code. Who are these software developers in the field? Well, the Big 3 EDA companies employ quite a few, but really everyone who writes Verilog or VHDL is already a software developer. Sure, they probably need to learn a new language before they go hack on a logic simulator (vhdl isn't the write language for that job), and maybe a new technique or two, but it's not as huge a stretch as everyone makes it out to be. They design microprocessors, networking chipsets, caches, PCIe root complexes for crying out loud, they have a better foundation in computer programming than the vast majority of "programmers" do. They can do learn how their tools work and how to hack on them.

Reply on news.ycombinator.com