Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/27/2012 in all areas

  1. If you look at the error message more closely, the problem is not caused by the existence of your "main" function, but by the missing sc_main function. The main reason for this is the preferred use of the dynamic library since SystemC 2.3.0. The dynamic libraries needs the sc_main symbol to be present, as you cannot decide during the (dynamic) linking step, if this function is actually called or not. Two solutions are possible link against the static library libsystemc.a (e.g. by moving libsystemc.so out of the way) add an (empty) sc_main Greetings from Oldenburg, Philipp
    1 point
  2. dakupoto

    Deleting dynamic objects

    From pure C++ point of view, it is just bad practice to use a 'new' and not have a matching 'delete'. A lot of people code with a 'set of pants' approach and are not very sure when exactly to invoke delete. So they just hope that the SystemC kernel take care of this messy issue, and with small examples it works out fine. But think about what would happen, if, as I had to recently, to tackle a design with 128 64-bit parallel-in serial-out shift registers. Then again, a lot of people use SystemC coming from a software background, and do not realize that in real hardware one cannot dynamically create components and then delete them. Hope that helps.
    1 point
  3. You are correct that SystemC does not automatically delete objects. The reason many coders ignore destructors for SystemC modules/objects is several fold: sc_object's (which includes sc_module's, sc_port's, sc_signal's, sc_prim_channel's, etc...) are created during elaboration and would not need to be destructed until the end of simulation when typically a SystemC program simply exits. Thus the operating system will mop up for you. For example: int sc_main(int argc, char* argv[]) { top_module top_instance("top_instance); //< Construct the design hierarchy aka elaborate sc_start(); //< run the simulation return 0; //< exit the simulator and allow OS to clean up } SystemC coders are somewhat lazy and given the above example rationalize it away This is how they were taught (sad but true) That stated, it is probably worth noting that this situation may not always be the case, and some SystemC coders do write destructors (e.g. myself). It should be noted that in a co-simulation environment, the assumption of exiting after simulation may not be true. A vendor simulator might even presume to restart a simulation. Thus I argue it is better to create destructors as good C++ programming habit. TIP: Use the C++11 std::unique_ptr<T> instead of raw pointers. Assumes you can use this class. For older versions of C++, you might consider std::auto_ptr<T>, which is deprecated as I understand it.
    1 point
×
×
  • Create New...