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.
> 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&...
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.
7 comments
[ 4.6 ms ] story [ 30.1 ms ] threadhttps://ceramichacker.com/blog/2-2x-a-bit-on-computers-hardw...
https://ceramichacker.com/blog/4-3x-verilog-fpgas-and-why-oc...
https://ceramichacker.com/blog/5-4x-ocaml-setup-hardcaml-bas...
https://ceramichacker.com/blog/11-5x-multi-module-circuits-i...
https://ceramichacker.com/blog/12-6x-memory-in-hardcaml
https://ceramichacker.com/blog/13-7x-registers-and-stateful-...
https://ceramichacker.com/blog/14-8x-design-patterns-convent...
https://ceramichacker.com/blog/15-9x-always-dsl-and-the-cont...
https://ceramichacker.com/blog/16-10x-testing-and-debugging-...
https://ceramichacker.com/blog/18-11x-cpu-functionality-wrap...
https://ceramichacker.com/blog/20-1212-project-conclusion
https://nationalfile.com/bombshell-new-york-times-fbi-confir...
> 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.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&...
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/d...