Introducción

La integración entre las metodologías existentes para diseñar de forma paralela la parte hardware y la parte software, y la definición de nuevas metodologías que sean aplicables tanto al hardware como al software.

Sólo en este último caso podemos hablar de verdadero codiseño hardware-software,puesto que en el caso anterior la mayor parte del proceso de síntesis del hardware y del software discurren por caminos separados. Sin embargo, la mayor parte de los sistemas analizado caen dentro de la primera categoría [BGJ+97, GVNG94, COB95, COH+99, VCC], ya que se basan en una fase de particionado inicial a partir de la cual los flujos de diseño de hardware y software se realizan por separado.

Hasta la fecha, el diseño conjunto de hardware y software tan sólo ha sido abordado con éxito para casos muy específicos, con modelos de computación muy concretos y sencillos (FSM, CFSM, Dataflow), y restricciones muy fuertes en la capacidad expresiva de los lenguajes de especificación (tipos de datos muy limitados, construcciones sencillas y fácilmente sintetizable en hardware). Un caso notable es POLIS [BGJ+97]. En función del tipo de aplicación para el que están diseñados, podemos distinguir cuatro tipos de sistemas de codiseño:

Para aplicaciones orientadas al control. Algunos ejemplos son CHINOOK [COB95],
POLIS [BGJ+97], SPECSYN [GVNG94], STATEMATE [Har90], y COSMOS [IOJ95].

Estas aproximaciones soportan la especificación y síntesis de control, sin soporte de gestión de memoria, ni tipos de datos abstractos. Para aplicaciones orientadas al flujo de datos. Existen varias aplicaciones entre las que se encuentran varios productos comerciales, como BONES/SPW de Cadence, COSSAP de Synopsys, DSP Station de Frontier Design, y también OCAPI [SVR+98], y Ptolemy [BHLM92].

Para aplicaciones dominadas por datos estáticos, cuyo tamaño es conocido en tiempo de compilación. Acropolis [DCM97] se centra en los aspectos de la trasferencia y almacenamiento de los datos, mientras que Atomium [CWG+98] trata los temas de optimización del flujo de datos y reutilización de datos. Para aplicaciones dominadas por datos dinámicos, como las aplicaciones de procesado de protocolos. Destaca MATISSE [WdSJC+99, VdSJY+99] de IMEC, que genera arquitecturas de memoria distribuidas específicas para cada aplicación para permitir la síntesis de gestores de memoria dinámica en hardware. MATISSE utiliza COWARE [N2C] para la generación de interfaces. En general, la aplicación del sistema de síntesis viene muy determinada por el modelo de computación subyacente,

A continuación analizaremos algunos detalles sobre aspectos concretos del proceso de diseño, como son la especificación de sistemas, la arquitectura destino, y la síntesis de interfaces

Especificación de sistemas

Los entornos de codiseño basados en las técnicas y herramientas de diseño de hardware han utilizado siempre lenguajes de especificación más cercanos a los lenguajes de descripción de hardware, mientras que los entornos basados en metodologías de software tienden a usar lenguajes de programación de propósito general con o sin extensiones y restricciones. En cualquier caso, podemos distinguir cuatro aproximaciones al problema

Mezclar en un nuevo lenguaje los conceptos cercanos al hardware con los mecanismos de abstracción de los lenguajes de programación de alto nivel. Algunas de las características de bajo nivel que se requieren son información detallada de la temporización, ejecución paralela, sincronización, etc. Como mecanismos de abstracción podemos citar funciones, tipos definidos por el usuario, soporte de orientación a objetos, primitivas de sincronización de alto nivel, etc. Un ejemplo moderno de esta aproximación es SYSTEMC [Sys, CoC].

La segunda posibilidad es utilizar un lenguaje ya existente sin modificaciones, ni en la sintaxis, ni en la semántica. Por supuesto, dada la mayor complejidad de los sistemas heterogéneos, se necesita una mayor capacidad de abstracción que la que ofrecen los lenguajes de especificación de hardware tradicionales, con lo que normalmente se utilizan lenguajes de programación de propósito general.

Ésta es una posibilidad que ha demostrado ser viable, al menos en algunos ámbitos, como los sistemas reactivos con el lenguaje Esterel en POLIS [BGJ+97]. Una aplicación más general pasa necesariamente por la utilización de lenguajes de especificación menos específicos. Esta tendencia, especialmente para la síntesis de sistemas a partir de C y C++, es una línea abierta de investigación y con bastante actividad [SD01b, Lia00, Wak99a].

3. Una tercera posibilidad consiste en definir un nuevo lenguaje teniendo en cuenta las nuevas necesidades debidas a la mayor complejidad y heterogeneidad de los sistemas hardware-software.

Esta aproximación es la que representa Rosetta y el grupo de estandarización del System Level Design Language (SLDL) [SLD99]. Sin embargo, hay que recordar que en el éxito de un lenguaje de especificación no sólo influye la idoneidad para la tarea concreta, sino que también influyen aspectos culturales (formación de los diseñadores, estilo de modelado, forma de pensar en el problema, etc.) y aspectos prácticos (código ya escrito, intercambio de información entre diseñadores, etc.).

4. La última posibilidad es utilizar múltiples lenguajes de especificación, de distintos niveles de abstracción, y ofreciendo mecanismos para garantizar la coexistencia pacífica.

El desarrollo de software ha seguido esta corriente. Actualmente se diseñan sistemas empotrados complejos utilizando varios lenguajes de programación simultáneamente (Ada, C, ensamblador).

Lenguajes de especificación
C y C++ son los lenguajes de programación más utilizados hoy en día. Por esa razón, en los últimos años también se han utilizado para síntesis de circuitos múltiples dialectos de C y lenguajes de descripción de hardware parecidos a C. Olympus utiliza como lenguaje de especificación HARDWAREC [MKMT90, KM92], un lenguaje similar a C con características muy cercanas a los lenguajes de descripción de hardware. No soporta punteros, ni recursión, ni memoria dinámica, pero es completamente sintetizable. Aunque la sintaxis es muy similar a C, la semántica es más parecida a un lenguaje de descripción de hardware, como VHDL o Verilog. El nivel de abstracción se mantiene muy cercano al hardware, y no provee mecanismos de encapsulación que puedan facilitar la reutilización de partes de la especificación. COSYMA [EB94] utiliza C_, otro superconjunto de C con procesos y restricciones temporales.

Durante la síntesis, las funciones se expanden (todas se tratan como funciones inline) y los punteros se manejan como referencias a memoria, con lo que el resultado de la síntesis es bastante ineficiente. CONES [SMP88], de los Bell Labs, es un sistema de síntesis automática que produce implementaciones a nivel de puertas a partir de modelos de comportamiento descritos en un lenguaje similar a C [BLR84]. En este caso, el modelo C describe el comportamiento del circuito en cada ciclo de reloj. El subconjunto de C soportado está muy limitado, y no incluye punteros ni bucles no limitados. De nuevo, el nivel de abstracción es demasiado bajo para el desarrollo de sistemas complejos. Más recientemente el profesor Wirth ha propuesto un nuevo lenguaje de especificación hardware que resulta familiar a Pascal [Wir98]. Sin embargo, en los últimos años se tiende a utilizar también para hardware lenguajes de programación de propósito general sin ninguna modificación. Así, se ha propuesto el uso de lenguajes reactivos como Esterel [BGJ+97], lenguajes imperativos como C++ [GL97] y Java [HO97, PPS+98], e incluso lenguajes funcionales como Haskell [BCS98]. Los beneficios que se obtienen del uso de estos lenguajes son muchos: El mayor nivel de abstracción permite modelar el sistema más fácilmente, lo que se traduce en un menor tiempo de diseño y un menor número de errores.

Las facilidades de encapsulación y ocultación de datos simplifican la reutilización de código en otros diseños, aumentando también la productividad y mejorando la fiabilidad. La especificación del comportamiento puede ser compilada y ejecutada de forma trivial en cualquier ordenador, lo que hace innecesario cualquier otro tipo de simulador funcional.

Se pueden preparar prototipos en muy poco tiempo, gracias a la rapidez del ciclo de desarrollo y las múltiples herramientas disponibles de diseño de alto nivel, de prototipado rápido, y de síntesis automática de código.

A diferencia de los métodos clásicos de especificación hardware, la independencia con la arquitectura destino es casi total. El programa describe sólo el comportamiento del sistema, sin tener en cuenta las características de los recursos disponibles, de forma que se puede reutilizar el código incluso para sistemas completamente diferentes. Las características de los recursos disponibles quedan encapsuladas en el compilador y el sistema operativo, que son ortogonales a la especificación del comportamiento del sistema, y por tanto pueden ser modificados de forma independiente. A pesar del alto nivel de abstracción que proporcionan los lenguajes de programación de propósito general, siempre existe la posibilidad de optimizar cualquier parte del sistema utilizando la interfaz con lenguajes de muy bajo nivel. En los últimos años, han surgido muchos proyectos con el propósito de utilizar lenguajes de programación de propósito general como entrada a los flujos de diseño actuales [Mic99]. En general, se añaden construcciones al lenguaje para soportar información estructural, informacióndetallada de temporización, y concurrencia de grano grueso. Estas características están presentes en los lenguajes de descripción hardware que hasta ahora se han empleado como entrada a los flujos de diseño. Las nuevas construcciones pueden ser definidas como extensiones sintácticas del lenguaje [EB94, LS99, VdSJY+99], en cuyo caso se crea un nuevo lenguaje, o como librerías [Sys, Cyn]. En el caso de ser implementadas como librerías, aunque existan restricciones aplicables para la síntesis del sistema, obtenemos el beneficio adicional de poder simular y depurar la funcionalidad del sistema utilizando herramientas estándar de desarrollo de software.

Modelos de computación
Para ser capaces de verificar la corrección de la especificación de un sistema es fundamental modelar el comportamiento del sistema, o al menos los componentes individuales, de acuerdo a ciertos modelos de computación. Hay muchos modelos útiles [ELLSV97], con semántica claramente definida, y propiedades interesantes que pueden ser verificadas con métodos y herramientas formales.
Algunos avances en este área provienen de la adición del soporte de un modelo de computación formal a un lenguaje de programación. Por ejemplo, POLIS [BGJ+97] usa el lenguaje Esterel para implementar máquinas de estados finitos que se comunican entre sí. Un lenguaje de texto auxiliar (SHIFT) se utiliza para especificar las conexiones entre máquinas de estados finitos. El modelo de computación subyacente, que es globalmente asíncrono y localmente síncrono, se denomina CFSM (codesign finite state machines).
POLIS puede implementar cualquiera de las máquinas de estados finitos (código Esterel) en hardware o en software. Todas las FSMs que van a software se implementan como tareas sobre un único microprocesador.
La hipótesis síncrona ha permitido el desarrollo de métodos eficientes para determinar
la equivalencia funcional de dos implementaciones diferentes, en el dominio de los circuitos síncronos y de los sistemas reactivos síncronos. Recientemente, se ha extendido estas técnicas de análisis para sistemas que no satisfacen la hipótesis síncrona en su interior, pero sí en la interfaz con el entorno [HBLSV00], lo que permite el análisis de ciertas propiedades formales en las especificaciones de POLIS.
Otros grupos de investigación han desarrollado lenguajes de especificación completamente nuevos basados en cierto modelo de computación, y sin pretender ninguna compatibilidad con otros lenguajes. V++ [CMM+98] está basado en el modelo síncrono, pero con mejor soporte para especificaciones a nivel de sistema. Una aproximación similar es la de ECL [LS99], pero manteniendo cierto nivel de compatibilidad con modelos ya diseñados en Esterel o C. La parte reactiva de la especificación, dominada por el control, que se identifica por el uso de construcciones síncronas heredadas de Esterel, se traduce a un fichero de código en Esterel, que puede ser compilado a hardware o a software. El resto, que corresponde a código C, se traduce siempre a software, desaprovechando posibles oportunidades de mejoras de eficiencia y consumo.
Ptolemy [BHLM92] fue diseñado como un entorno de simulación de sistemas heterogéneos en el que se pudieran mezclar diferentes modelos de computación en un único diseño.
Aunque ha sido utilizado para síntesis, sus capacidades son bastante limitadas.
El lenguaje OpenJ [ZG99] soporta múltiples modelos de computación en un sistema de dos capas. La primera capa implementa un núcleo común del lenguaje, sobre el que se implementan los diferentes modelos de computación en una segunda capa (capa del dominio).
Aunque mucho más flexible que otras aproximaciones, OpenJ dificulta la reutilización del
código ya escrito.
Desde hace unos años, el IEEE está apoyando el desarrollo de un nuevo lenguaje de descripción para sistemas heterogéneos, denominado System Level Design Language (SLDL) [SLD99]. SLDL pretende ser independiente del modelo de computación y soporta incluso el modelado de circuitos analógicos.
Arquitectura destino
Inicialmente, los sistemas de codiseño fueron diseñados pensando en una arquitectura destino que consiste en un microprocesador de propósito general y hardware específico en forma de uno o varios ASICs. Ésta ha sido la arquitectura destino de referencia para los primeros sistemas de codiseño [EB94, GVNG94, IOJ95], y algunos más modernos como POLIS [BGJ+97].

ANTECEDENTES
Con la aparición de los dispositivos lógicos reconfigurables, aparecen herramientas que aprovechan las características de estos dispositivos para obtener una plataforma de prototipado flexible y eficiente. Así, por ejemplo, el compilador Nimble [LCD+00], de Synopsys,
utiliza un sistema destino compuesto por un microprocesador, un dispositivo lógico programable
(FPGA) con reconfiguración dinámica, y una memoria estática. Con ciertos límites,
Nimble es parametrizable para arquitecturas que cumplan estos requisitos. Otro sistema
de síntesis de circuitos basados en dispositivos reconfigurables dinámicamente es CORDS
[DJ98].
Aunque la potencia de los microprocesadores sigue creciendo exponencialmente, la experiencia
demuestra que los sistemas empotrados tienden a estructuras más complejas, con
varios microprocesadores de propósito general y varios circuitos de aplicación específica.
Por tanto, los entornos de síntesis de estos sistemas empotrados tienen que ser capaces de
trabajar con arquitecturas más generales y flexibles. Algunos ejemplos de sistemas que tienen
un modelo general para la arquitectura destino son IPCHINOOK [COH+99], COSYN
[DLJ97], SOS [PP92], y el entorno de Li y Wolf [LW99].
Otro campo en el que se han publicado resultados interesantes para esta tesis es el de las
herramientas de desarrollo para arquitecturas específicas orientadas al diseño de SoC (System
on a Chip). Callahan y otros [CHW00] (U. C. Berkeley) han desarrollado herramientas de
compilación automática y particionado para la arquitectura GARP [HW97], formada por un
microprocesador MIPS 4000 y un coprocesador reconfigurable.
MorphoSys [SLL+00] (UC Irvine) es otra arquitectura diseñada para diseños SoC. Incluye
un microprocesador RISC muy sencillo (TinyRISC) y un array lógico reconfigurable
dinámicamente con múltiples contextos. Es una arquitectura sencilla, pero que se adapta muy
bien a varias aplicaciones multimedia.
Otra arquitectura novedosa que resulta especialmente interesante para el enfoque propuesto
en esta tesis es RED [RML01] (U. Castilla–La Mancha). En este caso se ofrece una
ruta de datos reconfigurable dinámicamente, con múltiples contextos de configuración, que
permiten cambiar toda la funcionalidad en cada ciclo de reloj. Esto hace posible extender la
ISA del procesador principal con operadores complejos, teniendo en cuenta las necesidades
de cada aplicación.
2.4. Síntesis de Interfaces
Recientemente ha habido un gran interés por la síntesis de comunicaciones para sistemas
empotrados de tiempo real distribuidos, pero hasta la fecha los esfuerzos realizados han ido
encaminados a resolver problemas parciales, y muchas de las aproximaciones existentes no
consideran las propiedades globales de los enlaces de comunicaciones.
Tanto Vahid y Tauro [VT97] como Ernst y Benner [EB94] proponen el uso de una librería
de comunicaciones con una interfaz claramente definida. Sin embargo, los protocolos de paso
de mensajes basados en prioridades requieren algo más que una interfaz claramente definida,
porque la asignación de prioridades tiene que ser única.
Rowson [RSV97] propuso una nueva metodología, Interface-Based Design, donde el
diseñador refina las comunicaciones en pasos sucesivos, desde los modelos abstractos hasta
la implementación final. En 1998, Ortega y Borriello [OB98] presentaron una herramienta
de síntesis de interfaces que de alguna forma automatiza esta metodología.
Daveau et al. [DMBIJ97] parten de una descripción a nivel de comportamiento y automáticamente
seleccionan un protocolo de una librería dada para implementar la comunicación.
Utilizan un modelo de comunicaciones abstracto y general, separando claramente computación
de comunicación. La tarea de síntesis de interfaces puede ser ejecutada de forma
automática, y seleccionará el mejor mecanismo de comunicación de los contenidos en una
librería de unidades de comunicación.
Yen yWolf [YW95] abordan el problema de múltiples procesadores heterogéneos conec50
CAPÍTULO 2. ANTECEDENTES
tados mediante topologías arbitrarias de buses. En este caso, asumen un protocolo abstracto
basado en prioridades de los procesadores.
CoWare [BDL+97] también soporta procesadores heterogéneos, pero se centra sólo en el
uso de comunicaciones mediante memoria compartida y protocolos específicos.
Gasteier y Glesner [GG96] sintetizan buses que no requieren arbitraje. Esta aproximación
es más adecuada para sistemas orientados al flujo de datos con patrones de comunicaciones
perfectamente predecibles, pero no se adapta bien a los sistemas reactivos dominados por el
control.
En IPCHINOOK [COH+99], las comunicaciones se modelan mediante canales abstractos
por los que se envían mensajes. Los mensajes son atendidos por los manejadores que estén
activos dentro de cada proceso modal, que son los módulos concurrentes en los que se divide
la especificación del comportamiento. Los procesos modales tienen modos, que definen los
manejadores que hay activos en cada puerto de entrada. Puede haber más de un modo activo
y, por tanto, más de un manejador en cada puerto de entrada.
Otra alternativa para la integración de varios subsistemas, es el uso de un sistema operativo
de tiempo real, que provee una infraestructura de comunicaciones mucho más flexible.
Sin embargo, esta aproximación sólo ha sido utilizada en sistemas software.
2.5. Sistemas operativos para sistemas empotrados
Los sistemas empotrados suelen ejecutar varias tareas simultáneamente. Los subsistemas
software suelen construirse sobre un sistema operativo, que gestiona los recursos para que
puedan ser utilizados por todas las tareas. Esto permite independizar el desarrollo de cada
tarea, simplificando su integración.
Por ejemplo, POLIS [BGJ+97] añade automáticamente un planificador dinámico, que
gestiona las tareas software. Alternativamente, puede utilizar un sistema operativo de tiempo
2.5. SISTEMAS OPERATIVOS PARA SISTEMAS EMPOTRADOS 51
real. De la misma forma, la mayoría de los sistemas que sintetizan una parte compleja en
software, delegan en un sistema operativo la responsabilidad de repartir los recursos.
Tradicionalmente, la noción de sistema operativo se ha asociado al manejo dinámico de
recursos. De hecho, algunos investigadores han acuñado el término de sistema operativo
hardware [Bre96, MLJ98] para referirse a metodologías de particionado encaminadas a la
explotación de las capacidades de reconfiguración dinámica de los dispositivos lógicos programables
modernos. Sin embargo, la gestión dinámica de recursos no es una característica
necesaria para un sistema operativo.
De cualquier definición podemos extraer que el objetivo de un sistema operativo es abstraer
y multiplexar los recursos. Esto permite simplificar el desarrollo de nuevas aplicaciones
porque elimina las dependencias con los recursos concretos. Estos beneficios son también interesantes
para los sistemas hardware-software, pero no conocemos ningún sistema en el que
se haya hecho uso de estas propiedades para ofrecer una visión homogénea de todos los
recursos, hardware y software, disponibles.
Respecto a la planificación de las tareas, recientemente, otros grupos de investigación han
propuesto nuevos esquemas de asignación de prioridades a las tareas especialmente orientados
a la síntesis de sistemas reactivos. En [NSVB00], a diferencia del enfoque clásico a
la planificación de sistemas de tiempo real, se persigue que no exista ninguna pérdida de
eventos internos, teniendo en cuenta los buffers de eventos.
La aproximación clásica del mundo software, donde el sistema operativo ofrece al programador
un gran número de abstracciones pesadas y poco flexibles, no resulta adecuada
para el desarrollo de sistemas hardware o hardware-software. Las pesadas abstracciones que
proporcionan los sistemas operativos tradicionales suponen un coste excesivo en área a la
hora de implementarlas en hardware.
Sin embargo, para el diseño de sistemas heterogéneos, sigue siendo muy interesante la
idea de ofrecer una interfaz homogénea sobre la que construir la aplicación, fomentando la
reutilización de código y separando claramente el comportamiento del sistema de las características
de la arquitectura destino. Por esa razón resulta conveniente extender también los
conceptos involucrados para crear un sistema operativo hardware-software que gestione todos
los recursos (hardware, software y los recursos de comunicación entre los subsistemas)
y ofrezca una interfaz de uso homogénea. Esto permitiría, por ejemplo, manejar de manera
homogénea el paso de información entre distintas unidades funcionales, ya sean hardware o
software.
Los nuevos enfoques de sistemas operativos muy reducidos (microkernels y nanokernels)
vuelven a despertar la posibilidad de implementar sistemas operativos hardware-software sin
un coste importante en área y prestaciones. En particular, los nanokernels, como el exokernel
del MIT [KE+97] y el Off y el Off++ de F. Ballesteros [BF97], resultan especialmente
adecuados por su simplicidad. La idea fundamental de estos sistemas operativos es que el
núcleo no provee abstracciones, sino que actúa básicamente como un multiplexor seguro de
los recursos disponibles. En el caso de Off, además, el núcleo está especialmente diseñado
para implementar sistemas distribuidos, y se consideran recursos disponibles todos los nodos
conectados a una red. Este enfoque resulta especialmente adecuado para su adaptación a la
síntesis de sistemas hardware-software porque el sistema completo puede considerarse como
una red cuyos nodos son los diferentes subsistemas hardware y software.
2.6. Aspectos metodológicos globales
Por último, vamos a analizar una serie de aspectos que están relacionados con el proceso
de diseño en conjunto, más que con una fase concreta del diseño.
La mayoría de las aproximaciones actuales al codiseño hardware-software [GVNG94,
COB95, COH+99, VCC] se basan en una fase de particionado inicial a partir de la cual los
flujos de diseño de hardware y software se realizan por separado (ver figura 2.1). Por tanto,
lo que se ha propuesto una extensión basada en C [LS99]. La versión comercial de POLIS
(Cadence VCC [Cad]) soporta múltiples lenguajes de especificación.
En IPCHINOOK [COH+99], la especificación del sistema se compone de una descripción
del comportamiento, una descripción de la arquitectura destino, y una función de asignación,
que hace corresponder el comportamiento a la arquitectura destino. Esta separación simpli-
fica la reutilización en la especificación del sistema y facilita la exploración de diferentes
alternativas de diseño.
Sin embargo, la simplicidad del proceso de síntesis de IPCHINOOK limita en gran medida
el beneficio que puede obtenerse de esta separación entre comportamiento, arquitectura, y
función de correspondencia. El comportamiento está descrito como un conjunto de módulos
concurrentes que interactúan (procesos modales). La descripción del sistema destino incluye
los procesadores disponibles, los dispositivos de entrada/salida, los buses de comunicaciones,
y la topología del hardware. La función de asignación determina simplemente qué proceso
modal se ejecuta en cada procesador.
Al igual que POLIS, y a diferencia de otros sistemas de cosíntesis, IPCHINOOK no intenta
automatizar el proceso de partición y asignación, se supone que eso viene dado por
el diseñador o por herramientas externas de generación automática de arquitecturas. Esto
impide manejar elementos de granularidad arbitraria, ya que un grano muy fino complican
enormemente la tarea del diseñador.
Otro aspecto que ha generado un gran número de publicaciones recientemente es lo que
se ha denominado “diseño basado en propiedad intelectual”, que no es otra cosa que el diseño
basado en componentes, pero haciendo énfasis en la confidencialidad del diseño en vez de
la encapsulación y la ocultación de datos para eliminar complejidad. El objetivo principal es
ser capaces de construir sistemas complejos a base de componentes obtenidos de distintas
fuentes.
Como objetivo secundario pero también importante, se ha planteado la necesidad de preservar
la identidad del autor de cada diseño. En este sentido, resultan interesantes las técnicas
de firma oculta (watermarking) propuestas por Hong y Potkonjak [HP99] para especificaciones
a nivel de comportamiento. Se basa en incluir en el diseño una serie de restricciones
adicionales, que codifiquen la firma del autor de forma indetectable con un impacto mínimo
en el resultado de la síntesis.
Problemas de escalabilidad
El grado de escalabilidad de los entornos de diseño actuales se ve muy limitado por el
bajo nivel de abstracción que manejan. Como hemos visto, la descripción del comportamiento
se compone de bloques (tareas, procesos, máquinas de estados) que corresponden
directamente con lo que ejecuta cada procesador (hardware o software). Por tanto, se están
manejando abstracciones absolutamente ligadas a la implementación. Si bien es cierto
que determinados patrones estructurales pueden ayudar a modelar mejor un sistema complejo
[GHJV95], existe una gran colección de técnicas de modelado y patrones de diseño
que permiten manejar eficazmente determinados aspectos, como la creación, destrucción, y
gestión de objetos, las comunicaciones, o la adaptación de diseños previos, que no tienen
necesariamente una correspondencia estructural útil o eficiente [GHJV95, BN94, Cop92].
Al mismo tiempo, el diseñador se ve forzado a la utilización de un lenguaje concreto y un
modelo de computación concreto, lo que dificulta el modelado si la aplicación no se adapta
bien a los requisitos del entorno de diseño.
Por otra parte, la imposibilidad de separar eficazmente los distintos aspectos del diseño,
y el aumento de complejidad que conlleva, impide manejar descripciones de gran tamaño.
Referencia de sistemas heterogéneos: www-lsi.die.upm.es/~josem/main.pdf