The ecosystem is terrible, I agree with you. However, the lock in is restricted for the final synthesis part. Simulation is mostly done with (very expensive) third party tools, such as Mentor Graphics Modelsim, and in professional settings the build is automated to a point that opening the vendor's GUI is frowned upon.
There are some quality open sources tools on FPGA build automation, but most places I had contact with have their own internal tools.
Of course, there's some dynamic between the tool chain and the language itself. For example, it doesn't matter if the language has the coolest feature if the compiler does not support it, and the toolchain will help you manage more complex code safely.
I recall one Xilinx event where a Xilinx presenter asked how many people were using the Vivado IDE for development. IIRC, only a single hand was held up.
Vivado isn't worse than the competition, though. Intel/Altera's offering is also a steaming pile of crap (we evaluate the competing platform every once in a while when we decide what FPGAs to use for new products).
I don't know why all FPGA tooling sucks, but it does.
That's how most companies do it in my experience (and I prefer it as well). That said, Vivado is leaps and bounds better than its predecessor (ISE). It may be horrible for HDL coding, but when you need to do timing analysis and floorplanning the GUI is really helpful and the integrated TCL command line makes it very flexible.
Tooling in FPGA-land is a sad story, unfortunately. It's stuck in the 90's. I've ranted enough times to feel I'm beating a dead horse, but it's frustrating to see how behind the times it is compared to software development. Just look at HDL IDEs as an example:
The vendor ones are worse than simple text editors, 3rd party IDEs cost an arm and a leg, while feature wise they are nowhere near their software counterparts. Take the most popular HDL IDEs (or should I say eclipse plugins?) and compare them with visual studio pro or jetbrains. The feature discrepancy is staggering (as is the price difference). We use Sigasi at work and while it's definitely better than a text editor, the basic version costs ~800$/yr and apart from error-checking, goto-definition and renaming there's not much else going on. For the same price you can get the whole jetbrains suite with a couple hundred dollars to spare.
I hope with FPGAs becoming more mainstream the open source/hobbyist community will step in and refine some things, but if the big EDA shops don't take hints from the software industry things are not going to change very fast.
With Xilinx toolchains, you're paying both for extremely expensive toolchain licenses, and paying quite steep prices for the FPGA units themselves. We're basically shoveling money at Xilinx as fast as we can.
A big part of the issue is compiling packages. I think this is a thing because synthesis takes so long.
Until synthesis time is reduced, I think we’ll see these hack-y solutions.
We select FPGAs based on HW features and that is that.
The tools are more than good enough for debugging or to kick off an occasional custom synthesis run when you don’t have the time to wrap it in a Makefile.
Our main reason to not have picked Altera was usually much poorer routing and inability to meet our bandwidth demands (>100Gb/s), but the poorer toolchain was also a factor.
However, for IDE, it can be a killer if use is a requirement.
Other than that, getting from Verilog to a design mapped to hardware is pretty trivial with both Quartus and Vivado. They both have excellent debugging tools with SignalTap and ChipScope, they have pin planners that works reasonably well. Synthesis and P&R results are decent.
If your design is so generic that it really doesn't matter which FPGA you're using, then, sure, make your decision based on this kind of detail. But I find that to be almost never the case. Price, number of DSPs and their precision, amount of block RAM, performance of the SERDES units. Those are real decision makers.
My experience went something like this: An hardware engineer needs to do a routine task like add a peripheral, swap some pin assignments, and modify the Verilog/VHDL. So they do all their synthesis and have an export ready to hand it off the the software engineer. They commit their changes and it probably causes differences in dozens of files, but so is life. It seems like this could be reduced to differences in a few human-readable files, except for the bitstream which obviously is binary.
The SW engineer then needs to update the FSBL and BSP for the board. I never found a way to automate this on the command line, you needed to update the FSBL using their horrible Eclipse-based import tool. In my case, I had to make some manual modifications to the FSBL. I think for my modifications that I needed to flip some GPIO pins early in the boot process and also do some RSA validation on the bitstream. Well, all those modifications would get wiped out. I never found a way to template those and preserve them across new imports.
So I had a bunch of differences that had to be manually merged every time. I had notes about it, but come on. What a pain. At the end of all of this, many dozens more files were changed. Once again, it seems like this should reduce to just handful of human-readable files like a FSBL configuration header / C file, the new U-Boot config, and the new kconfig. But instead you had two massive changesets in version control for some very routine work.
Honestly I find the situation better than 20 years ago now on the embedded processor front. The worst thing we have now is broken shitty standard libs and compilers. You can dodge around those by picking assembly (PIC for example, mpasm is actually ok) or platforms with GCC implementations (ARM/AVR)
I just have a very strong aversion for IDE's that fail to prioritize text editing, permanently wasting space on all sorts of buttons and knobs that are only needed 0.1% of the time. It doesn't help that they often also fail to be responsive.
Comparing it to software development toolchains, one might even go as far as calling it a steaming pile of horsedung. However, a lot of it can be hidden, making the flow: 1. Write verilog in your editor of choice, 2. Call make. 3. Come back tomorrow to check the result.