To grow the ecosystem, AMD needs more people working on their hardware. Restricting Linux will only alienates students, hobbyists, and devs who want to adopt AMD tech.

- From long term AMD user

They're not perfect, but they're better to work with than Xilinx. Also, their datasheetd are better than Xilinx in my experience.

Give Lattice a look for your next project.

Windows cannot provide feature parity for workloads that require cross compiling, AMD could at least support RHEL like the old days.

Trying to shrink that community seems like a pretty obvious error. The closest thing the Altera world ever had were the old Altera user forums, which were a gold-mine. Intel shut them down immediately on acquisition. I guess it's AMD's turn.

1. The Xilinx team are pushing back on the increasing number of things they have to support. Silver lining, maybe this means they're being asked to work on a new product that will require redistribution of headcount (like maybe another NPU )

1.1. Their Linux expertise is lacking / stretched across multiple teams (this is the impression I got from following the work in github.com/amd/xdna-driver over the last year or two). Maybe this is the outcome of a 'these are the things i'm doing now, so if you want me to do something new then tell me which of these things I can drop' type conversation & where the pushback is coming from (maybe we'll get some fedora support in that repo though ) .

2. Marketing have been pushing for something that helps them 'fight the AI fight', and it may be that they've now been given the mandate so the division is in the midst of the typical top-down mythical man-day reallocation wave. Xilinx have probably been told that priorities are shifting towards integrating more of the Xilinx inference tech with more mainstream AMD products, possibly at the expense of their existing roadmap. Xilinx have tenured employees who know what they're doing and don't want to retrain/change, so this is a side-effect of the pushback.

3. This is a straight-up monetisation strategy. Marketing ran a project and concluded thta it's just not worth supporting that lower tier for free. It may be that even though have a majority Windows userbase, the [commercially serious | higher stakes | CICD pipeline based] development actually happens on Linux, and this is them closing that loop. Not quite a Docker Desktop situation, but maybe not that dissimilar - they're saying that most professional/commercial users are Linux users, and the days of unlimited free commercial use on the smaller devices are over. Maybe the margins on those lower end devices aren't good enough to justify the amount of support overhead, and pay-to-play will filter out the noise and ensure they're talking to users who are already bought-in. Or, maybe somebody just needs an earnings blip on a slide somewhere, and this is them milking their startup/smb customers.

My guess is it's all of the above.

I am still contemplating my options. I can still use Vivado 2025, I guess, but I am not sure that is the right direction.

What are realistic alternatives for Vivado? (Taking into account the availability of supported affordable entry-level dev boards?)

The market is full of dark patterns, and vendors like AMD/Xilinx can pull shitty moves like what OP highlighted, knowing there is no decent alternative (Altera is another disaster). Lattice had the opportunity to fully embrace opensource toolchain and try to disrupt from the bottom, but they seem stuck in the middle, not wanting to commit one way or another.

I'm grateful to SymbiFlow, and IceStorm and others, even though they obviously lack support for proprietary hardware features.

One day held the world’s data centers are crashed and the next day we find the AMD C-suite has all resigned and all the leadership of the FPGA division. But it’s not enough now, to get Linux support back they have to make Vivado Linux exclusive and free at all levels.

However, Xilinx Vivado and Vitis are so obtusely distributed, making it incredibly hard to package them well.

Three random issues I remember:

1. We had a lot of trouble with Vivado projects randomly breaking. The culprit: German localization combined with automatic clock frequency derivation. Depending on which logic blocks where wired up how, you would get i.e. 99.999 MHz instead of 100 MHz. Apparently, Vivado uses a localized printf (or equivalent) to generate TCL scripts. In German localization, the decimal is a comma, which is interpreted as additional argument in the TCL scripts. 2. For simulation, scripts scripts are copied from a template folder to the user folder, and subsequently adjusted. They are copied in archive mode. If the template is read-only to the current user, so is the new copy, thus failing the subsequent adjustment. 3. If you run the installer with --help as argument, it pops up an X window displaying the help. In general, IIRC, we need to run a headless X just to run the installer in CLI/batch mode.

From a Linux distro maintainer perspective, the packaging is horrible. In particular separation of base installation, configuration, and add-ons is non-existent. Large amount of vendored dependencies, only then to depend on the most minute little packages that Ubuntu supposedly ships.

Setting up a reliable, reproducible CI/CD environment based on Vivado is a large headache.

That all goes to say: if anything, AMD/Xilinx should be paying its customers to deal with this. Unless there is a major improvement in the software distribution practices for Linux, I could not justify to my employer paying money for this experience.

On the other hand, if they commercialize on Linux support, there is soooo much that they can improve by a lot, who knows. Hope dies last and all.

1) This could actually be an attempt to gain more revenue from big customers that have users who use the free version to test that code can synthesize and run unit tests (by pretending to use smaller parts), and then only use the paid version for the final integration into the actual larger parts.

2) This could give them more customer data more easily. They make no secret of the fact that the free tiers share data with the mothership for product improvement reasons. Maybe they only want to maintain the infrastructure to do this on Windows, or maybe it's harder for customers to subvert on Windows.

3) There will be people running the Windows version on Linux, and explaining how to do it, in 3... 2... 1...

I want a robust open-source ecosystem where anyone can take my hardware projects and modify them without needing to deal with licensing friction.

Another casualty of this will be running the tools in docker containers, some folks have made some good templates for them and they greatly simplify deployment/installation.

(I used to prefer the AMD/Xilinx dev setup, but that has been a bit, and using FuseSoC makes moving platforms a lot easier).

I can understand that they wouldn't reply to the user but the way he replies is aggressive and would motivate me more to insult AMD and co that have a civil exchange.

That being said, it really sucks when companies do such asshole move as forcing you to use windows. Especially because it was not even AMD in the first place but they snatched xilinx and now will try to use the big tech playbook.

Even Apple, possibly the greediest company in the world, knows the importance of cheap hardware and free software for students. Because those students and amateurs eventually become pros who make money decisions.

AMD is always so close to pulling ahead of Intel and Nvidia but somehow manage to shoot themselves in the foot constantly...

https://www.youtube.com/shorts/tQIdxbWhHSM

Not saying I agree or support this decision, but I can see why they chose to do this, and their set of paying customers is quite different from your average piece of software.

If this were Google, they'd have made the whole backend of it cloud only, and required all customers to upload all data to their servers. Obviously this doesn't fly in a lot of industries FPGAs tend to be used in.

I see no problem with monetizing Linux users. If I am monetizing Windows and macOS users, there should be no exceptions towards Linux especially as Linux support is always ill defined (there are hundreds of distros to support and test.)