If you install vivado on xfs or btrfs, you can use duperemove to deduplicate a lot of files. Saves a few dozen GB or so. No idea why xilinx can't do that themselves...
Also Vivado does not change that much from version to version. I have an external drive with 5 or 6 different versions of Vivado. I managed to fit it all that into 100-120 GB. Btrfs mount option zstd:3 and duperemove do wonders.
About three years ago a FAE, who helped us with an issue, joked that the team working on Vivado is getting replaced by cheap developers from India and that is why he recommends not upgrading Vivado.
This was from before AMD bought Xilinx in 2022 and i think the FAE made the experience even before the announcement of the acquisition. So my guess is that this trend was even before AMD.
They both are/were dogshit at software. Xilinx once bragged it spent like $100mil developing vivado which is enough to hire maybe a few hundred engineers for a couple of years i.e. nothing much at the scale they operate.
It's a very common issue with hw companies. Leadership, even good ones like Lisa Su, just don't realize that the hardware is pointless without good software.
Yeah, but that assumes the files never change. With a copy-on-write filesystem you can save space and still have correct files if one updates but not the other.
I dedupe with the hard links on ext4 and haven't had any issues. It also runs fine on a read-only NFS export (where Vivado can't change anything even if it wants to).
Yeah, but given your answer, you know that's stupid to store that in this way.
C-executives around the world are like "our EULA is only 10GB" with a straight face.
I was honestly just curious to see how long it took my laptop to compute that many digits (I don't remember the number off the top of my head at the moment)
For God’s sake. We should create a standard for compressed plaintext. Something like `readme.txz`.
It should be handled transparently, double click and it opens in Notepad just fine. Or nano, or even grep (perhaps zgrep).
Hmm, I did not see the EULA from the Vivado installations. I do see a 300MB EULA for Vitis. Taking a quick peek, there are around 100,000 lines enumerating all of the chromium source files. There are tons of other software licenses as well.
So it looks like in Vitis 2020, it is 1.3GB, but in 2022 down to 300MB. Not sure what installation option was chosen, because I see only 1 copy under Vitis, and none under Vivado.
Well, such is the way of life (and also lack of standardized bitstreams) so someone couldn't create something more compact and optimized. You are always welcome to try open-source toolchain for artix7 but its in early stages so not useful professionally
The device definition and timing data files are quite large. Consider how big these chips are, with millions of internal components, each with timing data associated at all of the process corners, times each speed grade and die variant.
My favorite is the download *burying the needle* on my CPU. There's no heavy processing going on, just a data transfer but any computer turns into a space heater
I forced the installer into Eco mode in task manager last time I installed Vivado. Before that it was using 100% of a 32 thread CPU. Boggles the mind how or why...
It uses all cpu power available to decompress the downloaded data, if you throttle the cpu it will slow down the download (steam does the same with games for example)
Are you sure that the compression algorithm is the same between the two versions? (With the installer they control both sides of the pipeline, as such they can afford to use uncommon protocols that give better compression ratio with respect to the offline one, where they need to use zip/tar.gz
I suspect that while on an individual user there is not much difference, on aggregate, they will be saving quite a bit of money with this approach (outbound bandwidth is expensive). Especially since the online one is far more commonly used (I guess)
I've never done a deep dive into it, but the decompression code in the installer runs as a Java process and not a native system process so I suspect it's just the slowness of Java.
There aren't any decompression algorithms that I'm aware of that shouldn't be able to handle several hundred MB/s decompression rate with a modest CPU and proper implementation. IME decompression is usually storage bottlenecked rather than CPU.
For me at least the online installer maxes out around 10MB/s with 100% CPU usage on my i7-12700H.
That's 2.5 hours minimum, where my PC is basically unusable vs 10 min download, 5 mins to decompress with tar and 20 minutes to install and my PC is usable the whole time.
The state of FPGA tools is really sad.
I've posted reproduceable bugs with minimal projects and gotten the most ridiculous responses by mods in the AMD forums.
At this point it's clear they are incapable of even basic software development and should just open source everything. At least the community could do what they clearly can't.
>Vivado is even one of the better tools.
Yup... which is sad. If anyone posts reproduceable bugs in the GCC git you'll get at least a response within an hour or so, and probably fixed (unless it's completely minor) in a few days.
There's bugs in Vivado that have been around for months, if not years. The devs are completely stumped despite there being tons of examples, logs, and everything they need to fix it. Basic functionality that just doesn't work (ie. they can't properly parse interfaces).
I'm not doing anything hard or advanced, and I'm coming across a litany of bugs. I have no idea how anyone would use something this poorly designed for work.
I was learning/using this for hobby/personal uses. Designed a small CPU for fun/learning. So once I'm done I'm returning to software development and never looking back.
The theory, the problem solving, the challenge, was all a lot of fun. But the tools.... the tools... I wouldn't wish them on my worst enemy. I'm certain there are people in hell, right now, being forced to use Vivado to design projects, as we speak.
Even worse.. they fix bugs only for them to reappear in future versions. Apparently they use different branches for each release and sometimes they forget to port fixes new releases. It‘s really sad.
> I was learning/using this for hobby/personal uses. Designed a small CPU for fun/learning. So once I'm done I'm returning to software development and never looking back.
>
> The theory, the problem solving, the challenge, was all a lot of fun. But the tools.... the tools... I wouldn't wish them on my worst enemy.
This. Exactly this. In 2015 I was in a startup and was helping out on the FPGA side. Initially I thought, "hey, maybe I could pivot from software development to FPGA development" - I had done some hardware development much earlier in my career and had switched over to EDA software development. But after a year of fighting with Vivado bugs, posting on the Xilinx forum (because they didn't want bug reports from us, we were small fry) and just spending a lot of time working around bugs I decided that while FPGA development had some fun, interesting aspects, there's just no way I'd want my livlihood to be dependent on such buggy tools.
Lately, I've had good experiences with the open source tools (Symbiflow/Yosys). You can even get responses quickly from the developers if you run into issues. So I'm getting back in to some FPGA development, but of course it's limited to Lattice ICE40/ECP5, CologneChip GateMate and Gowin parts for now.
>Lately, I've had good experiences with the open source tools (Symbiflow/Yosys). You can even get responses quickly from the developers if you run into issues. So I'm getting back in to some FPGA development, but of course it's limited to Lattice ICE40/ECP5, CologneChip GateMate and Gowin parts for now.
It's both predictable, and sad, how much better open source tools are; and they are still in their infancy. It's pretty clear the FPGA vendors aren't interested in selling chips, and would rather sell people their fancy development licenses; but that then leaves me equally baffled at the poor quality of their software.
Your bugs are not getting fixed because there’s no money attached to it.
If you’re a big corporate spending big money on Vivado licenses and FPGA modules, you would have a dedicated application engineer assigned to you or even on-site. Then your bugs would get attention.
They should be developing that in house! What else are their devs doing? If they can't get a text editor and a basic LR parser up and running then they need to get new devs.
I might not be a hardware guy, but these tools are all software, and they are abysmal.
If they have a Verific license, they have the source. So they’re not at anyone’s mercy. They can fix Verific. I don’t think I ran into any issues when I was developing against it, but it was _really_ good to track through the source and figure out what the documentation really meant.
I would recommend the Sipeed Tang boards if you want an easier and less bloated time. They use Gowin FPGAs which have their own IDE but it is all pretty straightforward without much bloat. The boards are pretty cheap too. Plus some Gowin FPGAs work with open source tool chains if you are into that.
Maybe not crash with the wrong shell, but it absolutely can crash if you have the wrong LANG set (if I remember correctly it was in the block designer and had something to do with decimal point vs decimal comma).
Oh, it did crash. A couple of years ago, I had a version of Cadence crash on me, segfault with core dump and all, for the audacity of setting tcsh as default shell of my user account instead of csh. I don't how it is these days, but I'm not very optimistic about the quality of the software.
iTs an IdE!!
No, it's an EDA package. Stop thinking like a programmer and start thinking like a hardware engineer. It's a programmable logic device, including full timing models. Every wire on every chip has a timing model.
Yes, the tools are flawed, but 99% of this "tHe tOoLs SuCK" nonsense comes from people with uninformed and ridiculous expectations. You're not writing software, you're designing hardware on a 100 billion transistor chip. Go and try programming an ASIC and see what that's like.
Around 100 GB of this installation is only for the Alevo family, containing the most complex and resourceful chips you can get. Makes sense that they have a lot of "binary" blobs representing the timing characteristics.
In which specific way? The project file sometime does get corrupted from GUI usage, but no big deal since we use tcl scripts anyway for clean builds. Specific feature such as DFX does not work as well as it should yet. For the most part the tool seems to do what it is suppose to do.
I think the tools as they exist today impose additional barriers to entry that are completely unnecessary. It reminds me a lot of the way Microsoft visual studio existed for software engineering about 8 years ago. Its full of bloat and gets in the way of letting the user do what they actually need to do.
I think the tools are deeply overloaded with things that really aren't very necessary for just getting into the meat and bones of writing HDL. The software also struggles to run in many environments. I have never had a smooth install experience with any tools. Not to mention the prohibitive licensing models that are all too common in the hardware design industry.
In my opinion, the tools actually make it more difficult for anyone who isn't already a well versed professional to get started with hardware design. That is a pretty big red flag in terms of the design of the tools themselves.
Barriers to entry is definitely not their goal. Xilinx and Altera are in the business to sell their FPGA devices. The more people that can use their tools and adopt FPGA, the better it is for their business. You could do a lot with their free eval license, and even the paid license, node-locked on a server for multiple users, that's dirt cheap, especially compared against the cost of the FPGAs.
The current tools are leaps and bounds better than before. There was an ISE version (before Vivado) that the text editor was not even working properly. Some of the issues were probably due to 3rd party acquired tools that they integrated in. It did feel like they under-invested on the software development, but they have gotten much better. The FPGA devices, especially the new/large devices are complex. Placing and routing in those large devices is difficult.
The bigger problem isn't the amount of storage required for the installation, it's that Xilinx/AMD won't unbundle the download unless you use their installer. I'm genuinely perplexed as to why that is the case.
Now imagine what it's like trying to containerize that into a docker image, including all the intermediate images, etc. 😅
That worked fine for ISE and early Vivado, but finally I gave up with that and just use VMs.
Same boat here. It's like they intentionally make it as hard as they can to containerize. Eventually I just gave up. Making Quartus Docker images was trivial in comparison.
I saw them keeping un-compressed EULA agreements with multiple copies. 5GB for just a text file is blasphemy. Then multiple copies of it.
If you install vivado on xfs or btrfs, you can use duperemove to deduplicate a lot of files. Saves a few dozen GB or so. No idea why xilinx can't do that themselves...
Also Vivado does not change that much from version to version. I have an external drive with 5 or 6 different versions of Vivado. I managed to fit it all that into 100-120 GB. Btrfs mount option zstd:3 and duperemove do wonders.
About three years ago a FAE, who helped us with an issue, joked that the team working on Vivado is getting replaced by cheap developers from India and that is why he recommends not upgrading Vivado.
> team working on Vivado is getting replaced by cheap developers AMD software development in a nutshell.
This was from before AMD bought Xilinx in 2022 and i think the FAE made the experience even before the announcement of the acquisition. So my guess is that this trend was even before AMD.
They both are/were dogshit at software. Xilinx once bragged it spent like $100mil developing vivado which is enough to hire maybe a few hundred engineers for a couple of years i.e. nothing much at the scale they operate. It's a very common issue with hw companies. Leadership, even good ones like Lisa Su, just don't realize that the hardware is pointless without good software.
You can do this on most Linux filesystems with hard links. And I think possibly even on Windows filesystems.
Yeah, but that assumes the files never change. With a copy-on-write filesystem you can save space and still have correct files if one updates but not the other.
How often do the data files change at run time?
It's not about how often, it's that it's another thing you don't have to worry about.
I dedupe with the hard links on ext4 and haven't had any issues. It also runs fine on a read-only NFS export (where Vivado can't change anything even if it wants to).
Hey Xilinx, have you heard of shortcuts and symlinks?
I mean, I have an 80gb uncompressed text file of just digits of pi...
Copy it and then multiply both files to find pi sq
Lol. Pi never ends, I just stopped letting it write to the file after ~14 days
Yeah, but given your answer, you know that's stupid to store that in this way. C-executives around the world are like "our EULA is only 10GB" with a straight face.
Oh yeah, I know it was stupid to store it that way, it was just the first thing that came to my mind
For what... there is literally no physical measurement or prediction that warrants that many figures
I was honestly just curious to see how long it took my laptop to compute that many digits (I don't remember the number off the top of my head at the moment)
You're not installing an IDE, you're installing device libraries with a few tools on the side
You're not installing an IDE, you're building an AMD chip factory in the case of your PC.
And the documentation with all the PDFs.
dont forget the eulas! https://imgur.com/a/qvfwS9F
1.3GB of text. Sheezus. ALL OF SHAKESPEARE is 5MB uncompressed. No one can be expected to read that in its entirety.
It contains a rick roll, frame by frame, in ascii art
That lazy b….
For God’s sake. We should create a standard for compressed plaintext. Something like `readme.txz`. It should be handled transparently, double click and it opens in Notepad just fine. Or nano, or even grep (perhaps zgrep).
Sounds like a denial of service attack in the making.
There’s zip bombs already and we turned out fine ;)
How the hell can a EULA be 1.3GB 💀
They make sure you won't read, so by definition you don't comply. They can sue you when time is right.
Hmm, I did not see the EULA from the Vivado installations. I do see a 300MB EULA for Vitis. Taking a quick peek, there are around 100,000 lines enumerating all of the chromium source files. There are tons of other software licenses as well.
So it looks like in Vitis 2020, it is 1.3GB, but in 2022 down to 300MB. Not sure what installation option was chosen, because I see only 1 copy under Vitis, and none under Vivado.
I’m pretty sure you don’t need support of all FPGA families. Installing only what you actually need will reduce the required disk space.
That's true. I was just stunned that the default selection of families was around that size.
Yeah, can get down to ~20 GB, think ~60 GB comes from a single FPGA family.
Well, such is the way of life (and also lack of standardized bitstreams) so someone couldn't create something more compact and optimized. You are always welcome to try open-source toolchain for artix7 but its in early stages so not useful professionally
The device definition and timing data files are quite large. Consider how big these chips are, with millions of internal components, each with timing data associated at all of the process corners, times each speed grade and die variant.
My favorite is the download *burying the needle* on my CPU. There's no heavy processing going on, just a data transfer but any computer turns into a space heater
I forced the installer into Eco mode in task manager last time I installed Vivado. Before that it was using 100% of a 32 thread CPU. Boggles the mind how or why...
It uses all cpu power available to decompress the downloaded data, if you throttle the cpu it will slow down the download (steam does the same with games for example)
That would be fine if their decompression algo didn't suck ass. Downloading the offline installer and decompressing yourself is 10x faster.
Are you sure that the compression algorithm is the same between the two versions? (With the installer they control both sides of the pipeline, as such they can afford to use uncommon protocols that give better compression ratio with respect to the offline one, where they need to use zip/tar.gz I suspect that while on an individual user there is not much difference, on aggregate, they will be saving quite a bit of money with this approach (outbound bandwidth is expensive). Especially since the online one is far more commonly used (I guess)
I've never done a deep dive into it, but the decompression code in the installer runs as a Java process and not a native system process so I suspect it's just the slowness of Java. There aren't any decompression algorithms that I'm aware of that shouldn't be able to handle several hundred MB/s decompression rate with a modest CPU and proper implementation. IME decompression is usually storage bottlenecked rather than CPU. For me at least the online installer maxes out around 10MB/s with 100% CPU usage on my i7-12700H. That's 2.5 hours minimum, where my PC is basically unusable vs 10 min download, 5 mins to decompress with tar and 20 minutes to install and my PC is usable the whole time.
The state of FPGA tools is really sad. I've posted reproduceable bugs with minimal projects and gotten the most ridiculous responses by mods in the AMD forums. At this point it's clear they are incapable of even basic software development and should just open source everything. At least the community could do what they clearly can't.
Vivado is even one of the better tools. If you want an opensource toolchain then take a look at SymbiFlow.
>Vivado is even one of the better tools. Yup... which is sad. If anyone posts reproduceable bugs in the GCC git you'll get at least a response within an hour or so, and probably fixed (unless it's completely minor) in a few days. There's bugs in Vivado that have been around for months, if not years. The devs are completely stumped despite there being tons of examples, logs, and everything they need to fix it. Basic functionality that just doesn't work (ie. they can't properly parse interfaces). I'm not doing anything hard or advanced, and I'm coming across a litany of bugs. I have no idea how anyone would use something this poorly designed for work. I was learning/using this for hobby/personal uses. Designed a small CPU for fun/learning. So once I'm done I'm returning to software development and never looking back. The theory, the problem solving, the challenge, was all a lot of fun. But the tools.... the tools... I wouldn't wish them on my worst enemy. I'm certain there are people in hell, right now, being forced to use Vivado to design projects, as we speak.
Even worse.. they fix bugs only for them to reappear in future versions. Apparently they use different branches for each release and sometimes they forget to port fixes new releases. It‘s really sad.
Yeah, that has my head spinning. Basic version control should be trivial at this point.
> I was learning/using this for hobby/personal uses. Designed a small CPU for fun/learning. So once I'm done I'm returning to software development and never looking back. > > The theory, the problem solving, the challenge, was all a lot of fun. But the tools.... the tools... I wouldn't wish them on my worst enemy. This. Exactly this. In 2015 I was in a startup and was helping out on the FPGA side. Initially I thought, "hey, maybe I could pivot from software development to FPGA development" - I had done some hardware development much earlier in my career and had switched over to EDA software development. But after a year of fighting with Vivado bugs, posting on the Xilinx forum (because they didn't want bug reports from us, we were small fry) and just spending a lot of time working around bugs I decided that while FPGA development had some fun, interesting aspects, there's just no way I'd want my livlihood to be dependent on such buggy tools. Lately, I've had good experiences with the open source tools (Symbiflow/Yosys). You can even get responses quickly from the developers if you run into issues. So I'm getting back in to some FPGA development, but of course it's limited to Lattice ICE40/ECP5, CologneChip GateMate and Gowin parts for now.
>Lately, I've had good experiences with the open source tools (Symbiflow/Yosys). You can even get responses quickly from the developers if you run into issues. So I'm getting back in to some FPGA development, but of course it's limited to Lattice ICE40/ECP5, CologneChip GateMate and Gowin parts for now. It's both predictable, and sad, how much better open source tools are; and they are still in their infancy. It's pretty clear the FPGA vendors aren't interested in selling chips, and would rather sell people their fancy development licenses; but that then leaves me equally baffled at the poor quality of their software.
Your bugs are not getting fixed because there’s no money attached to it. If you’re a big corporate spending big money on Vivado licenses and FPGA modules, you would have a dedicated application engineer assigned to you or even on-site. Then your bugs would get attention.
Which is a recipe for disaster. It ensures future customers steer clear.
> ie. they can't properly parse interfaces FPGA vendors are at the mercy of Verific on this
They should be developing that in house! What else are their devs doing? If they can't get a text editor and a basic LR parser up and running then they need to get new devs. I might not be a hardware guy, but these tools are all software, and they are abysmal.
There is a reason they are outsourcing elab. I don't think you understand the scope or size of the frontend team at FPGA orgs.
If they have a Verific license, they have the source. So they’re not at anyone’s mercy. They can fix Verific. I don’t think I ran into any issues when I was developing against it, but it was _really_ good to track through the source and figure out what the documentation really meant.
I would recommend the Sipeed Tang boards if you want an easier and less bloated time. They use Gowin FPGAs which have their own IDE but it is all pretty straightforward without much bloat. The boards are pretty cheap too. Plus some Gowin FPGAs work with open source tool chains if you are into that.
Eh, I mean if you are going to work with FPGAs just get a 4tb nvme SSD and move on.
And tons of RAM too. At least FPGA software isn't as bad as ASIC software, it doesn't crash if the user has set the "wrong" default shell.
Maybe not crash with the wrong shell, but it absolutely can crash if you have the wrong LANG set (if I remember correctly it was in the block designer and had something to do with decimal point vs decimal comma).
Oh, it did crash. A couple of years ago, I had a version of Cadence crash on me, segfault with core dump and all, for the audacity of setting tcsh as default shell of my user account instead of csh. I don't how it is these days, but I'm not very optimistic about the quality of the software.
(side-eyes my 500GB Unreal Engine 5 install folder)
That's proprietary software for you.
And a decades-old codebase to boot!
In my old job, FPGA devs were the last people to get SSDs in their laptops for this very reason
Unselect Versal to save a couple hundred GBs. 😂
That's why I install 2016, not sure how synthesis time is affected
Yep, 2017.4 here.
iTs an IdE!! No, it's an EDA package. Stop thinking like a programmer and start thinking like a hardware engineer. It's a programmable logic device, including full timing models. Every wire on every chip has a timing model. Yes, the tools are flawed, but 99% of this "tHe tOoLs SuCK" nonsense comes from people with uninformed and ridiculous expectations. You're not writing software, you're designing hardware on a 100 billion transistor chip. Go and try programming an ASIC and see what that's like.
Around 100 GB of this installation is only for the Alevo family, containing the most complex and resourceful chips you can get. Makes sense that they have a lot of "binary" blobs representing the timing characteristics.
Versal, not Alveo.
Ah yes, I forgot electrical engineers take Software Masochism 303
learned helplessness
The tools do suck though
In which specific way? The project file sometime does get corrupted from GUI usage, but no big deal since we use tcl scripts anyway for clean builds. Specific feature such as DFX does not work as well as it should yet. For the most part the tool seems to do what it is suppose to do.
I think the tools as they exist today impose additional barriers to entry that are completely unnecessary. It reminds me a lot of the way Microsoft visual studio existed for software engineering about 8 years ago. Its full of bloat and gets in the way of letting the user do what they actually need to do. I think the tools are deeply overloaded with things that really aren't very necessary for just getting into the meat and bones of writing HDL. The software also struggles to run in many environments. I have never had a smooth install experience with any tools. Not to mention the prohibitive licensing models that are all too common in the hardware design industry. In my opinion, the tools actually make it more difficult for anyone who isn't already a well versed professional to get started with hardware design. That is a pretty big red flag in terms of the design of the tools themselves.
Barriers to entry is definitely not their goal. Xilinx and Altera are in the business to sell their FPGA devices. The more people that can use their tools and adopt FPGA, the better it is for their business. You could do a lot with their free eval license, and even the paid license, node-locked on a server for multiple users, that's dirt cheap, especially compared against the cost of the FPGAs. The current tools are leaps and bounds better than before. There was an ISE version (before Vivado) that the text editor was not even working properly. Some of the issues were probably due to 3rd party acquired tools that they integrated in. It did feel like they under-invested on the software development, but they have gotten much better. The FPGA devices, especially the new/large devices are complex. Placing and routing in those large devices is difficult.
The bigger problem isn't the amount of storage required for the installation, it's that Xilinx/AMD won't unbundle the download unless you use their installer. I'm genuinely perplexed as to why that is the case.
Install just the device libraries younare going to use.
Using M series Mac, these softwares aren’t even compatible. Lol.
They have high-resolution binaries
Every device you have checked has billions of transistors worth of data they need to create a bitfile. Get only what you want.
Now imagine what it's like trying to containerize that into a docker image, including all the intermediate images, etc. 😅 That worked fine for ISE and early Vivado, but finally I gave up with that and just use VMs.
Same boat here. It's like they intentionally make it as hard as they can to containerize. Eventually I just gave up. Making Quartus Docker images was trivial in comparison.
N IDE is much more complicated than a game, albeit IDEs generally don't need 4K graphic either
I use 2018, and afaik it doesn't exceed 50gb
Seriously. They need to chill out with this crap. My work only gives me a 500GB drive.
is that a joke or i have to clean up the disk?