01-10-2019 08:57 AM
I run my simulation and I get the following message:
Virtual Object tree message too large: 32194953
Obviously I am abusing the capacities of Vivado 2018.3. I searched for that message on the Xilinx web site and I can't find any hit. Anybody knows what is abused? Is it related to the wave config window or the Locals window or is it fundamental in the simulation?
01-10-2019 08:12 PM
When are you facing this while running simulation, I mean does this message occur when you are doing something specific in simulation? Or does it occur with every design you simulate? Also, can you please share a snippet of the message??
01-10-2019 08:15 PM
Can you please share the screenshot of the error message and the log file.
What steps have you followed and at which step does this issue occur? Does this happen with all the designs or is this issue specific to one design?
For me it looks like a out of memory issue. Can you please check if it occurs when logging the wave? Do you have large number of signals added into the Waveform GUI? If yes, please try reducing them and check.
How much memory does your machine have? Can you please check the resource utilization while running xsim?
01-11-2019 07:55 AM
I traced the code while I was looking at memory utilisation. I confirm this is a memory utilisation issue and it is not related to waveform display (I closed the display and I encountered the condition on the memory allocation). The snippet is shown above.
My machine (Windows7-64) has 12 GB of memory and it gets all used as when the message appears. Here is a very simplified version of the file containing the problematic code:
`timescale 1ns / 1ps package ImagePkg; class Image; shortint image; int pgm_size_x, pgm_size_y, pgm_max; task load_image; integer fileId; int i; int pixel; string chaine; fileId = $fopen( "whatever.pgm", "r" ); i=$fscanf(fileId,"%d %d", pgm_size_x, pgm_size_y); image = new[pgm_size_x * pgm_size_y]; for (int j = 0; j < (pgm_size_x * pgm_size_y); j += 1) begin i=$fscanf(fileId," %d", pixel); image[j] = pixel; end $fclose(fileId); endtask : load_image endclass : Image endpackage : ImagePkg
The object uses a dynamic array to hold 16-bit data. The array is allocated at runtime at 1984x1200 which should allocate a dynamic array of 1984x1200x2 bytes = 4 761 600 bytes.
When the allocation takes place at the line "image = new[pgm_size_x * pgm_size_y];" the memory footprint of the xsimk.exe process increased by about 2 GB. I understand that vhdl std_logic type have 9 states and signals consume more memory in the simulator than the actual memory they represent. However I chose to use SystemVerilog 2-state type (shortint) and dynamic array especially because it should be the most efficient way of allocating large array. A factor of 450 between what I want to allocate and the memory actually consumed seems quite excessive.
Is there any preferred type and allocation method for an array for testbench purposes in Vivado simulator? I mean, this isn't a signal that will be put in waveform and there will never be X or Z in that array, so there must be an efficient way to allocating that array.
Thank you for your support,
05-28-2019 12:40 PM
I've been trying to reproduce the issue, but it has become too difficult to reproduce. My guess is that the patch fixing a Kernel bug in Windows also impacted this problem and hides it well enough.
I think we should close the case for now.
06-20-2019 05:06 AM
I have the same problem and this is not "out of memory issue", because at the moment, when error accured, the pc have 70% of free memory.
No error appears when simulation is in progress, but when it stops for some reason ($error or user stop), it shows up.
06-20-2019 05:33 AM
When I was seeing the problem, it was not only the general PC memory that was used up, there was also a lot of allocation in SystemVerilog (a large array of 16-bit data of something like 1920 x 1200 entries) that was consuming 2GB of system memory when allocated. Obviously, the memory allocator of the simulator is not very efficient for that type of data (even if I use 2-state type, as opposed to 4 state types or VHDL 9-state types).
There was another bug (kernel failure) related to memory that only appeared in Windows simulation. In Linux the simulation ran fine. I received a configuration setting that workaround that Windows issue. My hypothesis is that workaround also helped the Virtual Object Tree problem. That fix should be included in 2019.1. Have you seen the Virtual Object Tree message in 2019.1?
06-20-2019 07:40 AM
I agree that the problem appears only on Windows platform. Unfortunately, I can't try on Vivado 2019.1. I need to launch my tb on 2018.3 version.
About what configuration setting are you talking about? You received some patch?