Jump to content
Anmol Sahoo

Wrapping an RTL model in a TLM LT Model

Recommended Posts

Hi everyone, 

Looking for some general directions or documents (if available), on the following problem - 

1. I have with me a cycle-accurate SystemC RTL. This represents one part of my SoC

2. I want to wrap this in a TLM 2.0 Loosely-Timed wrapper so that I can interface it with software

Thus I need some guidance, as to how I can implement that same, or if someone has done it before.

What have I tried, what do I know.

1. I am currently aware of the TLM 2.0 blocking and non-blocking interfaces. I understand that the blocking interface is implemented to create a LT model

2. In my understanding, the top level wrapper implementing a simple_target_socket could wrap my RTL C++ model. The blocking transport function should then take care of receiving the data, converting it to the input ports of the internal model, and then sending the response

3. One question I run into while following this model is of how to manage time. The RTL model will take a certain amount of time to execute and return the time taken. Should I make the initiator thread wait for that long? Or should I just update a side value? If I have multiple initiator targets, how will this be synchronised? 

Thanks for reading! Looking forward, if someone can help out! 

Share this post

Link to post
Share on other sites

Actually in the demo part of the tutorial 'Efficient use of Virtual Prototypes in Hardware/Software Development and Verification' (slides are here) there is exactly such a case show-cased. If you go to https://git.minres.com/DVCon2018/RISCV-VP/src/branch/develop/platform/src/rtl/spi_rtl.cpp you will find a class called rtl which instantiates a verialted RTL, a bus-functional model (BFM) of the TileLink protocol, and a few more converters adapting the RTL signals. The respcetive header can be found at https://git.minres.com/DVCon2018/RISCV-VP/src/branch/develop/platform/incl/sysc/rtl

The BFM implements non-blocking transport where the target socket mixin (which is similar to simple_target_socket) does the translation from blocking to non-blocking if needed. This is just since the TIleLink protocol has an explicit request and response channel (similar to AXI). In case of loosely timed model the blocking access with wait() will break your quantum thus syncronizing the time. Having several initiators with different annotated time will then change the order of accesses. You treat speed for accuracy...

I hope this gives you some idea. If you have further questions feel free to ask.


Share this post

Link to post
Share on other sites

The problem is, when you integrate RTL IP into Loosely-Timed  VP that way, the whole simulator will have a performance of cycle-accurate model. Because clock generator will be always on, and Verilated model will be triggered even if it is idle. So don't try to boot Linux with such a simulator.

If your RTL IP supports power gating or clock gating, it is a good idea to disable clock generation when RTL IP is turned off. In that case you don't pay for what you don't use: you can boot your OS quickly and then enable clock generator when you start to debug IP-specific driver code.

Share this post

Link to post
Share on other sites

@Eyck, Thank you for the documents. That looks like a good resource to start with. The points you mentioned seem good enough to model my use-case.


@Roman Popov, Thanks for the heads-up. I do not have any plans to boot Linux as of now, so I will just start and see how far I can go with it. I'll keep your suggestion in mind.


Thank you guys for the quick response! Hope to contribute back to the community, once I have some footing with SystemC and TLM!

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