I’m a little skeptical that it is easy as you say it is. Particularly when you are dealing with something as bad as the current toolchains, there are a number of barriers (say 10) and maybe the LLM clears some of them (say 6) and you still have a lot of details to get bogged down in.

In the software field you certainly hear things like “I have 20 agents running in my gas town and last night they they coded something that will put Google out of business” and also “all I get is unmaintainable trash.” My own experience is “your results will vary”, like I’ve been very impressed sometimes and other times the agent just couldn’t do it.

So I’d expect FPGA to be the same, helpful to some extent but not a revolution.

I also think you are right to say FPGA applications are scarce. FPGA are expensive for what you get, strong compared to other architectures when latency really matters, not so strong for throughput. I think about the new-retrocomputer space where display controllers are tricky (conceptually simple but a lot of parts) and an FPGA is an obvious option but people are more likely to use an ESP32 more because it is cheap than because it is easy to program.

> ..., fix timing issues.

Which might behave pretty differently on the specific hardware; getting the simulation correct is only a fraction of the path. A lot more is necessary, and usually you spend days (or months depending on the size) with the logic analyzer connected to the board.

> The biggest barrier to FPGAs was always that writing HDL sucked

Are you sure about that? From my experience, that was only 10-30% of the actual work (if your goal is not just to pass the simulator).