Jump to content

Recommended Posts

Hi,

I am seeing a similar issue as mentioned in the thread below with the tlm package shipped with SystemC-2.3.2 and SystemC-2.3.1.

https://workspace.accellera.org/Discussion_Forums/helpforum/archive/msg/msg?list_name=help_forum&monthdir=200802&msg=msg00013.html

Are the suggestions made by Alan the only options to work around this issue ? Would this be fixed in the official tlm release ?

Thanks in advance for the help/suggestions.

 

Share this post


Link to post
Share on other sites

Thanks for providing this feedback on the SystemC PoC implementation! It would help if you could share some more details about the exact error messages as well as a minimal self-contained example exposing the problem you are observing. Then, we may discuss the issue more seriously.

Share this post


Link to post
Share on other sites

Hi,

Thanks for the response. In lined is the test case that fails to compile.

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

class slave : public sc_module {
public:
        sc_port<tlm::tlm_fifo_get_if<int> > target_port;

        SC_HAS_PROCESS(slave);
        slave(sc_module_name nm) :
        sc_module(nm) {
                SC_THREAD(run);
        }
        void run() {
                for(int a = 0 ; a < 20 ; a++)
                {
                        int b;
                        target_port->nb_peek(b);
                        std::cout << b << " ";
                }
        }
};

Errors:

test.cpp: In member function 'void slave::run()':
test.cpp:17:17: error: request for member 'nb_peek' is ambiguous
    target_port->nb_peek(b);
                 ^
In file included from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/tlm_fifo.h:39:0,
                 from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_analysis/tlm_analysis_fifo.h:23,
                 from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_analysis/tlm_analysis.h:29,
                 from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm:26,
                 from test.cpp:1:
systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_fifo_ifs.h:54:16: note: candidates are: bool tlm::tlm_fifo_debug_if<T>::nb_peek(T&, int) const [with T = int]
   virtual bool nb_peek( T & , int n ) const = 0;
                ^
In file included from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_fifo_ifs.h:28:0,
                 from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/tlm_fifo.h:39,
                 from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_analysis/tlm_analysis_fifo.h:23,
                 from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_analysis/tlm_analysis.h:29,
                 from systemc/install/systemc-2.3.2/linux_x86_64/include/tlm:26,
                 from test.cpp:1:
systemc/install/systemc-2.3.2/linux_x86_64/include/tlm_core/tlm_1/tlm_req_rsp/tlm_1_interfaces/tlm_core_ifs.h:116:16: note:                 bool tlm::tlm_nonblocking_peek_if<T>::nb_peek(T&) const [with T = int]
   virtual bool nb_peek( T &t ) const = 0;
 

Share this post


Link to post
Share on other sites
1 hour ago, vasu_c said:

Thank you so much Roman and Philipp. Appreciate the work around suggested.

Please can I know which release would contain this fix ?

2.3.3 will be released next week w/o a fix. So most likely next one after 2.3.3

Share this post


Link to post
Share on other sites

Hate to bump an old, resolved thread, but I'm running into a linker issue using this work-around (systemc-2.3.1)

The simple version is that I'm getting an error message of an "undefined reference to "tlm::tlm_nonblocking_peek_if<CustomType *>::nb_peek(CustomType *&) const" when using the implementation as suggested by Philipp for the port interface and Roman in the call.

Any thoughts as to what might be causing this?  I have included tlm.h, is that sufficient?  Is there another library that needs linked in?

 

Share this post


Link to post
Share on other sites
On 1/30/2019 at 10:24 AM, tjd said:

Hate to bump an old, resolved thread, but I'm running into a linker issue using this work-around (systemc-2.3.1)

The simple version is that I'm getting an error message of an "undefined reference to "tlm::tlm_nonblocking_peek_if<CustomType *>::nb_peek(CustomType *&) const" when using the implementation as suggested by Philipp for the port interface and Roman in the call.

Any thoughts as to what might be causing this?  I have included tlm.h, is that sufficient?  Is there another library that needs linked in?

 

This is strange, tlm_nonblocking_peek_if is an abstract class, so compiler should not allow you to construct it. 

Can you give small complete example reproducing the problem?

Share this post


Link to post
Share on other sites

Just generated one.  There is a tarball attached that contains a producer, consumer, and a main that connects the two.  Also included is a simple bash script with my compilation commands and the log generated from running the script where I've also appended the G++ version to it.

 

tlm_ex.tar

Share this post


Link to post
Share on other sites
1 hour ago, tjd said:

Just generated one.  There is a tarball attached that contains a producer, consumer, and a main that connects the two.  Also included is a simple bash script with my compilation commands and the log generated from running the script where I've also appended the G++ version to it.

 

tlm_ex.tar

Oh nice, seems my workaround was wrong. I did not know that qualified name lookup suppresses dynamic dispatch of virtual functions.

https://en.cppreference.com/w/cpp/language/virtual

Quote

Virtual functions are member functions whose behavior can be overridden in derived classes. As opposed to non-virtual functions, the overridden behavior is preserved even if there is no compile-time information about the actual type of the class. If a derived class is handled using pointer or reference to the base class, a call to an overridden virtual function would invoke the behavior defined in the derived class. This behavior is suppressed if the function is selected using qualified name lookup (that is, if the function's name appears to the right of the scope resolution operator ::).

C++ is full of such traps 🙂

Share this post


Link to post
Share on other sites

Always fun for the lesser experienced C++ types (e.g., myself).

Putting notes here in case anyone else runs into this: When declaring the port as a

tlm_get_peek_if

no workaround is necessary, thus, you can directly do

target_port->nb_peek(x)

.

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×