Jump to content

svinco

Members
 View Profile  See their activity

  • Content Count

    14

  • Joined

  • Last visited

 Content Type 

Everything posted by svinco

  1. svinco
    I actually forced Simulink to work with the same time step (fixed time step of 1ms) and with the Euler solver (ode1), which in my understanding is the underlying solver of SystemC-AMS.. This is confusing me. SystemC-AMS starts diverging after two time steps..
  2. svinco
    My model contains a number of differential equations, that converge only if I set an appropriate initial condition. The model per se is correct (I double-checked both the model and the initial conditions with Simulink), but the corresponding SystemC-AMS implementation diverges after few samples. I set the initial condition as the third parameter of the constructor, e.g.: sca_lsf::sca_integ * myInteg; ... SC_CTOR(myModule){ myInteg = new sca_lsf::sca_integ("myInteg", 1.0, 5.0); ... }; where the initial condition is 5.0. Is this correct? Best regards, S.
  3. svinco
    We solved the issue by modifying the maximum stacksize of the operating system. We are running on a Linux machine, thus we used the system call: setrlimit(RLIMIT_STACK, <new size>) refs: https://linux.die.net/man/2/setrlimit. Thanks for the support and the discussion. Regards, S.
  4. svinco
    The topology is as in http://www.cs.virginia.edu/~skadron/Papers/thermal_taco04.pdf, figure 1. So you suggest that we should break the network, so that we have fewer connected ELN modules? And that the problem is caused by the recursive call? Regards, S.
  5. svinco
  6. svinco
    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:
  7. svinco
    Thank you very much for your hints - I managed to fix the code and to have 0 memory leaks! Regards, S.
  8. svinco
    Dear all, I implemented a memory manager (implementing the tlm_mm_interface interface). However, whenever I use the manager with TLM, I get loads of memory leaks, that seem to be caused by the new in the allocate method. Does anybody know an alternative implementation of this, or does anybody understand how I could avoid the leaks? What am I doing wrong? Best regards, S. #include <systemc.h> #include <tlm.h> class mem_manager : public tlm::tlm_mm_interface{ public: std::vector<tlm::tlm_generic_payload *> free_list; tlm::t
  9. svinco
    Dear all, I am new to payload extensions and I would appreciate a feedback on whether I am doing things right.. I need to declare a simple payload extension, including two additional fields: a reset value a 16 bit bit vector representing the value of a register In the header, I simply declare the clone/copy from functions, plus my additional fields: 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 &);
  10. svinco
    Dear all, I am new to payload extensions and I would appreciate a feedback on whether I am doing things right.. I need to declare a simple payload extension, including two additional fields: a reset value a 16 bit bit vector representing the value of a register In the header, I simply declare the clone/copy from functions, plus my additional fields: 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 &);
  11. svinco
    Dear all, to define extensions of the generic payload, I defined also a memory manager class, implementing the tlm_mm_interface. I googled and tried almost all implementations available out there - they all generate memory leaks (as bad as 80 bytes in 2 blocks, according to Valgrind). Can anybody help me? The issue seems to be caused by the allocate method. Header file: class mem_manager : public tlm::tlm_mm_interface{ public: std::vector<tlm::tlm_generic_payload *> free_list; tlm::tlm_generic_payload * allocate(); void free(tlm::tlm_generic_p
  12. svinco
    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_tran
  13. svinco
    Ralph, thank you for your prompt answer. I hadn't realized that the sc_vector is a novel construct of the 2.3.0 version of SystemC - and for some reason my files were working with the 2.2 version. It now works :) I also avoided using the class pointer. The resulting declarations are: sc_vector<reg > register_file; sc_vector <tlm::tlm_initiator_socket<> > initiator_socket; Thank you for your support. Regards, S.
  14. svinco
    I need to create a TLM module (that here we will call top_level) containing an array of TLM target modules (defined by class reg). As a consequence, the top_level module should implement the tlm_bw interface, and contain an array of initiator sockets, each bound to a target socket of the reg modules. Is it possible to implement this hierarchy by using the sc_vector construct? Here is a snapshot of the code that I am trying to implement, to give a clearer idea: Top level #include "reg.h" class top_level : public sc_module , public virtual tlm::tlm_bw_transport_if<> { priv
×
×
  • Create New...