What is the benefits or need of exlicitly making an sc_spawn process to be called before the end of elaboration (making it static) simillar benefits of making a SC_METHOD or SC_THREAD invoked from the end of elaboration callback(i.e. to make it dynamic)

[saswat mund]

This is what given in the LRM so I am confused when we need to explicitly like what are the benefits of making unspawned process dynamic and spawned process static.

A  static process is a process created during the construction of the module hierarchy or from the 
before_end_of_elaboration callback.

A dynamic process is a process created from the end_of_elaboration callback or during simulation.

An unspawned process is a process created by invoking one of the three macros SC_METHOD, 
SC_THREAD, or SC_CTHREAD. An unspawned process is typically a static process, but it would be a 
dynamic process if invoked from the end_of_elaboration callback.

A spawned process is a process created by calling the function sc_spawn. A spawned process is typically a 
dynamic process, but it would be a static process if sc_spawn is called before the end of elaboration.

[David Black]

The following is an informal explanation of static vs dynamic in a SystemC simulation.

The lifetime of a SystemC simulation divides into two major phases: 1. Design elaboration, and 2. Active simulation.

Conceptually, design elaboration represents the fundamental time when the simulated hardware is assembled (manufactured). The assembly process may dynamically determine customizations using configuration files, command-line options, or even ask the user for input as it executes. During this phase, simulation time does not exist. There is a brief moment at the end of this process known as the "end of elaboration" phase, when code may be executed to examine the result of the manufactured product. For instance, you can dump a "netlist" detailing the design hierarchy. Some simulators will execute SystemC code until the end of elaboration and save a snapshot of its memory state. Static variables, static sensitivity lists, and static processes are established during this simulation phase. The SC_THREAD, SC_METHOD, and SC_CTHREAD macros are normally used to identify which methods will be used as static SystemC processes. Using sc_spawn to create static SystemC processes during this time is permissible. Typically, this all happens in the constructor; however, it may continue during the "before end of elaboration" phase. Effectively, everything created during design elaboration is static.

When active simulation starts, simulated time (i.e., sc_time_stamp is valid) comes to life, and everything from this point onward may be considered dynamic. Conceptually, we can think of this time as the initial power-on of the simulated system. A brief "start of simulation" phase allows the application of initial conditions (e.g., establishing the initial reporting verbosity or loading a flash memory component). During simulation, we can no longer create new components or wiring interconnections. If you think about physical silicon devices in the real world, they cannot grow or change after manufacture (ignoring the idea of silicon aging). We can simulate turning various components on or off dynamically. Spawning or suspending a process simulates the idea of applying or removing power. Spawning dynamic processes may also be used to attach logic analysis to our design (e.g., to provide temporal assertion functionality or other observations). Sc_spawn is used for dynamic process creation.

When the simulation finishes, we can briefly enter the "end of simulation" phase to gather up statistics and report the status of the overall run (e.g., "Were there any errors detected?", "How many packets were processed?", "What was the final simulated-time stamp?", etc.).

Note that the first call to sc_start from sc_main calls before_end_of_elaboration, and end_of_elaboration. In other words, elaboration is not complete until part way through the first sc_start. Also, start_of_simulation is invoked. Subsequent calls to sc_start merely resume execution and do not call any of those overrides (sometimes referred to as "callbacks"). Calling sc_stop is only valid from within active simulation. 

[saswat mund]

I am not asking about the difference but rather what are the scenarios or benefits one can get by explicitly declaring a unspawned process to be dynamic(to invoke in end of elaboration phase) and declaring spawned process as static(invoked in before end of elaboration phase).

Anyhow the insights were helpful but please give example on detailing the mentioned above query.

[David Black]

I use SC_THREAD/SC_METHOD to model processes of hardware therefore static.

I use sc_spawn several ways during simulation:

1. For TLM approximately-timed models, we use spawned processes indirectly (via the payload event queue) to schedule the execution of payloads at the proper time. This simplifies coding somewhat.
2. To verify protocols, you can launch processes to track the progress of signals and see if they are obeying the protocol requirements.
3. To implement delayed transport assignments a process can be launched to delay before doing the assignment. Below is an example of such a model.

#pragma once

#include <systemc>

template< typename T=bool >
struct Delay_module : sc_core::sc_module {
  // This module transfers input to output with a fixed delay.
  //    +---------------+
  // -->|inp  delay  out|>--
  //    +---------------+
  sc_core::sc_in<T> inp{ "inp" };
  sc_core::sc_export<sc_core::sc_signal_in_if<T>> out{ "out" };
  sc_core::sc_signal<T, sc_core::SC_MANY_WRITERS> delayed;//< public to allow tracing
  const sc_core::sc_time m_delay{ sc_core::SC_ZERO_TIME };

  Delay_module( const sc_core::sc_module_name& instance, const sc_core::sc_time& delay )
          : sc_module( instance ), m_delay{ delay }
  {
    SC_HAS_PROCESS( Delay_module );
    SC_METHOD( delay_method );
    sensitive << inp;
    out.bind( delayed );
  }

  void delay_method()
  {
    sc_core::sc_spawn( [ & ]() {
      auto value = inp->read();
      wait( m_delay );
      delayed.write( value );
    } );
  }
};