HI Tristan, Could you post your build steps and envvar setting for ghdl. I am struggling to get simulate vhdl designs, even though I could compile ghdl without errors.
Thanks. On Sat, Oct 24, 2009 at 12:29 AM, Peter LaDow <[email protected]> wrote: > Doh! I realize I forgot to attach the project. > > On Fri, Oct 23, 2009 at 4:18 PM, Peter LaDow <[email protected]> wrote: > > On Tue, Oct 20, 2009 at 10:04 PM, Tristan Gingold <[email protected]> > wrote: > >> I can't reproduce the crash: > >> > >> $ ../fpga_stamp_t0 > >> ../../../tools/tb/tcon_t0/src/tcon_t0.vhd:216:5:@3400ns:(assertion > failure): Halt requested. > >> ../fpga_stamp_t0:error: assertion failed > >> ../fpga_stamp_t0:error: simulation failed > > > > Yep! That's what I expected... > > > >> What is your output ? > >> (I don't really use the same environment that yours - that may explain > things) > > > > Hmm.... Here's what I get when I run it in gdb. > > > > (gdb) r --trace-processes > > Starting program: > > /home/pete/ghdl-pladow/fpga_stamp/fpga_stamp_m0/test/fpga_stamp_t0 > > --trace-processes > > [Thread debugging using libthread_db enabled] > > run process .fpga_stamp_t0(behav).t...@tcon_t0(behav).tcon_con > [0932A328] > > [New Thread 0xf7c6c0 (LWP 16476)] > > [New Thread 0x5f7db70 (LWP 16479)] > > run process .fpga_stamp_t0(behav).t...@tcon_t0(behav).gpio_con > [0932A328] > > run process .fpga_stamp_t0(behav).cloc...@clocker_t0(behav).tcon_con > [0932E9E8] > > run process .fpga_stamp_t0(behav).cloc...@clocker_t0 > (behav).clk_gen(0).clk_con > > [0932F970] > > Now is 0ms +0 > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0xf7c6c0 (LWP 16476)] > > 0xec835356 in ?? () > > (gdb) bt > > #0 0xec835356 in ?? () > > #1 0x08094bb0 in grt.signals.compute_resolved_signal (resolv=0x9329910) > > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/grt-signals.adb:1796 > > #2 0x08096e72 in grt.signals.update_signals () > > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/grt-signals.adb:3075 > > #3 0x0809c84e in grt.processes.simulation_cycle () > > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/grt-processes.adb:692 > > #4 0x080a1ad3 in __ghdl_run_through_longjump ( > > func=0x809c832 <grt.processes.simulation_cycle>) > > at ../../../gcc-4.3.4/gcc/vhdl/grt/config/linux.c:312 > > #5 0x0809c266 in grt.processes.simulation () > > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/grt-processes.adb:840 > > #6 0x080a72b8 in grt.main.run () > > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/grt-main.adb:154 > > #7 0x080a58e4 in ghdl_main (argc=2, argv=Cannot access memory at > > address 0xe58955c7 > > ) > > at /home/pete/Download/gcc-4.3.4/gcc/vhdl/grt/ghdl_main.adb:49 > > #8 0x080a1ea6 in main (argc=Cannot access memory at address 0xe58955c3 > > ) at ../../../gcc-4.3.4/gcc/vhdl/grt/main.adb:24 > > (gdb) info threads > > 2 Thread 0x5f7db70 (LWP 16479) 0x00d76416 in __kernel_vsyscall () > > * 1 Thread 0xf7c6c0 (LWP 16476) 0xec835356 in ?? () > > (gdb) thread 2 > > [Switching to thread 2 (Thread 0x5f7db70 (LWP 16479))]#0 0x00d76416 > > in __kernel_vsyscall () > > (gdb) bt > > #0 0x00d76416 in __kernel_vsyscall () > > #1 0x007e7fa5 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/libpthread.so.0 > > #2 0x0808fb9c in wait_for_function_complete () at src/tcon_thread.c:86 > > #3 0x0808f633 in tcon_write (l=0xb7e00468) at src/tcon_t0.c:173 > > #4 0x008b6bda in ?? () from /usr/lib/liblua-5.1.so > > #5 0x008c1d5a in ?? () from /usr/lib/liblua-5.1.so > > #6 0x008b70c0 in ?? () from /usr/lib/liblua-5.1.so > > #7 0x008b2061 in ?? () from /usr/lib/liblua-5.1.so > > #8 0x008b66e3 in ?? () from /usr/lib/liblua-5.1.so > > #9 0x008b6745 in ?? () from /usr/lib/liblua-5.1.so > > #10 0x008b1e88 in lua_pcall () from /usr/lib/liblua-5.1.so > > #11 0x0808f9e0 in lua_thread_entry (p=0x0) at src/tcon_t0.c:402 > > #12 0x007e3935 in start_thread () from /lib/libpthread.so.0 > > #13 0x0071894e in clone () from /lib/libc.so.6 > > (gdb) > > > > This one I expect. This is the Lua script running in its own thread > > (thread 2). It is waiting on a condition for the VHDL to complete its > > side of things. Now, the VHDL sets the condition by calling > > exec_tcon() (in tcon_t0.c in tools/tb/tcon_t0/src). But things are > > getting messed upon the VHDL side of things, and I'm not sure where. > > > > So, to try and track things down I sprinkled some printf's and > > assert's throughout my code to see where this was happening. I've > > narrowed it down to the wait in the tcon_write function in the VHDL. > > I've attached another project with the extra debug output. Here's > > what I get: > > > > run process .fpga_stamp_t0(behav).t...@tcon_t0(behav).tcon_con > [081E7328] > > Calling init_tcon <-- This is on the C side, called from the VHDL. > > This is where the extra thread is created > > Calling tcon_gpio_clrdir with clrdir=7 <-- This is also on the C > > side, but called from the Lua thread > > Calling exec_tcon with 0 <-- This is on the VHDL side, called from > > the tcon process in tcon_t0. The function number corresponds with a > > tcon function of 'none' in the VHDL > > Returning 9 from exec_tcon <-- This is after the exec_tcon is done, > > returning with a new function code. It blocks in exec_tcon() until > > the Lua side sets a function code. The 9 indicates a new function, > > which is 'gpio_clr_dir' > > Calling exec_tcon with 9 <-- After the VHDL is done, it calls > > exec_tcon with the function code. The Lua thread is blocked waiting > > for the VHDL to finish. This call signals that the VHDL is done. It > > then blocks waiting for a new function. > > Calling tcon_write with req=0, addr=1, data=2710 <-- On the Lua side > > of things again. It sets the function code (along with the data) and > > blocks until the VHDL is done. > > Returning 2 from exec_tcon <-- Back to the VHDL side. The VHDL > > returns 2, which corresponds to a 'write' > > ../../../tools/tb/tcon_t0/src/tcon_t0.vhd:180:11:@0ms:(assertion > > note): VHDL: Executing tcon_write <-- Now the VHDL assertions > > showing the tcon_write is running in the VHDL > > ../../../tools/tb/tcon_t0/src/tcon_t0.vhd:144:7:@0ms:(assertion note): > > VHDL: Waiting for tcon_ack <-- Here the VHDL is waiting for up to > > 1ps for the tcon_ack to get set to '1' (though it occurs in 0 time). > > run process .fpga_stamp_t0(behav).t...@tcon_t0(behav).gpio_con > [081E7328] > > run process .fpga_stamp_t0(behav).cloc...@clocker_t0(behav).tcon_con > [081EB9E8] > > run process .fpga_stamp_t0(behav).cloc...@clocker_t0 > (behav).clk_gen(0).clk_con > > [081EC970] <-- We see the clocker_t0 processes run, which > > corresponds with the write we were doing (trying to write the clock > > generation modules). Then it goes kaput after this. > > Now is 0ms +0 > > ../fpga_stamp_t0:error: invalid memory access (dangling accesses or > > stack size too small) > > ../fpga_stamp_t0:error: simulation failed > > > > The fact that is runs fine on your system does seem strange. Now, I > > don't know what build you are using. Perhaps you can send me a > > compiled version of fpga_stamp_m0 and I can see if that works for me? > > If that compiled version works, then it would point to a problem with > > my GHDL build. If it poops out on my end, then it would point to > > library issues (perhaps buggy pthread or Lua libraries). > > > > Thanks, > > Pete > > > > _______________________________________________ > Ghdl-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/ghdl-discuss > >
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
