Does using Vitis with the Ultra96 really require 32GB of host memory?

I've tried running Vitis with 22GB and it seems OK. I've not pushed it though - just checked that it runs.

Thanks for the info.  I've decided to add another 32GB to the computer, but I'll give it a try with the 16GB while I'm waiting for the memory.  I'm getting a MiniZed so I think I'll try it with that first.  Not sure if the memory requirement scales with the part complexity.  I know Vivado has a different minimum based on the part you're using.  I should be able to get to it right after the New Year's activities are done.

Just a quick update.  I've installed Vitis on my existing setup, 16GB memory - with 10GB allocated to the VM.  I am using Ubuntu 18.04.3 (meant to install 18.04.2 - hope I don't have issues) and the 2019.2 version tools (Vivado is included in the Vitis install package).  I have started building an application for the MiniZed and things appear to be working.  I'll continue this discussion in a post about Vitis and the MiniZed.  If I'm successful, I'll try it with the Ultra96.  I'm still ordering my memory upgrade but will try without it first.

Hi there,

I can tell you from personal experience that 22GB is not enough ram.  I have built a few projects under Vitis with 32GB of ram and after about 1/2 of the project is built, my hard drive lights up like it is on fire.  That is, it is swapping everything to the hard drive.  So, while it DOES eventually build, it takes a REALLY long time due to the extra memory space needed.

I can say from personal experience, running a project for the Ultra96, I utilize about 48GB of system memory.

In the link below, you can see that is where the 32GB is coming from, but I've seen about 48GB utilized.

Also, from personal experience, I can 100% suggest you REINSTALL using a properly supported VM.  Unlike earlier tools that did not seem to mind, Vitis DOES NOT like unsupported OS versions.  Last I saw, 18.04.1,18.04.2 were officially supported and while there are workarounds to make 18.04.3 work, do you really want to trust your 1+hour build to that?  Without getting into details, with Vitis, I can 100% state you need to stick with the exact listed supported operating systems.

https://www.xilinx.com/html_docs/xilinx2019_2/vitis_doc/Chunk1012669809.html

--Dan

Dan,

Thanks for the input.  Good to get real feedback based on experience.  I’ll probably try a bit more with the MiniZed before I fix my VM setup.  I didn’t realize that I had incorrectly installed 18.04 instead of 18.04.02 until I tried to install Vitis and I don’t know of an easy way to upgrade/downgrade minor Ubuntu versions without doing a reinstall so I just upgraded to the latest LTS which was easy.  I haven’t gotten my additional memory yet anyway.

I wish Xilinx would allow you to use the same node locked licenses between VMs on the same computer as that would make switching between OS and tools versions simpler.  Maybe too many people would abuse that.

Ralph

Ralph,

Not a problem.  Regarding licensing, Xilinx does have quite a few options.  You might want to talk with your local FAE about options as there are things such as network licenses.  That would let you do what you are saying - basically as you use the tool, it checks out a license.  So as long as you are only using 1 VM at a time, you should not have an issue.

--Dan

Ralph / et al.,

I wanted to add to this with some new information - I think I found the source of the high memory use.  While experimenting using build scripts and what-not (as I usually do), I noticed that some code I pulled from the Xilinx GITHUB had the implementation command set to jobs 16.

Well, my machine is only a quad core.  This means that was the source of my issue.  Basically, once I changed that one line to jobs 4, my machine did NOT use more than 16GB of ram generating an image for a ZCU104 (7EV MPSoC).

I was not seeing this in any of the builds from Avnet's repo, as we had worked around this without even knowing it.  The intention we originally put the below code in for, was allowing customers to tune their performance.  In this case, it worked around the high memory issue I was seeing.

From make.tcl in the 2019.1 Avnet repo:

From the same repo, but the UltraZed build script

--Dan