Wrapping an RTL model in a TLM LT Model

[Anmol Sahoo]

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! 

[Eyck]

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.

Best

[Roman Popov]

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.

[Anmol Sahoo]

@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!

[Kirill]

On 11/22/2018 at 11:51 PM, Roman Popov said:

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.

Could you please clarify on how one can disable the clock? I have a Verilated RTL wrapped in a TLM AT. Please correct me if I am wrong, but I can't just put a clock gating in front of my RTL, because the events will still be generated. And I can't find a relevant method in sc_clock class to just disable the clock. Maybe I need to use dynamic sensitivity, but it is not  desirable for me, due to the Verilated part (or I just don't know how it should be done).

 

Ideally I would like to Suspend clock generation based on the PEQ in my target. 

 

Thanks in advance!

[David Black]

One way to disable the clock is to completely replace it with a model that does nothing. I presented a concept called no_clock at NASCUG a few years back demonstrating an approach. You can find the code on github: https://github.com/dcblack/no_clock with a link to the presentation.

You could even replace the declaration of sc_clock directly with a conditional macro test:

#ifdef USE_NO_CLOCK
  #include "no_clock.h"
  no_clock myclock{ "myclock", 10.0, SC_NS };
#else
  sc_core::sc_clock myclock{ "myclock", 10.0, SC_NS };
#endif

 

 

[Kirill]

4 hours ago, David Black said:

One way to disable the clock is to completely replace it with a model that does nothing. I presented a concept called no_clock at NASCUG a few years back demonstrating an approach. You can find the code on github: https://github.com/dcblack/no_clock with a link to the presentation.

You could even replace the declaration of sc_clock directly with a conditional macro test:

#ifdef USE_NO_CLOCK
  #include "no_clock.h"
  no_clock myclock{ "myclock", 10.0, SC_NS };
#else
  sc_core::sc_clock myclock{ "myclock", 10.0, SC_NS };
#endif

 

 

Thank you David, but I am interested in "turning off" clock temporarily, such that I can skip through IDLE periods in my simulation.

[Roman Popov]

10 hours ago, Kirill said:

And I can't find a relevant method in sc_clock class to just disable the clock.

Not possible with sc_clock.  You will have to write your own clock generating class. This is what we've done in similar case.

[Eyck]

If you can identify the condition of switching off clocks and the process being sensitive (and consuming the simulation time) you can enabel/disable the thread or method using the sc_process_handle as described here:

BR

[Kirill]

Thank you everybody for your replies. I ended up implementing new Clock based on the default sc_clock (which I found here). I figured that it would be more efficient if I stack to the default implementation, rather than a SC_MODULE with a SC_THREAD in it (not sure about it yet).