5 ms·

Cross post of some comments from http://www.fivecomputers.com/language-specification-length.html http://www.fivecomputers.com/language-specification-length.h...

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

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

by chiggs 11y ago

PhantomGremlin 11y ago

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.

krupan 11y ago

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