El diseño del equipo se acometió de manera modular. Es posible distinguir un bloque de adquisición de datos, una parte para el procesamiento de los datos y una parte para la transmisión vía Ethernet, aunque estas dos últimas están estrechamente relacionadas en el código de la aplicación. Esta delimitación permite la escalabilidad del diseño para su adaptación a otras tecnologías de acceso y protocolos; así como el uso de los módulos en otros proyectos.
Como plataforma para el diseño del hardware se empleó el Xilinx Platform Studio contenido en la versión 10.1 de Xilinx ISE Design Suite. Al utilizarse un microprocesador empotrado, se diseñó además una aplicación software en lenguaje C++. La misma fue programada y compilada enteramente en el Xilinx Platform Studio SDK (XPS-SDK).
Además de estas herramientas, se empleó la plataforma Max Plus II de la firma Altera. Dadas las facilidades que brinda su entorno de desarrollo y simulación para programar en lenguaje VHDL. Los resultados de la simulación de los componentes para la adquisición de datos que se mostrarán en el trabajo, se obtuvieron utilizando Max Plus II. Posteriormente se construyó un módulo IP en XPS donde se integraron los componentes de la adquisición de datos.
La estructura del proyecto exhibe un diseño híbrido HW-SW, donde se combinan módulos IP propios del fabricante Xilinx, un módulo IP del autor y el código fuente desarrollado en lenguaje C++. Las funciones necesarias para la adquisición de los datos se acometen a través del módulo IP exclusivamente diseñado para esto, enteramente en lenguaje VHDL.
La tecnología escogida para acometer el proyecto fue un kit de desarrollo Spartan 3 Starter Kit basado en el componente FPGA de Xilinx Spartan 3, modelo xc3s1000ft256. La capacidad de este dispositivo permite descargar la estructura del proyecto en su totalidad y aún queda un margen para implementar algunas mejoras, como las contempladas en la fase segunda.
La infraestructura HW del diseño está basada en el uso de un microprocesador MicroBlaze empotrado en un proyecto del tipo SoC desarrollado en EDK. Se configuró el acceso a memoria cache mediante el uso de los bancos de memoria SRAM contenidos en el kit de desarrollo. Se configuró el acceso a cache para instrucciones y datos tomando 8 KB para cada uno de los segmentos. El acceso a esta memoria se garantiza a través de los protocolos XCL (Xilinx Cache Link), los cuales son exclusivos para estas operaciones. Ver diagrama del proyecto en el anexo 4.
En el diagrama del proyecto se puede observar además, una memoria RAM de bloque de 16 KB (BRAM) con los buses de instrucciones y datos separados (“ilmb” y “dlmb” respectivamente), conectada esta al microprocesador siguiendo una arquitectura Harvard.
Para el control de las señales de los bancos de memoria se empleó un controlador de memoria externa multi-canal (“xps mch emc”). Sus características permiten utilizar ambos canales de la SRAM para el acceso individual a cache. La SRAM posee además una conexión al bus PLB que se destinó para el intercambio de los mensajes de señalización. En el proyecto se establecen como puertos externos al FPGA los buses de dirección y datos de la memoria externa; así como sus señales de control. Se utilizó el módulo IP “bus splitter” para limitar el tamaño del bus de datos del “xps mch emc” y hacerlo coincidir con el de la SRAM. El módulo “bus splitter” asimila a la entrada un bus de datos de 32 bits y lo secciona dando a la salida dos buses de tamaños configurables. A la salida del módulo se tiene un bus de datos de 16 bits para interactuar con la memoria SRAM externa. Las señales de control, dirección y datos, como el resto de las externas se relacionan a nivel de bit con pines específicos en el fichero system.ucf. Se observa una muestra del contenido del fichero a continuación.
### Module SRAM constraints
Net fpga_0_SRAM_Mem_A_pin<15> LOC=j3; Net fpga_0_SRAM_Mem_A_pin<14> LOC=k3; Net fpga_0_SRAM_Mem_A_pin<13> LOC=k5; Net fpga_0_SRAM_Mem_A_pin<12> LOC=l3; Net fpga_0_SRAM_Mem_DQ_pin<31> LOC=n7; Net fpga_0_SRAM_Mem_DQ_pin<30> LOC=t8; Net fpga_0_SRAM_Mem_DQ_pin<29> LOC=R6; Net fpga_0_SRAM_Mem_DQ_pin<28> LOC=T5; Net fpga_0_SRAM_Mem_OEN_pin<0> LOC=k4; Net fpga_0_SRAM_Mem_CEN_pin<1> LOC=n5; Net fpga_0_SRAM_Mem_CEN_pin<0> LOC=p7;
Net fpga_0_SRAM_Mem_WEN_pin LOC=g3;
En el diseño se destinó el banco cero de la memoria externa para guardar las instrucciones y datos del programa, así como para el espacio reservado a la cache. Luego, el banco 1 se destinó al almacenamiento temporal de los mensajes que capture el sistema durante su operación. A partir de la primera localización de memoria del banco 1 se comenzarán a almacenar los mensajes de señalización. Cada mensaje ocupa un espacio no mayor de 280 bytes, por lo que el banco de memoria externa SRAM es capaz de almacenar más de 900 mensajes al mismo tiempo, usando solo el primer octeto de cada localización de memoria. Esta capacidad resulta suficiente, si se tiene en cuenta que el flujo de datos de entrada es de 2 Mbps y el envío de datos al servidor, según requerimientos es de 100 Mbps.
El módulo “xps mch emc” tiene la posibilidad de operar con frecuencias de más de 100 Mhz y puede soportar hasta 4 bancos de memoria; por lo que se hace factible su empleo previendo un aumento de la capacidad del sistema.
Se escogió una frecuencia de 100 MHz para la señal de reloj de entrada al sistema. El procesamiento de los mensajes SS7 en determinadas funciones es complejo, luego se necesita una velocidad de cómputo considerable. Además de esto, para lograr una velocidad de transmisión de 100 Mbps en la interfaz Ethernet, es necesario una señal de reloj como la programada. Esta señal la provee el módulo de reloj “clock generator”.
El diseño requirió además de un controlador de interrupciones (“xps intc”), ya que existen dos fuentes de interrupciones: el módulo de adquisición de datos y el dispositivo Ethernet. Este controlador se conecta al bus PLB y asimila a su entrada las peticiones de interrupción antes mencionadas. Como resultado de al menos una de estas peticiones, el controlador genera una petición de interrupción al microprocesador, para lo cual envía una señal al puerto correspondiente del MicroBlaze. Se estableció como orden de prioridad mayor las solicitudes generadas por la adquisición de datos, en tanto este módulo está atendiendo un flujo de datos en tiempo real. A través de las funciones del driver del “xps intc” se conectaron las rutinas de atención de interrupciones de la adquisición de datos y del “xps ethernetlite”. Las funciones conectadas, por tanto, se ejecutarán tras detectarse su respectiva interrupción.
Fig. II.2 Esquema de interrupciones del sistema
Durante la realización de un módulo IP se puede configurar la generación de una señal de interrupción. Luego, en la entidad aparece un puerto “IP2Bus_IntrEvent” destinado para este fin. En el fichero user_logic.vhd contenido en el repositorio de módulos IP, mediante la instrucción
IP2Bus_IntrEvent <= "1";
se genera la señal de interrupción del módulo de adquisición de datos. Esta se genera cuando se detecta la activación de la señal “ready_s” indicando la entrada de un octeto completo procedente del flujo E1 monitoreado. El segmento de código siguiente (del fichero user_logic.vhd) muestra esta condición.
if clkE1'event and clkE1 = '1' then if Bus2IP_Reset = '1' then slv_reg0 <= (others => '0'); else if ready_s = '1' then
slv_reg0(0 to 7) <= octeto_s; slv_reg0(23) <= alarm_s(0); slv_reg0(31) <= LOF_alarm_s(0); case canal is when 0 => slv_reg0(8 to 15) <= "00000000"; when 1 => slv_reg0(8 to 15) <= "00000001"; … …
when others => slv_reg0(8 to 15) <= "00000000"; end case;
end if; end if;
end if;
Uno de los requerimientos del prototipo es el envío de los mensajes SS7 seleccionados hacia un servidor. Luego, otros dos periféricos empleados en el proyecto fueron el “mii to rmii” (Reduced
Media Independent Interface) y el “xps ethernetlite” para el control y la ejecución de las
transmisiones Ethernet. El módulo “mii to rmii” actúa como mediador. Está destinado a proveer una mediación entre la capa física de las redes Ethernet y los módulos IP de Xilinx que interactúan con esta tecnología, como el “opb ethernet”, “opb ethernetlite” y “plb ethernet”. Concretamente “mii to rmii” acepta las 16 señales de los módulos Ethernet e interactúa con la capa física con solo seis o siete señales de datos, con lo cual posibilita el uso del conector RJ-45 para aplicaciones con acceso a redes de datos.
El “xps ethernetlite”, permite la transmisión y recepción de tramas Ethernet. El driver de este dispositivo posee funciones que facilitan a bajo nivel la conformación de las tramas a transmitir, incluso calcula y añade el CRC automáticamente a la trama que se configura para transmitir. Este dispositivo cumple con las especificaciones del estándar 802.3 de la UIT. Posee la posibilidad de operar en modo Fast Ethernet (100 Mbps). Además puede operar en modo de interrupción o en modo DMA en transmisión o en recepción. Tiene un mecanismo de colas que permite acumular tramas para la transmisión. Este módulo se conecta al sistema a través del bus PLB.
El periférico de mayor importancia es el de adquisición de datos. Este consiste en un módulo IP diseñado exclusivamente para la toma de los datos que viajan a través de los enlaces de señalización entre las centrales telefónicas. Este es el encargado de interpretar el flujo E1 de entrada y enviar los datos al módulo de procesamiento.
Como parte del proyecto EDK existe un fichero (system.ucf) con algunas condiciones establecidas por el desarrollador. Aquí se especifican las conexiones de las señales de entrada y salida de los módulos IP con los pines del FPGA (incluyendo las señales externas). También se establecen condiciones en cuanto a tiempo en dispositivos como el “xps ethernetlite” y el “mii to rmii”. Algunas de estas condiciones, para determinados módulos IP, vienen indicadas en la hoja de datos del fabricante.
Las señales de entrada-salida de la interfaz Ethernet, que pasan a través del “mii to rmii” se conectaron a siete de los pines del conector de expansión A2 de la placa. A estos pines se puede soldar un conector RJ-45 para la conexión del prototipo a un dispositivo de red o una computadora directamente.
En cuanto a las señales relativas a la SRAM, se conectaron estas a los pines correspondientes según indica la documentación del kit de desarrollo de Spartan 3.
El mapa de direcciones de los dispositivos se muestra en la tabla 3.
Tabla II.1. Mapa de direcciones
Direcciones (Base – High) Dispositivo
0000000000-0x00003fff BRAM 0x81000000-0x8100ffff XPS Ethernetlite 0x81800000-0x8180ffff XPS INTC 0x84100000-0x841fffff SRAM (banco 0) 0x84200000-0x842fffff SRAM (banco 1) 0xcfc00000-0xcfc0ffff Adq_E1
Módulo de adquisición de datos
La entrada de datos al equipo, como se ha comentado antes, es un flujo E1 compuesto por un canal de sincronismo (canal cero) y 31 canales de datos. Cada uno de los canales transporta un octeto con información de señalización (ver figura I.1).
Para garantizar la captura de tramas E1 alineadas se programó un componente (alinea_e1) en VHDL. Este recibe directamente el flujo de entrada (señal “bits”), una señal de reloj de 2 Mbps de sincronismo con el flujo de datos (señal “clk”) y una señal de reset (señal “reset”). Como resultado de su operación genera una señal de salida para advertir que la transmisión E1 está sincronizada (señal “sync”) y una señal de alarma para notificar la pérdida de sincronismo (señal “LOF_alarm”). Se muestra un fragmento del código de programación del componente alinea_e1.
ENTITY alinea_e1 IS PORT (clk :in std_logic;
bits :in std_logic; reset :in std_logic; sync :buffer bit;
LOF_alarm :out std_logic_vector (0 to 0));
END alinea_e1;
Se utiliza en la arquitectura de “alinea_e1” una estructura Process en cuya lista de sensibilidad se incluye la señal de reloj. Aquí se evalúa cada bit de entrada con el objetivo de detectar las cadenas FR (C001 1011) y NFR (C1xx xxxx); donde “C” es un bit que porta la información para corrección
de errores (CRC-4) para multitramas de 4 o 16 tramas E1. FR y NFR son los octetos que se alternan en el canal de sincronismo de un flujo E1. Se considera que una trama está alineada si se ha detectado una secuencia del tipo FR-NFR-FR ó NFR-FR-NFR. Esto quiere decir que se necesitan tres tramas correctas, en cuanto a su canal cero, para considerar una transmisión como sincronizada. De manera análoga se considera pérdida de sincronismo cuando se detecte una secuencia distinta a las mencionadas anteriormente.
Para la detección de las cadenas FR y NFR se utilizó una máquina de estados de tipo Moore. Se utilizó una codificación para los estados al estilo one-hot-zero, la cual simplifica la lógica combinacional. La codificación empleada inicia el sistema con el primer estado en cero.
Partiendo de un estado de “no sincronismo”, el componente “alinea_e1” intenta encontrar la cadena FR. Luego de esto, dispone de un contador que indica cuando ha llegado lo que debe ser el octeto NFR y se evalúa el segundo bit del mismo. En caso de ser “1”, un contador de estados indicará la próxima vez que se encuentre la cadena FR y la trama quedará sincronizada.
Para lo anterior se evalúan los estados de la máquina en ambas transiciones de la señal de reloj (subida y caída). La señal de reloj en este caso es de 2 MHz, por lo que se garantiza un tiempo suficiente para el establecimiento de los datos en las variables y señales usadas.
En caso de detectarse pérdida de sincronismo el sistema reinicia el muestreo bit a bit de los datos de entrada, intentando encontrar las cadenas FR y NFR. Además, notifica este evento poniendo a cero la señal de sincronismo.
En cada transición de reloj, se evalúa el estado de la señal reset. Al detectarse la activación de esta señal (reset = 1) se restablecen los valores iniciales de las variables y señales necesarias, para reiniciar la operación del componente.
if ( clk='1' and clk'event) then case estado is
when H => if cont_FR>504 then cont_FR:=0; else cont_FR:=cont_FR+1;
end if;
if (cont_estados=6 and NFR='1') then sync<='1'; else sync<='0';
end if;
when A=> if reset='1' then sync<='0'; cont_FR:=0;
end if;
when others => cont_FR:=0; end case;
En el fragmento de código anterior, perteneciente al componente alinea_e1, se muestra parte del algoritmo de detección del sincronismo de las tramas E1. Este fragmento es el que sigue a continuación de la máquina de estados, cuya operación tiene lugar con la caída del pulso de reloj.
En el estado H se entra cuando se acaba de detectar una cadena FR, tras lo cual se activa el contador cont_FR, y se mantiene el mismo estado hasta que cont_FR alcanza el valor 505. Esta es la cantidad de bits que hay desde la cadena FR detectada hasta el comienzo de lo que debe ser la siguiente cadena FR. Antes, cuando el contador cont_FR alcanza el valor 250, se lee la entrada “bits” intentando detectar la cadena NFR (C1xx xxxx). Si hay un ´1´ a la entrada se pone a 1 la variable NFR. Pasados los 505 bits se vuelve a activar la máquina de estados, tras lo cual se sale del estado H. Entonces, si el octeto siguiente se corresponde con la cadena FR, obligatoriamente deberá transitarse por una serie de estados tal que un contador cont_estados tomará el valor 6. Habiéndose cumplido esta condición, en la próxima subida del reloj se detectará el valor de este contador y el de la variable NFR y se activará la señal de sincronismo sync (ver línea subrayada en el código). Como se verá a continuación, el componente adq_bits está escuchando la cadena de bits de entrada, así como la señal de reloj, pero no se activa hasta tanto no está activa la señal de sincronismo.
Luego de detectarse un estado de alineación de tramas, otro componente VHDL (“adq_bits”) se encarga de extraer los octetos de la transmisión serie. Para esto tiene en su estructura un puerto de entrada para las tramas E1, uno para la señal de reloj, un puerto para reset y uno para la señal de sincronismo. Consta además de un puerto de salida de ocho bits para los octetos, uno para la indicación de datos listos (ready) y otro para generar una señal alarma.
ENTITY adq_bits IS
PORT (clk :in std_logic; bits :in std_logic; sync :in bit;
reset :in std_logic;
octeto :out std_logic_vector (7 downto 0); canal :buffer integer range 0 to 30;
alarm :out std_logic_vector (0 to 0); ready :out bit);
END adq_bits;
En “adq_bits” existe un contador que lleva un registro de la cantidad de octetos consecutivos cuyo valor es cero (0000 0000) ó FF (1111 1111). Al llegar a un valor predeterminado, se dispara una señal de alarma indicando que existe una posible falla en la transmisión, o bien el canal en cuestión está vacío.
Este componente está constantemente recibiendo los bits de entrada al igual que “alinea_e1”. Cuando detecta la indicación de alineación, entonces comienza a extraer los octetos del flujo serie a la vez que los va relacionando con el canal que les corresponda. Los octetos válidos los pone en un puerto de salida, y pone en otro puerto el canal. Luego, pone a “1” la señal ready de salida, indicando que los datos están listos para ser tomados por la siguiente fase.
Este componente posee un contador que detecta cuando llega el canal cero del E1. Este canal no porta datos de señalización, por lo cual no es tomado en cuenta.
La señal reset, como sucede con el componente anterior, se activa y provoca que las señales y variables de “adq_bits” vayan a su estado inicial quedando el módulo preparado para reiniciar sus operaciones.
Para el funcionamiento conjunto de ambos componentes, se definió un par entidad-arquitectura de mayor jerarquía en VHDL (adq_e1_top) donde estos son instanciados. Seguidamente, la parte de declaración de los puertos, donde se observa que las entradas-salidas de la entidad son la suma de las de los componentes.
entity adq_e1_top is port(
clkE1 :in std_logic; bits :in std_logic; reset :in std_logic;
LOF_alarm :out std_logic_vector (0 to 0); octeto :out std_logic_vector (7 downto 0); canal :buffer integer range 0 to 30;
alarm :out std_logic_vector (0 to 0); ready :out bit);
end adq_e1_top;
Lo que sigue es un fragmento donde se realiza el mapeo de puertos entre los componentes y la entidad superior.
AlineaE1: alinea_e1 port map(
clk => clkE1, bits => bits, reset => reset, sync => sync_int,
LOF_alarm => LOF_alarm); AdqBits: adq_bits port map(
clk => clkE1, bits => bits, reset => reset, sync => sync_int, octeto => octeto, canal => canal, alarm => alarm,
ready => ready);
Los componentes antes descritos se programaron en VHDL utilizando la plataforma de diseño Max Plus II. Con esta herramienta se realizó además la compilación y la simulación del hardware. Para esto se seleccionó en Max Plus II el EPLD EPM3128ATC100-5 de la familia MAX 3000 de Altera. El siguiente esquema muestra la interconexión de de los componentes y sus señales de entrada-salida.
Fig. II.3 Esquema de interconexión de componentes VHDL para la adquisición de datos
Tras tener listos y simulados los componentes de la adquisición de datos, se construyó un módulo