#475 Compiling large memories can crash the compiler

[Anonymous]

The opencore vga_lcd design compiled just fine but when I run ivl to do simulation I get an error 134 with a stackdump. I have enclosed the Makefile and the stackdump file. Since it is easy to cvs the vga_lcd I will let you do that.

In the future if you want users to help with debugging the runtime, could you publish instruction on how to use gdb to facillitate the process.

P.S. This is run on an 2 GHz AMD chip with 2 GB of memory.

Best regards,
Michael A. Beaver
(408) 656-9526

===================
Icarus Verilog version 0.9.devel (s20080429)

Copyright 1998-2008 Stephen Williams
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA

Plain Text Attachment [ Scan and Save to Computer ]

--------------------------------------------
---- Compile Test: test_bench_top ----
--------------------------------------------
iverilog -g2x -I../../../rtl/verilog -I../../../bench/verilog
../../../rtl/verilog/generic_dpram.v ../../../rtl/verilog/generic_spram.v
../../../rtl/verilog/vga_clkgen.v ../../../rtl/verilog/vga_fifo_dc.v
../../../rtl/verilog/vga_pgen.v ../../../rtl/verilog/vga_wb_master.v
../../../rtl/verilog/vga_wb_slave.v ../../../rtl/verilog/vga_colproc.v
../../../rtl/verilog/vga_csm_pb.v ../../../rtl/verilog/vga_cur_cregs.v
../../../rtl/verilog/vga_curproc.v ../../../rtl/verilog/vga_enh_top.v
../../../rtl/verilog/vga_fifo.v ../../../rtl/verilog/vga_tgen.v
../../../rtl/verilog/vga_vtim.v ../../../bench/verilog/test_bench_top.v
../../../bench/verilog/wb_b3_check.v ../../../bench/verilog/wb_slv_model.v
../../../bench/verilog/wb_mast_model.v ../../../bench/verilog/sync_check.v
../../../bench/verilog/artsmcl18u_ram/art_hssp_512x24_bw_bist.v
../../../bench/verilog/artsmcl18u_ram/art_hsdp_128x24_bist.v
../../../bench/verilog/bist/rtl/verilog/bist_dp_top.v
../../../bench/verilog/bist/rtl/verilog/bist_sp_top.v ../../../bench/verilog/bist/rtl/verilog/bist_tp_top.v
../../../bench/verilog/bist/rtl/verilog/bist.v
../../../bench/verilog/artsmcl18u_ram/art_hssp_512x24_bw/art_hssp_512x24_bw.v
../../../bench/verilog/artsmcl18u_ram/art_hsdp_128x24/art_hsdp_128x24.v -o
../../../sim/rtl_sim/bin/tc_dsync.vvp \
/verilog/test_bench_top.v
../../../bench/verilog/artsmcl18u_ram/art_hssp_512x24_bw_bist.v: No
such file or directory
../../../rtl/verilog/vga_fifo.v:137: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:137: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:138: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:138: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:138: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:138: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:139: warning: Bit select [7] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:139: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:139: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:139: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:140: warning: Bit select [8] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:140: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:140: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:140: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:140: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:140: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:141: warning: Bit select [9] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:141: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:141: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:141: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:142: warning: Bit select [10] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:142: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:142: warning: Bit select [7] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:142: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:143: warning: Bit select [11] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:143: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:143: warning: Bit select [9] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:143: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:144: warning: Bit select [12] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:144: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:144: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:144: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:145: warning: Bit select [13] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:145: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:146: warning: Bit select [14] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:146: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:146: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:146: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:147: warning: Bit select [15] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:147: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:147: warning: Bit select [14] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:147: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:148: warning: Bit select [16] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:148: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:148: warning: Bit select [15] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:148: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:148: warning: Bit select [13] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:148: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:137: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:137: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:138: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:138: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:138: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:138: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:139: warning: Bit select [7] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:139: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:139: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:139: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:140: warning: Bit select [8] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:140: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:140: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:140: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:140: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:140: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:141: warning: Bit select [9] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:141: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:141: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:141: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:142: warning: Bit select [10] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:142: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:142: warning: Bit select [7] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:142: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:143: warning: Bit select [11] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:143: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:143: warning: Bit select [9] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:143: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:144: warning: Bit select [12] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:144: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:144: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:144: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:145: warning: Bit select [13] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:145: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:146: warning: Bit select [14] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:146: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:146: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:146: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:147: warning: Bit select [15] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:147: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:147: warning: Bit select [14] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:147: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:148: warning: Bit select [16] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:148: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:148: warning: Bit select [15] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:148: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:148: warning: Bit select [13] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:148: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:137: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:137: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:138: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:138: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:138: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:138: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:139: warning: Bit select [7] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:139: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:139: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:139: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:140: warning: Bit select [8] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:140: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:140: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:140: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:140: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:140: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:141: warning: Bit select [9] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:141: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:141: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:141: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:142: warning: Bit select [10] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:142: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:142: warning: Bit select [7] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:142: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:143: warning: Bit select [11] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:143: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:143: warning: Bit select [9] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:143: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:144: warning: Bit select [12] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:144: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:144: warning: Bit select [6] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:144: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:145: warning: Bit select [13] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:145: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:146: warning: Bit select [14] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:146: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:146: warning: Bit select [5] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:146: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:147: warning: Bit select [15] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:147: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:147: warning: Bit select [14] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:147: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:148: warning: Bit select [16] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:148: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:148: warning: Bit select [15] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:148: : Replacing expression with
a constant 1'bx.
../../../rtl/verilog/vga_fifo.v:148: warning: Bit select [13] out of
range of vector q[4:1].
../../../rtl/verilog/vga_fifo.v:148: : Replacing expression with
a constant 1'bx.
sh: line 1: 5724 Done(1) /usr/local/lib/ivl/ivlpp -L
-F/cygdrive/c/DOCUME~1/COMPAQ~1/LOCALS~1/Temp/ivrlg21a26f3a6
-f/cygdrive/c/DOCUME~1/COMPAQ~1/LOCALS~1/Temp/ivrlg1a26f3a6
-p/cygdrive/c/DOCUME~1/COMPAQ~1/LOCALS~1/Temp/ivrli1a26f3a6
4792 Aborted (core dumped) |
/usr/local/lib/ivl/ivl -C/cygdrive/c/DOCUME~1/COMPAQ~1/LOCALS~1/Temp/ivrlh1a26f3a6
-C/usr/local/lib/ivl/vvp.conf -- -
make: *** [sim] Error 134

[Nobody/Anonymous]

[Cary R.]

Logged In: YES
user_id=1651735
Originator: NO

> The opencore vga_lcd design compiled just fine but when I run ivl to do
> simulation I get an error 134 with a stackdump. I have enclosed the
> Makefile and the stackdump file.

Hmmm, this doesn't make sense. iverilog calls ivlpp and ivl to compile the code. You use vvp to actually run the simulation not ivl. This appears to be the compiler failing not the runtime. One thing to look at is if -tstub instead of the default (-tvvp) produces the same crash. This would help identify if the failure is in the code generator or the compiler proper.

> Since it is easy to cvs the vga_lcd I will let you do that.

Getting this is only easy if you have an account!

> In the future if you want users to help with debugging the runtime, could
> you publish instruction on how to use gdb to facillitate the process.

This doesn't appear to be the runtime, but if it was it would be as simple as gdb /usr/local/lib/ivl/vvp core, but This all depends on the system you are using. Debugging the compiler is harder in that you must figure out which executable failed (iverilog, ivlpp or ivl) the -d flag and -t stub can help. Without an example to demonstrate the problem there's not much more I can do.

> P.S. This is run on an 2 GHz AMD chip with 2 GB of memory.

It is almost always best to supply the OS and its version along with the compiler and its version. The speed of the CPU and memory are almost never the issue. From what you posted it appears you are using a Cygwin system. FYI I regularly compile on Cygwin so it should be fine.

[Michael A. Beaver]

Logged In: YES
user_id=452231
Originator: NO

OK, caryr,

Here are your answers.

1) Icsrus verilog version = latest development version
2) OS is win-xp sp2 using latest cygwin
3) iverilog is used to compile the code and vpp is used to run the simulation. This is evident from the Makefile. I have used iverilog with both -g2 andf -g2x switches.
4) Maybe it is the compiler which is failing. All I can see is the stackdump. If you really want to be helpful could you tell define an error code 134.
5) I noticed that iverilog is suppose to produce a vvp file and does not so it looks like the compiler is the problem.
6) The opencore vga_lcd core has been around for about 3 years and has been run using lots of commercial and shareware verilog tools. Do you guys ever test with real world designs? Get an account with the opencores.org folks. Its real easy :)
7) Here is the output with the -tstub switch
sh: line 1: 6012 Done(1) /usr/local/lib/ivl/ivlpp -L -F/cygdrive/c/DOCUME~1/COMPAQ~1/LOCALS~1/Temp/ivrlg2a7b642c -f/cygdr
ive/c/DOCUME~1/COMPAQ~1/LOCALS~1/Temp/ivrlga7b642c -p/cygdrive/c/DOCUME~1/COMPAQ~1/LOCALS~1/Temp/ivrlia7b642c
6044 Aborted (core dumped) | /usr/local/lib/ivl/ivl -C/cygdrive/c/DOCUME~1/COMPAQ~1/LOCALS~1/Temp/ivrlha7b642c -C/us
r/local/lib/ivl/stub.conf -- -
make: *** [sim] Error 134

8) Your stackdump is called ivl.exe.stackdump. I assumed ivl.exe was the problem.

best regards,
Michael A. Beaver
mbeaver408@sbcglobal.net
(408) 656-9526

[Cary R.]

Logged In: YES
user_id=1651735
Originator: NO

> Here are your answers.

Thanks for the reply.

> 1) Icsrus verilog version = latest development version

Actually this isn't quite true. You are using the latest snapshot (April 29th 2008). The latest code is available from the git repository.

> 2) OS is win-xp sp2 using latest cygwin
> 3) iverilog is used to compile the code and vpp is used to run the
> simulation. This is evident from the Makefile. I have used iverilog with
> both -g2 andf -g2x switches.

As one of the developers it's fair to assume I know how the Icarus flow works and how to read a Makefile. My comment was for you since you made the following incorrect statement in your original post "when I run ivl to do simulation". ivl is run during the compilation phase not the simulation phase

> 4) Maybe it is the compiler which is failing. All I can see is the
> stackdump. If you really want to be helpful could you tell define an error
> code 134.

The compiler is what is failing and there's no need to be snippy! Once the core dump happens everything after that is controlled by the system iverilog is not returning a code or producing the core file that is Cygwin.

> 5) I noticed that iverilog is suppose to produce a vvp file and does not
> so it looks like the compiler is the problem.

Yes that is correct.

> 6) The opencore vga_lcd core has been around for about 3 years and has
> been run using lots of commercial and shareware verilog tools. Do you guys
> ever test with real world designs? Get an account with the opencores.org
> folks. Its real easy :)

Again with the snippy. Yes we test, but this is free software and we don't have a dedicated QA person. Do you want to volunteer? It may be easy to get an opencores account, but there are very good reason that I won't be getting one.

> 7) Here is the output with the -tstub switch
> 6044 Aborted (core dumped) | /usr/local/lib/ivl/ivl

OK so the problem appears to be in the compiler proper not the code generator.

> 8) Your stackdump is called ivl.exe.stackdump. I assumed ivl.exe was the
> problem.

Don't blame that abomination on us. Like I said earlier once the core dump start the system is in control not iverilog. Did you look at the stackdump?

Cygwin is a great system when things are working well and it is very handy to have Unix like tools available in a windows environment, but it has terrible debugging capabilities. Can you try this on a Linux or other Unix like system? You could get a working core file which may help in tracking down the underlying problem. Like I said previously another thing to try is to use the various -d flags in iverilog to see what the compiler was doing just before it crashes.

If you want me to work on this you will need to do some debugging or provide a reduced example.

Cary

[Larry Doolittle]

Logged In: YES
user_id=1169926
Originator: NO

I think the compiler ran out of memory trying to instantiate a 128 MByte memory.
Starting on line 83 of bench/verilog/wb_slv_model.v does

parameter mem_size = 13;
parameter sz = (1<<mem_size)-1;

reg [31:0] mem[sz:0];

The instantiation on line 667 of bench/verilog/test_bench_top.v is

wb_slv #(24) s0(.clk( clk ),
...

On my machine, the compiler starts swapping like mad while working on that memory, and I'm not patient enough to find out if it ever finishes. If I change that 24 to 22, I can get a successful compile, and the simulation runs. It reports 43 Value Mismatch errors, which may or may not have anything to do with the reduced size of simulated memory.

It's possible there's a compiler bug (address overflow?) working with these large memories. 22 bits compiles and runs painlessly, but at 23 bits the compiler ran over a minute before I killed it.

[Larry Doolittle]

Logged In: YES
user_id=1169926
Originator: NO

Using the simplest possible memory instantiator:

module memtest;
parameter mem_size = 20;
parameter sz = (1<<mem_size)-1;
reg [31:0] mem[sz:0];
endmodule

I tried various memory sizes, and timed the compile on my
2.2 GHz AMD64 with 1 MB of RAM.

bits time(s)
20 0.43
21 0.88
22 1.64
23 5.24
24 >360 (thrashing swap)

Interestingly, the vvp files generated are all short.

[Larry Doolittle]

Logged In: YES
user_id=1169926
Originator: NO

I wrote:
> I tried various memory sizes, and timed the compile on my
> 2.2 GHz AMD64 with 1 MB of RAM.

Of course, that's 1 GB of RAM. I'm showing my age -- the first serious computer I bought actually did have 1 MB of RAM.

[Cary R.]

Logged In: YES
user_id=1651735
Originator: NO

Thanks for looking at this Larry. Now that I have a simple example I'll see if there is anything that can be done. Execution time and I'm assuming memory are growing linearly with array (memory) size. That's very bad. Not really a bug, but still something that needs to be changed if possible. Here's my table using your simple example:

bits time(s)
20 0.29
21 0.57
22 1.13
23 2.27
24 4.60
25 8.96
26 crash with bad allocation.

I have 4G of memory (4x what Larry had), so the short term fix appears to be run this on a machine with enough memory. The Cygwin and windows combination will likely hit this problem earlier.

I'm changing the summary to match the real problem.

> the first serious computer I bought actually did have 1 MB of RAM.

Ah, the good old days! Disk drives the size of washing machines and working on the original 1 MIPS CPU.

[Cary R.]

Logged In: YES
user_id=1651735
Originator: NO

I looked at this briefly. It looks like the compiler is initializing every array element and hence the large memory and time requirement. We should be able to do a lazy evaluation of the memory like is done in the run time. Since Steve did the vvp implementation I am going to leave this for him unless I get some free time before he gets to it.

[Cary R.]

Logged In: YES
user_id=1651735
Originator: NO

FYI someone provided me with a copy of the files. I corrected the attached make file and ran the simulation without any other changes, it ran without error until it got to the Pixel Data tests (276,986,685.0 ns). There were two run time warnings related to interrupts before this. The first during the R/W tests at 498.0 ns and the second during mode 0 testing at 33,603.0 ns. I changed the make file as follows. The -o output from iverilog should be the input for vvp. The vvp line currently references a different file and a non-existent directory. I made the vvp line just use the file produced by iverilog ($(SIM_DIR)/tc_dsync.vvp). This ran for over an hour on my Linux machine to get to the Pixel tests. Once you get this running you can expect it to be many times slower running under Cygwin.

I'm not sure what to make of the Pixel Data mismatch errors and I don't have time to look at them right now. I need to get some real work done.

[Stephen Williams]

Logged In: YES
user_id=97566
Originator: NO

It sounds like this issue can be condensed down to a single not-too-complicated sample program that can be attached to this PR. If somebody can do that, then I can look into dealing with the inefficiencies of array handling. It would be nice if we can get this problem report to be self contained.

[Cary R.]

Logged In: YES
user_id=1651735
Originator: NO

Steve,

Look at Larry's post. He has a five line program the can be used to check the excessive memory usage problem. I have had no time to track down the runtime problems that appear if you have enough memory in your machine to avoid the original memory crash.

[Cary R.]

Logged In: YES
user_id=1651735
Originator: NO

FYI the memory failure is happening at the NetNet call on line 1023 of elab_sig.cc.

[Larry Doolittle]

Logged In: YES
user_id=1169926
Originator: NO

Instrumenting iverilog shows that the blame for this linear use of memory and time lies in the NetPins constructor, which gets called with npins = the size (words) of the array.

Because I'm not the submitter, I can't add an attachment to this SF bug report. If you care to reproduce this experiment, grab my patch from http://recycle.lbl.gov:~ldoolitt/debug2023076.patch

[Stephen Williams]

Logged In: YES
user_id=97566
Originator: NO

Larry,

Your link doesn't seem to work. However, I've updated the permissions so you should be able to attach it now, assuming you are logged on.

[Larry Doolittle]

Logged In: YES
user_id=1169926
Originator: NO

> Your link doesn't seem to work.
My bad. That should have been http://recycle.lbl.gov/~ldoolitt/debug2023076.patch

> I've updated the permissions so you should be able to attach it now
Patch attached now, too.
File Added: debug2023076.patch

[Larry Doolittle]

instruments iverilog to localize this bug; not for production use

[Larry Doolittle]

Logged In: YES
user_id=1169926
Originator: NO

The massive array of NetPins of course in turn triggers a corresponding O(n) set of "new Link" and "new Nexus" calls. Those get initialized (all to the same value) in the NetNet constructor. That's all conceptually easy to do lazily. Then each of the NetPins is accessed in turn with the call stack
main nodangle Design::functor NetScope::run_functor nodangle_f::signal.
It's the loop in nodangle_f::signal that computes linked_flag. That's a little harder to make lazy, but plausible (I think) if that loop is made a method of the NetPins class.

It's actually impressive that iverilog works at all with this size memory instantiation. Cary's machine creates 32 million Links and Nexa, initializes, scans, and destroys them, in 9 seconds? Wow. This is both a testament to the efficiency of C++, and the ease with which you can shoot yourself in the foot 32 million times over with C++. ;*)

[Larry Doolittle]

Allow me to point out that this problem exposes three nearly independent problems:
1. The memory usage per Link is "too high"
2. The need to create one Link per memory element could be relaxed
3. Icarus segfaults instead of failing cleanly when it runs out of memory

Steve has made great progress on (1).

I have talked about, and started to code, an answer to (2).

That leaves (3), which is arguably the only actual bug. I will see if I can reproduce (3) on relatively small memories using ulimit or other Unix tricks, so I don't have to fight for control of a nearly out-of-memory workstation every time. I encourage others to do the same. Steve, can you play C++ tricks with "new" in the same way people wrap malloc with xmalloc?

[GiGi LoCic]

Adding simple programs to help debug this problem.

1. This below code compiles good and fast.

//8M * 4 Bytes
module big_mem();
reg [31:0] mem [(1024*1024*8)-1:0];
endmodule

2. following code, takes more time to compile and heavily loads the CPU,

//16M * 4 Bytes
module big_mem();
reg [31:0] mem [(1024*1024*16)-1:0];
endmodule

3. Following code throws the following Abort condition, we will not be knowing
what is causing this error if we have many files.,

terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted

//32M * 4 Bytes
module big_mem();
reg [31:0] mem [(1024*1024*32)-1:0];
endmodule

[Cary R.]

Larry has shown interest in fixing this so I am assigning it to him.

[Nobody/Anonymous]

As Larry suggested, it seems compiled CC++ programs cannot support the "large" memory request at run time. That is, in case of "large" memory array of Verilog statements, the design of class NetPin, when being instantiated, requires to create a new instance of NetLink for each and every NetPin object, which is not feasible in C++. This can be quickly verified by writing a small program by using C++ library <bitset>.

#include <iostream>
#include <bitset>
#include <string>

using namespace std;

int main()
{
const int w = 1048576; // 2^20

bitset<w> b0\(s\);
cout << "w = " << w << endl;
return 0;

}

The above program will run OK. But, when w is increased to around 2^27, I always get segfaults at run time. I use Fodera 7 and g++ 4.1.2.

I saw in netlist.txt of the Icarus development release 20081118 that Steve uses class NetMemory to describe Verilog memory, but not implemented. Maybe, Steve considered the potential problems of large memory allocation.

As for catching exception of segfaults, the Linux kernel, as I understand from the kernel source 2.6.18, would kill the process abruptly in which the program if it considers the process is requesting "too much memory." In other words, in such a case, even if you put in signal handlers in the program in order to abort gracefully, there would be no chance for the signal handlers to run because the process in which the problem program runs would get killed instantly.

Therefore, I guess Steve needs probably to design the class NetMemory to handle the Verilog memory array.