Jump to content

Search the Community

Showing results for tags 'bad_alloc'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • 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, CRAVE, FC4SC)
    • SystemC CCI (Configuration, Control & Inspection)
    • SystemC Datatypes
  • UVM (Universal Verification Methodology)
    • UVM (IEEE 1800.2) - Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • UVM Simulator Specific Issues
    • UVM Commercial Announcements
    • UVM (Pre-IEEE) Methodology and BCL Forum
  • Portable Stimulus
    • Portable Stimulus Discussion
    • Portable Stimulus 2.0 Public Review Feedback
  • IP Security
    • SA-EDI Standard Discussion
    • IP Security Assurance Whitepaper Discussion
    • IP-XACT Discussion
  • SystemRDL
    • SystemRDL Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • Commercial Announcements
    • Announcements


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

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL












Found 2 results

  1. Dear all, is it possible to apply standard SystemC tracing to tlm_extensions? I defined my own tlm extension to add a reset and a value fields to the standard payload: class reg_extension : public tlm::tlm_extension<reg_extension>{ public: reg_extension(); tlm::tlm_extension_base* clone() const ; void copy_from(tlm::tlm_extension_base const &); bool reset; sc_bv<16> value; }; Then, my testbench declares and uses it to carry data to/from the target: class testbench : public sc_module , public virtual tlm::tlm_bw_transport_if<> { public: tlm::tlm_initiator_socket<> initiator_socket; reg_extension * payload_data; ... } void testbench::run() { tlm::tlm_generic_payload * trans; sc_time time; mem = new mem_manager(); trans = mem->allocate(); payload_data = new reg_extension; payload_data->value = sc_bv<16>("00001111"); payload_data->reset = 1; trans->set_data_length(sizeof(register_data_t)); trans->set_auto_extension(payload_data); trans->set_address(0); trans->set_write(); initiator_socket->b_transport(*trans, time); ... } In my main, I try to apply standard tracing: int main(int argc, char* argv[]) { toplevel top("top"); sc_trace_file* fp = sc_create_vcd_trace_file("wave"); fp->set_time_unit(1, SC_NS); sc_trace(fp, top.tb.payload_data->reset, "reset" ); sc_trace(fp, top.tb.payload_data->value, "value" ); sc_start(); sc_close_vcd_trace_file(fp); return 0; } The code compiles correctly, but: with SystemC 2.2.0, the generated trace is weird (see attached - I truncated the value as it had far too many digits) things get worse when compiling with SystemC 2.3.0, as the execution returns this error: My impression is that memory is somehow not managed - this would explain the wrong size for the value field, the huge correponding value, and the bad_alloc. Please note that I forced some wait invocations to advance simulation time, so that write operations onto the extension fields occur at different simulation times. Thank you in advance, Regards, S. wave.vcd
  2. Hello All, I need to spawn a large number of threads for my simulation using sc_spwan(). My threads are very small piece of code. When I have 16384 threads the simulation stops by issuing the following message in iteration 5504 of the loop invoking sc_spawn(): Error: (E549) uncaught exception: std::bad_alloc In file: ../../../../src/sysc/kernel/sc_except.cpp:98 I know this happens due to stack size, but I don't know how much memory is used by each thread. Q1) Is there a way to get the size of stack for each thread? Is there a method/function like get_stack_size()? Q2) How can I use set_stack_size() when invoking sc_spawn()? Q3) My simulation is run in CygWin under Windows 7 (32-bit). Does 32-bit the OS impose a limitation to the stack size? In other words, can the problem be fixed using a 64-bit OS? Thank you so much in advance!
  • Create New...