Xilinx has come a long way with Vivado from its roots, but I'd never actually do day to day work in it, for the same reasons I wouldn't work in eclipse.

> Want to write code in a different editor like VSCode? Alright, but you'll need to manually register every new file you make in Vivado.

It is pretty straight forward to automate with a general script for this and you never deal with it again.

> Oh, and there's no syntax error highlighting in VSCode's Verilog extensions either.

This is not true.

https://marketplace.visualstudio.com/items?itemName=mshr-h.V...

https://marketplace.visualstudio.com/items?itemName=eirikpre...

> On the rare occasions you do get errors/warnings

Synthesis is notorious for barfing out thousands of warnings even on simple designs. I have never considered them rare, or heard someone else call them "rare," until this blog series.

Quite the opposite. We are inundated with so many warnings that people start to ignore them and that leads to problems. Vivado even invented "critical warnings" to try help with the situation.

> a friend and I once spent over an hour debugging an issue, only to find out that I mispelled a wire name.

This one has me puzzled. Did they misspell it such that it looked like another declared signal?

> The synthesis process doesn't throw error in cases where you would expect it to [...] You can have multiple modules / circuits outputting to the same wire.

You might expect that to be an error, but it's called a "wired-OR." It's often a mistake so you will definitely get warnings about it, but it's not wrong. Go back and look at transistor diagrams of gates.

> You can pass wires into a module by name, but it won't error if a wire is missing, misnamed, etc.

It's true that it won't error if one is missing, because it's not strictly wrong to do that. You will get warnings about undriven logic though.

It's hard to envision a scenario where something misnamed doesn't cause an error unless you typo it into another signal name.

You definitely will get errors trying to connect to a port that doesn't exist.

> You can pass a 1-bit wire to a 5-bit port on a module (or any other mismatched combination).

This is true. And if you aren't aware of it you can get into trouble. I had a friend run into this issue last week, mainly because he came from VHDL which (like ADA) is very strongly typed.

> Explicitly extending/truncating signals is already possible by making a module to transform your input/output, so I'm not sure why this implicit conversion should be allowed.

It's a reaction to VHDL (based on ADA), which with its extreme typing made arithmetic difficult to do. Verilog was intended to be more like C.

> Hardcaml really interesting because OCaml is functional, compiled, and statically typed. Also (and somewhat more importantly), Hardcaml supports testing

Ok, I think it's cool to try other languages and to branch out. I've tinkered with an HDL based on Clojure. But the post implies Verilog does not support those things..

Verilog supports testing trivially. It is statically typed, albeit weakly in some cases. It clearly is functional.

But the semantics get clunky. I would think that is where OCaml or Chisel or others would be interesting.

> On the rare occasions you do get errors/warnings, they're generally cryptic and require relatively deep understanding of Verilog. Not great for beginners.

This is true. I find it annoying about most languages I work with, most recently python.

> Tooling sucks. All the synthesis errors I complained about above could be identified through static analysis and surfaced as warnings/errors in the editor. Emphasis on *could be.*

Yes, it does suck. I'm hopeful for things like symbiflow and the tooling it's based on.

But to be fair, static analysis is very much a part of digital design. It's often called Formal.

> Tests also have to be Verilog modules, whereas usually in software it's preferable to use functions/methods for test cases.

I don't really understand what this point is. Your top level has to be a module (or a program) ... it's a fundamental unit Verilog. You can put all the functions/tasks you want in that module.

It's like complaining about classes in c++?

> Partially as a consequence of the previous point, testing requires a lot of boilerplate

That really depends on what level of testing you are doing. You can do the simple function/task based testing, and that is nearly zero boiler plate.

> There isn't really an ecosystem for things like continuous integration. For that matter, many testing innovations from the software world (like mocks/stubs) don't seem to carry over well to hardware.

I don't really get this either. Mocking and Stubs are an incremental design technique. They work fine. And all of my development and that of my team happens through gitlab-CI.

> A lot of automated testing seems to be based around printing assertions and generating waveforms in the Vivado console/waveform viewer. That's not very automatable.

I don't really know what this is talking about. I don't do testing with vivado... it's a compiler/synthesizer for me.

I think the real problem here is that tools are expensive for digital design (hopefully symbiflow/yosys et al get serious traction and change this). If you are stuck in vivado, maybe you can't do automated testing? I find it hard to believe.

ok, now that I'm done complaining about the blog post's complaints, on to the good stuff (I hope) re Hardcaml.

For the first point, many larger parts are Xilinx.

Hi, blog post author here. Thank you so much for your insights and responses to my Verilog critiques! I should note that my impressions of Verilog come from one semester of an intro course taught using the Vivado toolchain, so there's a fair bit I don't know. My post is not an expert analysis of Verilog as much as a summary of beginner impressions from basic coursework and online research. I'm sure that enterprise setups probably have better tooling and systems in place to ease development.

A few things in response to specific comments:

>> Oh, and there's no syntax error highlighting in VSCode's Verilog extensions either. > This is not true.

From what I recall, the ones I tried didn't catch all errors, and the errors they displayed were limited to basic syntax stuff, not any implementation issues / warnings.

> Synthesis is notorious for barfing out thousands of warnings even on simple designs.

That's a very good point. Our development process was mostly a code-simulate loop, with synthesis only run when submitting each phase of the project.

> Did they misspell it such that it looked like another declared signal?

That would be less embarrassing. This one was just a minor typo, but because we didn't see any warnings during simulation, it took a while to track down the root cause.

> You might expect that to be an error, but it's called a "wired-OR."

That makes sense, but it feels like something that should be done by the synthesis process as an optimization, or annotated with a special operator if the engineer needs direct control over it.

> But the semantics get clunky. I would think that is where OCaml or Chisel or others would be interesting. > You can put all the functions/tasks you want in that module.

Coming from a software background, the testing strategies available in Verilog seem very clunky and overly verbose. In comparison, Hardcaml's ASCII waveform expect-test solution feels extremely elegant and simple: https://blog.janestreet.com/using-ascii-waveforms-to-test-ha....

> And all of my development and that of my team happens through gitlab-CI.

That's probably more of a gap in my education than a fault of the ecosystem then.

---

Among other qualities, I prefer languages that let fewer mistakes slip through, and allow the developer to focus on the system they intend to build rather than avoiding bugs/misunderstandings that would be easy to catch otherwise. You bring up a lot of really good points, and I suspect that if we were doing Verilog "the right way", we would have probably run into fewer issues. But at the end of the day, developing in Hardcaml was a much more ergonomic experience: testing was straightforward, most "stupid mistakes" were impossible, setup was pretty easy, and the library provided a lot of really useful abstractions. For example, Hardcaml interfaces make it easy to represent practically any data structure that can be serialized to/from a bit vector, and the Always API allows for some pretty interesting non-trivial functional logic.

https://github.com/janestreet/hardcaml/blob/master/docs/hard... https://github.com/janestreet/hardcaml/blob/master/docs/enum... https://github.com/janestreet/hardcaml/blob/master/docs/stat...

Reply on news.ycombinator.com