WTF Xilinx

[kfnight]

50 GiB disk space to install Vivado 2020.1 and 100+ GiB to install it with Vitis. 

[BrianHG]

For all your future projects, I wonder what actual % of that 150GB you will ever access.

I say less around 10%.

[asmi]

For all your future projects, I wonder what actual % of that 150GB you will ever access.

I say less around 10%.

You don't have to install everything if you aren't going to use it all, or space is at premium.

[Berni]

Well you do also get 10s of GB with Altera/Intel Quartus tools too.

I don't really mind it is as the big name tools ware always big on disk. But if your aim is to install it on a SSD i could see the size of it being a pain.

By the way i hear that some Xilinx tools leave behind installation logs that are a few GB is size, so you could reclaim that.

[BrianHG]

For all your future projects, I wonder what actual % of that 150GB you will ever access.

I say less around 10%.

You don't have to install everything if you aren't going to use it all, or space is at premium.

Unfortunately, except installing support for FPGAs you never expect to use, you will never know what you may end up using.
It's just such a hassle to lateron re-run the install to add a feature while in the middle of work.
This even includes support for the other FPGAs which you might have never intended to use just as your current project may expand into new territory.
Even worse, after re-running the installer may crash or go funky in the middle of changing the list of supported features corrupting your current install leaving you to restore a system backup, or re-installing the entire development studio.

I say all this since all of this has happened to me with Quartus over the past 15 years.
I just do the complete install and bite the space.  In fact, I have multiple full complete key versions installed at once and still mostly develop with an older version which has proven to be completely stable and at times faster than the latest studio.

[james_s]

Even ISE is over 18GB and the old version of Quartus I use is almost 10GB. I've long been curious what it's doing with all that space, I know very little about how the software works internally.

[filssavi]

Even ISE is over 18GB and the old version of Quartus I use is almost 10GB. I've long been curious what it's doing with all that space, I know very little about how the software works internally.

All FPGA tools take a massive amount of space because each supported part needs it’s own model, that specifies not only features bitstream format etc but also all the detailed timing info to run routing, synthesis etc. Thus the higher end the supported parts are the bigger the models, and you have probably hundreds of them (a model might be “Only” Few hundreds megs of data, however you).

there was a talk by the open source FPGA toolchain folks where they talked this (I don’t remenber the exact title).

As for Vitis I was honestly a bit puzzled to, however if yocto has taught me anything is that embedded software stuff can easily eat up tons of space

[hamster_nz]

Wow! That is like $15 worth of space if installed on an SSD, or maybe $2.50 is you use a HDD...

[Someone]

Even ISE is over 18GB and the old version of Quartus I use is almost 10GB. I've long been curious what it's doing with all that space, I know very little about how the software works internally.

All FPGA tools take a massive amount of space because each supported part needs it’s own model, that specifies not only features bitstream format etc but also all the detailed timing info to run routing, synthesis etc. Thus the higher end the supported parts are the bigger the models, and you have probably hundreds of them (a model might be “Only” Few hundreds megs of data, however you).

Same as for ISE, the models are the major disk use. It used to be optional in the installer which parts you wanted to support (who's ever planning to touch space graded parts?) but you can still strip them out manually.

[Fred27]

It's bad, isn't it? There's also the version support hell that means you may well want 3 or so different versions of Vivado installed if you want to run through examples, courses, etc.

It does help if you remove support for devices you won't/can't use. Even after doing this I still found a 1.8GB folder of Versal data on a WebPACK installation of Vivado. At the time Versal was yet to be released and being fairly high-end wasn't supported by the free WebPACK anyway. Deleting it didn't cause any problems.

[0db]

Yesterday I bought a HONOR MAGICBOOK 14 because it's decent and powerful enough for daily use and very cheap (paid 500 euro) and I don't want to use my Mac because it's dedicated for video editing.

Now I have a problem. My MAGICBOOK only has 80Gbyte of storage. I'd best replace it with a bigger one.

[NorthGuy]

I've long been curious what it's doing with all that space, I know very little about how the software works internally.

This is mostly bloat - inefficient use of resources which takes space and makes software slow and buggy. However, I guess most people think that this is because what the software is doing is incredibly complex and cannot be done any other way.

[asmi]

This is mostly bloat - inefficient use of resources which takes space and makes software slow and buggy.

Every time I see someone's saying that I know he has no idea what he's talking about unless...

However, I guess most people think that this is because what the software is doing is incredibly complex and cannot be done any other way.

The only person who ever can talk about bloat that the one who demonstrates his own software that does the same thing but without all of that "bloat".

So - care to show us your lightweight, very fast software with zero bugs that does P&R for all Xilinx parts at least as good as Vivado does? Or it's the usual trash-talking?

[filssavi]

I've long been curious what it's doing with all that space, I know very little about how the software works internally.

This is mostly bloat - inefficient use of resources which takes space and makes software slow and buggy. However, I guess most people think that this is because what the software is doing is incredibly complex and cannot be done any other way.

If you can do so much better why don’t you do it yourself, of course you need to produce a functionally equivalent product, in comparable amount of time and with  comparable , and with roughly the same performances.

The reality is that apart from very very few collaborative projects (the Linux kernel springs to mind), or the hyperscalers,  most other software projects have just enough resources to work on features and fix the most critical bugs.

Optimising something for size requires dedicating large amount of resources, and also probably worsening performances (the ever present time vs memory trade-off in computer science).

Let’s not forget that Vivado in particular and Xilinx FPGAs are not targeted at hobbists in emerging countries, but at professional engineers and companies, so even the most basic pc will have at least a TB of Storage (or that can be upgraded for 100$ or less, why waste money I ask?

Look at an example yocto, the initial download is few hundred mega, however after a full compile of a non trivial distro the folder will be Several tens of GB, mine even approached 100. Is it bloat and crap?

Absolutely not, the space is occupied with various levels of cache, so your next build will not take 1 and a half hours but just 5 to 10 minutes.

Petalinux for example (which is mostly a repackaged and customised yocto install) download is IIRC 8 gigs.

Is the additional space wasted?

No they just included in the download part of the caches, so even the first builds will not take 1 hour

[james_s]

This is mostly bloat - inefficient use of resources which takes space and makes software slow and buggy. However, I guess most people think that this is because what the software is doing is incredibly complex and cannot be done any other way.

Are you basing this on something in particular or is it just an assumption? I could certainly believe there's a good deal of bloat, but in that case what specifically is that bloat? You're implying that you know something that most people don't, it's the specifics that I'm interested in.

I suppose support for all kinds of chips I'll never use could be lumped under bloat, it would be nicer if there was an easy way to choose what device support is added on a more granular basis. I may typically use a small handful of parts among 2 or 3 different families.

[SiliconWizard]

Managed to get Vivado install down to ~30GB with a custom install and removing support for the higher end parts like Virtex.
That's still a lot of data.
My ISE install takes ~17GB.

[ejeffrey]

At least with Intel the thing that gets me isn't so much the disk space (which is huge) but the download time.  The last time I downloaded Quartus it took over an hour on a very fast connection due to the download images being so huge and also the download went quite slowly.  I don't know if Intel just cheaped out on their CDN but I can usually only download at about 20 megabit from there even on 150 megabit or gigabit network links that have no problem sustaining those speeds to other sites.

[ejeffrey]

Let’s not forget that Vivado in particular and Xilinx FPGAs are not targeted at hobbists in emerging countries, but at professional engineers and companies, so even the most basic pc will have at least a TB of Storage (or that can be upgraded for 100$ or less, why waste money I ask?

Well, even in the US plenty of engineering desktop computers still have 256 or 512 GB SSDs -- even brand new machines much less the ones that have been on peoples desk for 5 years because replacing it is a hassle and CPU performance hasn't increased that much.  But yes, for under $200 you can buy a fast M.2 SSD with 1 TB of capacity and that costs less than a single part of the high end FPGAs that drive the storage requirements up so much. 

[DIPLover]

What surprised me is the sudden doubling in size (15 to 30GB) of the minimal Vivado install from 2018 to 2019.

And to the "So - care to show us your lightweight, very fast software with zero bugs that does P&R for all Xilinx parts at least as good as Vivado does?" crowd :

Yeah, right, whatever. Vivado has been a slow buggy mess for 7 years now... But keep worshipping the mythical Xilinx engineers...

ISE was a mess too, but at least for medium-size designs in medium-sized parts, it was reasonably fast.

Good software exists, it does not have to be built by ME (or YOU, or HIM) to prove that it's possible.

[Fred27]

I see that Vivado 2020.1 is just out. I suspect it'll be even bigger than 2019!

[Edit: Clearly I missed the 2020 in the first post. ]

[filssavi]

Yeah, right, whatever. Vivado has been a slow buggy mess for 7 years now... But keep worshipping the mythical Xilinx engineers...

First we were talking about space requirements, not speed, or bugginess
But most importantly Intel quartus prime alone (no SDK) can take up to 75GB as per the manual, so, also altera/intel engineers are crap with this mentality
Lattice radiant takes 3 GB to support less then 10 tiny parts, which  is probably a device or cumulative FPGA resources supported (LUTS DSP RAM etc) to GB ratio is probably even worse than xilinx, and so on

If all the serious FPGA tools are huge there must be a reason apart from bloat, don't you think?

If everybody converged to a huge install size despite having clear drawbacks even for the company (it costs much more in term of outbound bandwidth/cdn/servers since the download will be also larger)  there must be a valid engineering reason, we might not understand it, however as a users of a tool, and not a developers we must not be so full of ourselves to think that only we have all the answers and what everybody else does is crap

[helius]

If all the serious FPGA tools are huge there must be a reason apart from bloat, don't you think?

Hardware engineers don't read Fred P. Brooks, "The Mythical Man-Month".

Related: Do these tools still completely fail at supporting version control?

[daqq]

If all the serious FPGA tools are huge there must be a reason apart from bloat, don't you think?

I'm guessing that yes and no. While I'm sure that there's a reason the tools need a lot of space, there's also a growing culture of simply not giving a damn about disc usage at all and cleaning up after yourself. See:
https://www.eevblog.com/forum/fpga/free-2gb-of-store!-just-delete-the-bloody-install-xilinx-log/

[NorthGuy]

Are you basing this on something in particular or is it just an assumption? I could certainly believe there's a good deal of bloat, but in that case what specifically is that bloat?

The biggest drag is Tcl/Tk - nothing is done natively. Synthesis and  Implementation are not cohesive, but operate in a sequence of step, each of which access huge network of Tcl/Tk. Even simple operations take long time, such as writing bitstream may take 20 seconds. Should take a fraction of a second. Or opening a project ... why is that taking so long? Even a tiny project with everything placed and routed manually still takes several minutes from VHDL to bitstream.  I once wrote a script to enumerate all the BELs of a small FPGA (Artix-7 50). This is not a big output file really - 170 MB - I had to run  the script overnight. If the object access was efficient, It should've taken seconds, minutes at worse. When the routing algorithms operate on this object basis this is also painstakingly slow, no matter how good the algorithm is.

The only person who ever can talk about bloat that the one who demonstrates his own software that does the same thing but without all of that "bloat".

This is not about talking. Whatever I say doesn't change the reality. Vivado is in front of you. Look how it operates and draw your own conclusions.

[james_s]

The biggest drag is Tcl/Tk - nothing is done natively. Synthesis and  Implementation are not cohesive, but operate in a sequence of step, each of which access huge network of Tcl/Tk. Even simple operations take long time, such as writing bitstream may take 20 seconds. Should take a fraction of a second. Or opening a project ... why is that taking so long? Even a tiny project with everything placed and routed manually still takes several minutes from VHDL to bitstream.  I once wrote a script to enumerate all the BELs of a small FPGA (Artix-7 50). This is not a big output file really - 170 MB - I had to run  the script overnight. If the object access was efficient, It should've taken seconds, minutes at worse. When the routing algorithms operate on this object basis this is also painstakingly slow, no matter how good the algorithm is.

This is not meant as an attack on you, but none of that really answers my question. I suspect that nobody outside of Xilinx or Altera/Intel truly know what makes the software as big and slow as it actually is. It's easy to look at it from the outside and say it's slow and should be faster, but what I'm curious about is *why* it's slow, maybe it's perfectly reasonable given what it's doing, maybe it's not, but I'm not seeing any answers here, well other than someone else mentioning that it's mostly the models of all the different supported parts that take up space.

Like someone else said though, if you think something that takes 20 seconds takes to long then I'd love to see you write a program that does the same thing faster.