Una introducción a Texas Instruments DSP usando Firmware de Simulink y

RTDX

Este documento presenta un flujo de trabajo para verificar que el código que se ejecuta
en el DSP está dando el mismo o aceptables resultados a los obtenidos durante la
simulación. Este flujo de trabajo de diseño basado en modelos de simulación implica, la
generación de código, y la verificación. El último paso es la verificación. Aquí es donde
RTDX juega un papel vital para la verificación de código mientras se está ejecutando en
el DSP con un instrumento de prueba alrededor de Simulink. En este trabajo se examina
el proceso de la lente de verificación en el contexto del diseño basado en modelos con
tecnología RTDX. Detalle de implementación es a propósito evitar. Seguimiento de
documentos Sin embargo será profundizar en los usos específicos que se ejecutan en
particular TI DSP de coma fija.

¿Dónde encaja RTDX en el Marco de diseño basado en modelos?

Para entender realmente cómo tomar ventaja de los bloques de Simulink RTDX ayuda a
ver cómo estos bloques encajan en el proceso general de desarrollo. Voy a usar diseño
basado en modelos (MBD) como marco para presentar nuestra nueva capacidad de
RTDX. Podemos romper MBD en una serie de pasos. Estos pasos pueden variar en sus
detalles en función del proyecto concreto, pero en general el flujo se mantiene.

1. Un modelo de comportamiento. Construir un modelo de alto nivel que capta las

especificaciones de su diseño a nivel de sistema. Este modelo puede o no incluir detalles
como los efectos de punto fijo, los efectos de circuitos analógicos, efectos de la RF,
detalles de la estructura del filtro, el ruido, la no-linealidad, etc Estos efectos pueden y
deben ser incluidos en los modelos a seguir una vez que el modelo más simple se
demuestra para trabajar según sus necesidades. El mensaje detrás de la modelo de
comportamiento es que no debe empantanarse en los detalles antes de poder hacer algo
con el trabajo de características ideales. Tomar pequeños pasos. Este paso es
simulación, no RTDX o hardware que participan todavía.

Este es nuestro modelo de comportamiento simple, para la simulación solamente

3. Elaboración de modelos. En esta figura que acaba de agregar más detalles a los
subsistemas existentes en el paso 1. En la práctica, este paso podría romper hacia abajo
en una serie de modelos para aislar un conjunto de efectos de otra. O podemos tomar
ventaja de los subsistemas configurables.

4. Un Modelo de Ejecución. Este modelo tiene una particular DSP en mente y es muy
probable que un subconjunto del modelo de donde lo dejó en el paso 2. Ese subconjunto
que los bloques de Simulink que desea generar el código y ejecutar en el DSP. Los
bloques RTDX lado de destino a entrar en la foto aquí, pero usted aún no ejecuta nada
en el DSP. Se genera código en C, compilarlo, y vincularlo a un archivo. OUT y se
detiene allí.
Un modelo de aplicación de los conceptos. Tenga en cuenta la fuente y el disipador de
bloques se han ido. Sólo incluimos los bloques que vamos a generar código. Se genera
el código tanto para los bloques RTDX y el verde bloque DSP.

5. Un modelo para la verificación. Por último, el hardware está aquí. Una vez más, una
de las virtudes de la MBD es que no invocan costoso hardware y equipos de prueba
hasta que esté bastante seguro de sus ideas de trabajo en la simulación. Al llegar aquí,
en el paso 4, el salto de la fe es entonces mucho más pequeño. Este modelo también se
podría llamar el modelo de instrumento de prueba. Considerando que en el paso 3 que
cortar y utilizar la parte del modelo de sistema en el paso 2 que se apliquen de la DSP,
en este paso que hacemos todo lo contrario. En este paso, recortar y utilizar el
instrumento de prueba desde el paso 1 o 2, que interconecta con los módulos DSP.
Básicamente nos quite el bloque DSP y utilizar el resto. Los bloques RTDX HOST
entran en juego aquí. Para ejecutar este modelo de éxito que necesita su plataforma de
hardware y su emulador JTAG.
El modelo de verificación. Observe el bloque DSP no está presente como un bloque
explícito. Sin embargo, cuando uno presiona el botón de reproducción, el DSP. cabo
archivo que hemos construido en el paso 3 se carga en el procesador de la blanco y
comienza a funcionar. El DSP es entonces la lectura y la escritura desde / a los bloques
de RTDX host para comunicarse con Simulink. Esto es lo que llamamos el procesador
en el bucle (PIL) de la simulación. Aquí tomamos ventaja de nuestra instrumento de
prueba se utilizó durante la simulación Simulink-solamente. Reutilización del
instrumento de prueba misma es un gran beneficio que obtienen de MBD y viene sin
coste adicional. En esencia, utilizando el instrumento de prueba misma que debería
obtener la misma respuesta durante la prueba que tengo durante la simulación
(suponiendo un sistema puramente digital). Si no lo hago, luego como ingeniero que
debe corregir el problema o lógicamente justificar las diferencias.

Conclusión: un mayor enfoque en el front-end de un proyecto

¿Qué significa el flujo de trabajo MBD que acabo de describir compra que en
comparación con otros enfoques para la verificación? El principal punto a notar es en
Simulink, un entorno único, tiene una herramienta para la simulación, generación de
código, y la verificación. Esto simplifica el camino hacia un producto funcional DSP.
Es relativamente fácil cambiar entre la simulación y verificación cuando se trabaja con
los mismos bloques en un entorno donde la generación de señales, post-procesamiento y
visualización incluye de serie. Comparar y contrastar este enfoque con un flujo de
trabajo más tradicionales. Un ingeniero de sistemas puede desarrollar un modelo de
punto flotante para la simulación con la herramienta A. Se puede usar el mismo B o
herramienta para la simulación de punto fijo. A continuación, el diseño de punto fijo (o
tal vez el diseño de punto flotante) se entrega a alguien en el código manualmente el
algoritmo en un DSP con proveedor específico C. herramienta último tal vez otro grupo
como el equipo de pruebas desarrolla una aplicación externa con la herramienta D
unidad de la DSP con comandos de prueba de entrada y los vectores de datos de prueba
y al mismo tiempo controlar la respuesta del sistema para determinar pasa / no pasa de
estado. El código DSP se debe ser equipado con un código especial para dar cabida a
estas pruebas. Una vez más que es el código por lo general no es necesario que esté
disponible en el producto final. Es de usar y tirar código en el caso general después de
la verificación se ha completado.

Esto no quiere decir que siempre se puede evitar escribir una aplicación especial para la
verificación, ni que el actual flujo de trabajo DSP diseño es completamente roto. Por lo
menos sin embargo con la combinación de RTDX y Simulink un ingeniero puede
verificar que su diseño se ejecutará en el objeto DSP TI sin esperar a que otros grupos
de software para completar su aplicación o pruebas tareas de la aplicación.
Esencialmente, usted está libre para hacer más análisis what-if y se sienten más seguros
de que su diseño será el trabajo en el producto final en una fecha anterior. Esto se
traduce en menos dolores de cabeza abajo en el desarrollo de productos de ciclo de vida.
Algunos ejemplos específicos de cómo se hace esto se muestra en detalle en los
documentos a seguir.