4 ms·

Is SystemVerilog the COBOL of Electronic Design?

16 points by BooneJS 11y ago

iokevins 11y ago
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 11y ago
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 11y ago
  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 11y ago
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 11y ago
  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 11y ago
    But an interface isolates timing. Assuming you use it ( I do ).
    - krupan 11y ago
      How so?
      - DigitalJack 11y ago
        clock blocks
        krupan 11y ago
        Which is yet another SystemVerilog feature that doesn't necessarily need to be tied to the interface language feature.
nickpsecurity 11y ago
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 11y ago
  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 11y ago
    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.
chiggs 11y ago
Cross post of some comments from http://www.fivecomputers.com/language-specification-length.html 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.

16 points by BooneJS 11y ago

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 11y ago

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 11y ago
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 11y ago

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 11y ago
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 11y ago
  But an interface isolates timing. Assuming you use it ( I do ).
  - krupan 11y ago
    How so?
    - DigitalJack 11y ago
      clock blocks
      - krupan 11y ago
        Which is yet another SystemVerilog feature that doesn't necessarily need to be tied to the interface language feature.

nickpsecurity 11y ago

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 11y ago
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 11y ago
  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.

chiggs 11y ago

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