Live data from Hacker News

AMD pulls a bait-and-switch on Linux users with Vivado licensing changes

itsfoss.com

161–170 of 171 posts

Re: AMD pulls a bait-and-switch on Linux users with Vivado licensing changes

#161
post #115

Earlier quoted context omitted.

> Nothing stops someone from taking the free Windows Vivado and making it run on Linux 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 Get…

You can just ignore the EULA. Nobody is coming to get you. 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 r…

> You can just ignore the EULA. Nobody is coming to get you.

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.

Re: AMD pulls a bait-and-switch on Linux users with Vivado licensing changes

#162
post #34

Folks feel outrage when companies start charging for things that were once free. Okay, but what if you run a company whose business model no longer supports giving away free stuff? How can you transition? What would users consider less outrageous?

It’s still free on Windows. Your argument doesn’t have legs to walk on.

What argument?

Re: AMD pulls a bait-and-switch on Linux users with Vivado licensing changes

#163

Earlier quoted context omitted.

It depends on the HW:SW cost ratio and the volume. In favourable case the extra bit on the price tag can amount to a rounding error. Moreover, the price tag includes a profit margin, which is usually adjusted to match the competition already. Besides, "ignorant" HN comments on e.g. FOSS software and funding problems have mentioned that the paperwork you have to do to buy software licences can be a PITA, so free softw…

In my Embedded work experience, the BOM costs matters more than SW licensing costs. Which matches the business model of Xilinx. The company I worked for was selling million or tens of million of units per year. So in such cases it's easy to see why BOM costs trump the SW costs of a few licences, and why HW companies would like to keep chips costs down and charging you per SW license. If you haven't shipped million of…

I haven't shipped millions of units but I do have occasional glimpses of the HW side as a firmware programmer. My impression is that decisions regarding costs are not always entirely rational, hence my questioning. Thanks for the answers.

Re: AMD pulls a bait-and-switch on Linux users with Vivado licensing changes

#164

Earlier quoted context omitted.

Nothing about a winmodem prevented you writing a Linux driver. The problem is that nobody did write one.

Details of the hardware were kept proprietary.

Details of most hardware are kept proprietary.

Re: AMD pulls a bait-and-switch on Linux users with Vivado licensing changes

#165
post #85

Earlier quoted context omitted.

Honestly, my mind could never wrap around genealogy and family relations well at all. I thought they were indirect cousin/uncle , or as you say, cousins once removed. Also my understanding of many Asian cultures is they tend to have a much more tight-knit large family structure. And doubling that is the fact they're 2 heads of world-level hardware tech companies. And, well, there's no such thing as coincidences. Havi…

Well, but there absolutely are such things as coincidences. It is obvious that coincidences are to be expected. Combinatorial mathematics actually says certain types of coincidence happen more often than we seem to expect intuitively (eg. the Birthday "Paradox"). I have no particular view on AMD. But any argument that includes "I don't believe in coincidences" should probably be weakened in your estimation.

Adam Smith warns that "people of the same trade seldom meet together, even for merriment and diversion, but the conversation ends in a conspiracy against the public, or in some contrivance to raise prices". Book I, Ch. X, Part II; ~p. 54 .

A meteor or some natural phenomenon can be a coincidence. But especially so in industry, especially the same industry... with the respective CEOs as family, i wholeheartedly reject "coincidences".

The C word that should be used instead is "conspiracy".

Re: AMD pulls a bait-and-switch on Linux users with Vivado licensing changes

#166

Earlier quoted context omitted.

Details of the hardware were kept proprietary.

Details of most hardware are kept proprietary.

A lot of hardware that has had Linux drivers written for it is specced openly in this style: https://www.intel.com/content/dam/www/public/us/en/documents...

Re: AMD pulls a bait-and-switch on Linux users with Vivado licensing changes

#167
post #70

Smacks of collusion honestly. Maybe Microsoft offered them some kind of deal

I’ve always thought they were colluding with Nvidia, but then I suppose it could be both!

They've got a documented history of trying to strongarm everyone they can

Re: AMD pulls a bait-and-switch on Linux users with Vivado licensing changes

#169
post #161

Earlier quoted context omitted.

You can just ignore the EULA. Nobody is coming to get you. 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 r…

> You can just ignore the EULA. Nobody is coming to get you. 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 > Yo…

> > You can just ignore the EULA. Nobody is coming to get you.

> 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.

Re: AMD pulls a bait-and-switch on Linux users with Vivado licensing changes

#170

Earlier quoted context omitted.

Details of most hardware are kept proprietary.

A lot of hardware that has had Linux drivers written for it is specced openly in this style: https://www.intel.com/content/dam/www/public/us/en/documents...

And a lot of it isn't.
Post reply on HN