The tool is supposed to convert SC_THREADs to SC_METHODs, to increase the simulation performance of SystemC models.

The basic idea is extraordinary simple: Threads will be converted into co-routines by using duff's device. The tool will define wait() as a C++ macro that does the duff magic. That define will be placed right in front of the thread function and will be undefed afterwards. Additionally the tool will add duff init and duff end macros at the beginning and the end of the function.

The only further modification the tool does, is turning thread 'members' into class member variables, so they do not lose their values when the co routine is left. This implies that the used variables offer a default constructor, otherwise the construction of the SC_MODULE will fail. If they don't the tool will have to initialize them using an available constructor and set them to some dummy values.

To minimize the number of needed class members the tool will have to analyze the locality of variables, i.e. it has to find out if a variable's scope contains wait statements. If so it has to become a class member, if not it can stay local to the thread. A variable that can stay local to the thread even after conversion is called 'truly local'.

Afterwards the SC_THREAD macro of that function can be turned into an SC_METHOD macro.

There are some rules the SC_THREAD that is to be converted has to adhere to:

1. The thread may not use switch statements.

2. The thread may not use blocking function calls.

3. The thread may only use references to objects if they are truly local. (they could be converted into pointers otherwise, but that is quite a significant change of code and code semantics so it is not really want we wanna do...)

This is very restrictive, but an important use case is to write GreenBus user APIs by using threads that only use the nb_write/notify functions. This is much simpler than writing the APIs with SC_METHODS only, but of course the APIs are much slower than they could be. This disadvantage is then removed by applying the thread converter to the API.

So you end up with the ease of use of SC_THREADs but with the speed of SC_METHODs.

Check tasks assigned to the SCThread Converter project (see support) to find out what's the status of the development