The only reason why the "Linux community" cannot create adequate FPGA design tools is that the vendors like AMD refuse to document the necessary details of their products.
A few old AMD FPGAs have been reversed engineered, e.g. some ARTIX-7, so for them there is no need for the rather bad AMD tools, but for most AMD formerly Xilinx FPGAs it is impossible to create better tools for lack of documentation.
As long as AMD refuses to provide the technical documentation required to use their products, it should have been a legal obligation to at least provide basic tools that allows the buyer of such products to actually use "FPGAs", i.e. to "field-program" them, as the name of the sold product claims.
Like many other FPGA developers, I could write myself better FPGA development tools than what AMD provides, if I had access to the complete FPGA technical documentation to which only a few big companies have access, a restriction whose only possible purpose is to prevent competition in the FPGA market.
If AMD had documented the exact format of the bit stream required to program each model of their FPGAs and the complete timing consequences of each synthesis choice, nobody would need any FPGA simulation or synthesis tool provided by AMD in Vivado.
It's no more a bribe than having to pay money to buy the latest C++ standard when implementing a C++ compiler. The reality is that companies pay each other for partnerships all of the time. There is value to AMD for keeping this documentation secret and there is value for having control over what design tools exist for them. It makes sense that AMD would want to be compensated in this case and would not want to do work for free which could undermine their business.
The hardware is not in a broken state of usability since you can still buy usable design software.
> It's no more a bribe than having to pay money to buy the latest C++ standard when implementing a C++ compiler.
The C++ standard group didn't just sell me a piece of hardware that only runs C++, in a world where no free C++ compilers exist.
That analogy isn't even close.
> There is value to AMD for keeping this documentation secret
It's a value that doesn't deserve respect.
> It makes sense that AMD would want to be compensated in this case and would not want to do work for free which could undermine their business.
Their business is selling the hardware. Their money should come from selling the hardware.
I'm not demanding a free full-featured development environment. I think they should have to document the hardware and maybe provide a basic compiler. If they want to sell something beyond that, no problem.
> The hardware is not in a broken state of usability since you can still buy usable design software.
And if you don't?
It's a fixable broken state with enough money, but it's still a broken state.
Then how about the instruction manuals for the processors themselves. It's really not that different. People spend a lot of time and resources building something and compiling information and you are demanding to get it for free.
>It's a value that doesn't deserve respect.
It does deserve respect as a lot of people put in work in creating it and creating a successful product. If you think it's not that much effort to do then find someone to make their own FPGA and documentation for it.
>Their business is selling the hardware. Their money should come from selling the hardware.
It is rare for a business to be so 1 dimensional. Businesses have many income streams. Even for the same product. Take for example the iPhone. Apple gets income from people buying the device. Income from companies for letting them sell things in the App Store. Income from Google for setting Google as the default search provider.
>And if you don't?
If you refuse to get a compatible computer for the free software to flash the chips then you can't flash the chips for free. The chips are still fully functional and if you sold them to someone else they could program them.
> Then how about the instruction manuals for the processors themselves.
Those should come with the processor.
> People spend a lot of time and resources building something and compiling information and you are demanding to get it for free.
Documentation for a product should always be "free" when you buy that product.
Which is far from being "free" in the normal sense of the word.
> It does deserve respect as a lot of people put in work in creating it and creating a successful product. If you think it's not that much effort to do then find someone to make their own FPGA and documentation for it.
I respect the effort. I don't respect the competitive advantage gained by withholding documentation.
Was my meaning that unclear? I quoted the exact thing I don't respect.
> It is rare for a business to be so 1 dimensional. Businesses have many income streams. Even for the same product. Take for example the iPhone. Apple gets income from people buying the device. Income from companies for letting them sell things in the App Store. Income from Google for setting Google as the default search provider.
Some of those streams are more acceptable than others. Apple's income from Google is fine. Their income from the App Store would be fine if it wasn't mandatory, and is much less fine when it is mandatory. Paid documentation is pretty far into bad territory.
> If you refuse to get a compatible computer for the free software to flash the chips then you can't flash the chips for free. The chips are still fully functional and if you sold them to someone else they could program them.
In this case you can get Windows.
What if they stopped having the free Windows version either? Because the way you're talking about this situation it sounds like you would also call that acceptable.
They are useless for most people who buy the processor, even transitively. For people who will get called out of it, it makes sense to let companies charge for that value.
>Documentation for a product should always be "free" when you buy that product.
I feel this viewpoint does not value the work it takes to compile all of this information. Nor does it acknowledge how full documentation could reveal sensitive information. There is no reason for consumers to need to know how microcode instructions work since they will never be able to properly sign a microcode update. People will always like getting valuable stuff for free so you can't justify something by looking at how happy people are by getting value for free.
This also gets into a potential slippery slope where things like schematics or repair information, or even source code is forced to be given away for free. Confidential IP is a common part of many businesses and offers a tangible competitive advantage.
>I don't respect the competitive advantage gained by withholding documentation. Was my meaning that unclear?
What I was implying is that by forcing people to give up their hard work for free you are calling their work worthless. Finding innovative ways to make a product better deserves to be rewarded.
>Because the way you're talking about this situation it sounds like you would also call that acceptable.
I do think it's acceptable. I also think it's acceptable for them to charge money to sell you a programmer to use with the chip too. I don't think they have to give you the physical hardware to flash it with every chip they send you.
I'm not at all calling it worthless. It's very valuable. But I think it's a value that every owner deserves access to. And for IP licensing? If it's mandatory companies will figure it out.
If your competitive advantage needs you to not even release documentation, does it really? Really? Well the societal benefits are more important, sorry.
And it's still not giving up work for free. It's telling companies to sell these two things together.
A physical programmer is different because those have a marginal cost.
>Then how about the instruction manuals for the processors themselves. It's really not that different. People spend a lot of time and resources building something and compiling information and you are demanding to get it for free.
x86_64 processors maintain backwards compatibility. This means you can reverse engineer one chip and then have your software work on a different processor from a different company.
FPGAs don't even retain compatibility between different sizes of the same base model. If you reverse engineer one chip that's only one chip.
>It does deserve respect as a lot of people put in work in creating it and creating a successful product. If you think it's not that much effort to do then find someone to make their own FPGA and documentation for it.
I'm not sure why companies and online forum people defending the company are so obsessed with making their products less valuable, driving away customers and making less money in the long run. The financial incentives point exactly in the opposite direction.
>It is rare for a business to be so 1 dimensional. Businesses have many income streams
Why does it matter if it is rare? The only thing that matters is that you're making money. Why do I have to explain this?
Nvidia obtained a 5 trillion market by selling the hardware and giving the software to program and run on it away for free. Why do you hate it when AMD makes money?
Linux developers are supposed to build their own software and to do so they have to pay AMD for documentation under an NDA that prevents them from developing an open source toolchain?
What kind of logic is that? This is especially stupid since AMD benefits from every single FPGA sale so all they did was reduce the number of FPGAs they will sell, by locking out customers.
It's a pretty low risk if you don't put your identity out there. I know there's at least one Git forge that's a Tor onion service. Even on GitHub 99% of the time this ends with a DMCA takedown of the repository. You should probably put it on a pseudonymous alt account but you don't actually need to use a Tor onion service.
You could also get someone else to put their name on the web hosting and so on. Don't know who exactly, but there are a lot more people willing to take legal risk of having reverse-engineered an FPGA toolchain, than people who can reverse-engineer an FPGA toolchain. Doing the work is what's most important, and the rest can be figured out later. But you don't even see that. You don't see people being like "I reverse-engineered Vivado but I won't give you a copy because I could get sued."
"Doing the work is what's most important, and the rest can be figured out later."
I would say for most people his means they won't start the work if they don't know whether there is a way. Also most people like to get credit for their work. So the number of people capable AND willing to work without getting credit is low. And that is not surprising to me.
It is not my skill set, but I certainly would not invest much into something like this.
> You don't see people being like "I reverse-engineered Vivado but I won't give you a copy because I could get sued."
Eh, not Vivado, but back in my undergrad days I RE/cracked a tool used in a very specific niche and definitely kept my mouth shut as the developers could a) do some investigation and then sue me, a student without any legal budget to spare; b) improve copy protection on future releases; and/or c) prevent my access to future versions of the tool that I was using for my thesis.
On other threads about Denuvo you always see somebody saying they've got the chops but the risk to their livelihoods is not worth it.
I think there are a lot of (now) hobbyist reverse-engineers that learned the craft back in the day and kept the knowledge for themselves.
The only reason why the "Linux community" cannot create adequate FPGA design tools is that the vendors like AMD refuse to document the necessary details of their products.
A few old AMD FPGAs have been reversed engineered, e.g. some ARTIX-7, so for them there is no need for the rather bad AMD tools, but for most AMD formerly Xilinx FPGAs it is impossible to create better tools for lack of documentation.
As long as AMD refuses to provide the technical documentation required to use their products, it should have been a legal obligation to at least provide basic tools that allows the buyer of such products to actually use "FPGAs", i.e. to "field-program" them, as the name of the sold product claims.
Like many other FPGA developers, I could write myself better FPGA development tools than what AMD provides, if I had access to the complete FPGA technical documentation to which only a few big companies have access, a restriction whose only possible purpose is to prevent competition in the FPGA market.
If AMD had documented the exact format of the bit stream required to program each model of their FPGAs and the complete timing consequences of each synthesis choice, nobody would need any FPGA simulation or synthesis tool provided by AMD in Vivado.