sc_thread hangs at wait( ) statement

[shiva_2019]

Hi all, 

I have a systemC-tlm code that uses SC_THREAD( ) to implement parallel modules. I am working on latency analysis and hence included a few wait statements in each of the SC_THREAD functions.

It was working fine for a long time, until yesterday. The SC_THREAD functions with wait(time, SC_NS)  hang exactly at the wait statement. I tried debugging into the wait function, and found that the code throws an SC_REPORT_ERROR in wait( ) function in sc_wait.cpp. I am not sure if that error is caught, because I do not see any error in my console output.

Does anyone have a clue on why I am seeing this behavior?    

[David Black]

We would need to see some code.

[shiva_2019]

I kind of work on proprietary code. But here is an example of what I have

//## test.h

#include "systemc.h"
#include "tlm.h"

class test: public sc_module{

private:
	// some variables
public:
	test();
	sc_port <int> output_port;
    tlm::tlm_fifo<int> input_fifo;
   
	void command_initiator();
}

      
//## test.cpp
#include "test.h"
     
void test:test(){
      
	// initialize the variables
      
    SC_THREAD(command_initiator);
}
      
void test:command_initiator(){
 	
      while(true){
      
      // receive command
      if(!input_fifo.nb_can_get) wait(input_fifo.ok_to_get());
      cmd = input_fifo.get();
      
      // do some processing on the command
      // put the command in the outputport 
      if (! output_port->nb_can_put() ) wait(output_port->ok_to_put);
      output_port->put(cmd);
      
      // this is where the code hangs
      wait(4, SC_NS)
      }
}      

The code hangs in command initiator function at the wait statement 

 

[David Black]

Let's move this to EDA playground... https://www.edaplayground.com/x/55Sj

Doesn't compile. You can COPY into your own playground and fix the compile issues. Then I can look at it if you provide me with the URI.

 

[Philipp A Hartmann]

Generally speaking, it would be a bug if the whole SystemC simulation is hanging inside a timed wait.  I suspect that you have in face a separate (set of) process(es) that are running indefinitely without advancing SystemC time (beyond these 4 ns).

You can try to find the culprit by setting a breakpoint in a debugger on the affected line above, continue the simulation for a bit and then break, checking in which SystemC process you end up.  Maybe you are missing a similar "wait" on the consumer side?

Hope that helps,
  Philipp