View email archives for the history of this mailing list.
systemc-forum - Re: [systemc-forum] SystemC sc_simcontext destroy.
- To: "A, Nizamudheen" <niz@xxxxxx>
- From: "Philipp A. Hartmann" <philipp.hartmann@xxxxxxxx>
- Date: Thu, 04 Nov 2010 20:37:30 +0100
- Cc: "systemc-forum@xxxxxxxxxxxxxxxxx" <systemc-forum@xxxxxxxxxxxxxxxxx>
- Send Email to email@example.com:
- Send new message
- Reply to this message
find some comments below.
On 03/11/10 13:10, A, Nizamudheen wrote:
> Yes. I understand that the memory will be released upon killing the
> process (that instantiated the systemc-kernel). I am in a little strange
> situation....My application life is longer than the simulation life.
> Hence, even after quiting the simulation, the memory is not release
> and any subsequent invocation of the simulation makes it worse.
You can use dynamic processes. When they have terminated (e.g. when
your simulation run is finished), the (OSCI) kernel frees them up in
case that no process handle to the process is still around.
> I have to ask my customers to quit the application in case where he/she
> needs to re-run the simulation.
But how can you 're-run' the simulation? The OSCI kernel does not
support a second elaboration phase. So you already need to keep your
structural components (modules, ports, channels, ...) around. Why can't
you re-use the processes, too?
> I looked at the SystemC-kernel code and realized that each thread is
> created with a 64KB stack size.
You can reduce this, if this helps. See
> And this stack is never deleted (as there are no means to inform
> the SystemC that I am done with simulation -- sc_stop wont
> help either).
Not if you're using static processes, yes. But you can
- reset your internal state and reuse the process instances
- or use dynamic processes
> And, I have 637 threads in my simulation.
You might want to consider to use more method processes instead, if
feasible. This would both reduce the memory footprint and most likely
improve the simulation performance.
> I understand that the SystemC-kernel implementation has no easy
> means to clean-up the allocated-memory. But, is there a need
> to introduce a API in the LRM to be used by any other vendor
Personally, I don't see the memory allocation as a major problem, due to
the alternatives I outlined above. What I would really like to see is
an implementation of a full simulator reset (including elaboration)
within a single run of the application.
Greetings from Oldenburg,
> -----Original Message-----
> From: Philipp A. Hartmann [mailto:philipp.hartmann@xxxxxxxx]
> Sent: Friday, October 29, 2010 2:21 PM
> To: A, Nizamudheen
> Cc: systemc-forum@xxxxxxxxxxxxxxxxx
> Subject: Re: [systemc-forum] SystemC sc_simcontext destroy.
> On 29/10/10 08:29, A, Nizamudheen wrote:
>> The OSCI Reference Implementation uses sc_simcontext (that is
>> deprecated in the LRM, I believe). The sc_simcontext is the container
> You're right, the simcontext class is implementation-dependent and not
> part of the standard.
>> for the entire SystemC engine data-structures. The SystemC kernel comes
>> alive with the instantiation of this class. However, the LRM does not
>> define a means by which the kernel can be deleted. For instance, (in the
>> SystemC reference implementation) sc_default_global_context is a pointer
>> to sc_simcontext and allocated from heap at init-time. There is not code
>> in the reference implementation that deletes the same.
>> I think, there should be some means to destroy the kernel as well.
>> Can someone throw some light on this?
> Technically speaking, such a mechanism would be quite difficult or at
> least costly to implement. The main reason for this is, that all
> objects in SystemC's object hierarchy are associated with a (specific or
> global) simcontext.
> Destroying the simcontext would require a previous cleanup of all,
> potentially user-defined, objects in the hierarchy prior to that (which
> could live on the stack somewhere, so may not be destroyed via 'delete'
> from the context itself). Moreover, there are loads of code, that
> doesn't bother deleting their objects at all. So at least some kind of
> reference counting would be needed.
> Apart from the possibility to re-initialize the simulation and run an
> elaboration phase again, I don't see the need to destroy the simcontext
> explicitly from within a model. The operating system reclaims all
> resources after the program has ended anyhow.
> If you are interested in refactoring the reference simulator to
> support the deletion (and re-initialization) of the simcontext, I'm
> quite sure that OSCI would be interested in an implementation. :-)
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
Description: OpenPGP digital signature