Jump to content
Liyuan

Inserting existing software into TLM frame

Recommended Posts

Hi 

I have a long story about using Systemc TLM.

I am having some trouble trying to embed our existing software (including driver) into the TLM frame.

Originally I called the application function in an SC_THREAD and wanted to let the driver function access tlm socket.

But our software and driver are shared libraries and can not see the upper layer socket which reside in a SC_MODULE. Besides I don't want to change the existing libraries and pass the variables or function pointers (like how sockets really do) down to the driver.

So I changed my mind and created another SC_THREAD to receive the tlm_generic_payload from the first one. I used a sc_fifo (dynamic sensitivity) for them to communicate. To achieve this I have to declare the fifo global in the driver. And I need to link the libsystemc.a in the shared library of driver (libsystemc.so requires the sc_main function).

After everything is cleared and compilation is passed, I get this error message at the end of running phase.

double free or corruption (fasttop): ...
======= Backtrace: =========
...
======= Memory map: ========
...
Aborted (core dumped)

It seems that as long as I access global variables or functions in the driver, this happens (I can still get the variable).

I drew a simple schematic diagram to illustrate my project.

111.png.486a6b575360611eeb42280a871d0465.png

My Question:

I used static systemc library in the driver and a shared systemc library in the upper application, could this be the problem?

How can I solve my problem?

I believe that developing TLM model with software is a general case, is there a pattern to do this in a systematic way without changing the software (only interface) too much?

Was I primarily wrong at the beginning?

 

Any interpretation or suggestion would be appreciated.

Liyuan

Share this post


Link to post
Share on other sites

Each shared library or executable has its own copy of static variables. So, if part of your application links SystemC dynamically, and other part links SystemC statically, the result is that you have 2 conflicting SystemC kernels in your application. 

So you have two options:

- Use shared SystemC library everywhere

- Use static linking everywhere

Share this post


Link to post
Share on other sites
On 1/20/2020 at 9:13 PM, Roman Popov said:

Each shared library or executable has its own copy of static variables. So, if part of your application links SystemC dynamically, and other part links SystemC statically, the result is that you have 2 conflicting SystemC kernels in your application. 

So you have two options:

- Use shared SystemC library everywhere

- Use static linking everywhere

thanks so much.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...