Iván Albarrán me ha hecho llegar su Trabajo Final de Carrera titulado “Análisis de arquitecturas SoCs mediante modelos SystemC”.
En este proyecto Iván crea un modelo de simulación genérico para un SoC (System on Chip) que permita realizar un análisis de prestaciones de distintas arquitecturas. Para esto usa, cómo no, TLM como se puede ver en la figura

- Diagrama de bloques del sistema (en TLM)
El trabajo que ha hecho me parece excelente, las explicaciones de cada uno de los conceptos detrás de TLM-2.0 están, a mi entender, muy bien explicados. Y los resultados en cuanto a tiempos de simulación respecto a la cantidad de Initiators y cantidad de transacciones muy ilustrativas de la potencia de TLM para simular sistemas grandes y complejos.
Si queréis leer la memoria del proyecto, la podéis descargar de
aquí (PDF).
En breve colgaremos el código completo para poder usarlo en ejemplos posteriores.
VN:F [1.9.14_1148]
Rating: 0.0/5 (0 votes cast)
Sorry, this entry is only available in Español.
VN:F [1.9.14_1148]
Rating: 0.0/5 (0 votes cast)
A good way to retrieve information of what is happening in our SystemC simulations is to generate a log file with the information that we need (module name, simulation time, what phase is going on, etc.).
The most elegant and easy way to do that is to create a special class for that task, that the other modules in the simulation can use to send their information and to be stores in disk. This can be achieved designing a singleton type class. This design pattern restricts the instantiation of a class to one single object. In our case, it will cause that all modules use the same object and log file.
Read more…
VN:F [1.9.14_1148]
Rating: 0.0/5 (0 votes cast)
Today I tell you how to create a project in eclipse for work with TLM-2 and SystemC, it’s very easy!
Read more…
VN:F [1.9.14_1148]
Rating: 4.0/5 (1 vote cast)
First of all, I should remember you what means loosely-timed: we use the blocking function b_transport and therefore we have two synchronization points per transaction, that corresponds to the beginning and the end of the transaction. These two points can be in the same simulation time or in different simulation time. In case we have the two synchronization points in the same simulation time, we are using untimed).
Read more…
VN:F [1.9.14_1148]
Rating: 0.0/5 (0 votes cast)
Let’s go with the Direct Memory Inteface (DMI) defined in TLM-2.0. DMI mechanism in roughly speaking is to pass over transactions, protocols and so on. In short, the Target sends a pointer to its memory region (o part of it) to the Initiator to allow him to that memory region directly, without using transaction. This way, we speed up the simulation, because everything is more easy. DMI is focsed on memory type devices connected to modules that are accessing very frequently to that memory devices, like CPUs or DMAs. But the mechanism is there, and we can use it in any of our modules.
Read more…
VN:F [1.9.14_1148]
Rating: 0.0/5 (0 votes cast)
This coding style works with 2 timing points in each transaction, one in the function call and the other in the return for the b_transport function (using the base protocol these points corresponds to the start of the petition and the start of the response). We can put these two points in the same time to mark that the transaction is not using time.
Read more…
VN:F [1.9.14_1148]
Rating: 5.0/5 (1 vote cast)
Let’s start with the first example…
Initiator
We shall start with the include’s
#include
using namespace sc_core;
#include "tlm.h"
#include "tlm_utils/simple_initiator_socket.h"
Firstly we include systemc and then tlm.h
Then we include the easiest socket for that example.
Now it’s time to declare the Initiator class
class Initiator: sc_module
{
public:
tlm_utils::simple_initiator_socket initiator_socket;
SC_HAS_PROCESS(Initiator);
Initiator(sc_module_name name_);
private:
void initiator_thread();
};
Read more…
VN:F [1.9.14_1148]
Rating: 0.0/5 (0 votes cast)
Interfaces
Cuando usamos el canal normal para comunicar un Initiator con un Target usamos los interfaces que se definen en TLM2.0. De hecho, un Initiator crea una transacción y la pasa como argumento al método del interface (ya sea bloqueante o no). Este método lo implementa el Target que recibe la transacción y hace con ella lo que deba (la ejecuta). Este camino se conoce como forward path. Una vez el Target ha ejecutado la transacción, debe retornar al Initiator, y puede hacerse de dos formas distintas: a través de llamadas a métodos desde el Target al Initiator (a este camino se le llama el backward path; o usando el retorno del método del interface (se conoce como return path).
VN:F [1.9.14_1148]
Rating: 0.0/5 (0 votes cast)
TLM-2 lists modeling 3 different modes (called Coding Styles in official documents): untimed, Loosely-timed and Approximately-timed. Each serves a specific purpose, and to model different types of systems. We must also take into account the cost of each simulation mode (untimed less expensive, Approximatelly-timed more expensive).
VN:F [1.9.14_1148]
Rating: 5.0/5 (1 vote cast)
Follow Me!