Creación de Sistemas Digitales: una perspectiva desde MDA – Proyecto Simbiosis -

José Luis Uribe Aponte, Juan Camilo Gómez Herrera

Universidad de los Andes, Maestría en Ingeniería, Departamento de Ingeniería de Sistemas y Computación

Carrera 1 No 18A 10 Bogotá, Colombia {jl.uribe412, jc.gomez148}@uniandes.edu.co

Abstract. The methodologies for the development of Digital Systems consist of a specification stage, a design stage that includes a description of the hardware system architecture, an implementation on a synthesizable HDL (Hardware Description Language) and finally a physic implementation. This paper presents a proposal of software systems based on MDA (Model Driven Architecture) strategies and design of domain specific languages to give an infrastructure that allows systematize intermediate processes on the building of Digital Systems, to maximize the use of resources and time on the digital hardware development.

Resumen. Las metodologías para el desarrollo de Sistemas Digitales consisten en una etapa de especificación, una etapa de diseño, que incluye una descripción de la arquitectura del hardware del sistema, una implementación en un HDL (Hardware Description Language) sintetizable y por último en una implementación física. El presente artículo presenta una propuesta de sistema de software basado en MDA (Model Driven Architecture) y en el Diseño de Lenguajes de Propósito Específico que brinde una infraestructura que permita sistematizar procesos intermedios en la creación de Sistemas Digitales, y de esta forma maximizar el uso de recursos y tiempo en el desarrollo de hardware digital.

Keywords: MDA, Digital Systems, Models Specific Domain, Domain Specific Language, Meta-models, Hardware Design, HDL.

Palabras Clave: MDA, Sistemas Digitales, Modelos de Dominio Específico, Lenguajes de Dominio Específico, Metamodelos, Diseño de Hardware, HDL.

1 Introducción

A puertas de terminar el primer decenio del siglo XXI, es innegable la inclusión de la electrónica en todos los ámbitos en los cuales se desenvuelve el hombre, desde las actividades totalmente cotidianas, como hacer una llamada telefónica, hasta las más complejas como analizar su propio genoma.

Por otro lado e independiente de la funcionalidad del sistema electrónico que se

trate, éste se puede definir desde un nivel de abstracción muy alto, como una entidad con la capacidad de transformar un conjunto de señales de entrada en un conjunto de señales de salida por medio de dispositivos y/o tecnología electrónica [1].

De esta forma, y con base en la naturaleza de las señales que procesa el sistema, es posible referir las principales ramas que posee la electrónica, las cuales son: la electrónica análoga y la electrónica digital.

La electrónica análoga, se puede definir como la rama de la electrónica que crea y

manipula señales en las cuales la variable dependiente toma cualquier valor dentro de un rango establecido y limitado. Una de sus características principales es el uso de herramientas de modelado que emplean típicamente conceptos de matemática continua.

En contraste la electrónica digital, manipula y procesa señales, cuya variable

dependiente toma un conjunto finito de valores, típicamente dos, lo cual hace que también se le conozca a esta rama como electrónica binaria y se caracteriza por modelarse por medio de lógica y matemática discreta [1].

De hecho, desde su aparición, la electrónica digital ha incursionado en diferentes

campos de aplicación de acuerdo al cambio de las diversas necesidades industriales, militares, comerciales, académicas, etc., que se han presentado en los últimos años. Esto ha traído consigo que las técnicas y metodologías para la creación de sistemas digitales se estén evaluando continuamente, lo cual ha producido como consecuencia la automatización de procesos y la estandarización de procedimientos.

Sin embargo, y como se explicará en la sección 3, las metodologías actuales se

centran cuando ya se cuenta con una implementación en un Lenguaje de Descripción de Hardware (HDL – Hardware Description Language), la cual es inmediatamente previa a los procesos de simulación, verificación e implementación física del sistema.

Este hecho hace que los procesos de especificación del sistema digital a diseñar, el

modelado de la arquitectura del sistema y su dinamicidad en el tiempo, queden como procedimientos aislados, en algunos casos solamente necesarios para los procesos de documentación.

Lo anterior, puede traer consigo que la implementación final no sea totalmente acorde a los diseños iniciales, lo cual dificulta la trazabilidad en el proceso de construcción de los sistemas desarrollados, encarece los procesos de detección y corrección de errores, lo que se traduce en un incremento en los costos de producción de sistemas hardware. Por lo tanto, se presenta una metodología de diseño de sistemas digitales que parte explícitamente del proceso de especificación del sistema a diseñar hasta su implementación en un HDL determinado. De igual forma, y con el ánimo de contar con una herramienta que facilite la puesta en marcha de la metodología propuesta, se esbozan las características generales de un sistema de software que sirva de infraestructura para cumplir las exigencias del proceso metodológico mencionado.

De hecho, una característica muy importante de la metodología indicada, es que los resultados de los procesos que la componen, se pueden describir como modelos con un nivel de detalle, que van transformándose y refinándose paulatinamente hasta llegar a la implementación en un HDL, la cual debe ser sintetizable o programable en un dispositivo físico. Al analizar lo dicho anteriormente, se esta haciendo referencia a los elementos básicos de la Ingeniería Basada en Modelos o MDE (Model Driven Engineering) la cual se fundamenta como a través de modelos y sucesivas transformaciones es posible llegar a las soluciones deseadas [2]. Por tanto, si el proceso de creación de sistemas digitales se puede enmarcar en MDE, se propone la idea que el sistema de software que sirva de soporte, sea construido con la misma filosofía, en particular haciendo uso de MDA (Model Driven Architecture), la cual puede definirse como la materialización de los principios de MDE para la creación de sistemas de software [3].

En la sección 2 del presente documento se enuncian algunas generalidades de los sistemas digitales, con el fin de brindar un mejor contexto al lector. En la sección 3, se presenta un proceso metodológico para la creación de sistemas digitales. En la sección 4 se hace una referencia corta de los conceptos básicos de MDE y MDA, de tal manera que en la sección 5 se muestran los lineamientos de una solución de software, basada en MDA, que facilite llevar a cabo la metodología propuesta para la creación de sistemas digitales. Por último, en la sección de conclusiones, se presentan los puntos más importantes de la propuesta, destacando sus posibles efectos y beneficios.

2 Generalidades de los Sistemas Digitales

De aquí en adelante, se referirá a un sistema digital como un sistema que esta conformado principalmente por elementos o subsistemas electrónicos digitales. De forma similar, se consideran sistemas análogos los que se encuentran compuestos por unidades o subsistemas electrónicos analógicos.

No obstante, por el alcance que tiene el presente artículo solo se hará referencia a

sistemas 100% digitales. Éstos están compuestos principalmente por dos tipos de subsistemas, los cuales son de lógica combinatoria y elementos de memoria.

La lógica combinatoria es la encargada de que el sistema digital pueda tomar

decisiones, y está compuesto principalmente por compuertas lógicas, las cuales realizan operaciones lógicas, como conjunción (compuerta AND), disyunción (compuerta OR) y comparación (compuerta XOR – Or Exclusivo -) entre otras.

Los elementos de memoria están conformados principalmente por Flip-Flops, los

cuales pueden describirse como componentes de almacenamiento temporal que permiten leerse y escribirse mientras el sistema electrónico este funcionando y con capacidad de albergar un bit. De igual forma, la interconexión de varios Flip-Flops, se conocen con el nombre de Registros, los cuales son unidades de almacenamiento que

permiten lectura y escritura, pero con capacidades mayores a un solo bit, como los son los registros de de 8 bits (1 Byte), de 16 bits (1 Word), o de la capacidad que se requiera [4].

Es importante destacar, que aunque la distinción y las funcionalidades que cumplen

la lógica combinatoria y los elementos de memoria parecieran simples, realmente son las piezas fundamentales para crear sistemas como los microprocesadores que se encuentran en los computadores actuales, los cuales son capaces de ejecutar funciones y tareas cada vez más complejas.

Sin embargo, al hacer mención del microprocesador como ejemplo de sistema

digital, no debe confundirse los sistemas digitales con sistemas embebidos, dado que éstos hacen referencia a la integración de varios sistemas, digitales y análogos, en un solo chip para el cumplimiento de una funcionalidad específica y sobre todo, a la programación (software) que se ejecuta sobre la plataforma de hardware. En otras palabras, el sistema digital hace referencia al sistema físico (hardware), mientras que el sistema embebido incluye tanto los componentes de software y hardware, este último compuesto por varios subsistemas.

2.1 Evolución en la creación de sistemas digitales.

El perfeccionamiento continuo de los sistemas digitales, se debe en gran medida a la evolución misma que han sufrido las técnicas y metodologías para su diseño y desarrollo, a la par con las tecnologías físicas que soportan la implementación.

A mediados de los años 60’s, tras la masificación de la elaboración de circuitos integrados, la elaboración de sistemas digitales complejos se concentraba en la interconexión de muchos elementos lógicos básicos, la cual era entendida casi exclusivamente por el diseñador del sistema, lo cual dificultaba mucho la posibilidad de realizar sistemas escalables y extensibles. Por lo anterior, a mediados de los años 70’s, varios investigadores de diseño de hardware digital, concientes de las limitaciones y problemas que tenía la metodología empleada en ese momento, comenzaron a trabajar en formas alternativas para describir sistemas digitales, diferentes al dibujo de circuitos esquemáticos.

El resultado de estos trabajos es lo que se conoce actualmente como HDL’s (Hardware Description Language – Lenguajes de Descripción de Hardware), y se puede definir como lenguajes textuales que representan las conexiones dentro de un sistema lógico [5,6]. A continuación se muestra un ejemplo de lo dicho anteriormente.

Fig 1a. Circuito esquemático que muestra la transferencia de información de un solo bit.

Fig 1b. Representación del circuito de la Fig 1.a en un HDL

En la Figura 1a, se visualiza el circuito electrónico donde se muestra la

transferencia de información del Flip-Flop A al Flip-Flop B, la cual se encuentra condicionada a que se encuentre en 1 lógico la señal CS1. En contraste, por medio de la expresión descrita en la Figura 1b, se esta representando exactamente lo mismo pero de una forma mucho más concisa y sencilla de interpretar.

Nótese, que si no se quisiera transferir un solo bit de información sino 32 o 64 bits, como lo hacen los sistemas actuales, el circuito sería ya muy complejo de dibujar, dado que debería replicarse 32 o 64 veces, según el caso, y solo se esta ejecutando una sencilla transferencia de información. En contraparte, si se requiere escalizar el sistema anterior a 64 bits, la sentencia en un HDL sería equivalente a:

1) B[0..63] � A[0..63]

Por otro lado y a la par con la aparición de los lenguajes de descripción de hardware, la electrónica digital programable evolucionaba rápidamente. Los dispositivos programables son circuitos integrados que permiten la implementación de circuitos lógicos que cumplan una función particular reutilizando sus componentes internos (compuertas lógicas y elementos de memoria) cambiando las diferentes conexiones entre ellos; son realmente éstas últimas las que “programa” el diseñador.

Actualmente, los dispositivos programable más empleados en la industria son los

FPGA, Field Programmable Gate Arrays, dado que permiten implementar cualquier sistema combinatorio y de registros, además de albergar internamente sistemas de memoria y de almacenamiento no volátil [7].

Es así que junto la potencialidad que ofrecen los FPGA, con los HDL’s, han hecho

que surjan nuevas metodologías de diseño de hardware, lo cual se describirá en la próxima sección.

1) B � A

3 Proceso Metodológico de Diseño de Sistemas Digitales

En la mayoría de ocasiones, la industria marca las pautas tecnológicas para realizar diferentes procesos. En los últimos años, dos de las metodologías más usadas (“top down” y “bottom up”) para la creación de los sistemas digitales están orientadas o basadas en HDL, como lo señala Sagahyroon y Massouni [8]: “Basados en los cambios recientes de la industria, es claro que los HDL’s están convirtiéndose rápidamente en parte integral en los entornos de diseño”.

Los HDL’s son lenguajes para la descripción de hardware, es decir no son

lenguajes de programación en el sentido más estricto, sino que permiten describir la funcionalidad y comportamiento de un sistema digital [6,9].

Existen muchos HDL, sin embargo y debido a la gran proliferación de estos en la

década de los 80’s, el Departamento de Defensa de los Estados Unidos inició un proceso de estandarización cuyo resultado final fue la especificación del lenguaje VHDL (Very High Speed Integrated Circuits Hardware Description Language), que actualmente es uno de los estándares más seguidos por la industria [6]. No obstante, existen lenguajes que también son utilizados en la industria como System-C y Verilog [9].

Un código fuente en VHDL es el producto final en el proceso de diseño de un

sistema digital, dado que a partir de éste código, es posible realizar la implementación física en el circuito integrado. Este procedimiento se conoce comúnmente como “quemado” del chip.

Si se analiza el hecho anterior en un ambiente más global, este código es parte

intermedia del proceso, dado que posterior a este, viene el proceso de verificación, validación, ajustes etc. Si se hace un pequeño paralelo con el proceso de creación de sistemas informáticos (software), el código VHDL es el código fuente de la aplicación, pero que posterior a la obtención de éste, se debe iniciar el proceso de validación de requerimientos, despliegue, pruebas y demás.

Siguiendo con el paralelo anterior, para llegar al código fuente de la aplicación, es

necesario realizar un proceso de diseño, es decir un modelado en un lenguaje diferente al de la implementación. En el caso del Análisis y Diseño Orientado por Objetos (ADOO), se debió modelar el sistema y expresar este modelado por medio de diagramas UML, como por ejemplo: diagramas de clases, secuencia, colaboración etc., para posteriormente seleccionar un lenguaje orientado por objetos, para realizar la respectiva implementación.

Por tanto, y al igual que en el desarrollo de software, que no se llega al código

fuente de la aplicación sin un proceso de análisis y diseño, de forma similar sucede con la construcción de sistemas digitales, para llegar al código VHDL existen pasos intermedios. Esto se puede apreciar en las Figuras 2a y 2b.

Fig 2a. Diseño metodológico para sistemas digitales [10].

Fig 2b. Modelo cascada para la creación de sistemas de software [14].

No obstante, en la industria electrónica no se cuenta con herramientas que permitan realizar modelos de alto nivel. Se cuenta, en lugar de lo anterior, con diferentes tipos de software que facilitan la descripción de los sistemas digitales en VHDL, para luego entrar en una fase de análisis y depuración muy estrictos para la implementación física [10]. Como se aprecia en la Figura 2a, el proceso de diseño de hardware es iterativo, pero se parte del diseño implementado ya en VHDL o en el HDL escogido, para luego hacer pruebas de simulación, y aprobado este último, se procede a las fases que están mas involucradas con el proceso del diseño físico, como son la síntesis, el ruteo y la verificación final. Por tal motivo, el presente artículo busca por medio de la construcción de software basado en modelos, estructurar y soportar una metodología que permita llegar al diseño implementado de una forma coherente y aprovechado todas las ventajas que tiene este nuevo paradigma en la creación de sistemas informáticos. Para lograr lo anterior, se tomará como referencia una metodología desarrollada por la Sección de Técnicas Digitales del Departamento de Electrónica de la Pontificia Universidad Javeriana, aplicada en los cursos de pregrado de Ingeniería Electrónica: Diseño de Sistemas Digitales y Arquitectura y Organización de Procesadores [11]. Esta selección se hace con base en los proyectos satisfactorios que ha realizado y en el reconocimiento que ha obtenido esta unidad académica por trabajos como Implementación de un procesador digital BINARIC [12], mostrado en el Colombian Workshop on Circuits and Systems CWCAS'07 del 2007, y en el Analizador Lógico Remoto Implementado con FPGA [13], mostrado en XXIII Reunión Nacional de ACOFI - Asociación Colombiana de Facultades de Ingeniería.

La metodología mencionada, se compone básicamente de 6 grandes pasos, que se

describen brevemente a continuación: A. Especificaciones preliminares de diseño: En esta etapa, se describen las funcionalidades básicas del sistema digital a diseñar. Se realiza un diagrama de entradas y salidas (I/O), indicando claramente las características de las señales que interactúan globalmente en el sistema, es decir, no se especifica el funcionamiento interno del prototipo a diseñar. B. Diagramas Generales En este punto, se realiza una segmentación del sistema a diseñar en subsistemas más pequeños o simples y se realiza un diagrama de bloques en donde se muestra la interacción de los subsistemas. Posterior a esto, se realiza un diagrama de tiempos que permita ver el comportamiento dinámico del sistema. C. Descripción AHPL

AHPL (A Hardware Programming Language) es considerado uno de los lenguajes precursores de los diferentes HDL’s [6]. Su origen se remonta al año 1978 y según sus autores todo dispositivo que se pueda implementar en hardware, se puede describir con base en su conjunto simple de reglas [6]. Aunque no existe un estándar para AHPL, como si para VHDL, se considera uno de los lenguajes más sencillos que existen para describir hardware. De igual forma, una característica muy importante es que es independiente de la tecnología, es decir la funcionalidad del sistema se describe con base en Transferencia de Registros (RTL), sin importar en que clase de circuito integrado se realice la implementación física. En este punto, se describe a nivel de RTL las funcionalidades de cada subsistema y por ende, la del sistema completo. D. Esquemático preliminar En este paso, con base en la descripción anterior se puede diagramar el circuito físico del sistema descrito en el paso anterior, es decir especificar gráficamente las compuertas y elementos de memoria y sus conexiones internas. E. Descripción VHDL Aquí se debe tener en cuenta el tipo de tecnología con la que se va a implementar físicamente el sistema digital. Es importante notar que esta implementación depende directamente del paso C, y éste al depender de los anteriores, conlleva a una relación coherente en todo el proceso. F. Implementación física. Ya con el “código VHDL”, se realiza el proceso de “quemado” o implementación física del circuito integrado, lo que da como resultado el chip con el sistema digital incorporado. Es importante aclarar que para realizar el proceso de testing (el cual incluye procesos de verificación y validación) del sistema creado, no es necesario realizar el quemado del chip, sino trabajar con simuladores (con base en la familia y tecnología de circuitos integrados escogida), para luego proceder al proceso de ajustes y detalles finales.

Como se observa en la Figura 3, el primer bloque se puede ver como la abstracción de más alto nivel, en donde solamente se identifican las entradas y salidas del sistema digital a diseñar, cumpliendo así la primera etapa del proceso. Tras esta fase, el sistema debe descomponerse en subsistemas que interactuando entre sí, permitan cumplir la funcionalidad descrita en la fase previa. Es muy importante destacar que en esta transición se hace un refinamiento del modelo inicial, dado que ya no se ve el sistema digital como una “caja negra”, sino como subsistemas más pequeños que son capaces de comunicarse para cumplir los requerimientos del sistema a diseñar.

Posteriormente, es necesario realizar una descripción del sistema con la ayuda del AHPL, ésta fase tiene como insumo la descripción en diagrama de bloques del sistema, para que luego con base en esta descripción se pueda realizar un dibujo esquemático del circuito electrónico a partir de compuertas lógicas y elementos de memoria. Con los pasos anteriores, y como lo muestra la Figura 3, se procede a especificar el sistema digital en un lenguaje que pueda posteriormente ser sintetizado en un chip físico, como es VHDL. Observe que el objetivo de esta última descripción, es colocar en un lenguaje textual y estándar, el circuito dibujado previamente. Es importante recalcar en la anterior metodología, que lo que se busca es llegar de forma coherente al código VHDL que describa el sistema, partiendo primero de abstracciones de muy alto nivel, hasta poder llegar a describir el sistema en términos de los elementos lógicos más básicos que existen.

Fig 3. Proceso Metodológico para el Diseño de Sistemas Digitales

4 Algunas generalidades de MDE y MDA

En Noviembre del 2000 la OMG (Object Management Group) propuso un nuevo enfoque para la creación de sistemas informáticos llamado MDA (Model Driven Architecture), el cual se basa en 3 ideas principales: Representación Directa, Automatización y Estándares, lo cual se conoció posteriormente como el manifiesto IBM [2].

Fig 4. Principios fundamentales del manifiesto IBM [2].

La Representación Directa permite expresar soluciones en términos más cercanos al dominio del problema por medio de los DSL’s (Domain Specific Language). La Automatización se refiere a que la expresividad ganada por los DSL’s pueda procesarse con herramientas computacionales, y de esta manera tener un puente entre los conceptos expresados en el dominio del problema y la implementación de la solución. De igual forma, todo lo anterior debe estar enmarcado por el uso de Estándares, que permitan la interoperabilidad entre diferentes soluciones técnicas propuestas [2]. Por otro lado, uno de los aspectos más importantes de MDE es poder abstraer un problema, como un proceso en el cual a partir de un modelo inicial, éste puede ir transformándose y refinándose en otros tipos de modelos hasta llegar a la solución requerida. Es importante destacar, que si el modelo se puede describir en términos y conceptos del dominio del problema, la solución será más pertinente para el usuario del sistema. Es precisamente está filosofía lo que dio paso a lo que se conoce hoy en día como DSL’s. De hecho, una de las mayores contribuciones de MDE es la expresión de los DSL’s por medio de metamodelos. Un metamodelo describe los tipos de elementos que pueden ser contenidos por un modelo, la forma en la cuales estos se relacionan, al igual que los tipos de restricciones que pueden tener [2,3]. Un metamodelo actúa como un filtro para extraer los elementos pertinentes de un sistema para construir un modelo. Cualquier característica que no se encuentre en el metamodelo, no podrá ser tenido en cuenta cuando se construya un modelo del sistema a representar. Los metamodelos son usados para formalizar la construcción de los modelos.

Por otra parte, uno de los conceptos más importantes que tiene MDA es lo que se conoce como modelo Y (The Y Schema), que se muestra en la Figura 5:

Fig 5. Modelo Y1 [13]

Modelo Independiente de la plataforma (PIM – Platform Independent Model): Es un modelo de un sistema que no contiene información acerca de la plataforma o la tecnología que es usada para implementarlo. Modelo de Plataforma Específica (PSM - Platform Specific Model): Es el modelo de un sistema que incluye información acerca de la tecnología específica que se usará para su implementación sobre una plataforma específica. Uno de los problemas más comunes en la construcción de software es la dependencia que tiene la solución informática propuesta con las herramientas que la implementan. Esto se debe a que, dada la evolución tan rápida que tienen éstas últimas, la solución debe modificarse o “parcharse” con base en este cambio, así el usuario o cliente del sistema no haya cambiado sus requerimientos. Por tanto, parte de la filosofía de MDA es modelar el sistema a diseñar sin pensar en absoluto en la plataforma en la cual se implementará, es decir obtener un modelo PIM que realmente tenga en cuenta todos los aspectos del sistema, independiente de la tecnología a emplear. Posteriormente, con un modelo de la plataforma, por ejemplo: si se esta en el contexto de las aplicaciones empresariales, tener el modelo de EJB 3.0 en JEE5 o un modelo de servicios en un ambiente SOA, aplicar una transformación para que el PIM desarrollado se convierta en un modelo de plataforma específica o PSM. Una de las competencias que busca tener MDA, es que si cambia la tecnología, no se debe hacer modificaciones manualmente. Se debe realizar el modelo de la nueva tecnología y a partir de una transformación, tener el nuevo PSM.

1 Tomado de MDA Guide Version 1.0.1. The Object Management Group (OMG). Disponible

en línea: http://www.omg.org/docs/omg/03-06-01.pdf

Los temas anteriormente expuestos, son ampliamente tratados en las referencias [2, 3,15], lo mencionado en este artículo solo tiene como objetivo brindar una mejor contextualización al lector.

5 Sistemas Digitales: Un perspectiva desde MDA

Al analizar brevemente la metodología de creación de sistemas digitales tratada en la sección 3 y mencionadas algunas generalidades de MDA en la sección anterior, se identifican varios puntos claves:

i. La metodología presentada para crear sistemas digitales presenta varias similitudes

con un proceso de desarrollo de software, en donde se tiene un análisis previo, división en sub-problemas, una fase de diseño y por último una fase de implementación. Es claro que se está siguiendo un proceso cascada [14], similar al modelo cascada que se tiene en la creación de sistemas de software como se visualiza en la Figura 2b, y se parte de una descripción de requerimientos en la creación del sistema digital. El objetivo de esta propuesta, es estructurar la metodología de la creación de sistemas digitales, y presentar los lineamientos generales que una infraestructura de software, con base en estrategias de MDA, debe poseer para facilitar la aplicación de esta metodología de diseño electrónico digital.

ii. Actualmente, al aplicar la metodología, si hay un cambio en cualquier fase del

proceso, por ejemplo, nuevas interconexiones de diferentes subsistemas, se debe hacer manualmente una actualización a todos los niveles de diseño. De no hacerse, por no ser un proceso automático, imposibilita la trazabilidad entre los resultados de cada fase.

Por tanto, los lineamientos del software que se presentan en este artículo, de ser implementados en una solución concreta en trabajos posteriores, automatizarían este tipo de situaciones. Es precisamente un ejemplo como el anterior, lo que se refiere a que un sistema software sirva de infraestructura para la metodología en la creación de sistemas digitales.

iii. Al analizar los resultados previos de cada fase en el proceso metodológico se concluye que cada uno es una concepción y una abstracción a un nivel diferente del sistema digital, es decir, se cuenta con un conjunto de modelos vistos desde perspectivas distintas.

iv. Una de las ventajas que se tiene en la creación de sistemas digitales es que la decisión de la “tecnología” para implementar la solución, puede dejarse como la última decisión del diseño.

Ya identificados varios puntos de acción en el proceso metodológico para la creación de sistemas digitales se puede hacer una conclusión preliminar: Cada fase

metodológica entrega un modelo con un nivel de detalle diferente, que junto a un conjunto de transformaciones permite construir a un producto final, el cuál para este caso es el código VHDL.

5.1 Primera aproximación de metamodelo de Sistemas Digitales.

Una de las características actuales para la construcción de diseño de sistemas digitales es que no se cuenta con un estándar para las fases iniciales en la metodología, y muchos de los modelos preliminares se construyen o se basan en lenguaje natural, el cual no permite transformaciones automáticas o por medio de software. Por tal motivo, el primer paso para poder realizar un modelo que permita ser transformado es definir un lenguaje de propósito específico que permita el modelado de un sistema digital a nivel global, y de esta forma describir su conjunto de entradas y salidas y la definición de subsistemas y sus interconexiones. En otras palabras, se debe definir un lenguaje que describa de forma estricta los resultados de las fases A y B del proceso metodológico de sistemas digitales. Es decir, crear un DSL que permita definir un modelo de dominio específico (DSM - Domain Specific Model) o un lenguaje de modelado para un dominio específico (DSML) para describir modelos de diagramas de bloques digitales e interconexiones. A continuación, se presenta una primera aproximación del metamodelo para el diseño de sistemas digitales:

Fig 6. Metamodelo de un Sistema Digital

Como se muestra en la Figura 6, un SistemaDigital, se puede descomponer en bloques funcionales y en las interconexiones que existen entre ellos. Los Bloques

Funcionales, pueden ser de tres tipos: BloquesdeLógicaCombinatoria, que son los encargados de tomar decisiones o realizar operaciones lógicas y/o aritméticas, de forma instantánea. Por otro lado, las UnidadesAlmacenamiento, las cuales están compuestas principalmente por elementos de memoria, cuya función principal es guardar información que puede ser procesada posteriormente. De otra parte, los Contadores, aunque puedan modelarse como registros, permiten realizar conteos de intervalos de tiempo que son útiles en la interacción de los subsistemas internos. Las interconexiones entre los bloques funcionales se realizan por medio de Conexiones, que pueden ser internas (ConexionInterna), las cuales comunican subsistemas internos del sistema digital, y externas (ConexionExterna) que son las que interactúan con los usuarios, sean personas u otros sistemas. Es importante notar, que al definir un DSML que describa un metamodelo, sus instancias pueden transformarse sistemáticamente en otros modelos. Si se recuerda en la metodología de diseño descrita en la sección 3, la primera fase es especificar el sistema a nivel de entradas y salidas, para luego con base en esta, transformar este modelo de muy alto nivel a un modelo más especifico en donde se descomponga el sistema digital en subsistemas, con interconexiones muy bien definidas. Lo anterior se resume en la parte superior de la Figura 7. Con base en lo anterior, y con la ayuda de MDA, se busca abstraer los primeros pasos metodológicos en la creación de sistemas digitales por medio de la definición de un metamodelo para la definición de diagrama de bloques, para luego con base en éste, realizar un modelo que describa los subsistemas internos del sistema digital. Lo anterior se muestra en la Figura 7.

Fig 7. Creación de un Metamodelo para la definición de sistemas digitales.

5.2 Modelo de Diagrama de Bloques y AHPL

Como ya se mencionado en la fase C en el proceso de diseño de sistemas digitales, se debe realizar la descripción del sistema digital por medio de AHPL. Este paso es muy importante, dado que hasta ahora lo que se ha hecho es realizar un modelo estático del sistema digital. Se necesita realizar un modelo que describa cómo el sistema se comporta dinámicamente con el tiempo, lo cual no es posible realizarlo con el diagrama de bloques. Sin embargo, y aunque el lenguaje AHPL tiene una enorme importancia, una limitante que posee este HDL, es que no existen analizadores sintácticos que procesen esta descripción de hardware. De igual forma, al no existir un estándar que lo defina, no es única la forma de colocar comentarios en el código AHPL, lo que dificulta el proceso de documentación. Por tanto, se debe pensar en la creación de un analizador sintáctico y semántico que soporten este HDL, para modelar esta etapa de la metodología. Es importante recordar que la descripción en AHPL es totalmente independiente del lenguaje sintetizable a emplear (VHDL, Verilog, System-C etc.) y de la tecnología física que se empleará, es decir, en este caso se describe el sistema sin pensar en que tipo de circuito integrado o “chip” se va a implementar el diseño digital. De igual forma, los modelos estático (diagrama de bloques) y dinámico (AHPL), deben tener una correlación total, dado que ambos deben presentar una coherencia para tener un modelo de sistema digital realizable. Por lo anterior, se propone la creación de un lenguaje de entretejido (weaver) que verifique la consistencias entre los dos modelos. A continuación se ejemplificará lo dicho anteriormente. Considérese un sistema registro serial, similar al de la Figura 1a. Este sistema debe tener una entrada serial, solo debe ser capaz de memorizar dos bits y la carga de información al segundo Flip-Flop debe estar supeditada por una señal sincrónica externa. La salida del sistema es la salida del segundo Flip-Flop. En este caso, se tiene un primer modelo, en donde se especifican las entradas y salidas del sistema, el cual se muestra en la Figura 8a. En la Figura 8b se muestra como debe quedar el sistema a nivel circuital.

Fig 8a. Diagrama de Entradas y Fig 8b. Diagrama circuital interno del

Salidas de un sistema registro.

sistema de la Figura 81.

Como se ha mencionado, el software que sirva de infraestructura a la metodología de diseño debe empezar por tomar el modelo de más alto nivel, en este caso el modelo de entradas y salidas y abstraerlo en un modelo que permita ser transformable hasta llegar a una representación circuital, que se implementa en un HDL sintetizable. No obstante, si por ejemplo, en el modelo dinámico del sistema, es decir en la descripción AHPL, se tiene una declaración como esta: FF[1] � InSerial; FF[2]� InSerial; Estaría siendo conforme a la especificación estática del sistema, dado que no se tiene ninguna entrada o salida ilegal o sobrante, pero no se estaría respetando la arquitectura del sistema, dado que ese registro es no respeta las reglas de carga mencionada. Por lo tanto, el lenguaje de entretejido que se propone, es un lenguaje que permita establecer la coherencia dinámica y estática del sistema digital a construir. De esta forma, y si ya se cuenta con un modelo AHPL (dinámico) válido respecto a su modelo estático, se debe procede a realizar una última transformación para poder ya implementar el sistema en un lenguaje HDL sintetizable. Para lograr lo anterior, se hace referencia el modelo Y, descrito en la sección 4. Para el caso concreto que se trata en este artículo, se tiene que el modelo PIM, es el modelo AHPL, que como se ha dicho es independiente totalmente de la plataforma. Por otra parte, el modelo de la plataforma indicará sobre que se hará la implementación final, en este caso particular será sobre VHDL, nótese que podría ser Verilog o System-C, y como resultado final se tendrá el código VHDL que puede ser simulado o implementado físicamente en un chip. Si se analiza detenidamente, no se ha cambiado en ningún momento el proceso metodológico, simplemente se ha desarrollado una propuesta basada en modelos que busca apoyar la creación de sistemas digitales de una forma ordenada y totalmente coherente.

6 Conclusiones

Hasta el momento se han esbozado las ideas fundamentales del Proyecto Simbiosis, el cual se basa en el proceso metodológico en el diseño de sistemas digitales y los resultados previos a cada etapa, para abstraerlos y de esta forma presentar algunos lineamientos, basados en MDA, del sistema de software que permita automatizar esta metodología. En este caso es importante indicar, que el producto final al cual se

quiere llegar es código VHDL, el cual puede ser simulado y sintetizado para implementar físicamente en un chip.

Sin embargo es importante analizar qué alcances y contextos puede tener la propuesta anterior. En primera instancia y dado que el proceso metodológico proviene de un contexto académico, es natural pensar que su campo de acción se concentre en apoyar el proceso de aprendizaje de diseño de sistemas digitales en estudiantes de ingeniería. Incluso, es posible pensar que el modelado en Diagrama de Bloques y en AHPL, por ejemplo, contemple transformaciones paso a paso o incluso avise o sugiera corrección de errores o cambios en la arquitectura de hardware para realizar diseños de una complejidad mayor.

Por otro lado, y dado los reconocimientos y resultados que ha tenido la

metodología de diseño de sistemas digitales presentada aquí, se lanza una propuesta de sistema de software que permita estructurarla. De esta forma se aspira que con la implementación concreta, en trabajos posteriores, de estos lineamientos, se tengan resultados de línea de producción de sistemas digitales, similar a lo que se conoce como Fabricas de Software o líneas de producto de software [16], con el fin de reducir tiempo, y por ende costos, en el proceso de desarrollo.

De igual forma, se puede acelerar la creación de prototipos de prueba para otros

sistemas digitales con el fin de probar o descartar teorías para ser implementadas en desarrollos más complejos.

Referencias

1. Close, Charles. Modeling and analysis of dynamic systems.3rd ed. Hoboken, New Jersey John Wiley, (2002).

2. Bézivin. Jean, Generative and Transformational Techniques in Software Engineering, Model

Driven Engineering: An Emerging Technical Space, Springer Berlin / Heidelberg, Volume 4143/2006, pp 36-64. (2006)

3. Bézivin, J. In Search of a Basic Principle for Model Driven Engineering. UPGRADE , Vol.

V (No. 2), 21-24. (2004) 4. Katz, Randy. Contemporary logic design, Primera Edición, New York, The

Benjamin/Cummings Publishing Company, (1994). 5. Wakerly, John. Digital design: principles and practices. 4th ed. Upper Saddle River, New

Jersey Pearson Prentice Hall. (2006) 6. Hill, Frederick. Digital systems: hardware organization ad design. 3rd ed. New York. John

Wiley and Sons, (1987) 7. Salewski, F.; Kowalewski, S., "Hardware/Software Design Considerations for Automotive

Embedded Systems," Industrial Informatics, IEEE Transactions on , vol.4, no.3, pp.156-163, Aug. 2008

8. Sagahyroon, A.; Massoumi, M., "On the use of hardware description languages in teaching VLSI design courses," Frontiers in Education Conference, 1996. FIE '96. 26th Annual Conference., Proceedings of , vol.2, pp.713-716. Nov 1996

9. Borrione, D.; Piloty, R.; Hill, D.; Lieberherr, K.J.; Moorby, P., "Three decades of HDLs. II.

Conlan through Verilog," Design & Test of Computers, IEEE , vol.9, no.3, pp.54-63, Sep (1992)

10. Gabrick, M. Nicholson, R. Winters, F. Young, B. Patton, J. FPGA Considerations for

Automotive Applications. SAE TRANSACTIONS VOL 115; PART 7, pages 205-222 (2006)

11. VIVEROS, F. GONZÁLEZ, A. RUÍZ, M. SÁNCHEZ, J. MARCIALES, G. El aprendizaje

por proyectos y el uso de tecnologías móviles en el aula: VIII Congreso de Tecnologías aplicadas a la enseñanza de la Electrónica, Zaragoza-España. Actas del VIII Congreso de Tecnologías aplicadas a la enseñanza de la Electrónica. Zaragoza: Servicio Publicaciones Universidad de Zaragoza, 2008.

12.Álvarez B, Pinilla L, Implementación de un procesador digital: BINARIC. Trabajo de Grado para optar el título de Ingeniero Electrónico. Pontificia Universidad Javeriana (2007)

13.Garcia, L.Gonzalez, A. Moreno, H. Jaquenod, G.Remote logic analyzer implemented on FPGA, Departamento de Electrónica, Pontificia Universidad Javeriana, Bogotá, Colombia Micro-Nanoelectronics, Technology and Applications, 2008. EAMTA 2008. Argentine School of.

14. Bruegge, Bernd. Object-oriented software engineering : using UML, Patterns, and Java. 2nd

ed. Upper Saddle River, New Jersey, Prentice Hall, (2004)

15. MDA Guide Version 1.0.1. The Object Management Group (OMG), Disponible en línea: www.omg.org/docs/omg/03-06-01.pdf (2003)

16. Hallsteinsen, S.; Hinchey, M.; Sooyong Park; Schmid, K., "Dynamic Software Product

Lines," Computer , vol.41, no.4, pp.93-95, April 2008