Desarrollo de un prototipo basado en FPGA.uea2013.frbb.utn.edu.ar/wp-content/uploads/S4_1.pdfMHz)...

6
Desarrollo de un prototipo basado en FPGA. Experiencias recogidas de la reingeniería de una placa de comunicaciones Christian L. Galasso Grupo SITIC / Departamento Ing. Electrónica UTN-FRBB Servicio de Análisis Operativo, Armas y Guerra Electrónica (SIAG) – ARA – Puerto Belgrano, Argentina [email protected] Antonini, Alejandro Ariel Servicio de Análisis Operativo, Armas y Guerra Electrónica (SIAG) – ARA – Puerto Belgrano, Argentina [email protected] Guillermo Friedrich Grupo SITIC / Departamento Ing. Electrónica UTN – FRBB Bahía Blanca, Argentina [email protected] Gustavo Díaz Grupo SITIC – UTN – FRBB Bahía Blanca, Argentina [email protected] Resumen—Cuando se realiza la descripción del hardware de un prototipo mediante VHDL, se cuenta con dos herramientas para realizar la depuración. La primera es el banco de pruebas o “Testbench” en VHDL, con el que se pueden generar señales de entrada y analizar las salidas devueltas por el prototipo de forma simulada. La segunda es el analizador lógico, que permite registrar el comportamiento del dispositivo durante una prueba real. Ambos permiten efectuar una lectura de los diagramas temporales de entrada y salida del dispositivo bajo prueba (DUT: Device Under Test), y se complementan entre sí. Existen, además, cuestiones eléctricas que están ligadas a la configuración del dispositivo lógico programable, que es necesario contemplar para obtener el comportamiento deseado en las entradas y salidas del mismo. En este trabajo se presentan experiencias recogidas de un trabajo de re-ingeniería de una interfaz de comunicaciones basado en una FPGA. Palabras Clave: FPGA, Analizador Lógico, Banco de Pruebas, Diagramas Temporales , Adaptación de niveles. I. INTRODUCCIÓN El proyecto en el que se enmarca el presente trabajo tenía como objetivo desarrollar un reemplazo para las interfaces de comunicación de las computadoras del sistema automatizado de un grupo de buques. Tanto las computadoras como estas interfaces no son estándar sino de propósito específico. La interfaz en cuestión es la encargada de las comunicaciones con otras computadoras similares. Realiza una conversión de datos paralelo a serie y viceversa, utilizando para la transmisión protocolos exclusivos del fabricante. La misma tiene un software de prueba provisto por el fabricante, que permite verificar su funcionamiento haciendo un loop en su puerto serie. Se armó un banco de pruebas en el laboratorio, que permitiera investigar el funcionamiento de las interfaces originales, para luego hacer ingeniería inversa y finalmente testear los prototipos desarrollados, antes de pasar a los ensayos de campo. Del análisis, se pudo determinar que la interfaz no realiza ningún procesamiento de los datos, solo un chequeo de errores por hardware; el comportamiento de la misma es eminentemente lógico, y los tiempos de respuesta a los comandos recibidos eran muy bajos, del orden de entre 250 ns y 1 µs. Estas características determinaron que el dispositivo más conveniente para basar el desarrollo fuese una FPGA. Durante el desarrollo se observó que las cuestiones a resolver no sólo tenían que ver con el diseño de la lógica interna, sino que también debía resolverse la adaptación de niveles de tensión y que ésto tendría relación directa con la configuración de los puertos de la FPGA. II. ENTENDIENDO EL DISPOSITIVO A REPLICAR A. Diagramas temporales Figura 1. Parte de uno de los diagramas temporales de la placa a replicar. Existen generalmente, dos caminos para replicar el funcionamiento de algún dispositivo. El primero es, conociendo el diagrama esquemático y todos los componentes IV Congreso Microelectrónica Aplicada (uEA 2013) 59 Universidad Tecnológica Nacional - Facultad Regional Bahía Blanca RED_UIE

Transcript of Desarrollo de un prototipo basado en FPGA.uea2013.frbb.utn.edu.ar/wp-content/uploads/S4_1.pdfMHz)...

Desarrollo de un prototipo basado en FPGA.Experiencias recogidas de la reingeniería de una placa de comunicaciones

Christian L. GalassoGrupo SITIC / Departamento Ing. Electrónica UTN-FRBB

Servicio de Análisis Operativo, Armas y GuerraElectrónica (SIAG) – ARA – Puerto Belgrano, Argentina

[email protected]

Antonini, Alejandro ArielServicio de Análisis Operativo, Armas y Guerra Electrónica

(SIAG) – ARA – Puerto Belgrano, [email protected]

Guillermo Friedrich Grupo SITIC / Departamento Ing. Electrónica UTN – FRBB

Bahía Blanca, [email protected]

Gustavo DíazGrupo SITIC – UTN – FRBB

Bahía Blanca, [email protected]

Resumen—Cuando se realiza la descripción del hardware de unprototipo mediante VHDL, se cuenta con dos herramientas pararealizar la depuración. La primera es el banco de pruebas o“Testbench” en VHDL, con el que se pueden generar señales deentrada y analizar las salidas devueltas por el prototipo de formasimulada. La segunda es el analizador lógico, que permiteregistrar el comportamiento del dispositivo durante una pruebareal. Ambos permiten efectuar una lectura de los diagramastemporales de entrada y salida del dispositivo bajo prueba (DUT:Device Under Test), y se complementan entre sí. Existen, además,cuestiones eléctricas que están ligadas a la configuración deldispositivo lógico programable, que es necesario contemplar paraobtener el comportamiento deseado en las entradas y salidas delmismo. En este trabajo se presentan experiencias recogidas de untrabajo de re-ingeniería de una interfaz de comunicacionesbasado en una FPGA.

Palabras Clave: FPGA, Analizador Lógico, Banco de Pruebas,Diagramas Temporales , Adaptación de niveles.

I. INTRODUCCIÓN

El proyecto en el que se enmarca el presente trabajo teníacomo objetivo desarrollar un reemplazo para las interfaces decomunicación de las computadoras del sistema automatizadode un grupo de buques. Tanto las computadoras como estasinterfaces no son estándar sino de propósito específico. Lainterfaz en cuestión es la encargada de las comunicaciones conotras computadoras similares. Realiza una conversión de datosparalelo a serie y viceversa, utilizando para la transmisiónprotocolos exclusivos del fabricante. La misma tiene unsoftware de prueba provisto por el fabricante, que permiteverificar su funcionamiento haciendo un loop en su puertoserie. Se armó un banco de pruebas en el laboratorio, quepermitiera investigar el funcionamiento de las interfacesoriginales, para luego hacer ingeniería inversa y finalmentetestear los prototipos desarrollados, antes de pasar a losensayos de campo.

Del análisis, se pudo determinar que la interfaz no realizaningún procesamiento de los datos, solo un chequeo de errorespor hardware; el comportamiento de la misma eseminentemente lógico, y los tiempos de respuesta a los

comandos recibidos eran muy bajos, del orden de entre 250 nsy 1 µs. Estas características determinaron que el dispositivomás conveniente para basar el desarrollo fuese una FPGA.

Durante el desarrollo se observó que las cuestiones aresolver no sólo tenían que ver con el diseño de la lógicainterna, sino que también debía resolverse la adaptación deniveles de tensión y que ésto tendría relación directa con laconfiguración de los puertos de la FPGA.

II. ENTENDIENDO EL DISPOSITIVO A REPLICAR

A. Diagramas temporales

Figura 1. Parte de uno de los diagramas temporales de la placa a replicar.

Existen generalmente, dos caminos para replicar elfuncionamiento de algún dispositivo. El primero es,conociendo el diagrama esquemático y todos los componentes

IV Congreso Microelectrónica Aplicada (uEA 2013) 59

Universidad Tecnológica Nacional - Facultad Regional Bahía Blanca RED_UIE

(o sus reemplazos, dado que la placa en cuestión tiene más de30 años), hacer un circuito igual. El segundo es, lograrentender la lógica de funcionamiento y replicar elcomportamiento. Este último fue el camino escogido.

Para entender la lógica de funcionamiento de un dispositivoelectrónico es de suma utilidad contar con los diagramastemporales completos. Mediante ellos se pueden conocer lasdiferentes respuestas del sistema frente a las distintas entradas(su protocolo). Se contaba inicialmente con dos diagramastemporales de una transmisión de datos, provistos por elfabricante, y uno de ellos (Fig. 1) muestra cuando la placa pasadel estado “desarmada” a “armada” y viceversa. Sin embargo,los mismos eran muy escuetos y no cubrían todo el abanico deoperaciones de la interfaz, como así tampoco todas las señalesinvolucradas.

B. Capturas

Debido a que la descripción que se tenía era insuficientepara poder explicar el funcionamiento de la placa, de forma talde poder reproducir el mismo, se armó un banco de pruebasdonde pudiera ejecutarse el test que prueba todas lasfuncionalidades de la misma y pudieran realizarse capturasmediante un analizador lógico Tektronik TLA5202B (Fig. 3).Se construyeron para tal fin unas placas de extensión (Fig. 2)que permitieran identificar, de manera inequívoca, cada uno delos 77 pines (dato + control) de la placa.

Figura 2. Una de las placas de extensión diseñadas para poder conectar elanalizador de manera inequívoca.

Dado que el número de pines de la placa era superior a lacantidad de canales del analizador (68 canales), se buscaronaquellos que transportaban información correspondiente alprotocolo. Se tomaron todas las señales de control, todos lospines del puerto serie y la parte superior del puerto paralelo deentrada y de salida.

El test completo dura alrededor de tres minutos, pero elanalizador lógico solo puede almacenar 500 milisegundoscomo máximo. Esta limitación hizo necesaria unaidentificación de las diferentes subrutinas que componían eltest y de las señales más convenientes para disparar (trigger)cada captura. Se obtuvieron de esta forma las capturasindividuales de cada una de las partes del test. Con los datos

obtenidos se elaboraron dos nuevos diagramas temporalescompletos, mediante los cuales se comenzó a dilucidar elcomportamiento lógico de la placa. Cabe aclarar que, si bienpodría haberse utilizado algún software que tomara los datosdel analizador (dado que el mismo provee los datos de lascapturas tanto en formato propio como en formato texto) e irreconstruyendo el diagrama temporal completo de formadigitalizada, se consideró más productivo hacerlomanualmente, a fin de poder ir verificando cada una de lascapturas, para luego volcar las partes donde podía apreciarse lainteracción placa-procesador.

Figura 3. En primer plano el analizador lógico conectado al bus de lacomputadora para realizar las capturas. En el fondo, el banco de pruebas.

El trabajo de confección de los diagramas permitió entendergran parte de la lógica interna de la placa. Se pusieron tambiénal descubierto los cortos tiempos de reacción ante lasinstrucciones recibidas (250 ns a 1 µs). Esta fue una de lasrazones que motivó el desarrollo del prototipo sobre una FPGAen vez de un microcontrolador, dado que para ejecutarsubrutinas en los mismos se habría requerido una excesivacapacidad de cálculo.

III. LA DESCRIPCIÓN EN VHDL

A. Escribiendo y describiendo

Finalizados los diagramas, se comenzó con la descripciónen VHDL. Inicialmente se tomó como base la división modulardel fabricante (dado que se poseía un diagrama en bloques dela placa), la cuál, salvo ciertas diferencias, fue seguida hasta elfinal. No se realizó una replica exacta; algunos módulos fueronsuprimidos y/o absorbidos por otros, y se agregaron otrosnuevos para añadirle mejoras en cuanto a la detección de fallasy dejar abierta la puerta para agregar otra interfaz decomunicación (que permita la comunicación con otrascomputadoras modernas).

Los módulos se fueron escribiendo y probando medianteTestbench en VHDL. Sólo se dejaron sin testear tres módulos,que por su complejidad y gran cantidad de E/S, resultaba mássencillo y rápido hacerlo con el conjunto completo en lugar dehacerlo individualmente. Se hizo un diseño con un resetasincrónico y con un sólo reloj global, el de más alta frecuencia(4 MHz). Si bien la FPGA utilizada tiene la capacidad demanejar ocho dominios de reloj, la segunda señal de reloj (1

IV Congreso Microelectrónica Aplicada (uEA 2013) 60

Universidad Tecnológica Nacional - Facultad Regional Bahía Blanca RED_UIE

MHz) proveniente del puerto serie se utilizó como clockenable. Así, el registro desplazamiento de salida, encargado detransmitir las palabras por el puerto serie a razón de 1 Mb/squedó descripto de la siguiente manera:

proc_registro_desplazamiento: Process (reset, mc2d, s_load, fmc_1mhz, datos_u24, sp, s_registro26bit) begin

if reset = '0' then

s_registro26bit <= (others => '1'); dato_serie <= '1';

elsif mc2d' event and mc2d = '1' then if s_load = '0' then

s_registro26bit (1) <= sp;--Last Bit s_registro26bit (25 downto 2)<= not (datos_u24);--datos s_registro26bit (26) <= '0';--bit de start

elsif fmc_1mhz='1' then

s_registro26bit <= s_registro26bit (25 downto 1)& '1'; dato_serie <= s_registro26bit (26);

end if; end if; end process;

Obteniéndose de la síntesis del mismo, para el dato serie desalida, la lógica que se ve en la Fig. 4.

Figura 4. El Flip Flop que maneja la salida serie de los datos almacenadosen el registro desplazamiento

La señal “fmc_1mhz” es un pulso de 250 ns que se pone en'1' cuando se detecta el flanco ascendente del reloj provenientedel puerto serie, la misma quedó al describir el VHDL de estaforma, como un clock enable de la lógica. El bit 26 del registroestá conectado al pin “D” de la Figura, “fmc_1mhz” al “CE” y“mc2d” al reloj “C” del Flip Flop (Fig. 4) dado que es el relojglobal del sistema. La salida del dato serie se obtiene de “Q” yel reset asincrónico va al pin de reset.

B. Test bechs y depuración

La mayoría de los módulos se probaron antes de armar laestructura que los contuviera a todos. Esto se hizo mediantebancos de pruebas individuales, que se diseñaron basados enel comportamiento que podía inferirse de los diagramas de

señales y en algunas descripciones del fabricante. Luego decompletar el primer prototipo en VHDL, se comenzó porreplicar en los Testbench las secuencias completas de cada unade las subrutinas del programa de prueba. Para ello seanalizaron una a una las capturas y sus respectivostemporizados, para generar la misma señalización que produceel procesador cuando dialoga con la placa.

Se reprodujeron siete de las diez subrutinas que componenel test. Y desde la primera (que era simplemente un reset porsoftware de la placa, de 100 ms de duración) se encontraronerrores, como la falta de generación de señales o señales en unestado incorrecto. Una gran ventaja de los bancos de prueba enVHDL radica en la posibilidad de conocer no solo el estado delas entradas y salidas (como ocurre cuando conectamos unanalizador lógico a la placa), sino el de cada uno de los flip-flops que conforman la lógica interna del diseño, en cadainstante de tiempo. Esto fue tan complicado como útil, dadoque, cuando se encontraba un comportamiento incorrecto (unaseñal ausente o presente en un momento incorrecto) serevisaba la señalización, desde el módulo que genera la señalcon error; y siguiendo hacia atrás, verificando las señales queingresaban al mismo y pudiendo revisar aún las señalesinternas y externas de los módulos con los que interactúa elmódulo en cuestión. De esta forma resultaba factiblediscriminar si el módulo estaba mal diagramado, o bien no leestaban llegando las señales necesarias para pasar al estadocorrecto.

El primer prototipo fue simplemente una placa adaptadorade los puertos paralelos y serie, conectada al kit de desarrolloque se estaba utilizando. Al llegar a la séptima subrutina deltest, se completó el armado del mismo y se prosiguió con lasíntesis del VHDL sobre el kit. Se continuó montando elprototipo en la computadora y capturando el resultado de laejecución del test con el analizador lógico.

C. Análisis, captura y simulación

En esta nueva etapa de prueba se realizó una interacciónanalizador-simulador (Fig. 5). Durante la ejecución del test seidentificaba la rutina donde el prototipo fallaba. Luego,mediante el analizador se capturaron dichas situaciones yfinalmente se replicaron las señalizaciones en un Test Bench.En la figura superior se ve la imagen de una captura con elanalizador lógico. En la figura inferior la simulación medianteISIM[1,2]. Este procedimiento tuvo un elevado índice deaciertos. Prácticamente todos los errores capturados con elanalizador pudieron luego ser reproducidos en la simulación.Así fue posible identificar de manera inequívoca él o losmódulos internos que presentaban errores en su lógica,corregir el VHDL y obtener finalmente el comportamientodeseado del conjunto.

IV. PRUEBAS DE ADAPTACIÓN DEL PUERTO PARALELO

A. Cambios en la configuración de los puertos de salida por el tipo de adaptación

Durante las primeras pruebas del prototipo, no sólo, nofuncionó la placa en desarrollo, sino que, mientras estabaconectada no permitía que la computadora completa funcione,impidiendo la carga del sistema operativo.

IV Congreso Microelectrónica Aplicada (uEA 2013) 61

Universidad Tecnológica Nacional - Facultad Regional Bahía Blanca RED_UIE

Figura 5. En la figura superior se ve la imagen de una captura con el analizador lógico. En la figura inferior la simulación mediante ISIM[1,2].

Se realizaron capturas sobre el bus durante la carga delsistema operativo, para observar lo que estaba ocurriendo.Para tener un punto de referencia se hicieron mediciones delbus con la placa original colocada. La señalización obtenidade las capturas del prototipo era errática y sin lógica alguna,totalmente distinta a la observada con la placa original, dondehabía una secuencia de diálogo entre dispositivos, biendefinida y ordenada.

Entre las distintas pruebas que se realizaron se volvía asintetizar el VHDL sobre la FPGA. En una oportunidad seintentó realizar la carga del sistema operativo mientras seconfiguraba la FPGA. En esta circunstancia, la carga delsistema operativo se completó sin problemas. Revisando lahoja de datos de la FPGA, se encontró que durante el procesode configuración la FPGA coloca todas sus E/S en alta

impedancia. En el diseño, cuando la configuración terminaba,la lógica indicaba poner todas las salidas a '1', dado que el busal cual estaba conectada la placa es colector abierto, con loque el estado de reposo es alto. Se realizaron modificacionesen el VHDL para que mientras la placa, no tiene que dialogarcon el bus, el estado lógico de la salida sea 'Z' en vez de '1'.Esta modificación permitió que se realice la carga del sistemaoperativo con normalidad y que el prototipo empezara adialogar con el procesador. El motivo de que haya sidonecesario efectuar esta modificación es la manera en quetrabaja el dispositivo de adaptación de niveles de tensiónutilizado, GTL2000 (Fig. 6).

Como puede observarse en la Fig. 6, si se coloca un '0'lógico en el dispositivo del lado 'A' del GTL2000, se forzará elmismo estado del lado 'B', siempre y cuando el transistor del

IV Congreso Microelectrónica Aplicada (uEA 2013) 62

Universidad Tecnológica Nacional - Facultad Regional Bahía Blanca RED_UIE

puerto de la FPGA pueda absorber la corriente provista por laRpu(B) y la Rpu(A). Esto es correcto y deseable; elinconveniente surge si se coloca un '1' lógico del lado 'A', eldispositivo que se encuentre del lado 'B' que quiera poner un '0'se encontrará con que tiene que absorber la corriente provistapor la Rpu(B) (para lo cuál está calculado) más la corrienteentregada por Rpu(A). Si a ésto se le suma que puede habervarias de estas placas conectadas al bus, el problema aumenta.En el caso de que el puerto de la FPGA este configurado comosalida tres estados (un ejemplo de la misma puede verse en laFig. 7), como había sido configurado, en vez de drenadorabierto con resistencia de pull-up, cuando el transistor superiorse sature para entregar un '1' lógico, conectará la fuente dealimentación de 3.3 V al pin de salida. Así, será prácticamenteimposible que algún dispositivo del lado 'B' (como el de cargadel sistema operativo en este caso) pueda mandar a '0' algunade las líneas del bus, impidiendo de esta forma el diálogo através del mismo.

Figura 6. Conexionado GTL20xx o NVT20xx, dispositivo de adaptación deniveles de tensión con salida drenador abierto.

A continuación se muestra el código VHDL de la solución.Se habilitan las salidas cuando se quiere escribir en el bus y selas coloca en ´Z´ cuando no se dialoga con el mismo. Se utilizópara tal fin la señal “S_EN” provista por una placa que hace lasveces de controlador de interrupciones y que se pone a '0'cuando habilita la escritura en el bus.

---------SALIDAS PUERTO PARALELO---------with S_EN selecti24xdata <= S_DATOS_I when '0', "ZZZZZZZZZZZZZZZZZZZZZZZZ" when others;with S_EN selectidrp <= S_IDR when '0', 'Z' when others;with S_EN selecteip <= S_EI when '0', 'Z' when others;with S_EN selecto6xda <= S_DA_O when '0', "ZZZZZZ" when others;

with S_EN selectodrp <= S_ODR when '0', 'Z' when others;

El principal problema del GTL2000 es que no aumenta lacapacidad de corriente del dispositivo que tiene detrás, es más,puede que el dispositivo que adapte maneje corrientesnominales mayores a 16 mA (la FPGA que se utilizó, Spartan3AN, puede manejar, con ciertas limitaciones [6], hasta 24 mApor pin, pero el GTL2000 solo garantiza un '0' lógico cuando lacorriente que drena el mismo es inferior a este valor. Para elcaso en estudio, las resistencias de pull-up del puerto paralelode salida son de 270 Ω, con lo que la corriente nominal es de18,5 mA, aproximadamente. Se pensó entonces, en otrasolución a la adaptación de niveles de la salida (ya que para laentrada no había inconveniente con el GTL2000), para ellodebieron tenerse en cuenta ciertas consideraciones eléctricas.

B. Soluciones de traslación de niveles existentes [3]

• Dispositivos de doble fuente: esta es la mejor elecciónpara la mayoría de las aplicaciones de traslación deniveles. Estos dispositivos pueden operar de manerabidireccional en una gran variedad de niveles devoltaje. Ofrecen bajo consumo de potencia ypequeños retardos de propagación.

• Dispositivos drenador abierto: pueden utilizarse parasubir o bajar los niveles de voltaje, por medio del usode un resistor de pullup externo. Esta solución es muyflexible, pero no es tan eficiente dado que consumenmayor potencia.

• Dispositivos con entradas que soportan sobrevoltajes:proveen una muy sencilla opción para bajar niveles detensión. Si la señal de entrada tiene flancosascendentes y descendentes lentos el ciclo de trabajode la señal de salida puede verse afectado.

• Dispositivos CB3T: son switches FET, ideales paratraslaciones de 5 V a 2.5 V, 5 V a 3.3 V y 3.3 V a 2.5V. No proveen amplificación de corriente, debiendoutilizarse una salida con buffer en caso de sernecesario.

• Dispositivos CBT/CBTD: son utilizados paratraslaciones de 5 V a 3.3 V. Ofrecen tiempos depropagación reducidos y bajos consumos de potencia.No proveen amplificación de corriente, debiendoutilizarse una salida con buffer en caso de sernecesario.

• Dispositivos TVC: permiten una traslación de nivelesbidireccional sin la necesidad de una señal de controlde dirección. Esta solución requiere el uso deresistores externos de pull-up. El consumo dependerádel valor de dicha resistencia. Un dispositivo CBTpuede ser configurado para trabajar como un TVC.

• Dispositivos con entradas compatibles con TTL: losdispositivos de las familias HCT, AHCT, ACT, ABT,y FCT pueden ser utilizados para realizar la traslación3.3 V a 5 V (traslación ascendente únicamente). Estasolución provoca un exceso en el consumo de energíay se debe evitar en aplicaciones donde el consumo seaun factor importante.

IV Congreso Microelectrónica Aplicada (uEA 2013) 63

Universidad Tecnológica Nacional - Facultad Regional Bahía Blanca RED_UIE

C. Consideraciones eléctricas de la adaptación

Cuando se dialoga con un bus colector abierto esconveniente usar dispositivos de salida del tipo drenadorabierto, para una mejor compatibilidad eléctrica. Este fue unode los motivos de la elección del GTL2000. El otro fue la grancantidad de pines de adaptación (hasta 22 E/S por circuitointegrado). Según una nota de aplicación [3] de TI, para lograruna traducción de niveles de tensión no se debe usar unaresistencia de pull-up en los dispositivos con salida CMOS(push-pull es la salida típica de los dispositivos con salida 3estados). Esta técnica tiene varios defectos y debe ser evitada.El primer problema es el incremento de consumo de energíacuando la salida pasa a estado bajo. Otro problema se producecuando la salida del driver CMOS está en estado alto: eltransistor inferior de canal N está en corte y el superior decanal P está en saturación. Hay un flujo de retorno de corrientedesde la fuente de alta hacia la fuente de baja a través de laresistencia R y la parte superior del transistor de canal P. Esteflujo de corriente en la fuente de baja podría causar efectosindeseables (Fig. 7).

Figura 7. Conexionado de una salida 'Z' alimentada por 3,3V a un buscolector abierto alimentado por 5V.

Se decidió reemplazar Los GTL2000 que adaptaban lasalida por el buffer 74LVC07A[4]. Su salida es drenadorabierto y tiene un dispositivo de su familia con rango detemperatura extendido (deseable para la aplicación final).Además, podía manejar '0' lógicos bién definidos drenandocorrientes de hasta 24 [mA].

D. Cambios en la configuración de los puertos de salida por el nuevo tipo de adaptación

Las primeras pruebas con el nuevo prototipo, construidocon los pines de salida adaptados mediante el buffer74LVC07A (Fig. 8) en reemplazo del GTL2000, fallaron. Enesta ocasión, no podía dejarse en la línea de entrada del bufferun estado indefinido como se hacía cuando la adaptación de lassalidas era mediante los GTL2000, sino que debía colocarse un'0' o un '1' lógico según correspondiese. Se cambió en el VHDLdel diseño la asignación de 'Z' a la salida por '1'. Luego de locuál el funcionamiento fue correcto. Según el reporte deaplicación [5], cuando se utiliza como entrada desde un busTTL, el 74LVC07A debe alimentarse con VCC=5V para queinterprete dichos niveles lógicos en su entrada, mientras que,de ser necesario, a la salida puede ponerse un pull-up a valoresde tensión tan bajos como 1.8V (3.3V para este caso). A lahora de ser colocados a la salida del prototipo debió conectarsela alimentación del mismo a 3,3V con sus salidas conectadasmediante un pull-up a 5V.

Figura 8. Conexionado de una salida 'Z' alimentada por 3,3V a un buscolector abierto alimentado por 5V.

V. CONCLUSIONES

El hecho de contar con las simulaciones permitióaprovechar los tiempos ociosos que siempre aparecen cuandose diseña hardware: la compra de materiales (dos a tressemanas) y la fabricación de los PCBs (ídem).

La realización de diagramas de señales y de estados (en elcaso de las máquinas de estado) permitió encontrar los errorescon relativa facilidad. El prototipo en cuestión tenía variaspartes que realizaban acciones simultáneas y los planospermitieron ver fotografías de los estados de las partesconstitutivas en los distintos momentos

Reproducir los errores capturados en las simulaciones esun camino óptimo para la resolución de problemas en lalógica.

El dispositivo de traslación de niveles que se elijadependerá principalmente del tipo de bus al que se va aconectar, pero también de otras cuestiones, como niveles detensión a adaptar, corriente y velocidad a manejar, si debe seruni o bidireccional y el rango de temperatura de losdispositivos de la familia. El tipo de dispositivo tendrá directainferencia en la configuración de los puertos de la FPGA.

AGRADECIMIENTOS

A la memoria de un profesor, amigo y quién fuera elDirector del proyecto; incansable investigador y buscador de laexcelencia, Mg. Omar Alimenti. Al Director de Mrk Industries,Marcos Chaparro, brillante ex-alumno y aún más brillanteamigo, que lejos del egoísmo intelectual, gusta de compartirmuchos de sus avances y ha sido una gran ayuda para cumplircon los tiempos propuestos. Al Ing. Sergio Burgos, proactivobuscador de soluciones y recursos para alcanzar las metaspropuestas.

REFERENCIAS

[1] http://www.xilinx.com/tools/isim.htm

[2] UG660 (v14.1) – ISim User Guide – April 24, 2012.

[3] Texas Instruments – Application Report SCEA035A – June 2004:Selecting the Right Level-Translation Solution.

[4] scdd003a.pdf -Signal Switch including digital-analog-bilateral switchesand voltage clamps – pp 1164.

[5] SCED0006-Logic Selection Guide – pp30

[6] DS557 (v4.1). Spartan-3 – Spartan-3AN FPGA Family Data Sheet -Product Specification. “Simultaneously Switching Output Guidelines”.April 1, 2011, pp 43.

IV Congreso Microelectrónica Aplicada (uEA 2013) 64

Universidad Tecnológica Nacional - Facultad Regional Bahía Blanca RED_UIE