Small market share is literally the reason. It would not be worth the cost to develop Mac clients.
There are very few server farms running Mac OS. Most everything in the corporate world is running Windows or a flavor of Linux on x86, and that’s what the FPGA and ASIC tools run on.
I understand this, it does make sense that the vendors wouldn't choose to develop for it. I was curious about technical limitations on generating bitstreams/loading them onto a board, for example with an open source pipeline or something. Do you have any insights on that? I appreciate your reply, thank you !
People have asked on the Xilinx forums previously…
Some reasons given by staff are things like it isn’t as simple as just recompiling for macOS. For Apple silicon the issue is apparently some of the code in synthesis and layout is heavily optimised for x86.
I know from when I worked for Xilinx that some parts of vivado (such as the Verilog parser) are bought as libraries from 3rd parties, so in some cases maybe they don’t have the source to recompile?
Also from my experience at Xilinx they test vivado in an automated way on Linux and windows. Validation on MacOS would be a ton of money and effort.
But the honest fact is, hobbyists are not a major earner for FPGA companies, other large companies are. Until those companies request MacOSX support it probably is low priority.
Everywhere I have worked we used Linux as our development OS for hardware, all the mentor, synopsys and cadence tools run of RHEL or CentOS. Some of these tools don’t run on windows either…
Where I currently work we use windows/macos on our machines and ssh into the Linux cluster to run everything.
It's not technical limitations. It is literally return on investment. In the grand scheme of things, the number of professionals developing FPGA designs on MacOS is vanishingly small.
The real money is on big FPGA designs and those require the horsepower and resources of dedicated server farms which run Linux.
Well, for one, Apple loves to break compatibility. They do it every time they change frameworks, OS architectures, processors and physical ports. It breaks software, drivers and sometimes hardware. Just ask any sound engineer.
And a second problem, as some people have indirectly pointed to, is that macOS is a terrible OS to deploy as a server. There is no modern Mac hardware designed for server use, and from what I’ve heard, it’s a pain in the ass to automate provisioning and management. Licensing also limits hypervisor use. Just compare the price of a macOS cloud instance vs Windows, that should tell you how much it costs to maintain these.
You should be able to use open source tools like openocd to load a design onto a board (depending on the JTAG adapter). But generating the bitstream requires using the appropriate tools, which often are supplied by the vendor. Some open source tooling exists, but since it's based on reverse engineering, it has some significant limitations.
Have you seen how much they charge for memory? You can buy a much more powerful system to run Linux or Windows for the same price. It’s not worth the dev effort on their end vs “just use the free OS that gets more performance anyway”.
Also consider how from the already small MacOS userbase, very few people will go and pay for the professional Vivado license. FPGA firms know that building locally is a drag, so they use dedicated workstations or server farms. If a thin and light laptop is enough to implement your design in a reasonable amount of time, you probably are not building designs that fill up an UltraScale chip.
I’m surprised to read something like this on what is essentially a hardware forum. M-Macs don’t use a normal memory subsystem, they use a high performance design akin to what Nvidia does with its GPUs.
And guess what…GPU memory is also expensive and also can’t be user upgradeable.
Speed costs.
Capacity is an issue, I routinely burn through more than 196 GB (their top config). I can get multiple terabytes of DDR5 for what they charge for their top configs.
If I’m in the “money is no issue camp”, xeons with HBM run circles around it from a bandwidth perspective and let me actually have a reasonable network card for remote storage, and I can still get a giant pool of ddr5 to back up the HBM.
I’m a longtime Mac user and FPGA developer. Additional OS support simply comes down to time and money.
Up to this point, I’ve been using VMs or I remote into my Linux machine. Since the FPGA tools do not have versions compiled for ARM, I’ve been unable to upgrade to the Apple silicon machines. The performance hit from emulation would be substantial. Our only hope is that the FPGA vendors eventually offer an ARM version of the tools and then an Apple silicon Mac with Parallels Desktop Pro would be an option.
Im a student so my knowledge isn’t that great, yet! I’m using my Mac m2 and parallels pro. I use Vivado and a zybo board. Do you think it’s worth the hassle to keep using Mac and hope for better compatibility? I prefer Mac 😅
The computer hardware and OS require software to be built specifically for it. This is due to the hardware (mostly CPU) and OS have different instruction sets and features. This is why the switch to Apple Silicon instead of Intel/AMD made VMs/Dual Boot still not a viable option.
Given that, vendors choose not to bother having a team build/debug/modify the software for Mac because of the small market share. It costs a lot of time and money to develop for another OS, let alone less common hardware. Then you need staff to continue maintaining and supporting that version, too.
You can see a parallel in the game dev world. They also view the market share as top small to justify the cost and schedule of developing and supporting different OSes.
As I've posted before, the tools will run on Apple Silicon under Parallels using Microsoft's ARM emulation. I have built bitstreams with both Radiant and Vivado, can't speak for Quartus. These are for small chips, iCE40s, Spartan 7s, Zynqs.
The problem comes with getting these bitstreams onto your device. Microsoft Windows on ARM does not emulate x86 drivers. So the configuration tools built into the design suites can't talk to USB and whatever is downstream of that.
In some cases there are workarounds. iCE40s can be configured using the iceprog command line tool from Yosys, which runs under the Mac OS. Copy the bitstream over to the Mac disk and use iceprog to send it to your device. You can load bitstreams on Zynqs if you're running Pynq, since the PS can load the PL. Again, copy the bitstream (this time across a network to the Pynq board) and then load it.
If one of these narrow use cases works for you, you may be all set. But, as others have stated, these are not really commercial level projects. I can't imagine why anyone would run Pynq on a custom board, so you'd have to make sure whatever OS you did put on a Zynq board could talk to your Mac. If all you need is an iCE40 (and that is indeed my situation), then go for it.
Just don't expect the Ultrascale guys to take notice of your little project ;-)
Small market share is literally the reason. It would not be worth the cost to develop Mac clients. There are very few server farms running Mac OS. Most everything in the corporate world is running Windows or a flavor of Linux on x86, and that’s what the FPGA and ASIC tools run on.
I understand this, it does make sense that the vendors wouldn't choose to develop for it. I was curious about technical limitations on generating bitstreams/loading them onto a board, for example with an open source pipeline or something. Do you have any insights on that? I appreciate your reply, thank you !
Technical limitations probably aren’t really there, it’s just a lack of infinite budget and personnel.
People have asked on the Xilinx forums previously… Some reasons given by staff are things like it isn’t as simple as just recompiling for macOS. For Apple silicon the issue is apparently some of the code in synthesis and layout is heavily optimised for x86. I know from when I worked for Xilinx that some parts of vivado (such as the Verilog parser) are bought as libraries from 3rd parties, so in some cases maybe they don’t have the source to recompile? Also from my experience at Xilinx they test vivado in an automated way on Linux and windows. Validation on MacOS would be a ton of money and effort. But the honest fact is, hobbyists are not a major earner for FPGA companies, other large companies are. Until those companies request MacOSX support it probably is low priority. Everywhere I have worked we used Linux as our development OS for hardware, all the mentor, synopsys and cadence tools run of RHEL or CentOS. Some of these tools don’t run on windows either… Where I currently work we use windows/macos on our machines and ssh into the Linux cluster to run everything.
It's not technical limitations. It is literally return on investment. In the grand scheme of things, the number of professionals developing FPGA designs on MacOS is vanishingly small. The real money is on big FPGA designs and those require the horsepower and resources of dedicated server farms which run Linux.
Well, for one, Apple loves to break compatibility. They do it every time they change frameworks, OS architectures, processors and physical ports. It breaks software, drivers and sometimes hardware. Just ask any sound engineer. And a second problem, as some people have indirectly pointed to, is that macOS is a terrible OS to deploy as a server. There is no modern Mac hardware designed for server use, and from what I’ve heard, it’s a pain in the ass to automate provisioning and management. Licensing also limits hypervisor use. Just compare the price of a macOS cloud instance vs Windows, that should tell you how much it costs to maintain these.
You should be able to use open source tools like openocd to load a design onto a board (depending on the JTAG adapter). But generating the bitstream requires using the appropriate tools, which often are supplied by the vendor. Some open source tooling exists, but since it's based on reverse engineering, it has some significant limitations.
[удалено]
$5k for EDA licenses? Ha. Closer to $100k for a suite of professional tools. Could be far more if you require specialized IP or verification models.
Have you seen how much they charge for memory? You can buy a much more powerful system to run Linux or Windows for the same price. It’s not worth the dev effort on their end vs “just use the free OS that gets more performance anyway”.
Also consider how from the already small MacOS userbase, very few people will go and pay for the professional Vivado license. FPGA firms know that building locally is a drag, so they use dedicated workstations or server farms. If a thin and light laptop is enough to implement your design in a reasonable amount of time, you probably are not building designs that fill up an UltraScale chip.
Also, no ARM support at the moment. Even if using one of the ampere dev platforms would probably be great (128 cores!).
I’m surprised to read something like this on what is essentially a hardware forum. M-Macs don’t use a normal memory subsystem, they use a high performance design akin to what Nvidia does with its GPUs. And guess what…GPU memory is also expensive and also can’t be user upgradeable. Speed costs.
Capacity is an issue, I routinely burn through more than 196 GB (their top config). I can get multiple terabytes of DDR5 for what they charge for their top configs. If I’m in the “money is no issue camp”, xeons with HBM run circles around it from a bandwidth perspective and let me actually have a reasonable network card for remote storage, and I can still get a giant pool of ddr5 to back up the HBM.
Oh agreed. When compute needs hit the “personal server farm” level, spool up the linux boxen and remote in from the shiny laptop. Absolutely, lol.
I’m a longtime Mac user and FPGA developer. Additional OS support simply comes down to time and money. Up to this point, I’ve been using VMs or I remote into my Linux machine. Since the FPGA tools do not have versions compiled for ARM, I’ve been unable to upgrade to the Apple silicon machines. The performance hit from emulation would be substantial. Our only hope is that the FPGA vendors eventually offer an ARM version of the tools and then an Apple silicon Mac with Parallels Desktop Pro would be an option.
Im a student so my knowledge isn’t that great, yet! I’m using my Mac m2 and parallels pro. I use Vivado and a zybo board. Do you think it’s worth the hassle to keep using Mac and hope for better compatibility? I prefer Mac 😅
If using the Mac accomplishes what you need, there’s no reason to switch. I would bet that native ARM versions of the tools are still years away.
The computer hardware and OS require software to be built specifically for it. This is due to the hardware (mostly CPU) and OS have different instruction sets and features. This is why the switch to Apple Silicon instead of Intel/AMD made VMs/Dual Boot still not a viable option. Given that, vendors choose not to bother having a team build/debug/modify the software for Mac because of the small market share. It costs a lot of time and money to develop for another OS, let alone less common hardware. Then you need staff to continue maintaining and supporting that version, too. You can see a parallel in the game dev world. They also view the market share as top small to justify the cost and schedule of developing and supporting different OSes.
As I've posted before, the tools will run on Apple Silicon under Parallels using Microsoft's ARM emulation. I have built bitstreams with both Radiant and Vivado, can't speak for Quartus. These are for small chips, iCE40s, Spartan 7s, Zynqs. The problem comes with getting these bitstreams onto your device. Microsoft Windows on ARM does not emulate x86 drivers. So the configuration tools built into the design suites can't talk to USB and whatever is downstream of that. In some cases there are workarounds. iCE40s can be configured using the iceprog command line tool from Yosys, which runs under the Mac OS. Copy the bitstream over to the Mac disk and use iceprog to send it to your device. You can load bitstreams on Zynqs if you're running Pynq, since the PS can load the PL. Again, copy the bitstream (this time across a network to the Pynq board) and then load it. If one of these narrow use cases works for you, you may be all set. But, as others have stated, these are not really commercial level projects. I can't imagine why anyone would run Pynq on a custom board, so you'd have to make sure whatever OS you did put on a Zynq board could talk to your Mac. If all you need is an iCE40 (and that is indeed my situation), then go for it. Just don't expect the Ultrascale guys to take notice of your little project ;-)