SystemC Transfer Level Model Sockets: Two Way Communication - c++

Question

In Doulos's SystemC Transfer Level Model documentation, it is written
The top-level module of the hierarchy instantiates one initiator and
one memory, and binds the initiator socket on the initiator to the
target socket on the target memory. The sockets encapsulate everything
you need for two-way communication between modules, including ports
and exports for both directions of communication. One initiator socket
is always bound to one target socket.
My understanding of this was that when you create an initiator and a target the initiator starts the communication by calling b_transport, thereby triggering the target, which can reply back. However, I have been writing some code and this does not seem to be the case. Let us look at an example.
I have a very basic implementation of an adder that can be talked to using transfer level modeling. This modules servers as the target.
adder.cc
#define SC_INCLUDE_DYNAMIC_PROCESS
#include "tlm_utils/simple_initiator_socket.h"
#include "tlm_utils/simple_target_socket.h"
#include <iostream>
using namespace sc_core;
using namespace std;
#include "adder.h"
adder::adder(sc_module_name name)
: sc_module(name), socket("socket2")
{
socket.register_b_transport(this, &adder::b_transport);
socket.register_transport_dbg(this, &adder::transport_dbg);
}
void adder::b_transport(tlm::tlm_generic_payload& trans, sc_time& delay)
{
tlm::tlm_command cmd = trans.get_command();
sc_dt::uint64 addr = trans.get_address();
uint32_t *ptr = (uint32_t*)trans.get_data_ptr();
unsigned int len = trans.get_data_length();
unsigned char *byt = trans.get_byte_enable_ptr();
unsigned int wid = trans.get_streaming_width();
addend1 = *ptr;
addend2 = *(++ptr);
add();
cout << "addend1: " << addend1 << endl;
cout << "addend2: " << addend2 << endl;
cout << "sum: " << sum << endl;
uint32_t *return_sum_loc = ptr;
for(int i = 0; i< 2; i++) {
return_sum_loc++;
}
memcpy(return_sum_loc, (char*) &sum, sizeof(uint32_t));
cout << "New sum for return: " << *(return_sum_loc) << endl;
}
unsigned int adder::transport_dbg(tlm::tlm_generic_payload& trans)
{
return 0;
}
void adder::add()
{
sum = addend1 + addend2;
}
Then I have a test_bench module that is going to serve as the initiator
test_bench.cc
#define SC_INCLUDE_DYNAMIC_PROCESS
#include "tlm_utils/simple_initiator_socket.h"
#include "tlm_utils/simple_target_socket.h"
using namespace sc_core;
using namespace std;
#include "test_bench.h"
#include <fstream>
#include <iostream>
test_bench::test_bench(sc_module_name name):
sc_module(name), socket("socket")
{
SC_THREAD(run_tests);
}
void test_bench::run_tests()
{
ifstream infile("./adder.golden.dat");
ofstream ofs;
ofs.open("./adder.dat");
uint32_t theoretical_sum = 0;
while(infile >> data[0] >> data[1] >> theoretical_sum)
{
tlm::tlm_generic_payload *trans = new tlm::tlm_generic_payload;
sc_time delay = sc_time(10, SC_NS);
cout << "Sending" << endl;
cout << "Data[0]: " << data[0] << endl;
cout << "Data[1]: " << data[1] << endl;
trans->set_data_ptr((unsigned char*)data);
socket->b_transport(*trans, delay);
cout << "data[2]" << data[2] << endl;
ofs << data[0] << "\t" << data[1] << "\t" << data[2] << "\n";
delete trans;
}
infile.close();
ofs.close();
printf ("Comparing against output data \n");
if (system("diff -w adder.dat adder.golden.dat"))
{
cout << "*******************************************" << endl;
cout << "FAIL: Output DOES NOT match the golden output" << endl;
cout << "*******************************************" << endl;
}
else
{
cout << "*******************************************" << endl;
cout << "PASS: The output matches the golden output!" << endl;
cout << "*******************************************" << endl;
}
}
Here is the parent module that instantiates and connects them.
main.cc
#include "systemc.h"
#include "tlm_utils/simple_initiator_socket.h"
#include "tlm_utils/simple_target_socket.h"
#include "tlm_utils/tlm_quantumkeeper.h"
using namespace sc_core;
using namespace sc_dt;
using namespace std;
#include "test_bench.h"
#include "adder.h"
SC_MODULE(Top)
{
test_bench *tb;
adder *ad;
sc_signal<bool> rst;
sc_signal<bool> tb_irq;
sc_signal<bool> ad_irq;
Top(sc_module_name name) :
rst("rst")
{
tb = new test_bench("test_bench");
ad = new adder("adder");
tb->socket.bind(ad->socket);
tb->irq(tb_irq);
ad->irq(ad_irq);
}
};
int sc_main(int argc, char *argv[])
{
Top *top = new Top("Top");
sc_start();
}
When I run the executable this is the output I get.
< 1 0 0
< 1 1 0
< 2 1 0
< 2 2 0
< 2 3 0
< 3 3 0
< 4 3 0
< 4 4 0
< 5 4 0
< 5 5 0
1 0 1
1 1 2
2 1 3
2 2 4
2 3 5
3 3 6
4 3 7
4 4 8
5 4 9
5 5 10
FAIL: Output DOES NOT match the golden output
So my original thought was that you were passing by value this payload into the b_transport function of an initiator that is bound to a target. The target will receive and decode this payload. This part is happening. I am able to parse the uint32_t s passed in by value to the data[]. What I eventually realized based on my 0 return values, that were written into the memory that was passed, is that this is not actually passed by value. For some reason it is created as a pointer type, then it is dereferenced when passed. This in essence destroys that target's ability to manipulate the memory that was passed to hand back a response to the initiator.
So this whole two-way communication thing Aynsley mentioned has me a little confused. By two-way does, he mean both modules need target and initiator sockets to enable two-way communication?

Answer 1

This is the signature of b_transport call:
void b_transport( tlm::tlm_generic_payload& trans, sc_time& delay )
Payload is passed by reference, so target can modify it. Initiator can read returned value from the same payload object.
So this whole two-way communication thing Aynsley mentioned has me a
little confused. By two-way does, he mean both modules need target and
initiator sockets to enable two-way communication?
Blocking transport protocol implemented by b_transport call is unidirectional. Initiator module is active, target module is passive. Transaction finishes in a single call. Target is allowed to call wait() inside b_transport implementation.
But TLM2.0 also supports non-blocking protocol that consists of two calls:
nb_transport_fw from initiator to target
nb_transport_bw from target to initiator
This bidirectional protocol allows more fine-grained modeling of bus timing. For example you can model of out-of-order transaction processing in AMBA AXI bus.
In practice however almost everyone uses b_transport. Most models I've seen don't even support non-blocking interface.