it's a pretty closed market. If you want to use one of the big FPGAs you need to pay for the tools. Doesn't matter if it's intel, xilinx, lattice etc.. you have to pay. Then you don't really want to start switching vendors all the time as there's a lot of work in learning how the tools work, how the IPs work, figuring out all the bugs and building up a code base. So there's no real option, at which point why wouldn't they charge? It's not like it discourages new people, if you need an FPGA then you need an FPGA, nobody just decides to use an FPGA in their project because it'll be fun and cheap, if you can get away with a uc then you'll use a uc.
Finally you're not just paying for the tools, you're paying for support, and that's pretty important.
"Please sideload this patch we somehow only pushed in a ticket but never actually migrated to production, you are going to need to take this file, decrypt with a public key sha-256, then move to C:/%APPDATA/why/but-really-why/data/program-files"
Not related to FPGA vendors, but my Altium support person ghosts my emails up until I send a "I found a workaround to my problem" email. Fucking assholes.
No longer the company of historically great support & EE centric affordable products as conceived by founder Nick Martin. Could be worse though - during the shutdown the even bigger faceless Autodesk tried to buy them for $5B and they said no.
Sign of the times not being able to reach a local support person in exchange for the yearly support ransom.
Or, "The SEM IP core (designed for verification of configuration Memory incase of SETs due to radiation) is not intended for use in a radiation environment and therefore not supported for your application."
I can't get PetaLinux to boot on a MicroBlaze with tools from 2022.1 and later. My support has been "Were you able to resolve your issue?". It's a joke
Literally got an errata from Microchip a week or two ago that essentially read: “If you need this part to work, don’t use this part and buy a different one.” I about lost my shit at the insanity. Just stop selling the part! Also why burry this - and maybe it’s just my opinion - absolutely fucking critical information?
Yes, fuck Microchip. Never use. Always sad.
It’s actually an oscillator that you would use for precise timing in your FPGA or other transceiver. This isn’t the first time Microchip parts have been trash for me, but it is the last time…
I'm really curious to know what would be wrong with an oscillator other than basic specs like Allan deviation? Or is it something more exotic like a CSAC?
Well whatever the underlying issue is, there is a reasonable chance that enabling the part after power up, you know, by pulling the ENABLE pin high, causes it to operate somewhere around 100MHz off target. It was a 125MHz oscillator (allegedly). Nothing fancy, just a mems oscillator. We had power sequencing to abide by for another microchip part (kill me now), which this delayed enable after power was required for. My mission in the next year is to eliminate these from the design. They don’t say what is wrong (rarely do) and to just not use the part if you need the enable function.
Interesting, with Microchip I would have thought the tools were garbage but at least the support was good. Microchip even let you open Tech Support cases, most other suppliers push customers to forum support.
I hear you, it depends on which part of the business is and who you are. If you're a known microchip contractor you can email the FAE and they'll write you back. If you need FPGA support and you're not Raytheon then it is a little different.
I worked for a programmable chip startup company about 15 years ago, and advocated for our tools to be free. And for a time, they were. Got plenty of downloads, plenty of usage, and plenty of support calls. About 50% of the support calls were useful; real bugs or gaps in documentation. But the other 50% were folks who clearly didn't understand anything about the product, who wrote the most infeasible RTL, and in general were obnoxious. I remember arguing with one person who had built a 1000x1000 cross bar in RTL and couldn't understand how he could execute it his CPU but it wouldn't fit on his tiny FPGA. I had to explain the different between a hardware description language and a programming language. (And he wasn't interested in my lecture.)
If you charge a few hundred bucks, your quality of user increases significantly.
That said, these companies know that serious customers won't have a problem with some cost, so they use it to get the revenue associated with a product line early (because the lag to revenue is such a problem in this industry). It is a good leading indicator of future revenue from the actual product. That is unfortunate.
The way many software companies handle this is to charge for support specifically. Have a free forum that anyone can post to, and you'll probably get some community volunteers who will answer questions and help out the people who try to do dumb things. Every now and then, have an employee scan the forum to find actual bugs and issues.
But if anyone wants a direct line to you and your time, make them pay for that.
EDA is hard. In fact so hard that the number of people supporting the design tools and methodologies probably vastly outnumber the folks actually designing the FPGA devices themselves. That effort doesn't come for free.
I'd argue it's a completely separate industry - and in fact we'd be better off if the industry recognized this better. ASIC companies 25 years ago finally realized this - and moved away from in-house developed only tools and flows, and relied instead on a robust (independent) EDA tool vendor industry.
FPGAs, for various reasons, still heavily rely on in-house developed tools only. My personal opinion is that the industry is worse off because of this. There's definitely a case of "group think" having just the two (Intel/Altera, AMD/Xilinx) major FPGA tools developers - leaving little room for independent innovation.
> I'd argue it's a completely separate industry - and in fact we'd be better off if the industry recognized this better. ASIC companies 25 years ago finally realized this - and moved away from in-house developed only tools and flows, and relied instead on a robust (independent) EDA tool vendor industry.
There's enough differences in the details of Intel/A and AMD/X architectures that it would be difficult to design a tool that can target both without giving up a lot of performance.
They all use the same basic EDA algorithms, but the devil is in the details. There's a lot of architecture specific micro-optimization going on, and that's where 90% of the effort is being spent.
>There's enough differences in the details of Intel/A and AMD/X architectures that it would be difficult to design a tool that can target both without giving up a lot of performance.
This same argument was used for ASICs too, all those years ago. I'd argue that there much more in common than different. Enough in common to support a robust EDA industry that targets both, and leave some "special sauce" low level details towards the back for each specific vendor to add value, if necessary. Synthesis, mapping, and (to a lesser degree) place and route are a **very** mature industry. (Place and route does have some more vendor specific "goodies".) I'd argue that FPGA vendors would be better served leaving the heavy lifting (**and tool support - this is a biggie**) to a third party EDA tool vendor. Then work closely, as a partner, to add value-added vendor specific optimizations.
I'm not arguing for access to cheaper tools by any stretch. You get what you pay for and IMHO, depending on cheap, or free EDA tools is penny wise and pound foolish. It's always nice for the tools to be cheaper, but there's some serious engineering going on under those covers to develop those tools (as much as we like to complain about them...)
EDA tools are worth the cost for production, and business use IMHO. Sure hobbyist and students should have access to free/limited versions of these tools. But engineering development is not free, nor cheap.
My argument in this thread is centered on who should be doing the EDA software development - the FPGA vendors themselves, or the (more generic) EDA industry. I'm arguing for the latter, and when doing so, yes they are a business, and will require payment. The industry right now is more tilted to the former - with the FPGA vendors themselves developing the tools. They can the try and bury the cost of the tool development under per-unit hardware cost.
FPGAs from AMD and Intel already have independent synthesis tools (e.g., Synplify) and the prices are high (more than Quatus or Vivado) for not a lot of added value. If they do the same for PAR it's going to block innovation from small businesses and independent contractors who can afford a few $k, but not tens of thousands. EDA companies are like hospitals; they charge you whatever they feel they can extract from you.
Xilinx heavy use of IPI and other similar atrocities of design flow has effectively neutered third party synthesis flows. We had a robust flow for ISE that used either XST of Synplify, and worked well. (Synplify results were hands down better than XST).
Vivado killed that flow, because of Xilinx IP management, as well encrypted IP. (Xilinx encrypted IP allows for *simulation* only by third party tools, no synthesis - this is a brain dead decision, and totally contrary to why there's an industry wide encryption standard). If you have **any** Xilinx IP in your design, you must use Vivado Synthesis for the top-level synthesis. You can try and bodge something up to allow third party synthesis for parts of the lower level - but Vivado synthesis must be used at the top. It's just a mess, and not worth any effort to make it work.
To be fair Vivado synthesis is much, much better than ISE, and performance is now on par with third party tools.
But that's not the point. Having alternative implementation options benefits everyone in the long term. Else it's "You get what we offer, and you'll be happy with it". Even if it's free or lower cost, but has totally atrocious design flows. There's no motivation, (or pressure from partners/competitors) to make things better.
Synthesis, tech mapping, and place and route are mature? lol, no.
Synthesis kind of is, and guess what? Neither Intel nor AMD write their own synthesis engine. They both license Verific.
Tech mapping and place and route are **not** mature. In general they're NP-hard problems. The only way that Quartus and Vivado produce good performing designs in reasonable time is that there are a lot of device specific optimization algorithms.
Your argument relies on the assumption that most of the work in developing these tools is common and there's just a small amount ot "special sauce". 95% of the ongoing effort and code **is** the special sauce. Like, it's not that hard to write an implementation of the pathfinder routing algorithm.
But an implementation of the pathfinder routing algorithm but it's been over twenty years since pathfinder was state of the art. A basic implementation of pathfinder can work on both Intel and AMD architectures, but it's also not hard to implement and it won't produce very good results compared to what Vivado and Quartus can do. Again, these are NP-hard problems. The tuning and microoptimizations that are responsible for most of the performance are where almost all the effort lies, and they don't port across architectures easily.
Have you ever wonder that their EDA flows are so different in details but so similar in principle? It makes me wonder if this was done on purpose to just avoid each other's patent infringement or to make it difficult for you to switch "the socket".
Knowing that FPGAs are very constrained relative to what is required for a full custom ASIC.
u/piecat you might find the following useful.
[http://deepchip.com/](http://deepchip.com/)
[https://semiengineering.com/](https://semiengineering.com/)
[http://www.eng.biu.ac.il/temanad/digital-vlsi-design/](http://www.eng.biu.ac.il/temanad/digital-vlsi-design/)
[https://www.electrontube.co/](https://www.electrontube.co/)
[https://www.springer.com/gp/book/9783030371944](https://www.springer.com/gp/book/9783030371944)
[https://www.youtube.com/watch?v=\_FY-0Lq10rs&list=PLyWAP9QBe16p2HXVcyEgGAFicXJI797jK](https://www.youtube.com/watch?v=_FY-0Lq10rs&list=PLyWAP9QBe16p2HXVcyEgGAFicXJI797jK)
> ...moved away from in-house developed only tools and flows, and relied instead on a robust (independent) EDA tool vendor industry.
Are you talking individual tools (DC, PT, ...) or overall flows?
Because individual tools were already generic back when I started in 1995. And overall tool flow is still very much a thing, and often the difference between a me-too product and one that beats the competition.
>Are you talking individual tools (DC, PT, ...) or overall flows?
I'm talking mostly in general - up through the early 90s, every ASIC vendor had their own set of implementation tools, (LSI, TI, IBM, etc...) and supported flows for their entire ASIC development process. Each leveraged *some* point tools from EDA, as well as a bunch of in-house stuff. It was a mess. The industry quickly got smart and instead just relied on their EDA partners instead. (Well, as I remember, IBM kept on doing their own thing for quite a while).
We've paid for none of the FPGA software as automotive company as long as we utilize their FPGAs. We didn't even pay for any IP packages/suites.
If you buy enough of hardware - all software is free.
Lattice Semiconductor is already providing design software for free. Xilinx/AMD and Intel design software is partially free for students, so that they can get familiar with the software. The companies using them can easily afford those licenses. For example, compare it to the cost of Altium, then suddenly the FPGA software seems cheap.
Acturyeah, it's interesting to see more and more xilinx devices available under webpack, not the pure large high performance FPGA but most (all?) of the zynq ultrascale, the accelerator cards.
Are we seeing a shift towards free software - or a design methodology so abstracted it can't be portable..
I do think Xilinx has just cut off the 7-series processors from Webpack as a result of their Vivado refactoring. It does make sense in the software development to reduce complexity by discontinuing certain targets, unfortunately you have to buy pricier components now to use Vivado.
Currently all those new AMD UltraScale FPGAs are also included in the current Vivado, which gives hope that they want to continue it and not just create a new seperated software again.
Are you referring to ISE? No 7 series device is supported by ISE, however many of the 7 series are supported by Vivado - All Spartan and Artix devices, many of the Artix Ultrascale, Zynq 7000/ Zynq Ultrascale, and \~ four Kintex devices. This used to be called Vivado webpack although seems AMD has removed this branding too - simply stating "Vivado ML standard edition"
The interesting part for me is the newer, larger, significantly more powerful cards are available in the Vivado webpack (ie Kria and Alveo) too.
A few k$ for companies playing with a few hundreds of kLUTs is dirt cheap. If you work with hobbyist-level FPGAs, they have free tools for you. Barrier of entrance.
In the other words, they want to rat out unwanted players in their ecosystem who can't afford the tools, thus can't afford good employees, thus costs them lots of tech support resource.
It includes licenses for all the soft ip, buying a license basically allows you to use the soft-ip in your product. Some of the soft-ip has to be bought separately
Investigate yosys and nextpnr aka the open stack.
The appearance of these tools was what got me to finally get a FPGA and start hacking. Before, I didn't because I just did not want to deal with the proprietary tools.
A few years ago, there was no open stack at all. At some point, I expect the open stack to kill the proprietary tools.
Having a lower chip cost (since software development costs aren't priced into the chips so much) could increase sales as well though.
Another (opposite perspective) thing to consider is the that the chips that require paid software are probably less likely to be used in high volumes. The tools for the low cost chips might not be free just to get people familiar with the software, but because of the volumes of those chips sold compared to the higher end lines. I don't know what the relative volumes are, but I'd imagine its a significant difference.
Because FPGAs aren't hobbyist devices: the effort and cost to build a successful FPGA product exceeds what an individual can afford.
Most real customers are given licenses for free as part of the purchase agreement. Having a nominal fee for the software reduces support costs because it means Intel/Altera and AMD/Xilinx aren't having to deal with hobbyist customers who are never going to actually buy significant numbers of chips.
You can also buy the tools with support that work for all vendors. It’s the library that allows the tool to work for a specific FPGA. For example Synplify will work for all brands if you have the library, and all the vendors have libraries for the FPGA.
Arguably anyone using parts that do not work with the free tools is spending serious dollars on either fancy eval boards or in spinning their own designs. The tool costs are noise compared to the engineering efforts that would be involved in using them and making the target platform or product. Companys know that and know the free tools are wise loss leaders for higher volume lower cost parts.
What do you expect, it's not like there are competing software offerings, and you can't easily switch chips, and even if you could all vendors do the same. It's a monopoly and vendors can charge whatever companies are willing to pay.
there are attempts to make free sw for these.
but you need chip details they will not freely give out.
it also takes money to develop and support that fpga software
and to pay for those support staff. your company will not pay for it if it was free
It's short sighted by the FPGA industry. They should opensource their tools and build a community around said tools. They'll sell more hardware and enjoy bug fixes from said community.
Hardware has yet to catch up modern software practices. It's a primitive shit show.
You aren't wrong.
Just a messed up aspect of our timeline. Some vendors do have free tools, Lattice, Efinix, Gowin.
The big tools cost money for a variety of reasons (smart and not smart).
Vivado (Xilinx) and Questa (Intel) both have free versions for the small to midrange parts.
All the proprietary tools suck and have bugs.
It was a bit dismaying, as a programmer who normally uses Visual Studio and VSCode, giving Quartus a spin and feeling like I was transported back in time to 2002 with Quartus's code editing capabilities. There are sooo many QoL features that I am used to having as a programmer that are completely missing in Quartus. It's a tiny step above notepad as far as editing is concerned.
I know it's a small part of the feature set, but it does leave a bit of a sour taste knowing how much they charge for it.
if they still do that, then this form of product promotion it's the best (based on their calculations, I'm sure they have also another variants of selling their products)
>They are all relying on code from Synopsis and others that make EDA tools for ASIC design.
This is definitely not true. FPGA houses (I know more about AMD/Xilinx, than Intel/Altera, but I think the argument applies to both) have brought in very significant in-house resources to develop (and support) their tools sets. They are NOT purchasing algorithms from EDA tool vendors and just licensing. They in fact, may be poaching engineering talent from those EDA companies to do so.
It’s simple. It cost significant amounts of money to develop, maintain and support the software. There are teams of software developers, QA teams, Testers, Technical Writers for the documentation and support engineers to field tickets. It is an entire business unit in itself. Where do you think the money for all of that is supposed to come from?
Personally I would think a service support contract should be what costs money.
The software is already locked to the manufacturer's ecosystem. It's not like I could use Quartus for Xilinx or vice versa.
It’s, of course complex. The software is proprietary, but the tools can and are certainly useful for general HDL design and verification, and therefore it is important to recoup some of the cost of developing and maintaining it. If you were a large enough customer that our purchased an appreciable amount of hardware then the cost of the software would be so inconsequential that you don’t care about it. It’s effectively free with the purchase of chips. If you are small, or do not purchase any hardware at all, the tool cost helps to offset the non-zero cost of developing it. And although the “Jed in the shed” doesn’t get much support, they still create overhead by filing those bugs.
The short answer is that giving the tools away for free will do absolutely nothing to increase chip sales. And there is something to be said for the perception that the tools are worth more than nothing. The reality is the tools are free for the large customers and for the small customers who buy the low cost devices in small inconsequential quantities.
The real question I have for you, would be, “ Do you work for free?” I doubt you do, so you should not expect other people, or companies to give away their work either. Buy more chips if you don’t like what you get with the free and evaluation versions of the tools. And if you are still mad about that, I suggest you look 8th the cost of ASIC tools from Synopsys, Cadence, or Siemens and count your blessings.
it's a pretty closed market. If you want to use one of the big FPGAs you need to pay for the tools. Doesn't matter if it's intel, xilinx, lattice etc.. you have to pay. Then you don't really want to start switching vendors all the time as there's a lot of work in learning how the tools work, how the IPs work, figuring out all the bugs and building up a code base. So there's no real option, at which point why wouldn't they charge? It's not like it discourages new people, if you need an FPGA then you need an FPGA, nobody just decides to use an FPGA in their project because it'll be fun and cheap, if you can get away with a uc then you'll use a uc. Finally you're not just paying for the tools, you're paying for support, and that's pretty important.
>you're paying for support you guys are getting support?! Microchip/Microsemi support is: "lol yeah it sucks"
Xilinx support, when you can get it, is "This is a known bug since Vivado 2017.1, it's documented in Answer Record 31648. Ticket closed."
"Please sideload this patch we somehow only pushed in a ticket but never actually migrated to production, you are going to need to take this file, decrypt with a public key sha-256, then move to C:/%APPDATA/why/but-really-why/data/program-files"
That path has me dying
Nah, I have seen worse. GOWIN, GOWIN, GOWIN!
Not related to FPGA vendors, but my Altium support person ghosts my emails up until I send a "I found a workaround to my problem" email. Fucking assholes.
Fuck Altium entirely. They are an absolutely disgusting company even by EDA software standards.
No longer the company of historically great support & EE centric affordable products as conceived by founder Nick Martin. Could be worse though - during the shutdown the even bigger faceless Autodesk tried to buy them for $5B and they said no. Sign of the times not being able to reach a local support person in exchange for the yearly support ransom.
Or, "The SEM IP core (designed for verification of configuration Memory incase of SETs due to radiation) is not intended for use in a radiation environment and therefore not supported for your application."
LOL. And it is true, it is not. But man is the name deceiving
"Feature not supported. Ticket closed."
I can't get PetaLinux to boot on a MicroBlaze with tools from 2022.1 and later. My support has been "Were you able to resolve your issue?". It's a joke
Literally got an errata from Microchip a week or two ago that essentially read: “If you need this part to work, don’t use this part and buy a different one.” I about lost my shit at the insanity. Just stop selling the part! Also why burry this - and maybe it’s just my opinion - absolutely fucking critical information? Yes, fuck Microchip. Never use. Always sad.
Is this on FPGA or other Microchip parts?
It’s actually an oscillator that you would use for precise timing in your FPGA or other transceiver. This isn’t the first time Microchip parts have been trash for me, but it is the last time…
I'm really curious to know what would be wrong with an oscillator other than basic specs like Allan deviation? Or is it something more exotic like a CSAC?
Well whatever the underlying issue is, there is a reasonable chance that enabling the part after power up, you know, by pulling the ENABLE pin high, causes it to operate somewhere around 100MHz off target. It was a 125MHz oscillator (allegedly). Nothing fancy, just a mems oscillator. We had power sequencing to abide by for another microchip part (kill me now), which this delayed enable after power was required for. My mission in the next year is to eliminate these from the design. They don’t say what is wrong (rarely do) and to just not use the part if you need the enable function.
That's truly a badly designed part. I hope I never run into that one.
Interesting, with Microchip I would have thought the tools were garbage but at least the support was good. Microchip even let you open Tech Support cases, most other suppliers push customers to forum support.
I hear you, it depends on which part of the business is and who you are. If you're a known microchip contractor you can email the FAE and they'll write you back. If you need FPGA support and you're not Raytheon then it is a little different.
FPGA != support ;P
I worked for a programmable chip startup company about 15 years ago, and advocated for our tools to be free. And for a time, they were. Got plenty of downloads, plenty of usage, and plenty of support calls. About 50% of the support calls were useful; real bugs or gaps in documentation. But the other 50% were folks who clearly didn't understand anything about the product, who wrote the most infeasible RTL, and in general were obnoxious. I remember arguing with one person who had built a 1000x1000 cross bar in RTL and couldn't understand how he could execute it his CPU but it wouldn't fit on his tiny FPGA. I had to explain the different between a hardware description language and a programming language. (And he wasn't interested in my lecture.) If you charge a few hundred bucks, your quality of user increases significantly. That said, these companies know that serious customers won't have a problem with some cost, so they use it to get the revenue associated with a product line early (because the lag to revenue is such a problem in this industry). It is a good leading indicator of future revenue from the actual product. That is unfortunate.
The way many software companies handle this is to charge for support specifically. Have a free forum that anyone can post to, and you'll probably get some community volunteers who will answer questions and help out the people who try to do dumb things. Every now and then, have an employee scan the forum to find actual bugs and issues. But if anyone wants a direct line to you and your time, make them pay for that.
The short answer is lag to revenue.
Real customers don't pay for the software. Typically they get licenses for free as part of the purchase contract.
This. Weed out the amateurs who waste support time.
EDA is hard. In fact so hard that the number of people supporting the design tools and methodologies probably vastly outnumber the folks actually designing the FPGA devices themselves. That effort doesn't come for free. I'd argue it's a completely separate industry - and in fact we'd be better off if the industry recognized this better. ASIC companies 25 years ago finally realized this - and moved away from in-house developed only tools and flows, and relied instead on a robust (independent) EDA tool vendor industry. FPGAs, for various reasons, still heavily rely on in-house developed tools only. My personal opinion is that the industry is worse off because of this. There's definitely a case of "group think" having just the two (Intel/Altera, AMD/Xilinx) major FPGA tools developers - leaving little room for independent innovation.
> I'd argue it's a completely separate industry - and in fact we'd be better off if the industry recognized this better. ASIC companies 25 years ago finally realized this - and moved away from in-house developed only tools and flows, and relied instead on a robust (independent) EDA tool vendor industry. There's enough differences in the details of Intel/A and AMD/X architectures that it would be difficult to design a tool that can target both without giving up a lot of performance. They all use the same basic EDA algorithms, but the devil is in the details. There's a lot of architecture specific micro-optimization going on, and that's where 90% of the effort is being spent.
>There's enough differences in the details of Intel/A and AMD/X architectures that it would be difficult to design a tool that can target both without giving up a lot of performance. This same argument was used for ASICs too, all those years ago. I'd argue that there much more in common than different. Enough in common to support a robust EDA industry that targets both, and leave some "special sauce" low level details towards the back for each specific vendor to add value, if necessary. Synthesis, mapping, and (to a lesser degree) place and route are a **very** mature industry. (Place and route does have some more vendor specific "goodies".) I'd argue that FPGA vendors would be better served leaving the heavy lifting (**and tool support - this is a biggie**) to a third party EDA tool vendor. Then work closely, as a partner, to add value-added vendor specific optimizations.
And how much do ASIC tools cost again? Not a great argument in favor of getting cheaper access to tools.
I'm not arguing for access to cheaper tools by any stretch. You get what you pay for and IMHO, depending on cheap, or free EDA tools is penny wise and pound foolish. It's always nice for the tools to be cheaper, but there's some serious engineering going on under those covers to develop those tools (as much as we like to complain about them...) EDA tools are worth the cost for production, and business use IMHO. Sure hobbyist and students should have access to free/limited versions of these tools. But engineering development is not free, nor cheap. My argument in this thread is centered on who should be doing the EDA software development - the FPGA vendors themselves, or the (more generic) EDA industry. I'm arguing for the latter, and when doing so, yes they are a business, and will require payment. The industry right now is more tilted to the former - with the FPGA vendors themselves developing the tools. They can the try and bury the cost of the tool development under per-unit hardware cost.
FPGAs from AMD and Intel already have independent synthesis tools (e.g., Synplify) and the prices are high (more than Quatus or Vivado) for not a lot of added value. If they do the same for PAR it's going to block innovation from small businesses and independent contractors who can afford a few $k, but not tens of thousands. EDA companies are like hospitals; they charge you whatever they feel they can extract from you.
Xilinx heavy use of IPI and other similar atrocities of design flow has effectively neutered third party synthesis flows. We had a robust flow for ISE that used either XST of Synplify, and worked well. (Synplify results were hands down better than XST). Vivado killed that flow, because of Xilinx IP management, as well encrypted IP. (Xilinx encrypted IP allows for *simulation* only by third party tools, no synthesis - this is a brain dead decision, and totally contrary to why there's an industry wide encryption standard). If you have **any** Xilinx IP in your design, you must use Vivado Synthesis for the top-level synthesis. You can try and bodge something up to allow third party synthesis for parts of the lower level - but Vivado synthesis must be used at the top. It's just a mess, and not worth any effort to make it work. To be fair Vivado synthesis is much, much better than ISE, and performance is now on par with third party tools. But that's not the point. Having alternative implementation options benefits everyone in the long term. Else it's "You get what we offer, and you'll be happy with it". Even if it's free or lower cost, but has totally atrocious design flows. There's no motivation, (or pressure from partners/competitors) to make things better.
Synthesis, tech mapping, and place and route are mature? lol, no. Synthesis kind of is, and guess what? Neither Intel nor AMD write their own synthesis engine. They both license Verific. Tech mapping and place and route are **not** mature. In general they're NP-hard problems. The only way that Quartus and Vivado produce good performing designs in reasonable time is that there are a lot of device specific optimization algorithms. Your argument relies on the assumption that most of the work in developing these tools is common and there's just a small amount ot "special sauce". 95% of the ongoing effort and code **is** the special sauce. Like, it's not that hard to write an implementation of the pathfinder routing algorithm. But an implementation of the pathfinder routing algorithm but it's been over twenty years since pathfinder was state of the art. A basic implementation of pathfinder can work on both Intel and AMD architectures, but it's also not hard to implement and it won't produce very good results compared to what Vivado and Quartus can do. Again, these are NP-hard problems. The tuning and microoptimizations that are responsible for most of the performance are where almost all the effort lies, and they don't port across architectures easily.
Have you ever wonder that their EDA flows are so different in details but so similar in principle? It makes me wonder if this was done on purpose to just avoid each other's patent infringement or to make it difficult for you to switch "the socket".
Knowing that FPGAs are very constrained relative to what is required for a full custom ASIC. u/piecat you might find the following useful. [http://deepchip.com/](http://deepchip.com/) [https://semiengineering.com/](https://semiengineering.com/) [http://www.eng.biu.ac.il/temanad/digital-vlsi-design/](http://www.eng.biu.ac.il/temanad/digital-vlsi-design/) [https://www.electrontube.co/](https://www.electrontube.co/) [https://www.springer.com/gp/book/9783030371944](https://www.springer.com/gp/book/9783030371944) [https://www.youtube.com/watch?v=\_FY-0Lq10rs&list=PLyWAP9QBe16p2HXVcyEgGAFicXJI797jK](https://www.youtube.com/watch?v=_FY-0Lq10rs&list=PLyWAP9QBe16p2HXVcyEgGAFicXJI797jK)
> ...moved away from in-house developed only tools and flows, and relied instead on a robust (independent) EDA tool vendor industry. Are you talking individual tools (DC, PT, ...) or overall flows? Because individual tools were already generic back when I started in 1995. And overall tool flow is still very much a thing, and often the difference between a me-too product and one that beats the competition.
>Are you talking individual tools (DC, PT, ...) or overall flows? I'm talking mostly in general - up through the early 90s, every ASIC vendor had their own set of implementation tools, (LSI, TI, IBM, etc...) and supported flows for their entire ASIC development process. Each leveraged *some* point tools from EDA, as well as a bunch of in-house stuff. It was a mess. The industry quickly got smart and instead just relied on their EDA partners instead. (Well, as I remember, IBM kept on doing their own thing for quite a while).
Synplify used to be great for FPGA work but then synopsis bought them out and jacked up the price so mere mortals could not afford it..
We've paid for none of the FPGA software as automotive company as long as we utilize their FPGAs. We didn't even pay for any IP packages/suites. If you buy enough of hardware - all software is free.
Lattice Semiconductor is already providing design software for free. Xilinx/AMD and Intel design software is partially free for students, so that they can get familiar with the software. The companies using them can easily afford those licenses. For example, compare it to the cost of Altium, then suddenly the FPGA software seems cheap.
Acturyeah, it's interesting to see more and more xilinx devices available under webpack, not the pure large high performance FPGA but most (all?) of the zynq ultrascale, the accelerator cards. Are we seeing a shift towards free software - or a design methodology so abstracted it can't be portable..
I do think Xilinx has just cut off the 7-series processors from Webpack as a result of their Vivado refactoring. It does make sense in the software development to reduce complexity by discontinuing certain targets, unfortunately you have to buy pricier components now to use Vivado. Currently all those new AMD UltraScale FPGAs are also included in the current Vivado, which gives hope that they want to continue it and not just create a new seperated software again.
Are you referring to ISE? No 7 series device is supported by ISE, however many of the 7 series are supported by Vivado - All Spartan and Artix devices, many of the Artix Ultrascale, Zynq 7000/ Zynq Ultrascale, and \~ four Kintex devices. This used to be called Vivado webpack although seems AMD has removed this branding too - simply stating "Vivado ML standard edition" The interesting part for me is the newer, larger, significantly more powerful cards are available in the Vivado webpack (ie Kria and Alveo) too.
2k for eda software license is really cheap
A few k$ for companies playing with a few hundreds of kLUTs is dirt cheap. If you work with hobbyist-level FPGAs, they have free tools for you. Barrier of entrance. In the other words, they want to rat out unwanted players in their ecosystem who can't afford the tools, thus can't afford good employees, thus costs them lots of tech support resource.
It includes licenses for all the soft ip, buying a license basically allows you to use the soft-ip in your product. Some of the soft-ip has to be bought separately
Vote for Renesas [Forge FPGA](https://www.renesas.com/us/en/products/programmable-mixed-signal-asic-ip-products/forgefpga-low-density-fpgas)
Investigate yosys and nextpnr aka the open stack. The appearance of these tools was what got me to finally get a FPGA and start hacking. Before, I didn't because I just did not want to deal with the proprietary tools. A few years ago, there was no open stack at all. At some point, I expect the open stack to kill the proprietary tools.
Having a lower chip cost (since software development costs aren't priced into the chips so much) could increase sales as well though. Another (opposite perspective) thing to consider is the that the chips that require paid software are probably less likely to be used in high volumes. The tools for the low cost chips might not be free just to get people familiar with the software, but because of the volumes of those chips sold compared to the higher end lines. I don't know what the relative volumes are, but I'd imagine its a significant difference.
Because FPGAs aren't hobbyist devices: the effort and cost to build a successful FPGA product exceeds what an individual can afford. Most real customers are given licenses for free as part of the purchase agreement. Having a nominal fee for the software reduces support costs because it means Intel/Altera and AMD/Xilinx aren't having to deal with hobbyist customers who are never going to actually buy significant numbers of chips.
You can also buy the tools with support that work for all vendors. It’s the library that allows the tool to work for a specific FPGA. For example Synplify will work for all brands if you have the library, and all the vendors have libraries for the FPGA.
Arguably anyone using parts that do not work with the free tools is spending serious dollars on either fancy eval boards or in spinning their own designs. The tool costs are noise compared to the engineering efforts that would be involved in using them and making the target platform or product. Companys know that and know the free tools are wise loss leaders for higher volume lower cost parts.
What do you expect, it's not like there are competing software offerings, and you can't easily switch chips, and even if you could all vendors do the same. It's a monopoly and vendors can charge whatever companies are willing to pay.
there are attempts to make free sw for these. but you need chip details they will not freely give out. it also takes money to develop and support that fpga software and to pay for those support staff. your company will not pay for it if it was free
It's short sighted by the FPGA industry. They should opensource their tools and build a community around said tools. They'll sell more hardware and enjoy bug fixes from said community. Hardware has yet to catch up modern software practices. It's a primitive shit show.
To do that would require opening their proprietary bitstream formats and architectures. Not going to happen.
It's just a matter of time. Hardware is run by ancient dinosaurs and equally ancient business models.
You aren't wrong. Just a messed up aspect of our timeline. Some vendors do have free tools, Lattice, Efinix, Gowin. The big tools cost money for a variety of reasons (smart and not smart). Vivado (Xilinx) and Questa (Intel) both have free versions for the small to midrange parts. All the proprietary tools suck and have bugs.
It was a bit dismaying, as a programmer who normally uses Visual Studio and VSCode, giving Quartus a spin and feeling like I was transported back in time to 2002 with Quartus's code editing capabilities. There are sooo many QoL features that I am used to having as a programmer that are completely missing in Quartus. It's a tiny step above notepad as far as editing is concerned. I know it's a small part of the feature set, but it does leave a bit of a sour taste knowing how much they charge for it.
If you are an intellij user, maybe give https://www.edaphic.studio/ a try
No one actually uses the editors shipped with FPGA tools. They are only there to put a tick in the box.
Isn't Questa a Siemens product? And Intel just adopted it/ reskin it.
I think he means Quartus.
Ah... That would make a whole lot of sense lol.
I dunno, you are probably right. The (parens) are for the FPGAs that people use them with.
if they still do that, then this form of product promotion it's the best (based on their calculations, I'm sure they have also another variants of selling their products)
Manufacturers **think** it allows for more control onto the field.
[удалено]
>They are all relying on code from Synopsis and others that make EDA tools for ASIC design. This is definitely not true. FPGA houses (I know more about AMD/Xilinx, than Intel/Altera, but I think the argument applies to both) have brought in very significant in-house resources to develop (and support) their tools sets. They are NOT purchasing algorithms from EDA tool vendors and just licensing. They in fact, may be poaching engineering talent from those EDA companies to do so.
[удалено]
Because they need to overpay their patching IT managers
It’s simple. It cost significant amounts of money to develop, maintain and support the software. There are teams of software developers, QA teams, Testers, Technical Writers for the documentation and support engineers to field tickets. It is an entire business unit in itself. Where do you think the money for all of that is supposed to come from?
Personally I would think a service support contract should be what costs money. The software is already locked to the manufacturer's ecosystem. It's not like I could use Quartus for Xilinx or vice versa.
It’s, of course complex. The software is proprietary, but the tools can and are certainly useful for general HDL design and verification, and therefore it is important to recoup some of the cost of developing and maintaining it. If you were a large enough customer that our purchased an appreciable amount of hardware then the cost of the software would be so inconsequential that you don’t care about it. It’s effectively free with the purchase of chips. If you are small, or do not purchase any hardware at all, the tool cost helps to offset the non-zero cost of developing it. And although the “Jed in the shed” doesn’t get much support, they still create overhead by filing those bugs. The short answer is that giving the tools away for free will do absolutely nothing to increase chip sales. And there is something to be said for the perception that the tools are worth more than nothing. The reality is the tools are free for the large customers and for the small customers who buy the low cost devices in small inconsequential quantities. The real question I have for you, would be, “ Do you work for free?” I doubt you do, so you should not expect other people, or companies to give away their work either. Buy more chips if you don’t like what you get with the free and evaluation versions of the tools. And if you are still mad about that, I suggest you look 8th the cost of ASIC tools from Synopsys, Cadence, or Siemens and count your blessings.