DelImitación del problema de codiseño: consideraciones previas.

De esta manera, surgen varias posibilidades acerca de cómo la partición software ha de leer un dato producido por la hardware, o cómo esta última debe enviar un resultado a la primera. Básicamente, los modelos de comunicación por los que se pueden optar son los denominados de paso de

mensajes y de memoria compartida.

El primero de los mecanismos se caracteriza por la posibilidad de

comunicación directa entre el software y el hardware. De esta manera, si el

primero posee un dato requerido por el segundo, la transferencia se puede

realizar directamente entre particiones a través del bus. Por consiguiente,

este es un método rápido, pero posee el inconveniente de necesitar para su

funcionamiento una lógica costosa entre los dispositivos.

No hay que olvidar la posibilidad de que exista más de un único elemento por partición, lo que conllevaría desarrollar un mecanismo en el

que se indique la petición de qué datos y a qué módulo, así como los procesos de sincronización adecuados. Esto elevarla el coste del sistema,

aumentando su complejidad de una manera excesiva.

La segunda posibilidad, por la cual se ha optado, es la de memoria

compartida, que es menos eficiente, pero también mucho más sencilla de manejar y estudiar. Así, todos los datos producidos por las tareas se almacenan en posiciones de memoria determinadas. Cada vez que un

dispositivo necesita uno de estos datos, sabe en qué posición puede encontrado, y basta con un acceso a esta dirección para que los valores

estén disponibles.

Obviamente, la desventaja de este mecanismo es el peor rendimiento que ofrece, ya que por lo general, los accesos a memoria suelen llevar asociados un gran empleo de tiempo.

En esta situación, aparece una dificultad añadida, debido a la competencia por los recursos del sistema. En muchos casos, ambas

particiones se verán en la necesidad de acceder a memoria, ya sea para

U

e

e

e

2.2 Consideraciones del entorno de trabajo y simplificaciones realizadas.

U

U

• leer datos o para escribirlos. Como el bus es un recurso limitado, sólo uno

U

de sus posibles clientes puede acceder a él en cada momento, por lo que • sería necesario la determinación de un mecanismo de arbitraje.

u

Sin embargo, es posible evitar este tipo de situaciones si se imita el

U

número de dispositivos que pueden ser maestros del bus a sólo uno. De • esta manera, el procesador de la parte software, que evidentemente dispone • de la lógica necesaria para acceder directamente al bus, pasarla a ser el • único maestro disponible, mientras que el circuito hardware se vería

3

u

supeditado a realizar todas tas transferencias en modo esclavo

U

U

Para el presente trabajo se ha adoptado este modelo, debido

• fundamentalmente a dos factores. Primero, para simplificar la lógica

U

asociada al circuito. De esta manera, sólo es necesario el hardware

U

apropiado para acceso al bus en modo esclavo, evitando las más complejas

funcionalidades asociadas a la posibilidad de trabajo en modo maestro. Por • otro lado, no se necesita el mecanismo de arbitraje del bus, que de igual

U

manera obligaría a introducir una lógica en el circuito que permita

U

interaccionar con el procesador de una manera eficaz.

e

Una última cuestión relacionada con el problema de acceso al bus,

e

reside en el modo en que el circuito recibirá la información. Es evidente, que • en determinados momentos, la partición hardware necesitará una serie de

U

datos para efectuar las operaciones asociadas a una cierta tarea, datos

U

estos que, en muchas ocasiones, habrán sido producidos por la partición

U

software.

• Por lo tanto, es Imprescindible proveer al hardware de esta información • requerida a fin de que continúe sus operaciones sin introducir ningún retraso

U

en el sistema. Con el modelo adoptado, en el que el procesador es el único

e

U

U

En el caso de múltiples procesadores software habria que determinar cuál de ellos

U

realizarla la función de maestro, teniendo en cuenta posibles criterios de rendimiento.

U

U

-55-

Capítulo 2. Delimitación del problema de Codiseño; consideraciones previas.

maestro posible, se presentan dos alternativas a la hora de realizar la transferencia de datos.

La primera, se basa en la propia naturaleza de los sistemas que se van a sintetizar. En estos, una vez finalizado el proceso de Codiseño, con la partición hardware y la software perfectamente especificadas, el esquema temporal de comienzo y finalización de todas las tareas está completamente fijado. Esta labor se ha llevado a cabo como punto necesario para la estimación del tiempo global del sistema, y por lo tanto es perfectamente conocida.

Con esta consideración, el sistema es consciente desde el primer momento de su funcionamiento y de la distribución de tiempos asociada a la planificación de tareas de una manera inequívoca [BeEOO5J.Esta relación de tiempos ha de mantenerse constante, ya que se descarta la realización de una planificación dinámica4 [BLMSSB][MoDeO7],por lo que el procesador conoce en cada momento los instantes de tiempo en los que el circuito hardware necesita o ha producido unos datos en particular.

De esta manera, sería el propio procesador el que se encargaría de realizar la transferencia de datos a través del bus, bien sea de lectura o de escritura. En consecuencia, el circuito hardware encontraría la información disponible en el instante apropiado, o sencillamente volcaría sus resultados al bus cuando los hubiera procesado, sin tener que realizar ninguna interrupción a laparte software.

Una desventaja de esta propuesta reside en la excesiva carga que se añade al procesador, ya que no sólo debe realizar la tareas que le haya

Proceso que consiste en realizar una nueva distribución temporal de tareas una vez que el sistema ha comenzado su ejecución, atendiendo a diversos motivos de conveniencia dados por la situación general de los procesos.

e

e

U

U 2.2 ConsIderaciones del entorno de trabajo y simplificaciones realizadas.

U

e

U

• asignado el particionador, sino que además le corresponde la labor de • efectuar las comunicaciones de datos pertinentes con la otra partición.

U

Pero la característica más problemática está asociada a la

imposibilidad de predecir con exactitud los datos de entrada. Si se ha

u

_{estimado un tiempo de finalización de una tarea, y debido a la particularidad} • de los operandos se requiere más margen para finalizarla, se produciría un • desfase entre el componente hardware y el software.

• En consecuencia, si el procesador decidiera recoger los resultados

e

generados por el circuito en el instante establecido, adquiriria unos datos erróneos, lo cual repercutiria en el mal funcionamiento de todo el sistema. • Este modelo sólo sería conveniente para entornos con unos valores de

U

entrada determinados e invariables.

u

Por lo tanto, se precisa una sincronización adecuada entre ambos

e

_{componentes. Así, la segunda opción, que es la que se propone para este} • trabajo, consiste en que, al no poder acceder el hardware a la memoria por • si solo, debe informar de su necesidad al procesador, mediante una linea de • interrupción. De esta manera, el maestro conoce la petición realizada sobre unos datos particulares, encargándose de su lectura de la memoria y de su

U

U

volcado al bus.

U

Una vez realizada esta operación, avisa al hardware de ase hecho,

U

pudiendo este último recogerlos mediante un acceso en modo esclavo. La

U

condición de que los datos se encuentran listos podría venir dada por la

e

decodificación de unos ciertos bits del bus de direcciones, que servirían de

e

• capacitación al circuito de una forma inequívoca.

• Una desventaja de este método reside en la necesidad de dotar al

U

hardware del mecanismo necesario de petición de interrupciones, para que

e

pueda realizar la solicitud de datos en todo momento. Esto, por supuesto,

U

conlíeva un incremento del coste al aumentar la complejidad, así como

e

también del tiempo de interacción entre las dos particiones. Sin embargo, el

U

e

-57-

mi

mi

mi MI

mi

In document Técnicas de estimación de rendimiento y. en un entorno de Codiseño. (página 68-72)