Comment by oelang | Hacker News Reader

Comment by oelang | Hacker News Reader

Parent Full thread

I think verilog (and mostly systemverilog) is beyond saving. Systemverilog has a spec bigger than c++ and it's full of broken, unused features or features that aren't compatible. Over the years they have added any feature that some HW engineer asked for resulting in a true kitchensink language. I don't think that there is a single simulator that implements the complete spec. (and on top of the regular language they use lexical macros very heavily)

VHDL is a little better but the syntax is horribly verbose and it lacks power to do advanced verification (either it needs a better library or it needs a few more features). In my mind VHDL can be saved, some VHDL-coffeescript could be wonderful.

MyHdl is interesting, it's build with clear goals & it's made by an experienced HW engineer that also understands good software design (most don't). He would disagree with you about simulation (http://www.jandecaluwe.com/blog/its-a-simulation-language.ht...). The RTL code that MyHdl generates always looked very clean to me and the simulation possibilities with python are of course infinitely better than anything that systemverilog or vhdl can offer.

I agree with the general sentiment with VHDL. I't not a bad language beneath it all, but the syntax does not make it an enjoyable experience. Though I haven't touched it in years, I did at one point try to clean up the syntax very slightly using some rather dumb parsing/substitution. Once you're past the ada syntax and the bad tooling, it's not entirely bad.

http://log.fundamental-code.com/2011/06/11/vhdl-code-generat... http://github.com/fundamental/modv

I don't have enough experience in the other HDL options out there to really say anything conclusive other than the space is a bit of a mess as a whole.

Very nice comment, I agree with it 100%. Being able to apply good software desgin at a RTL design is a killer feature of MyHDL in my opinion.

The possibility to mix RTL and high level software is a very nice feature, for exemple: To make a FFT in Python in few lines and compare the output to your RTL FFT with asserts. And script it so you can loop through a different number of fixed bits width and check the TVE at each bit width.

To do this in Python I used ~50 lines, in VHDL it would be a headache and I probably would end up needing to use matlab to compare the results.

I guess I don't see this as such a big deal. My own experience is limited, but doing this kind of validation by iterating over the input space using e.g. perl to generate verilog is fairly straightforward. I've done exactly that with decent success; again it's a straightforward software problem, and I'm a software guy.

I think the problems I had is sort of the converse: hardware is hard. Reasoning about hardware is hard. And having the representation of your hardware about which you much reason be expressed in the actions of an interpreted program (where the synthesis is a side effect basically) makes things harder than it has to be. The RTL ends up being polluted with simulation constructs and hiding the meaning I'm trying to see. And if anything MyHDL is actually worse at this than Verilog or VHDL.

Because reasoning about hardware is hard it's important to be able to rely on simulation. I'm not saying that all issues can be caught/detected in simulation but many can. In most designs 90% of the code (typically the synchronous logic) can be fully debugged in simulation. Ok there is still a portion that can't be debugged, and you'll likely spend a large amount of time on that final 10% but the alternative is certainly worse.

A good designer can avoid constructs that can't be or are very hard to simulate correctly. A good example is signals that have to cross clock domains, metastability is easily missed in simulation and the problems it causes in actual hardware are huge. Good hardware design tries to avoid or encapsulate these kind of constructs.

Beyond this you still have to deal with the analogue world and that is often hard to simulate. Clock generators that misbehave, working with memory controllers (and buggy IP cores): it's not all under your control and that why hardware design often feels so hard. A lot of time is spend on these issues, but that's only because the rest is made easy by using VHDL.

What's your opinion on PSHDL and Chisel? They try to solve these problems in very different ways. PSHDL can interact with standard VHDL code. Chisel can generate Verilog and C++-based cycle-accurate software simulators.

https://pshdl.org/

https://chisel.eecs.berkeley.edu/

PSHDL is incredibly low-level & basic, afaik it doesn't even have functions & you can't define your own datatypes. I think it's a mistake to make a HDL language that aims to be 99% synthesize-able. I didn't write this but I do agree with it: http://www.jandecaluwe.com/blog/its-a-simulation-language.ht...

I haven't looked a chisel yet (scala is my favorite software programming language though).

You missed the point on SystemVerilog: It's a great language for use in both RTL and verification. The complex structures that you are addressing deal with assertions and classes and other constructs for verification. UVM built a verification library with those constructs. SystemVerilog.us

The problem is that they add a new language feature for every new use case instead of trying to make features fit together in a nice compact core & building on top of that core (in other words 'modern language design'). Systemverilog now has ~250 keywords, do you think you know all of them? There are so many that they allow you to selectively disable keywords using compiler pragmas. In python there are only 33 keywords! VHDL avoided this issue because they mostly copied the ADA language which was developed by competent language designers.

I don't doubt the usefulness of a subset of systemverilog, but as a language it's very badly designed.

Reply on news.ycombinator.com