Interested in knowing how you got started, any prior knowledge/training, as that seems quite the hill to climb?
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
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.
I’ve built my first computer with soldering all the parts and then started debugging it with oscilloscope to see signals from chips and analyse them to find the problem. And in doing so I have quickly realised that I am missing something. This something was ‘How chips actually work’. Turned out it was called Digital electronics so I’ve decided to learn this on the way.
My treasure and source of inspiration at school time was this book: Digital Electronics by Roger Tokheim. I was dragging it to school and back every day just like people cary notebooks these days. This was my bible back then. Boys in the school made fun of me for this. The book was amazing and I think it still is.
I remember it all as very exciting time.
Now FPGA seems like a nice opportunity to revisit all of this after many years of programming and developing a new point of view about many paradigms.
May be you can direct me and others like me toward a good community and tips for shortening a learning curve. Possibly many things I am familiar with already and yet with FPGA I didn’t find a good/easy way to start so far. Perhaps you can advice something about ‘how’ and ‘were’ to begin.
I have always been a big advocate of learning while doing, especially in software. Find something, preferably small, that you want to build (your Pong), and work on making it a reality. Maybe it's making Snake entirely in HDL. Maybe it's playing around with LiteX on your preferred development platform so you can build something cool with the RISC-V processor (I don't suggest this though, start with learning a normal HDL). Maybe it's simply looking through one of the existing retrocomputing cores, trying to figure out how stuff ticks.
Until you get to the CPU design level, the general concepts you'll encounter will be fairly simple. I think it's enough to just play around with blinking lights, learning how parallel synchronous logic works, relative to how we think of software working.
My challenge is to play with CPU designs at some point but in the beginning I agree it is easier to start with something like led blink, nand , register and then to other staff.
Is there some FPGA hardware you can advice to use for easy start? One that potentially(once I learn) capable to do let’s say UART or USB ? I do not know really how much of FPGA power required for those. Or it would be too big/expensive ? I can’t orient myself with this yet but I wish something physical to have for real motivation to ignite.
It may sound like shilling, but the Analogue Pocket is actually an excellent development platform because it's everything all in one; you don't need to figure out how to take input, load data, or output to HDMI, because that's all taken care of you automatically. Now you pay for that in having a $200-250 price tag, plus ~$50-70 for your JTAG adapter, but I think it's excellent for starting.
For OSS, I would probably recommend a Lattice FPGA. Gowin FPGAs are really, really cheap (Tang Nano 9k), and _partially_ support an OSS toolchain, but it's missing many core components, and I've actually found bugs in the hardware (confirmed by others), so probably stay away.
The DE-10 Nano is very capable, though fairly sought after at this point. It has a decent amount of IO, and can run the MiSTer retrocomputing project, which has the largest collection of OSS cores out there.
----
However, probably before you even buy any hardware, play with simulations. Choose your HDL (Verilog is US focused, VHDL is EU focused) and choose a simulator. For VHDL, you can use GHDL and GTKWave for an entirely OSS setup. For Verilog, I would recommend downloading the closed source Intel ModelSim, but you can also produce very fast, C++ controlled simulations using Verilator.
In any case, start simulating and looking at waveforms. Debugging multiple sets of nets at once is a very interesting experience and is at the core of what you're doing when working with FPGAs (verification is something like 80-90% of the time), so you can learn a lot without any hardware just working on that. If you use Verilator, you can have psuedo LEDs or even a display to draw on.
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!
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".
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.
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).
What sorts of hardware projects?