It's long been said:
"AMD never misses a chance to miss a chance."
In this case, the chance to trash its reputation with customers.
"AMD never misses a chance to miss a chance."
In this case, the chance to trash its reputation with customers.
Hardware vendors lost the plot in the Winmodem era.
The actual problem with winmodems was them breaking the established software/hardware boundary, and the Linux community not having the resources to follow suit.
Nothing stops someone from taking the free Windows Vivado and making it run on Linux, or taking a Winmodem driver and making it run on Linux, or writing a from-scratch software implementation of a 56k modem that can run on any sound card plugged into a phone line (which is what a Winmodem is), or reverse engineering the bitstream format for these FPGAs and writing a compiler from scratch (or even just the device-dependent backend - the frontend and middle-end can be developed in a more normal way and can be shared with other toolchains). But nobody actually stepped up and did it, which I think is proof that the free software community is a lot weaker than it thinks it is.
You could even do it right now, if you wanted to. You're not, and I'm sure there are good reasons for that. Extrapolate it across all developers, and it's unfortunate that it seems none of them have enough reason to do it. On the flip side, if anyone reading this does suddenly decide they have enough reason to do it... (Incentive: FPGAs are fun to play with!)
The EULA and the fact that the linux versior runs faster & has fewer bugs.
> just the device-dependent backend would be a major improvement and the frontend and optimizer could be shared with other toolchains
That's yosys and it's used by smaller commercial vendors.
> or reverse engineering then bitstream format for these FPGAs
Getting the timing is the hard part (+ good routing afterwards). The bitstream format has AFAIK mostly been reversed. 7 series has mediocre support , but US, US+ and Versal doesn't (probably because they're too expensive for personal usage).
Sounds like yosys is good. Why is nobody using it? Why are we all hoping for Vivado instead of just using Yosys?
You can extract the timing information from Vivado. Such information is not copyrightable. You should be able to extract timing data and connectivity data from anything supported by the free version. You could also collaborate with someone with a really fast oscilloscope to gather some timing yourself, though that'll be extremely tedious.
Even if you just get the connectivity data and bitstream format and no timing, that's massively useful for less-than-high-speed projects. A single open source developer just has to make a contribution, doesn't have to do the whole thing in one go. The reverse engineering parts are often the most valuable, especially if they require access to hardware.
You can, but it's not gonna gain broad attention.
> Why is nobody using it?
It's used for chips with a good open source backend (lattice, gatemate). But it's non-trivial to integrate with the vivado backend and doesn't bring many benefits when used as such.
> You can extract the timing information from Vivado. Such information is not copyrightable.
Yes
> You could also collaborate with someone with a really fast oscilloscope to gather some timing yourself
No. Especially not fast-fast and slow-slow corners.
> Even if you just get the connectivity data and bitstream format and no timing, that's massively useful for less-than-high-speed projects.
Not really, you need at least a rough worst-case estimate. Otherwise even trivial designs might not work.
> A single open source developer just has to make a contribution, doesn't have to do the whole thing in one go.
A large part (clocks, routing, LUTs, BRAM, IO, a basic timing model) has to work, otherwise it's not really usable.
It's really non-trivial to get to a basic usable point. I would estimate at least 4-5 very experienced people working on this 2-3 years. Nothing impossible, but also not something that easily happens.
> You can, but it's not gonna gain broad attention.
True I guess nobody ever gave a shit about The Pirate Bay. That project died without gathering a single user.
> > Why is nobody using it?
> It's used for chips with a good open source backend (lattice, gatemate). But it's non-trivial to integrate with the vivado backend and doesn't bring many benefits when used as such.
Sounds like someone should reverse engineer the vivado backend so it's not needed any more.
I think you misspelled "winmodems were completely proprietary and prevented Linux community from writing their own drivers for the hardware".
Winmodems were the beginning of the era of "you cannot be allowed to use the hardware".
(As a technical solution, SDR makes perfect sense. The obstacle isn't technical.)
If you want the platform to be x86 but not AMD then your only other choice is Intel, but they've only recently started making high performance GPUs. So then you need another vendor for the GPU, and your only choice is Nvidia.
A lot simpler, cheaper and predictable to go with a single vendor for both I imagine?
They tried to push the same into the desktop market with their APUs, where it was mostly ignored. But console games only target a couple hardware configurations, making it viable to take advantage of such hardware features
Consoles are always pressured to minimize upfront purchase costs, and they generally replace the vendor-provider SW stack with their own anyways.
Actually looking at this thread, there’s a lot of good reasons they were the go-tos for consoles. Consoles seem to be in rough shape at the moment, I wonder if part of that is that AMD has been doing too well since Zen, haha.
Nvidia never cared much for those types of deals. They preferred to lose Apple as a business than to admit fault, they’ve always refused to compete on price for the business of Sony and Microsoft’s consoles. They’re adamant to beat at the sound of their own drum.
(Note that mention of Steam Linux is not about the games aspect, but about the Valve’s seeming plans to become a competitive target for Linux support to the exclusion of other consumer-focused miscellaneity. But I tend to go on about this too often, and shouldn’t have invoked it here, apologies.)
Baseless speculation
> probably is somewhat of a loss leader for small-batch users
Wrong. AMD/Xilinx doesn't sell devices directly to customers, they sell them to distributors in huge quantities. Those distributors then sell them to "small-batch users", and they're not involved with AMD/Xilinx free-tier software at all.
> they’re running at around -10% profit on small sales to try and drive subscription revenue multipliers
More baseless speculation
Your elided quote removes the five words where I declared my views as speculation openly and in plain language. The complete sentence that you misquoted opens with that:
> I would hazard a guess
I’m perfectly content to be wrong at HN; it’s a forum where we all have opinions and people rarely restrict themselves to exclusively their own expert subjects, or else we’d all never learn anything! So I will be considering the arguments made here by others before engaging with this topic in the future.
Edit: https://news.ycombinator.com/item?id=48256417 from a few days ago apparently makes some of my points much more clearly, or at least with less hostile replies. I wish I’d found it sooner, but I didn’t realize this entire post was a dupe in time to go back through its comments in detail. Would have saved me commenting at all! Ah well.
It might be excusable that they want to vet their customers receiving the tool chain for the high end chips to avoid leaking trade secrets to Intel, but that isn't excusable for the low end. Someone who starts with your $10 chips is likely to develop brand loyalty and if they need $100k chips later, they'll be more likely to pick your ones.
Xilinx/AMD charging for any of their tools is also a recent thing. 20 years ago, you could download these tools freely without even having to register on their website.