There are in fact parts that have CPUs included. However these aren't always the best route. Sometimes you don't want a CPU in the design at all, since software is SLOW compared to RTL designs for certain applications (DSP, Data acquisition, etc).
Xilinx has a number of SOC parts that bundle ARM cores alongside FPGA fabric, and they're very tightly coupled to make passing data between them very efficient. These include the Zynq and Versal families.
There are already some open source cores out there, including NEORV32. There are also closed source ones, like Xilinx's Microblaze IP. Which comes in both ARM32/64 variants, as well as RISC-V now.
I honestly think this is it, and it's not arbitrary. I think it's because really any build server will be running Linux (either natively or via Docker). AMD/Xilinx probably thinks "Build Servers are an advanced use case, so not covered under the free license"
I would like to preface this with the fact that I hate this new change. As a professional FPGA Engineer, who has exclusively used Xilinx parts for most of my career, I figured I'd offer my two cents.
Vivado was never open source to begin with. So I don't see how this would allow more back doors to be in the program, and I'm also not sure what you mean by a back door in this context. Do you mean making Vivado install back doors into the bitstreams themselves? If so, this would be difficult to do given there are independent tools out there that allow you to verify what is in the compiled netlist (which is an intermediate step in a design) vs the HDL (Hardware Description Language, the type of Language that is used to program FPGAs, main ones are VHDL and Verilog). There's also some new tools coming out do compare the bitstream against the net list. With these tools, you can all but guarantee there aren't any back doors or Trojans in the design.
Vivado is also already export controlled IIRC. At the very least, you've always had to input your country/address/etc due to controls on it. I'm in the USA, so it's never been a problem, so I don't really know what happens for people in, say, China. It might just be for logging/tracking purposes, and then in the future it could get locked down, so you may be right on that count.
I have started using LLM tools recently after taking a new job where a lot of people do it. I've discovered that it's actually fairly helpful not only for explanations, but in two other respects
Sifting through immense amounts of documentation. I have to deal with some datasheets that are hundreds of pages, where there will be info scattered throughout. It's very helpful sifting through those.
Doing boiler plate "plumbing work" in my code. I'm mostly drawing a line where I don't want it doing the "core" work in that which I'm an expert, since I agree that if I stop doing that, I'll atrophy. However it can help accelerate my process if I pass off some of the minutiae that I don't feel the need to do.
However all that said, I am honestly pretty impressed how well it works. I've mostly been using Claude, and damn, it's honestly pretty competent. I had it make me a helper Python GUI program for me to test some stuff (I'm not a UI/high level engineer like that, I'm an FPGA Engineer), and it did a decent job. It definitely needed a good amount of massaging and guidance. However I can definitely see the appeal, and I think it's a slippery slope, and I need to make sure I remain disciplined in not letting it do everything
Can I get an ELI5? My understanding is that easements are the fees that customers (either individual or community) pay to get the equipment/infra run to their property for service.
Are you saying that customers wouldn't have paid those easements if it was the normal telecom company doing it, as opposed to Google? If so, what are the "damages" in this case? I'm not understanding for what you could sue.
Yes, you are correct. I guess baked penne would be a better name. My SO doesn't like Ziti.