I'm enjoying this series. I've got a few comments about inaccuracies: > Vivado, the dominant IDE for hardware design I haven't heard that one before. I use

I'm enjoying this series. I've got a few comments about inaccuracies: > Vivado, the dominant IDE for hardware design I haven't heard that one before. I use it when I'm working with Xilinx parts, but I rarely open the GUI. I use VSCode mainly, and nvim. 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.VerilogHDL https://marketplace.visualstudio.com/items?itemName=mshr-h.V... https://marketplace.visualstudio.com/items?itemName=eirikpre.systemverilog 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.