Indeed. The whole field is missing 20-40 years of experimental research with different abstractions. It's like trying to write FORTRAN-77. About the only thing that's ahead of this is "Chisel".

There's also a disease of people trying to write "C to HDL" converters without thinking of the very different paradigms involved there. While it can be made to work it will always be extremely inefficient.

Tooling is actually okay, it seems archaic because with a FPGA you are actually designing the very fundamentals of computing. There is no hand holding there.

It would be the equivalent of a newbie programmer looking at GCC and saying: "This program that makes other programs looks so archaic, it runs on an 70's computer terminal."

i disagree, getting accustomed to one of these tool chains takes a really long time. you can run a pipeline for hours only to have it fail with some unreadable message. everything is layered over with lots of poor deep-menu ui, but it doesn't save you from having to understand the pipe in its entirety. oh right, i forgot that depending on what you are doing you may have to open up several different tools manually.

oh right, and the insistence on using feature wizards, which somehow work fine for the on example case but fail in mysterious ways or aren't capable of expressing what you actually want to do

its really a long way away from "gcc hello.c ; ./a.out"

then multiply that with the tool licensing and various feature sets, the IP licensing...support for different parts, entirely different tooling for different vendors.

part of it as you say is that reality is a lot more inherently complicated than software...but the tooling really is a mess. time and cost are a huge barrier to entry.

You are probably mixing RTL design with Place and Route, those are two completely different things.

You can design and simulate without your FPGA, most of the tools allow for simulation without calling a GUI. It will be not different than calling GCC. Worst case scenario, you can always use this open source Verilog simulator, it's good enough if you are only designing for FPGAs: http://iverilog.icarus.com/

Again, you don't need any FPGA to do the design and you shouldn't even use it, it's a waste of time synthesizing the design every time you make a change.

Place and Route comes after the design gets to a complete state and you should only be able to do it once.

If you are doing something different from this flow, you are most likely doing it wrong.

i almost certainly am. made the mistake of listening to the AE

+1 vhdl is much harder to reason about than c. With fpgas you don't write a code flow, instead you write logic that gets executed all at the same time.

It's good for things that are compute heavy, but not for anything else.

I'd also wager that asics might make more sense than fpgas. Which seems to be the path we are going down

VHDL (or Verilog) isn't harder to reason about than C in my experience, it's just different.

I haven't used VHDL for work yet (just skimmed the existing code base), but I just took a course on it, this was my main takeaway. There were some gotchas in the language (perhaps in the error reporting in the particular implementation more than the language itself) that took some getting used to, but the hardest conceptual problem for the class (most of us were programmers, and the hardware guys were green and came from non-CMPE backgrounds) was the idea that many of the statements you write happen concurrently, or are scheduled to happen at a future point in the code. So code like:

  process
  begin
    X <= X + 1;
    Y <= X;
  end process;

With X = 4 at the start, you will end up with (X,Y) = (5,4).

Once you start wrapping your head around these concepts reasoning isn't so hard (and having been a CMPE major once I had the basis for this academically, but it was far in the past so had been forgotten). Certainly not harder than trying to understand distributed systems and coordination between them, in fact it's a lot of the same problems just applied at a different scale.

The problem with programmers trying to design hardware is that when they see code, they think of instructions. If you start shifting your mindset to actual hardware constructions, like flip-flops and combinational logic, the hardware language will start making a lot of sense.

There is also IceStorm though (for use with iCE40 FPGAs).