
Is SystemVerilog the COBOL of Electronic Design? - BooneJS
http://www10.edacafe.com/blogs/realintent/2015/11/12/is-systemverilog-the-cobol-of-electronic-design/
======
nickpsecurity
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](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.

~~~
electrichris
Chisel ([https://chisel.eecs.berkeley.edu](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](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](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.

~~~
nickpsecurity
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/](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.

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

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

~~~
krupan
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.

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

~~~
krupan
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.

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

~~~
krupan
How so?

~~~
DigitalJack
clock blocks

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

------
chiggs
Cross post of some comments from [http://www.fivecomputers.com/language-
specification-length.h...](http://www.fivecomputers.com/language-
specification-length.html) 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.

~~~
krupan
"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.

