5 ms·

Interested in knowing how you got started, any prior knowledge/training, as that seems quite the hill to climb?

petrohi 3y ago
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 https://a.co/d/imzGBK5 as well as freely available ARM edition https://dl.acm.org/doi/book/10.5555/2815529 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!
- misnome 3y ago
  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".
  - sweetjuly 3y ago
    >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.
    - misnome 3y 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!). 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).
- rodlette 3y ago
  > 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?
agg23 3y ago
I _technically_ had prior knowledge as a computer architecture class had us stick some premade pieces together to create a CPU we designed, but I personally wrote no Verilog, and it was a small subset of the class. I don't have much documentation for getting started with HDLs (Verilog, VHDL, etc), but I have tried to document my process as much as possible. I have primarily developed for the Analogue Pocket, so my documentation is themed towards that device, but there's IP (code modules) and wiki entries that would be useful for everyone: https://github.com/agg23/analogue-pocket-utils https://github.com/agg23/analogue-pocket-utils I had previously written a cycle accurate NES emulator, so I was familiar with hardware techniques, but not what they look like in circuits. The first core I wrote was a schematic accurate Pong implementation. This was both good and bad because it's very simple and has no CPU (and thus no code), but it also makes it very hard to tell what is going on. I went from there to doing a lot of ports (NES, SNES, PCE, and a few more), and after that I worked on my own cores (Tamagotchi, Game and Watch). Tamagotchi I took a very typical software approach where I wrote massive amounts of unit tests and wrote against those tests. While this is what real hardware developers do, I found it to be a huge waste of time when you're working by yourself on a small project. I, and a few others, are very willing to help people learn (though I'm still really a noob). If you want to play around in this space, let me know and I'll try to help you with what you need.
- agg23 3y ago
  On the note of my sibling comment, a common book in this space for learning is "Designing Video Game Hardware in Verilog", which is specifically retrocomputing related.
  - 0xcafefood 3y ago
    I second this book recommendation! I just started it exactly to get a foothold on FPGA programming. It's very accessible.
    - lovelyviking 3y ago
      with what FPGA hardware is better to start for first tries?

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 https://a.co/d/imzGBK5 as well as freely available ARM edition https://dl.acm.org/doi/book/10.5555/2815529 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!

misnome 3y ago
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".
- sweetjuly 3y ago
  >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.
  - misnome 3y 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!). 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).
rodlette 3y ago
> 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?

agg23 3y ago

I _technically_ had prior knowledge as a computer architecture class had us stick some premade pieces together to create a CPU we designed, but I personally wrote no Verilog, and it was a small subset of the class. I don't have much documentation for getting started with HDLs (Verilog, VHDL, etc), but I have tried to document my process as much as possible. I have primarily developed for the Analogue Pocket, so my documentation is themed towards that device, but there's IP (code modules) and wiki entries that would be useful for everyone: https://github.com/agg23/analogue-pocket-utils https://github.com/agg23/analogue-pocket-utils I had previously written a cycle accurate NES emulator, so I was familiar with hardware techniques, but not what they look like in circuits. The first core I wrote was a schematic accurate Pong implementation. This was both good and bad because it's very simple and has no CPU (and thus no code), but it also makes it very hard to tell what is going on. I went from there to doing a lot of ports (NES, SNES, PCE, and a few more), and after that I worked on my own cores (Tamagotchi, Game and Watch). Tamagotchi I took a very typical software approach where I wrote massive amounts of unit tests and wrote against those tests. While this is what real hardware developers do, I found it to be a huge waste of time when you're working by yourself on a small project. I, and a few others, are very willing to help people learn (though I'm still really a noob). If you want to play around in this space, let me know and I'll try to help you with what you need.

agg23 3y ago
On the note of my sibling comment, a common book in this space for learning is "Designing Video Game Hardware in Verilog", which is specifically retrocomputing related.
- 0xcafefood 3y ago
  I second this book recommendation! I just started it exactly to get a foothold on FPGA programming. It's very accessible.
  - lovelyviking 3y ago
    with what FPGA hardware is better to start for first tries?