Large array crashes ghdl #812
Comments
|
This might be related to #752. @wsneijers, did you try increasing the size of the stack as suggested in #611 (comment)? |
|
@umarcor Yes I did try increasing the stack size, it did not work though. I don't know if it is related. Could definitely be. That is using vunit however and not cocotb. |
|
2**28 * 128 is a huge number of signals. |
|
@tgingold Good sugestion. Never thought of it, thanks! It does solve one problem, the speed. It is now as fast as normal. However it still breaks with 2^28 array size. Though it is a little more descriptive: It does now mention a NULL access deference. But the |
|
If you think about it: 2**28 * 128 equals 32 Gbit. I'am not sure about the internal representation of std_logic, but with a efficient encoding it needs at least 4 bit. If it's implemented as a char (8bit), you'll need 32 GB of memory just for the data storage not including any overhead. |
|
I am having the same problem with 2d array defined as: subtype CCD_Width_Range is natural range 0 to 2752 - 1;
subtype CCD_Height_Range is natural range 0 to 2002 - 1;
subtype CCD_Pixel_Data_T is std_logic_vector(12 - 1 downto 0);
type CCD_Matrix_T is array (CCD_Height_Range, CCD_Width_Range) of CCD_Pixel_Data_T;which should amount to cca. 65 MB. Problem is, as was said, the array is being allocated on stack. In future would it be possible to detect big allocations and allocate them on heap instead? However, what's puzzling is, that I tried rising the stack size limit and it doesn't immediately crash, but it tries to allocate more than 16GB of memory (memory requirement does not seem to scale linearly?). @tgingold |
|
Can you post a testcase ? The initial issue was with signals which are never allocated on the stack.
|
|
Yes, this one is even more interesting. It runs with 8MB stack limit but still it tries to allocate all of my RAM :). Running LLVM flavour, but same thing should happen under mcode. I know the code has problems, the point is, the memory usage is high even when instantiating entity with all array elements set to all '0'. test_pkg.vhd library ieee;
use ieee.std_logic_1164.all;
package test_pkg is
subtype CCD_Width_Range is natural range 0 to 2752 - 1;
subtype CCD_Height_Range is natural range 0 to 2002 - 1;
subtype CCD_Pixel_Data_T is std_logic_vector(12 - 1 downto 0);
type CCD_Matrix_T is array (CCD_Height_Range, CCD_Width_Range) of CCD_Pixel_Data_T;
end package test_pkg;array_test.vhd library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.test_pkg.CCD_Matrix_T;
entity array_test is
port(
clkIn, rstAsyncIn : in std_logic;
ccdArray : in CCD_Matrix_T
);
end entity array_test;
architecture RTL of array_test is
begin
ctrlProc : process(clkIn, rstAsyncIn)
variable currWidth, currHeight : natural := 0;
begin
if rstAsyncIn = '1' then
currWidth := 0;
currHeight := 0;
elsif rising_edge(clkIn) then
report "Current pixel: " & to_hstring(ccdArray(currHeight, currWidth));
if currWidth >= ccdArray'high(2) then
currWidth := 0;
currHeight := currHeight + 1;
else
currWidth := currWidth + 1;
end if;
end if;
end process ctrlProc;
end architecture RTL;array_test_tb.vhd library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.test_pkg.all;
entity tb_array_test is
end tb_array_test;
architecture tb of tb_array_test is
signal clkIn : std_logic;
signal rstAsyncIn : std_logic;
signal ccdArray : ccd_matrix_t;
constant TbPeriod : time := 1000 ns;
signal TbClock : std_logic := '0';
signal TbSimEnded : std_logic := '0';
begin
dut : entity work.array_test
port map(
clkIn => clkIn,
rstAsyncIn => rstAsyncIn,
ccdArray => (others => (others => X"000"))
);
TbClock <= not TbClock after TbPeriod / 2 when TbSimEnded /= '1' else '0';
clkIn <= TbClock;
stimuli : process
begin
TbSimEnded <= '1';
wait;
end process;
end tb; |
|
I can reproduce the memory issue.
|
|
Note that you are using ~60E6 signals. A signal needs at least 144bytes, so you need at least 9GB for the signals. Then you also need to add drivers...
You should use variables instead of signals when possible.
|
|
Where's the ~60E6 coming from? I see that my model needs: Where did I err in my calculations? Otherwise thanks, I will rewrite it to use variables 👍 . |
|
The CCD_Matrix_T is an array of 2752*2002 vectors of 12 std_logic.
You forgot the 12.
|
|
Ah, thanks again. It makes sense now. |
Hello,
I've been running into an issue with GHDL using large arrays in vhdl (declared as type). To start I already saw previous issues about the same sort of subject: #342, #471 and #611. In those issues the problem is marked as solved. However I still have the same sort of issue, even with the latest master sources.
In my case I'm using a test setup combining cocotb and GHDL. Where cocotb creates the test stimuli and monitors. Don't know if this can make a difference, but for completeness I thought id mention it. I'm trying to simulate the following file:
Which for me causes the following output in the testbench:
When I decrease the size of the array I get to a point where it starts working again:
However the simulation is very very slow! I already tried debugging with GDB, breaking at
_exitand__ghdl_fatal. The breakpoint at__ghdl_fataldoes not work. The breakpoint at '_exit' does, however the output is not very usefull:At this point I'm kinda lost at what to do.
The text was updated successfully, but these errors were encountered: