About AT

[mm317]

I'm just new to TLM. I'd like to discuss some doubts I have. 

1 AT: My understanding of AT is , TLM seperates the commucation to phases . During commucation , callback functions can indicate sender and receiver which phases are they in. In principle, we can create as many phases as RTL has. But  it is not necesssay to be that accurate if my model is fucus on functionality.  Delay parameter is used to modelize the hardware delay.  One question is when should we use AT model. (1) if I want to modelize a protocol , i need accurate time modeling (instead of approximate model)(2) if i want to modelize a computing unit , i don't care the commucation phase at all. 

2 About delay parameter , we can set delay parameter to modelize hardware delay. If TLM model is developed before hardware, how do we know this value? I think it is a general question, in none TLM model, we use wait() to modelize it. If we are not aware of delay in advance, how the statistic from TLM is reliable? 

3 The typical use scenarios of TLM. It is for performance analysis or functionality verification?

Thanks.

 

[David Black]

Approximately-Timed (AT) models provide decent timing accuracy for modeling purposes. Common use cases include architectural analysis (cost vs performance). AT models are used to understand the effects of interconnect and bus protocols on overall performance.

Loosely-Timed (LT) models provide for simulation performance (i.e. fast), but often use techniques that sacrifice modeled timing accuracy. The intent is for use in software development on virtual platforms. Techniques used include Temporal De-coupling coupled a notion of a Quantum, and Direct Memory Interface. LT models usually try to minimize calls to wait() due to overhead of context switching. Fast models almost never use sc_clock (slows simulation).

Both modeling styles (AT & LT) should be register accurate and functionally correct. Both include timing, but obviously the degree of accuracy differs greatly.

Standards compliant models will provide both modeling styles in a single design; although; it is often the case that early modeling starts with one or the other and later adds the missing style. Generally, b_transport functions provide the LT coding style, and nb_transport_* methods provide the AT coding style.

Neither should be as accurate as RTL because that would require adding so much code overhead that you might as well write RTL and skip SystemC. Clock cycle accurate models are generally inappropriate. Cycle-Approximate or Cycle-Count Accurate modeling is a better description of AT models.

[As an employee of Doulos Ltd, I teach courses on SystemC modeling with TLM-2.0. You might find that taking an on-line class from us is beneficial. https://www.doulos.com]

[mm317]

Many thanks for your reply, David. I will have a look of your courses.

AT is used to model interconnect and bus protocols. I think these products would focus on their transmission delay ,speed , bandwitdh . These statistics are highly relevant with clock and time. Is it possible to assess interconnect and bus protocol with only approximate time? And if my product is bus protocol, is it practical to use socket to abstract communication ?

Could you please specify what metrics we can get from AT to do architectural analysis?

Br,

 

 

 

 

 

[David Black]

TLM (Transaction Level Modeling) is focused on communication (interconnection) of SystemC models. So your question is slightly irrelevant. From what you indicate, I would say that AT modeling style would accomplish what you are interested in. Sockets are an almost essential aspect of  TLM as they simplify modeling and can provide information about the transaction.

As to what metrics you can get, that is up to you. SystemC is not a prepacked set of subroutines, nor is it a narrowly focused on one type of analysis. SystemC is a methodology using C++ to model any variety of ideas using an event driven simulation core (provided). You provide the code to stimulate and assess the information. It is common to obtain things such as bus bandwidth and utilization, but there are no primitives provided to do this on its own.

Important: You need to be well versed in C++ to effectively use SystemC. Far too many folks approach SystemC thinking it will be a panacea and only requires C.

There are companies that provide commercial tools on top of SystemC to help with modeling. I will not comment on their utility, but obviously they have some value or they would not be around for long. There are also consulting companies that specialize in SystemC. Learn more on the main Accellera website (https://www.accellera.com). My employer (and thus myself) focuses on the training/educational aspect.

[tmp_sc]

Hi David,

regarding simulation speed:

On 7/18/2020 at 1:15 PM, David Black said:

Loosely-Timed (LT) models provide for simulation performance (i.e. fast), but often use techniques that sacrifice modeled timing accuracy. ... LT models usually try to minimize calls to wait() due to overhead of context switching.

Since SC_THREAD needs to use wait(), which techniques is possible to use in order to minimize context switch? Only temporal decoupling?

[David Black]

There are several techniques. Temporal decoupling is one. DMI is another, which allows a processor to access memory much faster. You must keep in mind the use cases these intend to solve. LT models are for the creation of VM's used by software developers to focus on firmware development, and as such sacrifice timing accuracy in favor of performance. Software developers want register and functional accuracy. Generally, programmers do not care about timing precision. If performance analysis is desired, then use of AT modeling is better suited.

A key trick to performance is avoiding the use a real clock (i.e., sc_clock). Clock's produce two context switches per cycle regardless of whether they are actually be used. The trick is to use strategic waits instead. For instance, a timer that is set to provide an interrupt in 10ms, with a conceptual 10ns clock, can simply schedule a notification 10ms into the future and save 1,999,999 context switches. By saving the start time of the timer, you can even allow code to interrogate the current time count by simple calculation (e.g., counter = original - ( current_time - start_time ) / 10ns ).

A very important question for any model must be kept in mind: What problem am I trying to solve and what features need to be preserved in order to get the answer?

[tmp_sc]

You are right, usecase is very important. But my question was focused only on simulation speed of some bigger design, w/o taking into account the precision (which we will definitely get with AT models).
If I am not wrong, we have 2 choices (1) AT models which can be implemented with SC_METHOD (which are faster than SC_THREAD) vs (2) LT models which need to be implemented with SC_THREADs?
Solution (2) will be faster, if we can minimize context switches. But what can we use in order to minimize it? Temporal decoupling, DMI and events in stead of toggling clock?