Jump to content

Search the Community

Showing results for tags 'stack overflow'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Accellera Systems Initiative
    • Information
    • Announcements
    • In the News
  • SystemC
    • SystemC Language
    • SystemC AMS (Analog/Mixed-Signal)
    • SystemC TLM (Transaction-level Modeling)
    • SystemC Verification (UVM-SystemC, SCV)
    • SystemC CCI Public Review
  • UVM (Universal Verification Methodology)
    • Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • Simulator Specific Issues
    • UVM Commercial Announcements
    • UVM 1.2 Public Review
  • Portable Stimulus
    • Portable Stimulus Discussion
  • IP-XACT
    • IP-XACT Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • OCP (Open Core Protocol)
  • UCIS (Unified Coverage Interoperability Standard)
  • Commercial Announcements
    • Announcements

Categories

  • SystemC
  • UVM
  • UCIS
  • IEEE 1735/IP Encryption

Calendars

  • Community Calendar

Found 2 results

  1. Dear all, I need to simulate a (very) large RC network modeling a circuit equivalent model to simulate thermal distribution, ~12,000 Rs, ~4,000 Cs, ~4,000 nodes). When I run the simulation, I get a segmentation fault. GDB says that the call is caused by a call to: sca_core::sca_implementation::sca_conservative_view::move_connected_module( and, if I look at the call stack, I see that many invocations of these function are recursively done, until the simulation crashes. I had a look at the code with Valgrind, and got that the seg fault is caused by a stack overflow: I tried to increase stack size, by recompiling both SystemC (2.3.1) and SystemC AMS (2.1), as suggested in the INSTALL: However, I still get the same error and the same output from Valgrind. Is there any other way to increase stack size, or to improve the code so that I can run the simulation? Or am I simply being too ambitious? :) For the sake of clarity, here is a (very brief) extract of the RC network I have to simulate, just to show how network elements are being declared: SC_MODULE(network) { //Interface declaration: sca_tdf::sca_in<double> p_die_grid_1_1; sca_tdf::sca_out<double> t_die_grid_1_1; ... // isource to use values on input ports as currents sca_eln::sca_tdf::sca_isource* itemp_1_1_grid; ... // vsink to write voltage values on output ports sca_eln::sca_tdf::sca_vsink* vtemp_1_1_grid; ... // network elements sca_eln::sca_r* r_amb_grid_1_1; sca_eln::sca_c* c_1_1_SILICON; sca_eln::sca_node node_1_1_SILICON; ... sca_eln::sca_node_ref gnd; SC_CTOR(network){...}; ~network(){...} } Regards, S.
  2. My top-level is a NoC consists of a Network-On-Chip with a grid of 15*15 nodes (Router+PE). Been trying to simulate it in different machines/configurations but kept stopping at different times of the simulation. Can't see what causes the problem and hence I am stack. 1) Running only SystemC / C++ executable (output of the compiler) in a LSF cluster. Simulation runs normally with expected output then it stops at the 55000ish cycle (cycle accurate model) with this error message: noc_exe: ../../../../src/sysc/kernel/sc_cor_qt.cpp:107: virtual void sc_core::sc_cor_qt::stack_protect(bool): Assertion `ret == 0' failed. /home/#######/.lsbatch/1438183854.772657: line 8: 15547 Aborted (core dumped) ./noc_exe 2) Running with Cadence irun command in a LSF cluster. The simulation was heaps of times slower but managed to reach 100 000ish cycles before generating this error message: Simulation interrupted at 1025080 NS + 0 ncsim> ncsim: *W,NCTERM: Simulation received SIGTERM signal from process 22268, user id 0 (/env/seki/app/lsf/8.0/etc/sbatchd). make: *** [run] Error 15 I have investigated the error NCTERM with nchelp and got: nchelp: 14.20-s010: (c) Copyright 1995-2015 Cadence Design Systems, Inc. ncsim/NCTERM = A SIGTERM signal was received by the running simulation. This signal may have been issued due to various reasons: * sent by the user using the kill command * machine on which the job was running went down * sent by LSF (Load Sharing Facility) to enforce certain user specified job control limits (memory, CPU, swap, etc.) I had a little doubt that the stack size might not be enough for my threads. The outputs from 1) and 2) took place even after I tried to increase the stack size. In 2), it is enough to add the -SC_THREAD_STACKSIZE 0x80000 switch to irun command. In 1), I had to go to every registration of thread in my constructors and append it with another line: SC_THREAD(controller_thread); set_stack_size(NOC_THREAD_STACK_SIZE); // 0x80000 I'd appreciate any prompt reply When I run the same test with a smaller number of nodes, the issue does not occur.
×