El objetivo final en el desarrollo de sistemas embebidos es el de diseñar el hardware y el software en todos los niveles de abstracción, tradicionalmente la investigación se ha concentrado en el particionamiento de hardware/software, pero sin resolver el problema de la abstracción de las plataformas de hardware. En lugar de utilizar modelos especiales de hardware, El próximo paso en la
40
automatización sería la síntesis de transferencia de datos, la sincronización y la interconexión, la comunicación, y particiones de hardware/software. [Jerraya, 2005]
Actualmente los sistemas de hardware están diseñados como la composición de interconexiones de componentes inherentemente paralelos. Los componentes individuales están representados por modelos analíticos (ecuaciones), que especifican sus funciones de transferencia. Estos modelos son deterministas (o probabilísticos), y sus composición se define mediante la especificación de cómo fluyen los datos a través de múltiples componentes. Los sistemas de software, por el contrario, están diseñados a partir de componentes secuenciales, como objetos y temas, cuya estructura cambia a menudo de forma dinámica (componentes se crean, eliminan y pueden migrar). Los componentes están representados por modelos computacionales (programas), cuya semántica se define operacionalmente por un motor de ejecución abstracto (también conocido como máquina virtual, o un autómata). Las máquinas abstractas puede ser no deterministas, y su composición se define especificando cómo controlar los flujos a través de múltiples componentes, por ejemplo, la acción atómica de los procesos de independencia pueden ser intercaladas, posiblemente limitado por un conjunto fijo de primitivas de sincronización.
Por lo tanto, el funcionamiento básico para la construcción de modelos de hardware es la composición de funciones de transferencia, la operación básica para la construcción de modelos de software es el producto de los autómatas. Estos son dos puntos de vista radicalmente diferentes para la construcción sistemas dinámicos a partir de componentes básicos: es decir, una analítica (basada en ecuaciones), la otra computacional (basado en sistemas informáticos).
El punto de vista analítico es frecuente en ingeniería eléctrica; el punto de vista computacional, en ciencias de la computación: la representación de un circuito en
41
netlist (descripción en texto de la conectividad de un diseño electrónico.) es un ejemplo de un modelo analítico, cualquier programa escrito en un lenguaje imperativo es un ejemplo de un modelo de cálculo. Dado que ambos tipos de modelos tienen fortalezas y debilidades muy diferentes, las implicaciones en el proceso de diseño son dramáticas. [Henzinger, 2006]
Las nuevas generaciones de diseños de software intensivo y que cuentan con ventanas de mercado a corto plazo y son cada vez con funcionalidades más complejas y fiables. Los enfoques actuales de diseño ASIC son altamente difíciles de escalar para tales SoC con varios procesadores funcionando en paralelo. El diseño de estos nuevos sistemas por medio de métodos clásicos da unos costes inaceptables para la realización y los retrasos. Los diseñadores tendrán un problema importante en la entrega de productos competitivos en el mercado que al mismo tiempo respeten un corto “time-to-market”, sean de bajo costo, y sean diseños complejos y fiables en SoC de varios procesadores. Los desafíos claramente están en el diseño de nuevas metodologías innovadoras.
La Figura 3, muestra la evolución de los niveles de abstracción en diseño de chips. Desde el diseño a nivel RTL, la abstracción se ha aplicado a los componentes de hardware e interconexiones (Figura 3 a), en cuanto a la interconexión, cables se abstraen de las líneas de metal a nivel de diseño para señales a nivel RTL. [Ahmed, 2004]
Por encima de RTL, la abstracción tiene que ser aplicada a software y componentes de hardware (Figura 3 b). Puesto que los componentes de software se ejecutan en los procesadores, la abstracción de la interconexión entre el software y componentes de hardware es totalmente diferente de la actual abstracción de los cables entre los componentes de hardware. De hecho, los componentes de software no se comunican con el mundo externo a través de cables, sino a través de llamadas a funciones (dispositivo piloto) o las
42
instrucciones de montaje (load/store). La interfaz hardware/software tiene que manejar dos interfaces diferentes: uno sobre el lado del software usando la API (Application Perihelia Interface es el conjunto de funciones utilizado como una capa de abstracción) y una en el lado del hardware utilizando alambres.
Figura 3. Evolución de los niveles de abstracción en el diseño de SE
Ahmed, Long Term Trends for Embedded System Design, 2004.
Esta heterogeneidad hace que el diseño de la interfaz hardware/software sea muy difícil y lleva mucho tiempo debido a que el diseño requiere el conocimiento de los programas y el hardware y su interacción. Por lo tanto, un nuevo tipo de diseñador, es decir, el diseño de la integración de hardware/software sea necesario. En términos de madurez de la técnica de diseño, el diseño de la interfaz de hardware/software sigue siendo uno de los cuellos de botella en el diseño SoC y, por tanto, tiene que ser dominado. [Ahmed, 2004]
43
Los enfoques actuales para el problema de codiseño de hardware-software se quedan cortos, se cree en una de dos razones. El modelo formal que no es definido lo suficientemente abstracto para ser utilizado como una implementación independiente de la representación en los procesos de diseño del sistema, De lo contrario, el modelo no es suficientemente detallado para la síntesis eficiente como una mezcla de componentes de hardware y software. [Chiodo, 1994]
44