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).
DMI
Existe un interface especial, llamado Direct Memory Interface que proporciona acceso directo a áreas de memoria dentro de un Target permitiendo acceder directamente, sin tener que pasar por todos los posibles componentes del sistema (bridges, árbitros, etc) usando un puntero a esa zona de memoria en lugar de acceder mediante llamadas a b_transport o nb_transport. Este interface especial esta pensado para acelerar las simulaciones donde se use masivamente accesos a memoria.
Debug Interface
Este intterface proporciona acceso inmediato y no intrusivo a un Target, de manera que cualquier lectura o escritura a través del Debug interface usará la misma estructura que el forward path, pero sin ningún tipo de delay o wait o notificación de evento, etc. Digamos que el resto del Target “no se entera” de que ha sido accedido.
Sockets
Para simplificar la interconexión entre módulos, TLM-2.0 nos ofrece sockets, que agrupa y “gestiona” tanto el forward como el backward path (y DMI y Debug Interface), habiendo sockets para Initiator (Initiator socket) y sockets para Target (Target socket). Desde TLM-2.0 se recomienda el uso de sockets en lugar de los interfaces por facilidad de uso y portabilidad.
TLM-2.0 define una serie de distintos sockets (convenience sockets) que implementen distintas características. Aquí va una tabla resumen:
| Socket | Registra Callbacks | Multiports | Conversión b/nb | Tagged | Binding |
|---|---|---|---|---|---|
| tlm_*_socket | No | Si | No | No | Si |
| simple_*_socket | Si | No | Si | No | No |
| simple_*_socket_tagged | Si | No | Si | Si | No |
| passthrough_target_socket | Si | No | No | No | No |
| passthrough_target_socket_tagged | Si | No | No | Si | No |
| multi_passthrough_*_socket | Si | Si | No | Si | Si |
Socket: Nombre de la clase y del socket
Registra Callbacks:Indica si el socket proporciona una función para registrar una función cualquiera como función transport.
Multiport: Si el socket permite conectar múltiples Initiators a un Target o al revés.
Conversión b/nb: el Target socket convierte las llamadas a b_transport a nb_transport (pasa una llamada bloqueante a no-bloqueante)
Tagged: Cada interface son etiquetados (tagged) para saber por qué socket han llegado
Binding: Si el socket permite conexión jerárquica, de manera que un Modulo puede tener “dentro” un Initiator y su socket conectado a éste.
En otra entrada del blog explicaremos cada uno de los sockets disponibles en el estandard.
Deja un comentario