AMD and Xilinx Stockholders Overwhelmingly Approve AMD’s Acquisition of Xilinx

I agree on the 'user friendliness' of FPGA tooling, but SW Engineers (myself including) often make the mistake of thinking an FPGA toolchain is like a software toolchain and therefore everything is equivalent. These are the two main reasons that FPGA toolchains aren't as open as compilers (I'm not saying they're good ones):

* Processors have a defined interface ("instruction set") that you can implement a compiler for and have it keep working. The interaction between the FPGA tooling and the FPGA targeted it much more complicated. It's a bit like graphics card drivers and the hardware, where the line between the two is blurry and you have to consider them both together as the graphics system. This means that the 'cleverness' of the design is much more exposed to the toolchain and having that open source would give a way a lot to competitors

* Synthesising FPGAs is a LOT harder and more complicated than compiling code (and compiling code is pretty hard). There are many stages in the pipeline involving synthesising the logic and laying it out on the target for best performance. To give an example, we upgraded our toolchain for a Xilinx FPGA and power consumption improved by 20% because they'd changed the ways that they segment clock domains and gate off stuff being used. Good performance in the tooling is a major differentiating factor that you might not want to give away.

There's open source tooling for a bunch of FPGAs:

QuickLogic EOS S3 (provided by QuickLogic)

Lattice iCE40 (reversed, project icestorm)

Lattice ECP5 (reversed, project trellis)

Lattice Nexus (reversed, project oxide)

Gowin GW1N (reversed, project apicula)

Xilinx family 7 (reversed, project x-ray)

With more on the works. Hopefully an AMD Xilinx will start contributing to the open source tooling themselves, as they do with CPU and GPU tooling.

Quick Logic is an FPGA manufacturer that recently started to offer chips & boards with a fully open source toolchain: https://www.quicklogic.com/tag/open-source-fpga/

I'm a bit skeptical on this one. Open tools may help, but for full vendor support you are going to have to use their tools.

Also I wouldn't say that their tools are in the dark ages- most of the problems with their tools stem from modern software tool design. So for example, I find Vivado / SDK to be complex yes, but also much more pleasant to use than tool chains for simple micro-controllers. An example is the total mess that is software libraries delivered via STM32CubeMX (no part migration, libraries depend on custom BSPs vs. auto-generated code, good luck preserving your fixes if their auto-generated code has bugs).

A reason that the Xilinx tools are big and complex is that they are following modern software tool practices (that I hate): it's a large Java-based tool that aims to hide the underlying relatively simple command line programs. Xilinx tools from the mid-90s are actually closer to what the open source FPGA tools look like today.

There are a bunch of fully open FPGA designs on the first efabless shuttle run: https://efabless.com/open_mpw_shuttle_project_mpw_one

Considering AMDs software chops, I guess that won’t be coming from them.

I somewhat agree, but I think the number 1 factor of low FPGA adoption is the absurd price. Put a good price tag like in GPUs and you have a new industry. Of course, there are issues with tooling too. Maybe there needs to be a simplified API, akin to OpenGL, that takes care of the boilerplate.

Absolutely!

And the FPGAs need not even be as efficient in packing as Xilinx or Altera.

The thing that always gets me: you are already charging for HW - that's the only real business model. The CAD tools 1) suck, 2) aren't going to be a major money maker, and 3) desparately need UI design and programming talent well beyond what ever gets applied today.

> FPGA tooling is in the dark ages compared to modern software development environments.

Dear god is it ever. My fiancee, bless her, got me a Spartan 6 for Christmas one year. I never got around to using it because I couldn't find a download for the single, outdated version of (I think) Arduino Software it claimed it 100% required.

clash? I like their mailing list :)

https://clash-lang.org/

> [...] spend years working on getting acquired instead of working on new chips (which happened to Altera) [...]

I'm interested in what you mean by this. I was working at Altera at the time the acquisition went through, on the software tools mind you, but I didn't notice a significant shift in strategy. Are you referring to before or after the acquisition was announced?

>spend years working on getting acquired instead of working on new chips (which happened to Altera)

That's interesting, can you expand on this? I'm curious what could have impacted them that much (I'm a student about to finish my undergrad in comp eng)

Yup, I don't see how this helps Xilinx users. At best it creates some shareholder value and creates opportunities for advancement within each company.

This is an idea that's been around forever and from a hardware perspective it's super easy. The problem is finding applications for this. You need to find something that is so difficult that it requires atleast dozens of instructions (because the FPGA isn't going to be running at the CPU clock speed so it needs to be a decent chunk of work to jsutify), is done often enough to dedicate silicon for (the FPGA can't be dark 99.999% of the time), but not often enough that you can't justify full custom implementation. Then you need to write a set of custom instructions that map to this logic, and build support for using these custom instructions into the compiler - accounting for the fact you don't just need to dispatch data to the fpga, you need to program it each time you change instruction and that takes forever in CPU terms.

It's not impossible, it's just very difficult, impacts every single part of the stack, and is very difficult to justify.

Intel at one point tried an FPGA-in-package with a server CPU. It turns out that you can't downclock/power gate parts of FPGA designs nearly as easily as you can CPU components, so the whole package had thermal regulation issues. You had to run the CPU at a very conservative frequency in order to let the FPGA use power as it needs to.

There are FPGA-SoCs out there that are mostly FPGA, and that seems like the way to go if you want to combine FPGAs and CPUs, otherwise they should probably be on separate power and heat budgets.

Wondering the same; from my 10,000 ft view a cpu-fpga marriage seems like the kind of thing that could transform how performant general purpose computing is done.

We could but then we need software to take advantage of it, which means FPGA are like GPU in the early days without Direct X or OpenGL drivers sitting on top. Someone ( Microsoft ) will have to create a something that work across on both Xilinx and Altera.

Although I dont see that happening soon. Mostly because no one has the interest in doing so. What most likely will happen is that Apple are so far ahead in this game they started to take notice and work on something.

On Server it is very different though. Tiles and Chiplet will finally means FPGA can have their own node and optimisation while sitting next to CPU without all the complexity of trying to get them into the same silicon. Although the cost of specific software optimisation for specific task will likely means they only goes to HyperScaler.

To add to the other responses, I believe the end goal of "programmable specialized instructions" is being successfully explorer by other options than FPGA, ie the Raspberry Pi Pico state machines, for one example. Then there are also the hybrid CPU-FPGA models (or FPGA SoC) mentioned in the other replies, like the Zynq.

The problem for consumer devices is that FPGAs are power hungry; and consumers value battery life a great deal.

Yep, 5V tolerant CPLDs are a wonderful thing when you're making hardware for retro computers it would absolutely suck if the 9500XLs get discontinued.

Indeed, they're really neat little devices and they're also dirt cheap.

My guess was the latter, given how high AMD's market cap is currently. However, Xilinx/AMD have some common technology requirements around 2.5d integration and 7 nm IP.

I was hoping for an FPGA-SoC with some Xeon cores when Intel bought Altera, and now I'm hoping for one with Epyc cores.

I am really not knowledgeable regarding cpu/gpu/fpga pros/cons but:

Would the chiplet differentiator for AMD impact implementation details in a significantly positive way?

The biggest problem with this concept is that while ASICs can be extremely efficient, FPGAs are much less efficient than the equivilent ASIC. The flexibility comes at a substantial power, chip area, and speed cost. So much so that e.g. raw number crunching is more efficiently done by CPUs or GPUs in almost all cases. You need a particularly quirky computation before an FPGA is a good accelerator. FPGAs are more naturally suited to applications where ultra-low (or ultra-predictable) latency, extremely high bandwidth I/O (with relatively little processing), or particularly specialised DSP is required. Most of these are best served with an FPGA with a CPU attached, as opposed to the other way around, and the cost of the FPGA is not likely to be worth the cost to the majority of users. For an example of a specialised use-case: ASIC designers use racks of them to simulate the digital logic in large-scale designs, which are otherwise far too difficult to simulate on a CPU because CPUs really struggle to simulate billions of seperate logic elements individually, and latency is a real killer for parallel processing. Even so, they run much, much slower than realtime.

This. Highly underappreciated how the monopoly problem in wafer fabrication is "infecting" the rest of the industry.

What are your reasons for not supporting this move? I have no skin in the game and no understanding of what's going on here.

They're both American companies, why would China be involved in this deal?