The arguement in [1] doesn't make sense to me. Xilinx tools are free, as in beer, and the sale of ICs funds those tools so they are implementing your system of a "tax on every chip". Surely the VP of tools at Xilinx knows this.
What problem are you unable to solve with an FPGA because you do not have the source code to Vivado?
I understand why Xilinx doesn't want to release their source. They don't want to support it. Supporting code is a huge overhead and it's not clear, to me anyway, what Xilinx gains from the expendature.
My argument for the VP was essentially not to release their source, rather to release all of the details that you need to create, sign, and then load a bitmap file into their FPGAs. Also to document how the chip is laid out, and how you can floorplan it by hints in the .bit file.
If they did just that, then the source code would "appear" as people wrote back ends for the various open source HDLs that are already in existence.
The challenge that I see is that Xilinx has already had the experience of selling that data to vendors like Synopsis who sell their own synthesis tools and charge major money for them. And like a person who holds an unvested stock option for a stock that goes from price A above the strike price, to a price B that is below the strike price, they feel as if they "lost" money. Similarly, Xilinx can't see "giving up" thousands, if not millions of licensing dollars they are getting from tools vendors, just to enable an open source community to start. Because they fundamentally can't see that having a vibrant open source ecosystem benefits all players. And this in spite of the gcc example which is pretty incontrovertible in my opinion.
They do document how the chip is laid out and exactly what HW resources the chip has. If you want to make your own backend you can. Use the get_ set_ property of physical constraints, extract and redo placement on the entire design via TCL, or save to your own intermediate file and work off that. I don’t think one needs access to Xilinx’s binary formats.
> Supporting code is a huge overhead and it's not clear, to me anyway, what Xilinx gains from the expendature.
In what world is this the case? You host the project on github or the like and let people contribute bug fixes at the cost of filtering pull requests. Letting the community contribute bug fixes is a huge reason companies open source their tools.
You're mixing up WebPack (which is a licensing plan for some of Xilinx's tools) and Xilinx ISE (which is one of those specific tools).
Xilinx ISE is indeed deprecated. There are quite a few parts in production which it will still generate bitstreams for, though.
Vivado is the newer replacement. It will not build designs for parts older than 7-series, though, so Xilinx ISE is still required to work with 6-series and older parts, as well as with Xilinx CPLDs.
WebPack licenses are not deprecated. The WebPack program is still active, and will generate limited licenses for both Xilinx ISE and Vivado.
Most EE EDA/CAD tools are ancient monstrosities of patchwork with a user experience reminiscent of using eclipse 0.01. Full of bugs, lack of fast CLI tools. Everything must start a core process that takes many seconds to even boot. It's ridiculous. Software engineers don't know how good they have it in terms of tools.
I started off doing digital design but quickly switched to embedded software after seeing the state of tooling. It's not just the tools themselves either. There are folks who will vehemently defend the way things are and shoot down even the slightest improvement efforts as naïve. With that culture in place, I'm happy just having someone else slap a cortex-mX on a board and programming it with gcc/makefiles/openocd.
Being able to do that for embedded software is also a sign that things are changing. For the longest time embedded devices were only programmable from a vendor supported IDE (looking at you TI and Cypress). At least now the open source community have figured out how to get around the limitations and the tools are starting to flourish with increasing vendor support.
What problem are you unable to solve with an FPGA because you do not have the source code to Vivado?
I understand why Xilinx doesn't want to release their source. They don't want to support it. Supporting code is a huge overhead and it's not clear, to me anyway, what Xilinx gains from the expendature.