AMD Is in Advanced Talks to Buy Xilinx
I think this is a terrible idea for the future of technology. AMD would not be existentially dependent on the FPGA market and the stack is so important to cutting-edge tech that it demands focused stewardship. It&#x27;s clear something needs to change in FPGA land. Xilinx and Intel both produce abhorrent FPGA software causing project delays and cancellations of cutting-edge technology dependent on their devices. Xilinx probably needs an activist investor to force their software to move past the time in history when Java was something you put on your resume. Maybe AMD can be that, but I doubt it and an acquisition by AMD would likely result in the same abandonment we see from Intel towards Altera.<p>Xilinx had an opportunity to be in the position NVidia is in today and it was not obvious in 2005 who was going to win the high performance computing (HPC) market because the inherent advantages that FPGAs had and still have today for high speed I&#x2F;O, RAM throughput, and hard timing requirements. NVidia&#x27;s CUDA, on the other hand, produces generally painlessly portable results, with easy improvement on new devices. They have essentially won in HPC application development.<p>Fundamentally the FPGA companies need to adopt an open-source, cloud-first ethos towards their stacks and especially be focused on making agile low-level application development. Making a counter control some LEDs should be a 10 second process. Changing the clock speed should be a 1 seconds process. Adding a button to reset the counter should be a 1 second process. None of this is true. Good luck getting this to work within one day as a newbie on a vanilla machine. Good luck even installing Vivado and compiling any bitstream in one day (thank God they have AWS images -- good luck getting that going within 2 hours). Good luck coordinating with source control and generally merging work with a team.<p>There was some hope when Intel bought Altera that the compilers engineering expertise might help improve virtual CPU stacks, or at least some investment in the usability of their software tools might have been thought of as a competitive advantage, but all the FPGA vendors have seriously dropped the ball on improving the eco-system with usable software. FPGA software is so bad that you have to justify a 6 month development cycle for something that should probably take a few days if things were even remotely sane. It&#x27;s hard to enumerate all the examples of broken-ness but small changes end up taking a long time to re-build, things like inverting your reset in a module and then waiting two hours for trivial changes to resynthesize and place-and-route. (edit, two hours later the trivial reset polarity inversion failed timing, because it also required me to add synchronization stages to send the inverted reset signal across clock domains, shouldn&#x27;t be doing this at night).