Issue while calling sc_main multiple times from main

[Nitin_S]

Hi all,

I was trying something different and came across a issue which looks odd to me.

I have a main function and from there I am calling sc_main().

In sc_main,  I am starting and ending simulation  < sc_start, sc_stop >.

something like 

Example :

int main(){

		sc_main() //gives the expected output

 		sc_main() // creashes Error: insert module failed: elaboration done

return 0

}

 

I am expecting that my simulation should run 2 times.

But, I am facing " ERROR- insert module failed: elaboration done " while calling 2nd sc_main.

---Its seems like the old simulation is itself not getting cleared----

As after doing sc_stop the simulation should stops and clears all memories, then I believe it should have worked.

--Can any help me to make this done, if possible--

Any hint will be very helpful for me.

Thanks in advance :). 

 

Best Regards,

Nitin

[Eyck]

You cannot call sc_main directly from main(). main() comes with the SystemC reference implementation (SystemC simulator) and initailizes the simulation kernel. You miss that in your main function, you migh tlook it up at https://github.com/accellera-official/systemc/blob/master/src/sysc/kernel/sc_main.cpp and https://github.com/accellera-official/systemc/blob/master/src/sysc/kernel/sc_main_main.cpp

Despite that, you cannot call your sc_main twice. The simulation kernel in the reference implementation is not re-entrant. Thus the LRM states in section 4.3.4.2 Function sc_start:

Quote

Once the function sc_stop has been called, function sc_start shall not be called again.

in the sequence you described you would call sc_start() after sc_stop() has been called

[David Black]

@Eyck is correct. It would be a major rewrite of SystemC to allow this. If you are trying to launch multiple simulations (sequentially) perhaps with different parameters, you need to do that from a script. If you are super insistent you have to do it under C++, you could try the following:

// Compile your main SystemC as run.exe and place it in the same directory as this program

int main(void)
{
  int errors = 0;
  errors |= system("./run.exe -option 1");
  errors |= system("./run.exe -option 2");
  return errors;
}

Or just use your favorite script language (bash, perl, zsh, csh, python) to do the equivalent. You can store results in files and read configuration data from files. It's just C++.

If you want to rewrite the main.cpp from the library, feel free to do so, but you still won't be able to reset SystemC's internal data structures without invoke a completely new process.

[Nitin_S]

Thanks @Eyck and @David Black for the answer.

I understood it's not possible.

As Eyck told, "main() comes with the SystemC reference implementation (SystemC simulator) and initializes the simulation kernel."

Just out of curiosity why we can't do it again.

Even if we did sc_stop which will stop the simulation, and clears the memory, why init is not possible after that?.

If you think this is irrelevant question,  you can ignore , just for my understanding and learning the concepts I asked this.

You can direct me to the section of LRM I can read.

 

Best Regards,

Nitin

 

[maehne]

The primary reason is that the SystemC Proof-of-Concept (PoC) implementation uses some global data structures, which get constructed during elaboration, which are not fully cleaned up when sc_stop() is called. These data structures are only freed by the OS when the application quits. There have been some efforts improve the PoC implementation in this area, but these are currently stalled. Unfortunately, partially due to bad code examples, bad habits, and laziness, many SystemC models also not cleanly deallocate their dynamically allocated resources, as they still use manual resource allocation using the new operator, but never release that memory using delete as they don't implement a destructor out of laziness. Since the general availability of smart pointers in C++'11, especially std::unique_ptr<T>,  managing cleanly dynamic memory management has become much more convenient and there is no justification anymore to write such dirty code. However, there is a lot of legacy code out there making a bad example and hardware engineers often lack a formal education in C++ instead learning the language basically on the job. This will only resolve slowly over time. 

@David Black's suggestion to launch your multiple simulations from a separate process implemented using your favourite scripting language or even in C++, is the easiest workaround for the above problems.

[Eyck]

Just to add 2 cents to @David Black proposal: If the instantiation is exepensive you could fork() (https://en.wikipedia.org/wiki/Fork_(system_call)) your programm after instantiating the design. Basically you create a new OS process as copy of the current one and here you can continue the simulation. But in essence it is the same approach as David described.

[Nitin_S]

Thanks @Eyck @maehne and @David Black for your replies.
All yours solutions and advices really help for my understanding.

Thanks again 🙂

 

Best Regards,

Nitin_S

Edited August 4, 2020 by Nitin_S
Change name