Hacker News Reader

Comment by petrohi | Hacker News Reader

Not the parent poster, but my experience may be relevant.

My background is exclusively in software engineering and computer science. I started by reading “Digital Design and Computer Architecture”. There’s new RISC-V edition https://a.co/d/imzGBK5 as well as freely available ARM edition https://dl.acm.org/doi/book/10.5555/2815529. The book starts from Boolean logic and transistor technology and goes all the way to assembly programming with everything in between. Most importantly gives great introduction to HDLs. Next I played with a bunch of hardware projects specifically targeting inexpensive Arty-A7 board to get comfortable with FPGA tooling.

I can attest to the parent saying that this is sufficiently different from software engineering I do at my day job and therefore feels a lot more like hobby. Especially if you also foray into wire-wrap prototyping, PCB design and assembly. Finding and fixing analog "bugs" is so much fun!

View on HN

Finding out the digital design parts seems like the easy half of the problem.

The non-open-source-tooling (that is what you need for the dev boards I have played with) is what I've had a real struggle with - Vivado and Quartus are so horrendously complicated, that it seems easy to find a project failing at some late stage because you clicked a button wrong two days ago.

Learning these, and the interplay between board specifics and the way any onboard CPU talks to the FPGA mesh and how you interface between the peripherals just seems like a massive explosion of complexity that you seem to have to know in order to know how to learn it. And every board seems to be a horrendous combination of seemingly opaque "IP" blobs.

I've looked even for paid tutorial series, but everything seems to be assuming you've gotten past this stage, or aimed at the "here is how you build up pure stuff in VHDL/Verilog".

>Vivado and Quartus are so horrendously complicated, that it seems easy to find a project failing at some late stage because you clicked a button wrong two days ago.

The (open) industry secret is that nobody actually uses the GUIs for anything other than analyzing build products (viewing floorplans, etc.); everything else is done through tcl scripts and Makefiles. This lets you both avoid the disaster that is the GUI portion of the tools and keep the entire project in a regular text representation (which means you can actually edit everything and check it into version control!).

As an extreme example, I've never even managed to get Lattice Radiant's GUI to even run, the damn thing just crashes almost immediately. It doesn't matter though because the backend tools all still work perfectly. We've just written some tcl scripts which handle everything for us and we called it a day.

> The (open) industry secret is that nobody actually uses the GUIs for anything other than analyzing build products (viewing floorplans, etc.); everything else is done through tcl scripts and Makefiles. This lets you both avoid the disaster that is the GUI portion of the tools and keep the entire project in a regular text representation (which means you can actually edit everything and check it into version control!).

I've sort of worked out this but it seems to be a weird mix of "you need to know what the UI is doing and why in order to avoid the UI". Getting that initial understanding seems a very high barrier.

(version control also seems to be something they manage to break on a whim over toolchain versions - maybe it's one of these hardware things where people just stick with the same toolchain version over the life of the product).

> Next I played with a bunch of hardware projects specifically targeting inexpensive Arty-A7 board to get comfortable with FPGA tooling.

What sorts of hardware projects?

Reply on news.ycombinator.com