MÉTODO Y SISTEMA PARA LA COMUNICACIÓN INDIRECTA DE LOS COMPONENTES DE UN SISTEMA ELECTRÓNICO.

Método y sistema para la comunicación indirecta de los componentes de un sistema electrónico. Campo de la invención La presente invención se encuadra en el sector técnico de los sistemas electrónicos, más concretamente en el campo del direccionamiento de los distintos componentes que forman parte de un Sistema en Chip en escenarios dinámicos. Antecedentes de la invención Actualmente, y gracias a los continuos avances y mejoras en los procesos de fabricación de circuitos electrónicos, cada vez se integra más funcionalidad en un solo sistema. Uno de los exponentes más ilustrativos de este crecimiento en la capacidad de integración de los circuitos son los denominados Sistemas-en-Chip (del inglés System-on-Chip), abreviadamente SoC. Un SoC incluye, además del procesador o controlador encargado de ejecutar las instrucciones de un programa, toda la electrónica auxiliar necesaria para una aplicación concreta. Por ejemplo, diversos periféricos como memorias, procesadores de señal o procesadores gráficos. Todo ello forma un sistema electrónico completo y listo para su explotación. La comunicación entre los distintos elementos que forman parte del sistema electrónico se realiza a través de un canal de comunicación que interconecta dichos componentes. La infraestructura de interconexión más sencilla, y por su simplicidad y facilidad de uso la más extendida, es la arquitectura basada en buses. Un bus es un conjunto de líneas eléctricas que son utilizadas para la transmisión y distribución de información dentro del circuito. Un bus (referencia numérica 1 de la figura 1) es un medio compartido al cual todos los componentes del sistema se conectan y son capaces de recibir y transmitir información a través de él. Sin embargo, los buses presentan serios inconvenientes cuando el número de componentes que se conectan a él es elevado, hecho que no es inusual debido a la creciente complejidad de los sistemas. Con el objeto de dar una solución al problema de la escalabilidad en los sistemas basados en buses, se aportan modificaciones en la arquitectura de comunicación como son las estructuras de buses jerárquicas (figura 2). La comunicación entre dispositivos conectados a diferentes segmentos es posible mediante la utilización de pasarelas (referencias numéricas 1 y 2, de la figura 2) o puentes que redirigen las transacciones de un dominio de comunicación a otro cuando el valor de la dirección corresponde al rango de direcciones del bus para el que hacen de puente (referencias numéricas 3, 4 y 5 de la figura 2). Otra aproximación para solucionar el problema de escalabilidad que presentan los buses como infraestructura de interconexión, es la utilización de micro redes de conmutación de paquetes dentro del chip (más comúnmente denominadas NoCs, del inglés Network-on-Chip) para la gestión de las comunicaciones entre un elevado número de componentes (figura 3). Estas redes, a diferente escala, se basan en los conceptos y mecanismos utilizados de las redes de computadores clásicas. En cualquiera de las infraestructuras de comunicación para SoCs enumeradas anteriormente, es necesaria la identificación o direccionamiento de los componentes que participan en el proceso de comunicación. Así, los componentes que tienen la capacidad de iniciar una transacción sobre el canal de comunicación (también denominados maestros) (referencia numérica 2 de la figura 1) proporcionan el valor de la dirección (referencia numérica 3 de la figura 1) que identifica el componente que implementa la funcionalidad requerida (también denominados esclavos) (referencia numérica 4 de la figura 1). Los esclavos disponen de una interfaz electrónica al canal de comunicaciones (referencia numérica 5 de la figura 1) que descodifica la dirección presente en él y determina si debe o no atender a la petición (referencia numérica 6 de la figura 1). Los esclavos pueden atender peticiones dirigidas a una dirección o un conjunto de direcciones, lo que se denomina rango de direcciones o espacio de direcciones del periférico. Muchos de los mecanismos de direccionamiento utilizados (Véanse las referencias [1] y [2] de la lista de referencias) tanto en buses, como jerarquías de buses y NoCs se caracterizan por un fuerte acoplamiento o dependencia de algunos parámetros relacionados con la naturaleza de la infraestructura de interconexión subyacente. Por ejemplo: En un bus simple, cada dispositivo tiene una dirección física que es única y suele ser establecida en tiempo de diseño (referencia numérica 7 de la figura 1). En los buses jerárquicos, la dirección o rango de direcciones de un periférico debe ser un subconjunto del rango de direcciones del segmento al cuál esté conectado (referencia numéricas 6 y 7 de la figura 2). En las NoCs, es muy habitual que la dirección física sea codificada en función de la ubicación relativa del componente dentro de la NoC (por ejemplo, especificando las coordenadas X e Y de un nodo en una malla bidimensional o de árbol) (referencia numérica 1 de la figura 3). 2 ES 2 353 792 A1 Así, en entornos dinámicos, donde la ubicación o estado de los componentes del sistema pueden variar en tiempo de ejecución, estos mecanismos se vuelven inapropiados. Algunos escenarios que ejemplifican este hecho son: Sistemas adaptativos en los cuales, por criterios de calidad de servicio y productividad, determinada funcionalidad deba ser migrada. La migración puede realizarse trasladando determinados componentes de un segmento a otro en una jerarquía de buses o de un nodo a otro, en el caso de una NoC. La traslación puede realizarse físicamente con el apoyo de lógica reconfigurable o bien de manera lógica invalidando cualquier referencia a la ubicación física original que esté en posesión de los componentes que se comuniquen con ellos. Otro tipo de migración contemplada en este caso es aquella en la cual la funcionalidad del componente afectado es asumida por una rutina software ejecutándose en un procesador del sistema. Sistemas en los que se utilice lógica reconfigurable, permitiendo la creación y destrucción de hardware en tiempo de ejecución. En este caso, la referencia o dirección a un componente puede: (a) no ser válida en un instante determinado por no encontrarse activo o (b) cambiar su valor una vez que dicho componente vuelva a ser instanciado en la lógica reconfigurable tras un desalojo. Sistemas en los que se utilicen buses dinámicos en los cuales los componentes pueden ser añadidos y eliminados del bus en tiempo de ejecución. Sistemas para alta disponibilidad, tolerante a fallos, en los cuales aquellos componentes que son críticos para el sistema se encuentran replicados. En caso de fallo (referencia numérica 1 de la figura 4.a) en uno de ellos, el resto de componentes que hacen uso de él deben inmediatamente actualizar su dirección o referencia física (referencia numérica 2 de la figura 4.b) y seleccionar otro componente equivalente del grupo de replicación (conjunto de componentes que implementan la misma funcionalidad) (referencia numérica 3 de la figura 4.b). En la actualidad, las soluciones existentes para la gestión en tiempo de ejecución de cambios en el espacio de direcciones asignado a un componente o periférico se basan en la utilización de rutinas software. La principal razón que explica este hecho es que el modelo actual de utilización de los componentes o periféricos es asimétrico, es decir, los periféricos esclavos son componentes pasivos que ejecutan determinada funcionalidad siempre a petición de un maestro. En la mayoría de los casos dicho maestro es un procesador o microcontrolador que ejecuta la rutina software que se comunica con el dispositivo (también denominada controladora de dispositivo). En cuanto al método utilizado para determinar en tiempo de ejecución la dirección física de los dispositivos, suele basarse en un mecanismo de consulta sobre todos los elementos del sistema hasta encontrar el adecuado. Este método es claramente ineficiente ya que inunda el canal de comunicación con peticiones innecesarias que consumen una importante fracción del ancho de banda del canal lo que puede repercutir en el rendimiento del sistema. Descripción de la invención La presente invención se centra en la resolución de la problemática asociada con la dependencia física de los modos de direccionamiento existentes mediante una infraestructura hardware. A diferencia de otras implementaciones que utilizan un software para (re)configurar las direcciones físicas mediante escrituras en los dispositivos afectados, se proporciona a los dispositivos la lógica necesaria para obtener en tiempo de ejecución la dirección física del dispositivo con el que quiere comunicarse. Otros trabajos (véase la referencia [3] en la lista de referencias) describen mecanismos genéricos parecidos al descrito en esta patente...

1. Método de comunicación entre dos componentes hardware de un circuito integrado interconectados a través de un canal de comunicación, siendo uno de ellos el que inicia el proceso de comunicación, dispositivo cliente o maestro, y otro el que atiende su petición, dispositivo servidor o esclavo donde dichos componentes conectados al canal de comunicaciones poseen un identificador de dispositivo (ID) único en el sistema y un identificador de clase de dispositivo (ICD) que puede no ser único y donde el dispositivo cliente o maestro se conecta al canal de comunicación mediante un adaptador de acceso indirecto al canal (AAIC, el método está caracterizado porque para la obtención de la dirección base de acceso físico (DBF) del dispositivo servidor o esclavo en tiempo de ejecución se ejecutan los siguientes pasos: a. El dispositivo cliente o maestro, solicita una operación de escritura/lectura, proporcionando para ello el dispositivo cliente al AAIC el ID o ICD del dispositivo servidor o esclavo el tipo de operación y los datos, si se trata de una escritura; b. El AAIC determina la existencia y validez de una DBF de acceso al dispositivo servidor con el ID o ICD requerido; c. Si el AAIC posee una referencia válida, inicia la operación sobre el canal de comunicaciones utilizando el valor de la DBF que almacenaba para el direccionamiento del esclavo; d. En caso de no poseer una referencia o ser ésta inválida, el AAIC solicita una nueva DBF de acceso al dispositivo servidor a un módulo repositorio de referencias (MRR), el MRR comprende una tabla de referencias remotas (TRR) que comprende el ID, el ICD y la DBF de los componentes; e. Si la consulta al MRR no ha devuelto error, el AAIC realiza la petición de lectura/escritura sobre el dispositivo servidor, utilizando la DBF proporcionada por el modulo repositorio de referencias MRR. 2. Método de comunicación según la reivindicación 1, en el que en caso de que la consulta al MRR devuelva un código de error que identifica que no se ha encontrado ninguna entrada en la TRR que cumpla los criterios de búsqueda, el AAIC notifica al dispositivo cliente que no se ha podido establecer la comunicación con el dispositivo servidor. 3. Método de comunicación, según la reivindicación 1 caracterizado porque para la gestión de fallos de un sistema electrónico en tiempo de ejecución, el AAIC, al detectar que se ha producido un fallo en la comunicación con el dispositivo esclavo, invalida la entrada correspondiente en la TRR y posteriormente solicita al MRR una nueva DBF. 4. Método de comunicación, según la reivindicación 1 caracterizado porque para cambiar la funcionalidad de un sistema electrónico en tiempo de ejecución, no utiliza lógica dinámicamente reconfigurable y porque los componentes del sistema se auto organizan en base a la información contenida en la TRR. 5. Método de comunicación según la reivindicación 4, caracterizado porque un programa software es el encargado de actualizar la información de la TRR que determina una nueva configuración. 6. Método de comunicación según la reivindicación 4 caracterizado porque un componente hardware es el encargado de actualizar la información de la TRR que determina una nueva configuración. 7. Método de comunicación según la reivindicación 4, caracterizado porque el MRR posee diferentes perfiles de organización, y él se encarga de actualizar la información de la TRR según dichos perfiles. 8. Método de comunicación, según reivindicación 1, en el que la implementación del MRR es hardware. 9. Método de comunicación, según reivindicación 1, en el que el canal de comunicación es un bus. 10. Método de comunicación, según reivindicación 1, en el que el canal de comunicación es un bus jerárquico. 11. Método de comunicación, según reivindicación 1, en el que el canal de comunicación es una red en chip. 12. Sistema de comunicación entre componentes hardware de un circuito integrado conectados a un canal de comunicaciones, donde los componentes hardware poseen un identificador de dispositivo (ID) único en el sistema y un identificador de clase de dispositivo (ICD) que puede no ser único, caracterizado porque dicho sistema comprende: Un dispositivo cliente o maestro, que es el componente hardware que inicia el proceso de comunicación. Un dispositivo servidor o esclavo que es el otro componente hardware que atiende su petición de comunicación. 9 ES 2 353 792 A1 Un módulo repositorio de referencias (MRR) que comprende una tabla de referencias remotas (TRR) que incluye el ID, el ICD y la dirección de base física (DBF) de los componentes. Un adaptador de acceso indirecto AAIC mediante el que se conecta al canal de comunicación el dispositivo cliente o maestro, donde: El dispositivo cliente o maestro incluye medios para, cuando quiere solicitar una operación de escritura/lectura, le proporciona para ello al AAIC el ID o ICD del dispositivo servidor o esclavo el tipo de operación y los datos, si se trata de una escritura; El AAIC incluye medios para: recibir dicha información del dispositivo cliente, 2) determinar la existencia y validez de una dirección de base física DBF de acceso al dispositivo servidor con el ID o ICD requerido; si el AAIC posee una referencia válida, iniciar la operación sobre el canal de comunicaciones utilizando el valor de la DBF que almacenaba para el direccionamiento del esclavo; en caso de no poseer una referencia o ser ésta inválida, solicitar una nueva DBF de acceso al dispositivo servidor al módulo repositorio de referencias MRR; si la consulta al MRR no ha devuelto error, el AAIC realiza la petición de lectura/escritura sobre el dispositivo servidor, utilizando la DBF proporcionada por el modulo repositorio de referencias MRR; El MRR incluye medios para: Recibir una petición de solicitud de una DBF del dispositivo servidor desde el AAIC y para Devolver la DBF solicitada al AAIC. 13. Sistema de comunicación según la reivindicación 12 donde el módulo adaptador de acceso indirecto al canal (AAIC) para la conexión de dispositivos clientes o maestros a un canal de comunicación, está caracterizado por estar implementado en hardware y porque incluye medios para: a. Recibir del dispositivo cliente o maestro una solicitud de una operación de escritura/lectura, proporcionando para ello el dispositivo cliente al AAIC el identificador de dispositivo (ID) o el identificador de clase de dispositivo (ICD) del dispositivo servidor o esclavo, el tipo de operación y los datos, si se trata de una escritura; b. Determinar la existencia y validez de una DBF de acceso al dispositivo servidor con el ID o ICD requerido; c. Si el AAIC posee una referencia válida, iniciar la operación sobre el canal de comunicaciones utilizando el valor de la DBF que almacenaba para el direccionamiento del esclavo; d. En caso de no poseer una referencia o ser ésta inválida, solicitar una nueva DBF de acceso al dispositivo servidor a un módulo repositorio de referencias (MRR) y porque e. Una vez obtenida una DBF de acceso al dispositivo servidor o determinada la validez de una DBF previa, almacenada localmente, traducir las peticiones de escritura o lectura del dispositivo cliente a la secuencia de activación de señales según el protocolo de comunicación del canal de comunicaciones al que está conectado. f. En caso de un error en la obtención de la nueva DBF de acceso al dispositivo servidor, notificar la condición de fallo al dispositivo cliente. 14. Sistema según reivindicación 12, caracterizado porque el módulo AAIC implementa una interfaz local de comunicación punto a punto entre el dispositivo cliente o maestro y el AAIC, que se caracteriza por: una señal para indicar el inicio de operación (request), una señal de tipo de operación (read/write), un bus para la comunicación de datos entre el AAIC y el dispositivo maestro, una señal para indicar el dispositivo esclavo sobre el que se realiza la petición y una señal de error para indicar al maestro una condición de fallo. 15. Sistema según reivindicación 14, caracterizado porque la señal para indicar el dispositivo esclavo codifica el ID del dispositivo. 16. Sistema según reivindicación 14, caracterizado porque la señal para indicar el dispositivo esclavo codifica el ICD del dispositivo. 17. Sistema según reivindicación 14, caracterizado porque la señal para indicar el dispositivo esclavo codifica el ID o el ICD del dispositivo, según se indique en una señal adicional denominada clase/dispositivo que sirve para indicar el tipo de comunicación a realizar - con un dispositivo concreto o con cualquier dispositivo que implemente la funcionalidad de una clase de dispositivos. 18. Sistema según la reivindicación 12, caracterizado porque el módulo repositorio de referencias (MRR) comprende una tabla de referencias remota (TRR) sobre la que se pueden realizar operaciones de consulta y administración tanto por un programa software como por un dispositivo hardware, donde dicha tabla de referencias remota mantiene para cada dispositivo una entrada con su identificador, ID, su identificador de clase, ICD y su dirección base de acceso físico, (DBF). ES 2 353 792 A1 19. Sistema según la reivindicación 18, caracterizado porque la TRR mantiene por cada dispositivo datos estadísticos de acceso. 20. Sistema según la reivindicación 19, caracterizado porque por la TRR mantiene la siguiente información estadística de acceso a la tabla: a. Una marca de tiempo (MT) que indica la última vez que se proporcionó la DBF asociada a la entrada correspondiente. b. Un contador de accesos (CA) que mantiene el número total de veces que se ha proporcionado la DBF asociada a la entrada correspondiente. 21. Sistema según la reivindicación 18, caracterizado porque el módulo MRR está adaptado para una operación de consulta (buscar-id) sobre la TRR en la que el módulo MRR proporciona la DBF de acceso al dispositivo con el ID proporcionado como entrada. 22. Sistema según la reivindicación 18, caracterizado porque el módulo MRR está adaptado para una operación de consulta sobre la TRR (buscar-clase) en la que el módulo MRR hace uso de los datos estadísticos almacenados en la TRR para seleccionar un dispositivo del conjunto de entradas de la tabla que poseen el mismo valor del campo ICD, requiriendo un ICD como entrada para la búsqueda. 23. Sistema según la reivindicación 22, caracterizado porque el módulo MRR proporciona la DBF del dispositivo con el mínimo valor del campo MT. 24. Sistema según la reivindicación 22, caracterizado porque el módulo MRR proporciona la DBF del dispositivo con el mínimo valor del campo CA. 25. Sistema según la reivindicación 21 o 22, caracterizado porque implementa las operaciones de consulta sobre el MRR, como lecturas del MRR utilizando las líneas de dirección del canal de comunicaciones para codificar los parámetros necesarios para cada tipo de consulta, en el que los parámetros preferiblemente son un prefijo de la dirección física para direccionar el dispositivo MRR, ID o ICD del dispositivo requerido y dos bits para codificar la operación de consulta. 26. Sistema según la reivindicación 18, caracterizado porque el módulo MRR está adaptado para añadir una nueva entrada (registro) en la TRR. 27. Sistema según la reivindicación 18, caracterizado porque el módulo MRR está adaptado para eliminar una entrada (borrar) en la TRR. 28. Sistema según la reivindicaciones 26 o 27, caracterizado porque el módulo MRR implementa la operación de añadir una nueva entrada o eliminar una entrada como escrituras en el canal de comunicaciones utilizando las líneas de dirección, que preferiblemente comprenden un prefijo de la dirección física para direccionar el dispositivo MRR, ID o ICD del dispositivo requerido y dos bits para codificar la operación de administración y datos del canal de comunicaciones, que preferiblemente son el ICD del dispositivo si es una operación de registro y la dirección base física de acceso al dispositivo, para codificar los parámetros necesarios. 29. Sistema según cualquiera de las la reivindicaciones 25-28, caracterizado porque el MRR implementa la lógica de interfaz esclava de acceso al canal de comunicaciones que interpreta las líneas de control, líneas de dirección y líneas de datos del canal de comunicaciones para la activación interna de las operaciones requeridas. 30. Sistema según la reivindicación 19, caracterizado porque la implementación de la TRR se realiza mediante dos memorias de acceso por contenido y una memoria RAM, donde las dos memorias de acceso por contenido almacenan los campos de la tabla ID y ICD y son utilizadas para indexar la memoria RAM que almacena las DBF y la información estadística. 31. Sistema según la reivindicación 23-25, caracterizado porque el módulo MRR proporciona calidad de servicio en las comunicaciones de un sistema electrónico al distribuir la carga de accesos entre los dispositivos servidores de acuerdo a la política de selección de referencia elegida. 32. Sistema según la reivindicación 19, caracterizado porque el módulo MRR incluye un módulo que implementa la lógica necesaria para la realización de las operaciones de administración sobre la TRR, poseyendo dicho módulo dos interfaces: una para la comunicación con la lógica de interfaz esclava que activa las operaciones de registro y borrado; y otra interfaz para las escrituras en las memorias que implementan la TRR; y en el que el módulo de lógica de administración hace uso de un registro de huecos para la gestión del espacio disponible en las memorias que implementan la TRR. 11 ES 2 353 792 A1 33. Sistema según la reivindicación 19, caracterizado porque el módulo MRR incluye un módulo que implementa la lógica necesaria para la implementación de las operaciones de búsqueda sobre la TRR, donde el módulo posee dos interfaces, una para la comunicación con la lógica de interfaz esclava, la cual activa las operaciones de búsqueda, y otra interfaz para la comunicación con un módulo de política de selección. 34. Sistema según la reivindicación 33, caracterizado porque el módulo MRR implementa en hardware la selección de DBF mediante el análisis de la información obtenida mediante lecturas sucesivas de la memoria RAM, donde las posiciones de la RAM leídas son deducidas de la información de acierto que indica la salida de la memoria de acceso por contenido que almacena los ICD de las entradas de la TRR. 12 ES 2 353 792 A1 13 ES 2 353 792 A1 14 ES 2 353 792 A1 ES 2 353 792 A1 16 ES 2 353 792 A1 17 ES 2 353 792 A1 18 ES 2 353 792 A1 19 ES 2 353 792 A1 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA