4 ms·
Considering AMDs software chops, I guess that won’t be coming from them.
by AlphaSite 6y ago
Considering AMDs software chops, I guess that won’t be coming from them.
- xbmcuser 6y agoI thought that was one of the reasons that they acquired Xilinx to improve the software side.
- DoingIsLearning 6y agoThat was my hope as well, I still dream of Xilinx or Intel deciding to 'LLVM' their toolchain down to bitstream, I keep looking with a lot of interest at Lattice and the Yosys project as it is maturing. These companies make money selling hardware, just open the tools and let people use what they want instead of forcing this 'visual programming' paradigm with half-baked IDEs on everyone. My worry with AMD is what will happen to the SoC chips that have actual ARM cores in the fabric (like the Zynq family)?
- aseipp 6y agoVisual block diagram editors like the one in Vivado, Libero, etc are extremely useful and powerful in practice and an equivalent alternative for open source EDA design would be very welcome. And I'm a person who absolutely loathes Verilog, so it's not like I'm a purist or anything. If that's your representative example of your issues with proprietary FPGA software, I honestly don't think it's a very good one.
- DoingIsLearning 6y ago> 'visual programming' paradigm with half-baked IDEs The paradigm is the least important, when it works, I don't know anyone in real world projects that didn't have to configure something manually through a tcl script because it was either not exposed in GUI or not working in GUI. My issue is not with 'visual programming' my issue is with the 'half-baked' part of the tools. There are too many multi year old bugs that go acknowledged by Xilinx. The VHDL2008 standard came out more than a decade ago and from memory it was only in 2019 that they supported it as a valid simulation file in Vivado. There a plethora of autogenerate/copied/cached files that add a ridiculous amount of friction to any attempt of sane version control. There is just too much complexity in what I assume is an attempt to hide the shoe-horned messiness of the tcl backend and 'prettifying' the GUI frontend.
- rcxdude 6y ago> The paradigm is the least important, when it works, I don't know anyone in real world projects that didn't have to configure something manually through a tcl script because it was either not exposed in GUI or not working in GUI. Worse is the other way around, a GUI control not exposed through the TCL scripts, which makes it very difficult to maintain a TCL build script which can be version controlled (unlike the project files: this particular IDE likes to completely rewrite its project files in a way which is not at all amenable to diffing).
- buran77 6y ago> My worry with AMD is what will happen to the SoC chips that have actual ARM cores in the fabric (like the Zynq family)? Why does that worry you? AMD already has ARM cores in their portfolio at least for their A-series Opterons and the PSP.
- DoingIsLearning 6y agoI actually wasn't aware of that, I hope that means that the portfolio and ARM cores remain supported for longer term.
- Symmetry 6y agoThey do seem to be trying to integrate the GPU and FPGA toolchains, at least. https://forums.xilinx.com/t5/Xilinx-Xclusive-Blog/AMD-and-Xilinx-Demonstrate-Converged-ROCm-Runtime-Technology/ba-p/1175091 https://forums.xilinx.com/t5/Xilinx-Xclusive-Blog/AMD-and-Xi...
- aseipp 6y agoAlmost certainly not; I'd be extremely surprised if AMD rocked the boat at all here. Xilinx is already the dominant player in the spaces they're batting for (datacenters are where all the money is and their major focus for several years now), they won't feel pressure to do such things. Overall it seems like a move to strengthen their portfolio for integrated high-end solutions, not something they want to radically shake up. So I suspect it'll be business as usual at Xilinx after the acquisition, but maybe one day we'll actually get a mythical datacenter-class FPGA/CPU combo using Epyc, if it makes sense for their customers.
- franga2000 6y agoLooking at their open-source Linux graphics stack, if they ever end up integrating FPGA fabric into their chips as a kind of dynamic accelerator (I remember reading about that being one possibility after the acquisition), I wouldn't be entirely surprised if they did the same for that. Still probably not a fully FOSS FPGA tool suite, but at even drivers and such would be an improvement over what I've heard the current state of the industry is.
- zokier 6y agoLooking the pretty spectacular failure that was AMD "Fusion", I wouldn't hold my breath on succesful FPGA integration. Fusion was the name AMD gave pretty soon after ATi acquisition to their fancy HSA concept of accelerating compute with gpgpu, especially with the integrated gpus in their APUs. It was announced with great fanfare and pomp, but never really became reality. Today their gpgpu framework (rocm) is both unpopular and doesn't even support igpus in apus.
- bri3d 6y agoWhile AMD's software is historically trash, they do have a track record many years long now of publishing ISA / microcode documentation, which is still a step ahead of FPGA vendors (as far as I know, all known bitstream formats are reverse engineered, not first-party documented).
- rockdoe 6y agoMeanwhile, support for monitoring their Zen CPUs was backed out of the kernel in December because the interface is undocumented and buggy, and AMD isn't helping. AMD is a Big Company, could go either very right or very wrong.