Recently discovered FPGAs. My first project is a 4-digit
BCD adder for the AU FPGA kit.
I’m quite pleased with the board and Lucid V2!
After a lifetime of software development it took me some time to adapt to this way of thinking, but I think I’ve started to get it.
Welcome 
I come from software development too, and my first FPGA is an Au too.
My first ever project was a simple decimal counter that displays the current value on the Io’s 7-segments.
My second was a basic PDM to PCM converter that read from a mic and send the result to PC via the Ft module.
My most recent project is a simple implementation of a UART tranciever.
I’m still learning and I mostly use Verilog because it’s an industry standard and there are a lot of examples, documentations and ready-to-use modules out there, but I happen to use Lucid too for some modules that helps me learn, and import the generated verilog in Vivado
I like to use Vivado for the debugging because the signal viewer can come handy to understand what is happening and simulate the design, and it aslo have a very usefull ILA (Integrated Logic Analyzer) module that you can embed in your design and capture the real hardware signals for further debugging and checking if needed.
I studied hardware in college (decades ago), and did some hardware right out of school, but I’ve been solidly in software since 2000. But I caught the bug of wanting to do a hardware project, about a year and a half ago now. I started with a microcontroller-based card, but I ran into enough hard realtime limitations with it that I decided to take the plunge into FPGAs because they are vastly better at hard realtime.
I’m still using Lucid (just v1 actually), but I’m sure I will need to cut the cord like gc74 did, at some point. I was able to get the Au to being able to do the basic functionality of my card in just a couple of weeks. The card sniffs the bus on a legacy Apple IIe, and exports every bus event to a remote host (like a Pi5), which, among other things, can watch the bus for writes to video memory and thus render the Apple II display out to HDMI. This might sound complicated, but the part that the FPGA does is actually incredibly simple, and all the complicated stuff is stuff I’d already done with microcontroller implementations before even touching an FPGA.
How did I wind up specifically trying to use the Au? Because to do the entire Apple IIe bus takes quite a lot of pins! The Alchitry boards were the first FPGA platform I found which exported enough pins that I could support the entire bus interface without having to mux anything, as well as having high enough offboard I/O (via the Ft board) to get the bus data off to the Pi5. It takes about 32Mbit/sec, which the Ft is vastly overkill for. But USB1 or 10Mbit Ethernet (the typical options available) are not enough! The relatively easy-to-use dev environment was just a bonus.
I picked Alchitry because of their main feature : freedom.
They are almost the only boards around the web that are 100% modulable, and they use high density connectors allowing for faster bandwidth if needed.
You get exactly what you want : a functional FPGA and a maximum of available IO, and then you can add what you need.
There in no built-in XX port or YY interface that takes away pins you could have used for something else.
This lead to another advantage of Alchitry : being minimal makes them much cheaper than other dev kits.
Then you have Lucid which being easier to learn makes an excellent language to start with, but when you are getting comfortable, you can start using the FPGA’s maker’s tools (Vivado and Icecube) if you want to try out industry standard languages and powerfull tools.
And on top of all this freedom, you have direct contact with Alchitry here for help and feedbacks 
I have no hardware background at all, but I always enjoyed reading datasheets when having to interface with a device for which I (hobby) / we (work) had no driver. The FPGA gives me a chance to discover a new playground.
Price certainly played a big role when choosing Alchitry to experiment/play with something I knew nothing about, just because my grandson had to program one for a course in university and I wanted to understand what he was talking about. We frequently discuss his software assignments, and I must say they are really interesting and useful, like writing a mini OS for a Raspberry Pi, including setting up the MMU etc.
Well, technically there’s the fairly sizeable number of pins which have been connected to the built-in SDRAM. 
But that’s a pretty standard choice for System-on-Module, not least because of how much of a beast SDRAM is to get working reliably.
I have almost 40 pins still free on my Au design, despite my high pin count need (which is likewise about 40 pins for the bus and control logic, plus the 24 pins used by the Ft board, which is essential). But there’s certainly things I could add! One thing I may add is some PSRAM, because I am expecting to need hard latency guarantees for a certain feature. I’m sure I could get the SDRAM to meet that latency, but I’m less sure that I could do any of the other things I’d be wanting to do with the SDRAM as well, without opening myself up to missed latency windows because of another operation being in progress when my hard-realtime event hits. Adding some PSRAM would let me allocate the hard-realtime feature to its own separate, deterministic memory channel. PSRAM latency isn’t great, but it’s still fast enough for what I need.
Oh yes I forgot the SDRAM, it could be optional but I think it’s mandatory whenever you want to use the Microblaze soft CPU, not sure about this.
The SDRAM itself can run at 800 MHz on the Au and Pt, and by using some FPGA magic (especially FIFOs and caching) like Justin shows in the SDRAM tutorial, you design don’t have to run that fast.
So if the gap beetween the SDRAM speed and your design’s speed is big enough, the SDRAM can look like SRAM for your design!