Câmara em Rede com tecnologia FPGA

Transcrição

1 Câmara em Rede com tecnologia FPGA Tiago Filipe Abreu Moura Guedes Dissertação para obtenção do Grau de Mestre em Engenharia Electrotécnica e de Computadores Júri Presidente: Orientador: Co-Orientador: Vogais: Prof. Doutor Mário Serafim dos Santos Nunes Prof. Doutor Horácio Cláudio de Campos Neto Prof. Doutor Mário P. Véstias Prof. Doutor Carlos Manuel Ribeiro Almeida Novembro de 2007

2 2

3 3

4 Agradecimentos Um trabalho desta envergadura não pode ser conseguido sem o apoio importante das pessoas envolvidas no trabalho como também do círculo de pessoas de índole pessoal. Desejo agradecer ao Professor Orientador Horácio Neto e ao Professor Co-Orientador Mário Véstias pelo apoio prestado na elaboração deste trabalho, pela sua paciência e dedicação revelada. Também desejo agradecer ao Mestre José Germano do Grupo SIPS do INESC-ID, pelo apoio prestado relativamente ao módulo de interacção com a câmera digital. Desejo mostrar a minha gratidão à minha namorada e à minha família pela compreensão e apoio dado no decorrer deste trabalho. I

5 II

6 Resumo Este documento descreve os passos do desenvolvimento e implementação de um sistema que integra um Servidor Web executando sobre um processador embebido e hardware reconfigurável em específico uma FPGA. O servidor de páginas Web integra as imagens recebidas de uma câmara digital ligada ao sistema. Para mostrar a funcionalidade e as potencialidades do sistema desenvolvido, foram incluídas no projecto funcionalidades de processamento de imagem para enfatizar estes dois aspectos. A implementação deste sistema é dividida em duas áreas relacionadas entre si hardware e software na medida em que o software executa sobre o hardware desenvolvido. O projecto de hardware prende-se essencialmente com o desenvolvimento da lógica a implementar na FPGA. Esta vertente do desenvolvimento do projecto é organizada em módulos lógicos denominados IP Cores que facilitam a conceptualização do projecto. O projecto de software compreende a aplicação do servidor Web. Esta aplicação assenta sobre um sistema operativo de modo a existir pseudo-paralelismo e mecanismos de sincronização entre processos bem como comunicação por sockets. O sistema foi desenvolvido na placa ML403 da Xilinx que inclui uma FPGA Virtex-4 FX com um processador embebido PowerPC 405. O ambiente de desenvolvimento com o qual foi projectado o sistema hardware/software é o EDK do fabricante (Xilinx). Palavras-chave Hardware Reconfigurável; FPGA; Sistemas Embebidos; Servidor Web; Processamento de Imagem; III

7 IV

8 Abstract This document describes the development and implementation of a system which integrates a Web Server running on an embedded processor and on reconfigurable hardware - specifically a FPGA. The server of Web pages integrates the images received from a digital camera which is connected to the system. In order to show the functionality and the potential of the developed system, specific functionalities for image processing have been included in the project to emphasize these two aspects. The implementation of this system is divided in two components related between themselves - the hardware and software so that the software runs on the developed hardware. The hardware design is essentially related with the development of the logic implemented in the FPGA. The system has been organized in logical modules called IP Cores that facilitated the project s conceptualization. The project of the software part includes the application of the Web server. This application must seat on an operative system in order to explore pseudo-parallelism and mechanisms of synchronization between processes as well as socket communication. The system was developed using the development board ML403 of Xilinx that contains a FPGA Virtex-4 FX with an embedded PowerPC 405 processor. The hardware/software system has been developed using the design environment provided by the FPGA manufacturer (Xilinx). Keywords Reconfigurable Hardware; FPGA; Embedded Systems; Web Server; Image Processing; V

9 VI

10 Índice 1. Introdução Sistemas Embebidos Lógica programável - FPGA s Especificação do Sistema EDK FPGA s e a Virtex-4 FX Field Programmable Gate Array (FPGA) Virtex-4 FX Processador PowerPC 405 Embebido Módulo de interacção com a câmara Software Kernel Embebido Xilkernel Implementação do Sistema Hardware Módulo de interacção com a câmara Software Sistema Operativo e Sistema de Ficheiros Servidor Web Captura de imagem Desempenho e utilização de recursos Funcionalidades e Manual do Servidor Web Conclusões e Trabalho Futuro...67 Referências...69 VII

11 VIII

12 Lista de figuras Figura 1 Esquema Global do Sistema...3 Figura 2 Câmara Omnivision OV9650FSL...5 Figura 3 Virtex-4 FX...8 Figura 4 Relação entre arquitecturas PowerPC [8]...10 Figura 5 Organização do PPC Figura 6 Gestão de Memória do PPC Figura 7 Esquema do módulo original de interacção com a câmara...13 Figura 8 Ciclo de Leitura do protocolo SCCB [12]...13 Figura 9 Ciclo de Escrita do protocolo SCCB [12]...13 Figura 10 Diagrama de blocos do Módulo original de interface com a Câmara...14 Figura 11 Estrutura dos blocos de memória do Módulo VHDL do SIPS...15 Figura 12 Fluxograma do algoritmo de escrita nas memórias do Core VHDL...16 Figura 13 - Fluxograma do algoritmo de leitura das memórias do Core VHDL...16 Figura 14- Organização do XMK...17 Figura 15 Organização do Xilkernel em Módulos...19 Figura 16 Escalonamento orientado a Prioridades...20 Figura 17 Estados de Contexto de Processos...21 Figura 18- Diagrama de blocos do design do sistema do Web Server...24 Figura 19 Legenda do Diagrama de Blocos do sistema...24 Figura 20 Diagrama de blocos do IP Core PLB DDR...27 Figura 21 - Diagrama de Blocos de Alto nível do Core PLB EMC...29 Figura 22 Diagrama do IP Core PLB EMAC...30 Figura 23 Diagrama de Blocos do IP Core JTAGPPC_CNTLR...31 Figura 24 Diagrama do PLB Interconnect...33 Figura 25 Diagrama de Blocos do IP Core PLB v Figura 26 - Diagrama de Blocos de alto nível do módulo OPB Arbiter...35 Figura 27 - Diagrama de Blocos do IP Core PLB to OPB Bridge...37 Figura 28 - Diagrama de blocos do IP Core Interrupt Controller v1.00c...38 Figura 29 - IP Core s auxiliares utilizados...39 Figura 30 - Diagrama de blocos do Core Processor System Reset Module...40 Figura 31 Cenário de implementação do Core Utility Vector Logic...41 Figura 32 Operação executada pelas Instâncias do Core Utility Vector Logic...41 Figura 33- Diagramas do IP Core Utility Bus Split...41 Figura 34 Diagrama de Blocos do IP Core DCM Module...42 Figura 35 Diagrama do Controlador PLB BRAM...44 Figura 36 Diagrama de Blocos ilustrativa da inclusão da Câmara no Servidor Web..46 Figura 37 Diagrama de blocos do IP Core OPB IPIF...46 Figura 38 Cenário de utilização do IP Core IPIC...47 Figura 39 Diagrama de Blocos do IP Core IPIF associado ao IP FIFO BRIDGE...47 Figura 40 Algoritmo de inserção de um elemento na FIFO do IP Core FIFO BRIDGE...48 Figura 41 Formato dos dados da FIFO do IP FIFO BRIDGE...48 Figura 42 Esquema do conector físico do SIPS...49 Figura 43 Fluxo de Execução do Software...50 Figura 44 Fluxo de execução da aplicação do WebServer...53 Figura 45 Algoritmo relativo ao software de captação de imagem...56 Figura 46- Formato do ficheiro BMP...57 Figura 47 Imagem exemplo da câmara em tons de cizento...57 IX

13 Figura 48 - Imagem exemplo da câmara em tons de verde...57 Figura 49 Esquema do algoritmo de Filtro de Média...58 Figura 50 Imagem de background sem perturbações...60 Figura 51 Imagem apresentada no modo detector (ausência de perturbações)...60 Figura 52 Imagem apresentada no modo detector com perturbações...60 Figura 53 - Página HTML principal (index.html) do Web Server...65 Figura 54 - Página HTML de notificação de ficheiro não encontrado (404.html)...66 X

14 Lista de tabelas Tabela 1 Características de algumas FPGA s do Grupo Virtex-4 [1]...9 Tabela 2 - Relação entre dispositivos físicos e IP Core s...25 Tabela 3 Configuração UART para RS Tabela 4 Parâmetros de Implementação do IP Core PLB DDR...28 Tabela 5 Parâmetros de implementação do Core PLB EMC...29 Tabela 6 Parâmetros de implementação do Core PLB EMAC...31 Tabela 7 - Parâmetros de Implementação do Core PLB v Tabela 8 - parâmetros de implementação do Core OPB v Tabela 9 Parâmetros de Implementação do Core PLB to OPB Bridge...37 Tabela 10 Parâmetros da instância do Core Interrupt Controller v1.00c...39 Tabela 11 Parâmetro da Instância do IP Core Processor System Reset Module...40 Tabela 12 Parâmetros da Instância do Core Utility Bus Split...42 Tabela 13 Valores dos parâmetros de implementação da Instância 1 DCM...43 Tabela 14 Valores dos parâmetros de implementação da Instância 2 DCM...43 Tabela 15 - Alguns componentes do design do Web Server...45 Tabela 16 Associação dos sinais de interacção com a câmara a pinos...49 Tabela 17 Parâmetros de implementação do Kernel Embebido Xilkernel...51 Tabela 18 Parâmetros de implementação da biblioteca LwIP...54 Tabela 19 Utilização dos recursos por instância de IP Core...61 Tabela 20 Utilização dos recursos da FPGA...62 Tabela 21 Frequência máxima de trabalho de algumas instâncias...62 Tabela 22 Frequências de trabalho e utilização das memórias...62 Tabela 23 Ocupação das memórias físicas...63 XI

15 XII

16 Lista de siglas BSP - (Standalone) Board Support Package CAS - Column Address Strobe/Select CLB Configurable Logic Block DDR Double Data Rate (SDRAM) ECC Error Correction Code EDK - Embedded Development Kit FPGA Field Programmable Gate Array GPIO General Purpose Input Output HTTP HyperText Transfer Protocol I/O - Input/Output IP Intellectual Property IPC - InterProcess Communication JTAG - Joint Test Action Group LUT - Look-up table MFS Memory File System OPB On-Chip Peripheral Bus PLB Processor Local Bus PPC - PowerPC QVGA Quarter Graphics Array SCCB - Serial Camera Control Bus SDK (Platform Studio) Software Development Kit SDRAM - Synchronous Dynamic Random Access Memory SRAM Static Random Memory UART - Universal Asynchronous Receiver Transmitter VHDL VHSIC Hardware Description Language VHSIC - Very High Speed Integrated Circuit XMK Xilinx MicroKernel XIII

17

18 1. Introdução Com o ritmo do avanço da tecnologia no domínio dos sistemas embebidos e hardware reconfigurável, que temos vindo a observar nos últimos anos, a capacidade de desenvolver sistemas complexos hardware/software numa FPGA 1 tem aumentado muito significativamente tornando possível a sua utilização em inúmeras aplicações. Neste trabalho implementou-se um servidor de páginas HTML que integram imagem de uma câmara digital. Este trabalho tem a particularidade de ser desenvolvido num sistema embebido, que tem como componentes principais hardware reconfigurável e um processador embebido. Nas secções seguintes, apresenta-se um enquadramento relativo aos conceitos mais relevantes relacionados com este projecto, sendo a última secção dedicada à especificação do sistema. 1.1 Sistemas Embebidos Um sistema embebido é um sistema de microprocessamento no qual o computador é completamente encapsulado ou dedicado ao dispositivo ou sistema que ele controla. Diferente de computadores de âmbito geral, como o computador pessoal, um sistema embebido realiza um conjunto de tarefas predefinidas, geralmente com requisitos específicos. Já que o sistema é dedicado a tarefas específicas, através de engenharia pode-se optimizar o projecto reduzindo o tamanho, recursos computacionais e custo do produto. 1.2 Lógica programável - FPGA s O hardware programável torna possível criar um circuito digital que pode ser mudado a qualquer momento com o mesmo hardware físico, bastando apenas a reprogramação do dispositivo noção de Lógica Programável. Com uma FPGA podemos desenvolver todo aquele hardware lógico que pretendemos com a flexibilidade de, usando o mesmo suporte físico, podermos a qual momento alterar o projecto do circuito, por simples reprogramação da FPGA. A placa de desenvolvimento ML403 da Xilinx contendo uma FPGA Virtex 4 (XC4VFX12) e um processador embebido PowerPC 405 (que permite correr programas escritos em linguagem C e suportar sistemas operativos embebidos como o Linux Embebido), conjugado com outros dispositivos (Memória externa, Ethernet, entre outros), oferece inúmeras funcionalidades e assim uma grande diversidade de implementações de sistemas. Com o uso de alguns dos componentes presentes na placa ML403, é possível criar um servidor de páginas Web (portanto, utilizar o protocolo http), também com a funcionalidade de alojamento de ficheiros, através da rede Ethernet. No capítulo 2 será desenvolvido este tema, para uma melhor percepção do tema. 1 Field Programmable Gate Array- Circuito integrado programável 1

19 1.3 Especificação do Sistema Pretende-se implementar um sistema embebido em tecnologia FPGA integrada, que inclui um Servidor Web, com comunicação HTTP/1.1 sobre Ethernet a 100Mb/s, em que as páginas integram imagens recebidas de uma câmara digital, assim como opções de apresentação/processamento da imagem. A placa de desenvolvimento escolhida para a concretização do sistema é a placa ML403 [5], devido à mesma providenciar os requisitos hardware necessários à sua implementação. Como é esperado dum servidor Web, pretende-se um sistema multi-utilizador, isto é, vários utilizadores podem estar ligados em paralelo ao servidor Web. Assim, para que este requisito seja satisfeito será necessário utilizar um sistema operativo, de forma que o servidor possa lançar threads para cada pedido de forma a haver comunicação paralela. O sistema operativo será responsável pelo escalonamento dos processos e por o fornecimento de mecanismos de comunicação entre processos InterProcess Communication (IPC). Na Figura 1 é possível ver uma representação do cenário objectivo deste projecto. O cenário que este projecto tem como alvo, é constituído por utilizadores com um browser http/1.1, que tendo conhecimento do endereço IP do servidor Web (Placa com a FPGA e processador embebido), conseguem visualizar a imagem da câmara ligada à placa e interagir (modificar as características da imagem) com o servidor Web. Esta comunicação é totalmente realizada através do protocolo http sobre rede Ethernet a 100 Mbps. 2

20 Rede Ethernet ML403 Utilizadores HTTP sobre Ethernet Stdout da placa (debug) Ligação Câmera/Placa Figura 1 Esquema Global do Sistema A linha unidireccional a tracejado entre a placa e um utilizador apenas, refere-se à comunicação UART, por RS232. Esta ligação apenas tem como função a de monitorização do servidor Web. O capítulo 2 apresenta a plataforma de desenvolvimento e detalha os componentes principais utilizados no desenvolvimento do sistema. No capítulo 3 são apresentados os passos de implementação do sistema, e os dois capítulos seguintes contêm informação relativa à utilização dos recursos e informação relativa à interface do sistema com o utilizador. 3

21 4

22 2. Plataforma de desenvolvimento Tal como foi referido no capítulo de Introdução, o sistema foi desenvolvido na placa de desenvolvimento ML403 da Xilinx, que contém os dispositivos seguintes: Memória - 64 MB DDR SDRAM e 8Mb ZBT SRAM Saída para debug - Porta Série RS-232 Ligação à rede - Porta Ethernet 10/100/1000 RJ-45 Pinos de expansão para ligação à câmara Conector de expansão de utilizador de 64 bits Lógica Programável FPGA Virtex-4 FX (XC4VFX12-FF668-10C) Processador PowerPC 405 embebido A câmara digital utilizada é da Omnivision (OV9650FSL). A Figura 2 mostra uma imagem da câmara. Figura 2 Câmara Omnivision OV9650FSL Esta câmara inclui um sensor e lentes on-board e é destinada para aplicações móveis onde o consumo e dimensões reduzidas são considerados importantes. A câmara suporta até pixeis, em formato SXGA/VGA e funções de controlo como de saturação de cor e de controlo de Gamma. Utiliza como interface de configuração o protocolo Serial Camera Control Bus (SCCB), que permite a programação de todas as suas funcionalidades. 2.1 EDK A configuração do sistema a nível de utilização de hardware físico (entre o disponível na placa ML403), o projecto do circuito lógico e a programação da aplicação a correr no processador foram desenvolvidos com base no ambiente de projecto do fabricante Xilinx denominado Embedded Development Kit (EDK) específico para configuração e programação deste tipo de sistemas embebidos. O EDK compreende ferramentas de síntese de hardware e ferramentas de simulação. 5

23 Para uma melhor organização do projecto da lógica programável, os elementos funcionais característicos (interacção com a porta Ethernet, por exemplo) estão organizados por blocos de hardware lógicos, com entradas e saídas lógicas. Estes blocos lógicos são chamados de Intellectual Property (IP) Cores. Ao adicionarmos IP Cores ao sistema, estamos a criar uma instância desse IP Core (analogia com a programação orientada a objectos). A Xilinx disponibiliza IP Cores para funções complexas usadas frequentemente, tais como DSP, interfaces de barramento, processadores e periféricos de processadores. Usando os produtos Xilinx LogiCORE, e Cores de entidades terceiras, os clientes podem diminuir o tempo de desenvolvimento, reduzir o risco associados à elaboração do projecto e melhorar a sua performance. Também é possível aos projectistas criar novos IP Cores com o sistema CORE Generator, permitindo implementar esses IP s em FPGA s Virtex-4 com predição e performance repetitiva. Com uma simples interface de utilizador, torna-se amigável a geração de cores flexíveis com base em parâmetros. O EDK inclui um compilador de linguagem C o gcc e uma aplicação com um ambiente de desenvolvimento mais rico o Platform Studio Software Development Kit (SDK), baseado no open source Eclipse - que permite o desenvolvimento de aplicações na referida linguagem. O EDK oferece a possibilidade de inclusão de um kernel embebido. A necessidade de se usar um kernel prende-se com vários aspectos: Muitas aplicações embebidas de controlo têm o compromisso de executarem várias tarefas, de uma determinada forma de escalonamento. É muito complicado organizar manualmente as tarefas quando o número de tarefas aumenta. A capacidade de resposta de uma aplicação desce dramaticamente quando a complexidade aumenta. É muito mais intuitivo implementar várias tarefas derivadas de uma tarefa complexa num sistema operativo do que implementar uma única aplicação complexa Permite ao utilizador escrever código a um níivel abstracto, em vez de um código standalone ao nível de um micro-controlador Muitas aplicações assentam sob serviços do sistema operativo, tais como sistemas de ficheiros; gestão temporal, etc. Xilkernel é uma biblioteca que oferece estes serviços essenciais, permitindo a migração ou o uso de bibliotecas open source comuns (como de grafismo ou de protocolos de rede) Mais detalhe acerca deste tema será descrito mais à frente deste documento. 2.2 FPGA s e a Virtex-4 FX 6

24 Esta secção descreve com mais detalhe o conceito de FPGA e descreve o caso específico da FPGA Virtex-4 FX usada na implementação deste projecto Field Programmable Gate Array (FPGA) A FPGA é um circuito integrado que contém uma matriz (desde dezenas até milhares) de células idênticas. Cada célula pode ser programada individualmente para realizar uma função lógica específica. As células individuais estão interligadas através de interruptores programáveis. Um projecto é implementado através da definição da função lógica de cada célula, e da implementação das interligações. O vector de células lógicas e a sua interligação formam a base de blocos de circuitos lógicos. Projectos mais complexos são conseguidos através da combinação destes blocos básicos. A arquitectura de uma célula varia consoante a família de FPGA s. Em termos gerais cada célula realiza uma função lógica de várias entradas e uma ou mais saídas, dependendo da função lógica booleana especificada no programa. Na maior parte das famílias de FPGA s, é possível ao programador registar o resultado combinatório de uma célula, de forma que lógica síncrona possa ser facilmente implementada. A lógica combinatória das células pode ser fisicamente implementada através de uma memória, denominada Look-up table (LUT), ou através de um conjunto de multiplexers e portas lógicas. Com o custo de tempo de propagação, células de LUT s, tendem a ser um pouco mais flexíveis e permitem mais entradas por célula do que as células implementadas com multiplexers. O significado de Field Progammable advém do facto que a função de uma FPGA é definida pelo programador final e não pelo fabricante. Um circuito integrado típico executa uma função específica definida na altura de fabrico, enquanto que a função da FPGA é definida por um projecto desenvolvido por alguém que não o fabricante. Dependendo da particularidade de cada dispositivo, o circuito lógico pode ser carregado permanentemente; semi-permanentemente como sendo parte constituinte de um processo de criação de uma placa; ou pode ser carregado a partir de uma memória externa cada vez que o dispositivo é ligado. Esta flexibilidade de programação põe ao dispor do utilizador integrados complexos sem os altos custos de engenharia associados com o desenvolvimento de circuitos integrados específicos Virtex-4 FX 7

25 Os dispositivos Virtex-4 fabricante Xilinx - são FPGA s com vários elementos configuráveis e núcleos (cores) optimizados para projecto de sistemas de alta complexidade e alta performance. Na Figura 3 está uma imagem do dispositivo Virtex-4 da família FX (existem outras duas famílias LX e SX). A família FX é indicada para conectividade série e processamento embebido - contêm processadores embebidos e controladores USB, ect. -, o que vai de encontro às linhas de orientação deste projecto. A Virtex-4 oferece as seguintes funcionalidades: Blocos de I/O (Input/Output) providenciam a interface entre os pinos do dispositivo e a lógica interna configurável. Os standards I/O mais populares e usuais são suportados por estes Blocos de I/O (IOBs). Estes IOB s estão optimizados para aplicações síncronas, que inclui deskew ao bit, serializador/deserializador de dados, divisores de clock e recursos dedicados para relógios locais Blocos de Lógica Configurável (CLB s), os elementos de lógica base de FPGA s da Xilinx, concretizam lógica síncrona e combinatória assim como memória distribuída e registos de deslocamento (SRL16 Shift Registers) Módulos de RAM, oferecem 18Kb flexíveis de RAM de dupla porto, que são hierarquizáveis para formarem RAM s de maior dimensões. Componentes DSP s embebidos com multiplicadores dedicados de 18 x 18 bits, somador integrado, e acumulador de 48 bits. Blocos para gestão de sinais de relógio (Digital Clock Manager DCM) com calibração automática, soluções completamente digitais para compensação de atrasos nos sinais de relógio, multiplicação/divisão de frequência Figura 3 Virtex-4 FX Além das funcionalidades referidas, as Virtex-4 da família FX suportam as seguintes fuincionalidades de sistema embebido: Transceivers de alto débito até ritmos de 6,5 Gb/s por canal O Processador embebido RISC da IBM, PowerPC 405 (até 450 Mhz), com uma unidade de processador auxiliar Núcleos 10/100/1000 Ethernet media-access control (EMAC) 8

26 A matriz de interligação geral (General Routing Matrix GRM) desta FPGA contém um conjunto de switches de routing entre cada componente. Cada elemento programável está relacionado com a matriz, permitindo múltiplas ligações à matriz geral. As interligações gerais programáveis são hierárquicas de forma a suportar projectos de alto-desempenho. Todos os elementos programáveis, incluindo os recursos para routing, são controlados por valores guardados em memória estática. Estes valores são carregados na memória das células durante a configuração e podem ser novamente carregadas para alterar as funções dos elementos programáveis. Na Tabela 1 estão resumidas algumas características numéricas das FPGA s Virtex-4. O dispositivo usado neste projecto é o FX12. A coluna XtremeDSP Slices refere-se aos DSP s embebidos. O transceiver RocketIO é o transceiver de alto débito referido anteriormente. Tabela 1 Características de algumas FPGA s do Grupo Virtex-4 [1] Notas: 1. 1 CLB = 4 Slices = Máximo de 64 bits 2. Cada camada XtremeDSP contém um multiplicador 18 x 18, 1 somador e um acumulador 3. Alguns das linhas/colunas do array são usadas pelos processadores nos dispositivos FX 2.3 Processador PowerPC 405 Embebido Como foi referido na secção anterior, a FPGA Virtex-4 FX12, contém o processador RISC embebido PowerPC 405 da IBM. O PowerPC 405 (PPC405) é uma implementação de 32 bits do PowerPC embeddedenvironment architecture que deriva da arquitectura do PowerPC. Especificamente, o PPC405 é o core embebido do processador PowerPC 405D5. A arquitectura do PowerPC tem um modelo de software que assegura a compatibilidade entre implementações da família PowerPC de microprocessadores. Esta arquitectura define parâmetros que garantem a compatibilidade ao nível da aplicação/programa, permitindo uma margem de flexibilidade de implementações derivativas do PowerPC que satisfaçam requisitos específicos. Na Figura 4 é possível ver um diagrama de relações entre as arquitecturas do PowerPC [8]. 9

27 Figura 4 Relação entre arquitecturas PowerPC [8] O processador permite aplicações embebidas de vírgula fixa com alta performance a um baixo consumo de energia. É compatível com o PowerPC UISA. As características chave do PPC405 incluem: Arquitectura de 32 bits, contendo 32 registos de uso geral (General Purpose Registers GPR s) Extensões adicionais para suporte de aplicações de sistemas embebidos Operações em little-endian Gestão flexível da memória Instruções Multiplicação/Acumulação para aplicações computacionalamente intensivas Funcionalidades de debug avançadas Time base de 64 bits 3 temporizadores: Programmable Interval Timer (PIT), Fixed Interval Timer (FIT), e Watchdog Timer (todos síncronos com o time base) Melhoramentos de performance: o Predição de salto estático o 5 andares de pipeline com um ciclo de execução para a maior parte das instruções, incluindo load s e store s o Instruções de Multiplicação/Acumulação o Hardware para multiplicação/divisão (4 ciclos para multiplicação e 35 ciclos para divisão) o Gestão de string s e de múltiplos word s avançada 10

28 o Suporte de loads e stores não alinhados para cache array; memória principal e On-chip Memory (OCM) o Latência de interrupções minimizada Cache de instruções integrado (16 KB, 2 vias associativo) Cache de dados integrada (16 KB, 2 vias associativo) Gestão de memória flexível (Tradução de endereços lógicos de 4 GB no espaço de endereçamento físico; protecção de controlo adicional usando zonas Suporte de debug usando operadores lógicos (seguimento para trás e para a frente de intruções) Gestão de consumo de energia avançado Na Figura 5 e 6 está representada a organização do PowerPC e a gestão de memória do processador.. Figura 5 Organização do PPC405 11

29 Figura 6 Gestão de Memória do PPC405 Estes elementos de informação foram retirados da bibliografia respectiva [8]. 2.4 Módulo de interacção com a câmara O Módulo original de interacção com a câmara referida, foi desenvolvido anteriormente pelo Grupo SIPS do INESC-ID, e além da especificação VHDL inclui uma parte física de ligação ao sensor e ligação à ficha VGA. Este módulo permite processamento de imagem em tempo real através de uma FPGA, mostrando o resultado no monitor. Este módulo configura a câmara (resolução, etc.) através de um protocolo a 2 fios - Serial Camera Control Bus (SCCB) - e recebe dados através de sinais dedicados de saída da câmara (sinais de informação de bit e de sincronização). O fluxo de dados é obtido após configuração da câmara e fornecimento contínuo de um clock externo ao sensor. Na Figura 7 está representado o esquema do sistema a que este módulo se destina. Este módulo (código VHDL) foi alterado para ser possível a integração no servidor Web. 12

30 FPGA com módulo VHDL, ligado ao sensor e monitor através dos pinos de expansão Figura 7 Esquema do módulo original de interacção com a câmara Para o modo de funcionamento desejado da câmara é necessário configurar os registos da mesma, através do protocolo SCCB (ver ilustração do protocolo na Figura 8 e 9). Este protocolo é semelhante ao protocolo IIC, utiliza 2 sinais, um para o Sinal de Clock (designado habitualmente por SCL, que é gerado pelo dispositivo master) e outro para dados (denominado SDL, partilhado pelos vários intervenientes, sendo assim bidireccional). Nas figuras ilustrativas o sinal SCL está em cima e o SDL em baixo. Esta configuração é iniciada de forma manual e feita em 2 fases: Reset ao dispositivo, para os registos ficarem com valores por defeito Configuração dos registos, para a câmara funcionar no modo pretendido Figura 8 Ciclo de Leitura do protocolo SCCB [12] Figura 9 Ciclo de Escrita do protocolo SCCB [12] 13

31 O reset inicial ao dispositivo é feito levando a high ( 1 lógico) o sinal de entrada correspondente ao pino de reset do sensor. Esta acção leva ao reset dos registos ficando estes com os seus valores por defeito. A configuração dos registos deve-se à necessidade de se definir o modo de funcionamento da câmara (resolução, codificação de imagem, etc.). A câmara é configurada com a resolução de QVGA (320 x 240), e com a codificação de cor YUV (8 bits - 4:2:2). No entanto só é aproveitada parte da frame (128 x 64) e só a componente da luminância (componente Y da codificação YUV). O Core guarda as frames em 2 blocos de RAM idênticos (portanto de dimensões 128 x 64 e com profundidades de informação de 8 bits). Na Figura 10 está representado o diagrama de blocos de alto nível deste módulo. Processing Module Camera Interface 2 Memórias de 128 x 64 x 8 Bits VGA Interface Clock Figura 10 Diagrama de blocos do Módulo original de interface com a Câmara 14

32 O Módulo divide-se logicamente em 3 blocos principais: Camera Interface; Processing Module e VGA Interface. A seta de entrada representa os sinais de entrada da câmara, tanto os respeitantes à informação de pixel (8 bits) como os respeitantes à sincronização (3 sinais). O bloco Camera Interface tem como função a configuração da câmara através de SCCB a 2 sinais (1 deles bidireccional), que está representado no esquema pela seta bidireccional, assim como também a função de capturar os pixeis e o seu endereço (posição na frame) correspondente. Dentro deste bloco existem as 2 memórias que guardam 2 frames idênticas. Estas memórias são preenchidas através dos sinais de comando do bloco Processing Module e são lidas pelo bloco VGA Interface. A representação destas memórias é feita pela Figura 11. Clock de Escrita Clock de Leitura Dados para Leitura Enable de Escrita 8 Enable de Leitura Endereço para Escrita Endereço para Leitura Dados para Escrita 8 Figura 11 Estrutura dos blocos de memória do Módulo VHDL do SIPS O acesso a estas memórias, tanto para escrita como para leitura pode ser feito em simultâneo, e com ritmos diferentes (daí o facto dos 2 relógios de entrada). Nas Figuras 12 e 13 seguintes estão representados os fluxogramas referentes à escrita e leitura destas memórias. 15

33 Rising_Edge(Clock de Escrita) N S Enable de Escrita == 1 N Memoria[Endereço de Escrita]=Dados de Escrita S Figura 12 Fluxograma do algoritmo de escrita nas memórias do Core VHDL Sempre que há um flanco ascendente do relógio correspondente ao tipo de acção (uma entrada de relógio para leitura e outro para escrita) é verificado o Enable também correspendente à acção, e caso este esteja activo (a high 1 lógico) será escrito no endereço indicado ou lido o valor do endereço indicado consoante a acção seja de escrita ou leitura. Rising_Edge(Clock de Leitura) N S Enable de leitura == 1 N Dados de Leitura = Memoria[Endereço de Leitura] S Figura 13 - Fluxograma do algoritmo de leitura das memórias do Core VHDL 16

34 2.5 Software A implementação a nível software é conseguida através do uso da entidade Xilinx MicroKernel (XMK) incluída no EDK, que representa o conjunto colectivo de: Software das bibliotecas de C; Xilkernel - kernel embebido; Standalone Board Support Package (BSP); Memory File System (MFS) - sistema de ficheiros em memória; LibXil Drivers - drivers para suporte dos periféricos. Biblioteca lwip que integra as funcionalidades de rede através de Ethernet. A estrutura do XMK está representada na Figura 14. Como é mostrado na figura, a aplicação do utilizador pode interagir com os componentes do XMK de várias formas. As bibliotecas são independentes umas das outras, existindo no entanto algumas interacções e dependências entre algumas delas. Figura 14- Organização do XMK Como exemplo realtivo às dependências, o Xilkernel internamente utiliza o standalone BSP, e o LibXil File pode opcionalmente trabalhar com o LibXil MFS. O LibXil Drivers e o Standalone BSP constituem a abstracção de mais baixo nível de hardware. Todas as bibliotecas e componentes do Sistema Operativo do XMK baseiam-se em componentes de bibliotecas standard de C. A biblioteca math, libm.a, também está disponível para conexão com aplicações do utilizador. Utilizadores podem misturar as bibliotecas componentes da aplicação mas existem algumas restrições e implicações. 17

35 O BSP é um kernel do tipo barebone (sistema base). Providencia uma interface simples com o hardware, permitindo uma funcionalidade mínima que poderá ser requerida pelas aplicações. Algumas funcionalidades típicas oferecidas pelo BSP, são inicializar o sistema de interrupções, sistemas de excepções, configuração de caches (activação/desactivação, etc) e outras funções específicas do hardware. O LibXil Driver refere-se aos controladores dos periféricos que estão incluídos na plataforma de software para fornecer uma interface com os periféricos do sistema. Estes drivers são fornecidos com o EDK e são configurados com a componente Libgen (Library Generator) do EDK. O LibXil File, providencia um sistema de ficheiros baseado em stream de dados, e acesso a dispositivos através de interfaces como open, close, read, e write. A biblioteca libc contém funções do tipo dummy para esse tipo de chamadas específicas de sistema operativo. A biblioteca LibXil File contém rotinas próprias para sobrepor-se a estas dummy functions. Estas rotinas destinam-se a interagir com sistemas de ficheiros tais como o Xilinx Memory File System (MFS) e dispositivos de periféricos do tipo Universal Asynchronous Receiver Transmitter (UART), UARTLITE (UART menos complexa) e General Purpose Input Output (GPIO). É possível criar um simples sistema de ficheiros baseado em memória externa com a biblioteca LibXil MFS, permitindo assim um fácil acesso aos dados usando primitivas de leitura/escrita baseada naquelas usadas para ficheiros. O kernel Xilkernel é um simples kernel para processador embebido, o qual pode ser configurado para um determinado nível de desempenho para um dado sistema. O Xilkernel tem as funcionalidades chave de um kernel embebido tais como: multi-tarefa escalonamento preemptivo baseado em prioridades comunicação entre processos IPC funcionalidades de sincronização tratamento de excepções etc. É modular, configurável ao nível do utilizador e pode ser usado em diferentes configurações de sistemas. As aplicações também podem linkar estaticamente com o Xilkernel, de diferente modo, e formar um único executável. Na secção seguinte o Xilkernel será aprofundado visto a sua importância no projecto desenvolvido. 18

36 2.5.1 Kernel Embebido Xilkernel A placa ML403 com o processador PowerPC 405 embebido oferece inúmeras potencialidades a nível de suporte de um sistema operativo embebido, desde o VxWorks até ao Linux Embebido. O Xilkernel é um kernel robusto, modular e compacto. É uma biblioteca de software grátis que é distribuída com o EDK. Permite personalização, permitindo aos utilizadores definirem um compromisso entre ocupação de recursos e funcionalidade. Suporta as funcionalidades requeridas de um kernel embebido e leve, com um API POSIX. O Xilkernel corre tanto nos processadores embebidos MicroBlaze e PowerPC 405. Serviços de IPC suportados pelo Xilkernel podem ser usado para implementar serviços de alto nível (como ligação à rede, vídeo, etc.) O kernel é modular, de forma que é possível seleccionar e personalizar os seus módulos que são utilizados pela aplicação. A Figura 15 ilustra a organização do Xilkernel. Figura 15 Organização do Xilkernel em Módulos Seguem-se as suas funcionalidades principais: Kernel embebido com API POSIX como alvo Funcionalidades base de Kernel como: o Threads POSIX com escalonamento round-robin ou de prioridade estricta o Sincronização POSIX semáforos e mutex s o Serviços IPC POSIX memória partilhada e fila de mensagens o Alocação dinâmica de buffers o Timers por software o API de tratamento de interrupções do utilizador 19

37 Kernel altamente robusto, com chamadas de sistema protegidos por parâmetros de verificação de validade e retorno de erros POSIX convenientes Kernel de alta escalabilidade para ser possível a acomodação de novas funcionalidades Configuração completa do kernel, dentro do sistema de desenvolvimento do software As unidades de execução do Xilkernel são denominadas contextos de processo. O escalonamento é feito ao nível do contexto de processo. Não existe o conceito de associação de grupos de threads, chamadas convencionalmente por processos, pelo contrário, todas as threads competem igualmente pelos recursos. A API de threads POSIX é a interface primária visível pelo utilizador no uso destes contextos de processos. As interfaces permitem criação; destruição; e manipulação das threads criadas. As threads são manipuladas por identificadores de threads. O contexto de processo subjacente é identificado com um identificador de processo pid_t. Nas Figuras 16 e 17 estão representados esquemas relativos ao escalonamento e processos respectivamente. Figura 16 Escalonamento orientado a Prioridades 20

38 Figura 17 Estados de Contexto de Processos Como se pode observar este kernel permite implementações de aplicações standard que exijam serviços de um sistema operativo como escalonamento de processos. 21

39 22

40 3. Implementação do Sistema O sistema a implementar é constituído por duas componentes: Hardware Software O software irá executar sobre hardware (parte dele programável). Assim, é necessário determinar qual o hardware que o sistema necessita de forma a satisfazer as necessidades do software. Visto o hardware físico estar disponível (através da placa ML403), o próximo passo é o projecto do circuito lógico. Este circuito fará a interligação entre os vários componentes de hardware físico incluindo o processador embebido PowerPC, e é implementado dentro da FPGA, o que permite, como foi referido na introdução, uma implementação flexível, isto é, tolerante a alterações do projecto. Após o projecto de hardware concluído, pode-se então iniciar o projecto do software. As secções seguintes deste capítulo descrevem a implementação detalhada da parte de hardware lógico e da parte de software. 3.1 Hardware Para determinarmos os IP s Cores a instanciar temos de considerar o hardware físico que faz parte do sistema: Processador, onde corre o código da Aplicação e sistema operativo; Ethernet; UART, para envio de mensagens através da porta série para um programa do tipo HyperTerminal; Memória RAM, para armazenamento do código da aplicação e ficheiros do servidor (o sistema de ficheiros será criado em memória volátil); JTAG (Joint Test Action Group), para debug do processador e memória; Câmara para captura de imagem Na Figura 18 está esboçado o diagrama de blocos do sistema, e na Figura 19 está a legenda correspondente. 23

41 Figura 18- Diagrama de blocos do design do sistema do Web Server Figura 19 Legenda do Diagrama de Blocos do sistema O sistema é constituído por 2 barramentos partilhados, estando o processador e as memória RAM ligadas ao mesmo barramento. Existe comunicação entre barramentos como se pode observar na Figura 18. Nas próximas secções será apresentada com detalhe a implementação deste sistema e assim explicado este diagrama de blocos. O hardware é constituído por duas componentes ligadas entre sí servidor Web e Módulo de interacção com a câmara. Seguidamente será apresentado a implementação do hardware por secções. 24

42 Sistema Global e Servidor Web A cada um dos elementos constituintes do sistema corresponde um IP Core específico para existir comunicação entre os mesmos elementos. Na Tabela 2 é feita essa correspondência: Tabela 2 - Relação entre dispositivos físicos e IP Core s Hardware físico IP Core necessário Versão do IP Core utilizado Processador PowerPC 405 PPC405_VIRTEX4 1.01a RS232 OPB UARTLite 1.00b DDR SDRAM PLB DDR 2.00a SRAM PLB EMC 2.00a Ethernet PLB_ETHERNET 1.01a JTAG JTAGPPC_CNTLR 2.00a O Core relativo ao processador (PPC405_VIRTEX4), corresponde ao processador embebido. Este Core permite a criar a interface (conceito de Wrapper) de forma que o processador seja visto como qualquer outro IP Core. A comunicação UART através de RS-232 é assegurada pelo Core OPB UARTLite (versão mais simples que o IP Core OPB UART cerca de um quarto dos recursos utilizados: na ordem dos 50/60 para 200/300 FlipFlop s). Este Core permite uma comunicação simples, suficiente para o envio e recepção de caracteres como é necessário neste projecto. Foram usadas as seguintes características deste Core: 1 canal para transmissão e outro para recepção sendo assim full duplex 1 FIFO para transmissão e outra para recepção de 16 caracteres cada Número de bits por caracter 8 Baud rate de bps Neste projecto foi configurado da forma como é apresentado na Tabela 3. Tabela 3 Configuração UART para RS-232 Parâmetro Valor Descrição C_BAUDRATE Baud Rate C_DATA_BITS 8 Bits por caracter C_USE_PARITY 0 Não uso de Paridade C_CLK_FREQ Relógio Externo C_BASEADDR 0x Endereço base da instância C_HIGHADDR 0x4060ffff Endereço máximo da instância 25

43 Além do código da aplicação (incluindo sistema operativo) e suas variáveis, é necessário armazenar os ficheiros html do servidor Web, assim como ficheiros relacionados com a apresentação da imagem da câmara (por exemplo, o cabeçalho do formato de imagem a usar, que será guardado no sistema de ficheiros). Visto não termos disponível memória secundária (tipo discos rígidos), será necessário arranjar outra alternativa para se armazenar esta informação. O EDK oferece a possibilidade de se criar em memória volátil um sistema de ficheiros simples o Memory File System (MFS). Por decisão de projecto - motivos de organização e simplicidade o código e sistemas de ficheiros são armazenados em RAM distintas: DDR SDRAM código da Aplicação SRAM sistema de ficheiros MFS O Core PLB DDR, faz a interface de controlo entre o Bus e a memória externa DDR. Foram usadas as seguintes características: Execução da sequência de inicialização do dispositivo aquando de condições de power-on e reset em aproximadamente 200 us Execução de ciclos de auto-refresh Largura de dados de 32 bits ligações big-endian a dispositivos Latência de CAS (Column Address Select) de 2 ou 3 ciclos Na Figura 20 está esboçado o diagrama de blocos do Core PLB DDR [6]. 26

44 Bus 1. Opcional Sinais de Clock Externos Figura 20 Diagrama de blocos do IP Core PLB DDR O módulo PLB funciona como interface entre o bus e o controlador. O módulo de interface IP Interconnect (IPIC) permite comunicação entre o módulo PLB IPIF (IP Interface ligação ao bus PLB) o controlador DDR SDRAM. O bloco Init State Machine gera um atraso de 200us e a sequência para inicialização da DDR SDRAM (quando completo activa o sinal DDR_init_Done). O bloco Command State Machine gera comandos e endereços para a memória DDR. O módulo Data State Machine transfere dados para a DDR SDRAM. O módulo IO Registers instancia os sinais correctos (DM, DQ e DQS), para interacção com os registos da DDR SDRAM. O bloco Read Data Path captura os dados e guarda-os numa FIFO (sincronizada com o relógio do bus). O módulo de lógica Error Correction Code (ECC) é opcional (definido por parâmetro) e gera os bits de verificação ECC a guardar na memória também corrige erros simples de dados lidos da memória. Na Tabela 4 encontram-se os parâmetros de implementação relevantes deste Core. 27

45 Tabela 4 Parâmetros de Implementação do IP Core PLB DDR Parâmetro Valor Descrição C_PLB_CLK_PERIOD_PS C_REG_DIMM 0 C_DDR_TMRD C_DDR_TWR C_DDR_TRAS C_DDR_TRC C_DDR_TRFC C_DDR_TRCD C_DDR_TRRD C_DDR_TRP C_DDR_TREFI C_DDR_AWIDTH 13 C_DDR_COL_AWIDTH 9 C_DDR_BANK_AWIDTH 2 C_DDR_DWIDTH 32 C_MEM0_BASEADDR 0x C_MEM0_HIGHADDR 0x03ffffff NOTA: Tempos de atrasos dados em ps. Período do relógio do Bus PLB Não é dispositivo registado DIMM Tempo de ciclo do comando Load Mode Register Tempo de Recuperação do Write Atraso após commando ACTIVE e antes do comando PRECHARGE Atraso após commando ACTIVE e antes do comando ACTIVE ou AUTOREFRESH Atraso após commando AUTOREFRESH antes de qualquer outro commando Atraso entre ACTIVE e comando READ/WRITE Atraso entre comandos ACTIVE para linhas diferentes Atraso após comando PRECHARGE Tempo médio entre comandos de actualização periódica Largura de endereço Largura de endereço de Coluna Largura de endereço de Banco Largura de dados (não incluindo bits de verificação ECC) Endereço base da instância Endereço máximo da instância Para termos acesso à memória externa SRAM, é necessário o Core PLB External Memory Controller (EMC). Este Core é utilizado como interface entre o Bus e dispositivos síncronos/assíncronos de memória. A Figura 21 representa o Diagrama de Blocos de Alto nível do Core PLB EMC [9]. 28

46 Figura 21 - Diagrama de Blocos de Alto nível do Core PLB EMC. O Core recebe sinais de controlo do bus de leitura/escrita do periférico externo de memória. Contém também uma interface com o bus e um ou mais (até 4) bancos externos de componentes de memória. Suporta larguras de bus de 8, 16, 32 e 64 bits. É possível definir tempos de acesso para escrita; leitura e tempo de recuperação na mudança de leitura para escrita e vice-versa. A Tabela 5 mostra o valor dos parâmetros de implementação deste Core. Tabela 5 Parâmetros de implementação do Core PLB EMC Parâmetro Valor Descrição C_PLB_CLK_PERIOD_PS C_NUM_BANKS_MEM 1 C_MAX_MEM_WIDTH 32 C_INCLUDE_NEGEDGE_IOREGS 1 C_INCLUDE_DATAWIDTH_MATCHING_0 1 Período do clock do Bus PLB Número de Banks de memória Máximo (Largura Banco x Bus de Dados) de todos os Bancos Calculado automaticamente Os sinais de controlo e de dados são(data and control signals are input/output on the falling edge of the clock) Executar multiplos ciclos de acesso à memória para corresponder com C_MAX_MEM_WIDTH com bus de dados PLB 29

47 C_MEM0_WIDTH 32 C_SYNCH_MEM_0 1 C_TCEDV_PS_MEM_0 0 C_TWC_PS_MEM_0 0 C_TAVDV_PS_MEM_0 0 C_TWP_PS_MEM_0 0 C_THZCE_PS_MEM_0 0 C_TLZWE_PS_MEM_0 0 C_MEM0_BASEADDR C_MEM0_HIGHADDR 0x x060fffff Largura Banco x Bus de Dados Memória Síncrona Apenas usado para memórias assíncronas, mas de carácter obrigatório Endereço base da instância Endereço máximo da instância Para termos acesso à rede Ethernet, é necessário instanciar o Core PLB_ETHERNET. O Core PLB Ethernet 10/100 Mbs Media Access Controller (PLB_EMAC), faz a interface entre o hardware físico de Ethernet e o Bus, de acordo com a norma de interface IEEE std MII. Este Core suporta uma interface de 10 e 100 Mbps. Inclui funções e a flexibilidade de muitos controladores de Ethernet presentes no mercado. Neste projecto foi configurado com a taxa de 100Mbps. Na Figura 22 está um diagrama de blocos correspondente aos módulos do IP PLB EMAC [6]. Figura 22 Diagrama do IP Core PLB EMAC O Core PLB EMAC compreende 2 blocos IP como está representado acima: a interface IP (IPIF) que implementa aas funcionalidades da interface com o bus PLB e o bloco relativo à comunicação Ethernet. 30

48 Na Tabela 6 encontram-se os parâmetros de implementação. Tabela 6 Parâmetros de implementação do Core PLB EMAC Parâmetro Valor Descrição C_DMA_PRESENT 1 C_IPIF_FIFO_DEPTH C_PLB_CLK_PERIOD_PS C_BASEADDR C_HIGHADDR 0x x8040ffff Não necessita de funções de DMA Profundidade da FIFO de pacotes em bits Período do clock do Bus PLB Endereço base da instância Endereço máximo da instância O Core JTAGPPC_CNTLR permite o debug do processador PPC405. À semelhança do Core PPC405_VIRTEX4, trata-se de um Core de interface, pois existe hardware físico dedicado. Na Figura 23 está o diagrama de blocos deste Core. Figura 23 Diagrama de Blocos do IP Core JTAGPPC_CNTLR A lógica adicional deve-se ao facto deste Core suportar até 2 processadores PPC. Na placa ML403 só existe um processador embebido, logo este Core somente é usado em conjunto com um processador. Este Core não possui parâmetros de implementação. 31

49 Para permitir a interligação entre os diversos elementos referidos é necessário usarmos barramentos partilhados. Estes barramentos são implementados através de IP Cores s específicos. No sistema são usados 2 tipos de barramentos: - Bus PLB Processor Local Bus - Bus OPB On-Chip Peripheral Bus O Bus PLB é indicado para conectar o processador e memórias externas assim como também o Core de Ethernet. O Bus OPB é usado para ligar outros tipos de Cores, como por exemplo Cores Personalizados do utilizador, UART, etc. A razão da indicação de cada tipo de barramento prende-se com aspectos de implementação e funcionalidades específicas. O Bus PLB é implementado através do Core Processor Local Bus (PLB) v3.4 (v1.02a para a Virtex-4). Consiste numa unidade de controlo de bus, com um watchdog timer, endereço separado, data path s para escrita e leitura com funcionalidade de Árbitro a 3 ciclos. Contém uma interface slave DCR para garantir acesso aos seus registos de erros. Também contém um circuito gerador de reset no arranque do sistema, caso não exista um sinal de reset externo. Entre outras funcionalidades destacam-se: Endereçamento, encaminhamento de dados e Arbitração até 16 masters Número de masters ligados ao bus configurável Suporte de masters e slaves de 64 e/ou 32 bits 4 Níveis de prioridade de pedidos dinâmicos de master Suporte até 16 slaves, configurável através de parâmetro Circuito de Reset Na Figura 24 está representado um diagrama do Core PLB, fazendo de interface com 3 slaves e 3 masters [6]. 32

50 Figura 24 Diagrama do IP Core PLB Interconnect É constituído por um Árbitro do bus central, pela lógica necessária para controlo do bus, e pelas estruturas de OR/MUX próprias do bus. Suporta até 16 masters e 16 slaves. Na Figura 25 está representado o diagrama de blocos do Core PLB v3.4 [6]. 33

51 Figura 25 Diagrama de Blocos do IP Core PLB v3.4 O módulo Address Path contém a lógica necessária para seleccionar o endereço master ou slave. O módulo Write Data Path contém a lógica para encaminhamento dos dados de escrita de masters e slaves. A unidade Read Data Path é análoga à anterior, referindo-se à leitura. A unidade Bus Control Unit consiste numa unidade de controlo que gere endereços e fluxo de dados através de DCRs e do bus PLB. A Tabela 7 contém os valores dados aos parâmetros de implementação do Core PLB v3.4. Tabela 7 - Parâmetros de Implementação do Core PLB v3.4 Parâmetro Valor Descrição C_DCR_INTFCE 0 Não incluir interface DCR slave C_EXT_RESET_HIGH 1 Reset externo activo a high O Bus OPB é implementado através do Core On-Chip Peripheral Bus V2.0 com o módulo OPB Arbiter v1.10c. O bus OPB V2.0 é realizado com base num multiplexer distribuído implementado com uma função AND para master ou slave, e por uma função OR para junção dos vários drivers num único bus. 34

52 Seguem-se algumas das características utilizadas deste Core: Inclui sinais de I/O que podem ser parametrizados, suportando assim até 16 dispositivos masters, e um número de slaves inderterminado (a Xilinx recomenda um máximo de 16) no sistema desenvolvido 1 master e 2 slaves A estrutura OR pode ser implementado usando apenas LUTs ou uma combinação de LUT s com um somador de carry rápido para redução do número de LUT s na interligação de OR s definido automaticamente pelo EDK Na Figura 26 está o Diagrama de Blocos de alto nível do módulo OPB Arbiter. Figura 26 - Diagrama de Blocos de alto nível do módulo OPB Arbiter O bloco IPIF é o bloco de interface OPB que lida com o protocolo OPB de leitura e escrita, de registos de prioridades e do registo de controlo em conjunto com o OPB Arbiter. O módulo Arbitration Logic determina qual dos pedidos tem a prioridade mais elevada e o bloco Park/Logic determina qual dos masters deverá obter acesso ao bus. O WatchDog Timer acciona um timeout caso uma resposta de um slave não seja recebida dentro de 16 ciclos. Na Tabela 8 estão indicados os valores dados aos parâmetros de implementação do Core OPB v

53 Tabela 8 - parâmetros de implementação do Core OPB v2.0. Parâmetro Valor Descrição C_EXT_RESET_HIGH 1 Reset externo activo a high Para existir passagem de informação entre os 2 barramentos, é incluído um IP Core que é específico para o efeito - plb2opb_bridge (vs 1.01a). Este Core traduz as transacções de dados no barramento PLB em transacções no barramento OPB. Funciona como slave do lado PLB e master do lado OPB. Contém uma interface slave DCR para permitir acesso aos registos de estado de erros. Este Core com a função de ponte de dados é necessário quando um dispositivo master PLB necessite de aceder a periféricos OPB que é o caso deste projecto, como será mostrado mais à frente. O utilizador pode activar/desactivar funcionalidades deste Core para ir de encontro às exigências das aplicações e assim melhorar o rendimento em termos de espaço e performance (frequência de trabalho). Seguem-se as características tanto do lado de Slave PLB como do lado Master OPB: Interface Slave PLB: o 32 ou 64 bits, Configurável por parâmetro usado 32 bits neste projecto o Descodifica até 4 gamas de endereçamento separadas (limites programáveis) o Comunica com Masters PLB de 32 e 64 bits apenas 32 bits usados o Transferências burst, de dimensão fixa (word, double, word) ou variável, até à largura do buffer associado (16). Foram desactivadas através de um parâmetro de design o Suporta até 16 Masters PLB (configurável) 2 apenas neste sistema Inteface Master OPB: o Largura de dados configurável (não suporta dimensionamento dinâmico sem lógica adicional) 32 bits Os relógios de PLB e OPB podem ter as seguintes relações síncronas: 1:1; 2:1; 3:1 e 4:1 no sistema é de 1:1 Para lidar com erros tem Bus Error Address Registers (BEAR) e Bus Error Status Registers (BESR) Buffer de escrita e buffer de leitura de pre-fetch de profundidade de 16 A Figura 27 mostra o Diagrama de Blocos do IP Core PLB to OPB Bridge. 36

54 Figura 27 - Diagrama de Blocos do IP Core PLB to OPB Bridge As transacções PLB são recebidas e descodificadas na lógica de interface PLB. Esta lógica gera a sequência necessária de sinais OPB (endereço, byte enables, e dados) para executar a transacção. Estes padrões de sinais OPB são então carregados pela lógica de interface que actua como uma FIFO, para separar a interface PLB do master OPB. A lógica de interface OPB recebe padrões de dados e põe como output no OPB. A lógica OPB também lida com sinais de handshaking (request/grant, select, entre outros). Para transacções de leitura de PLB, o master OPB retorna os dados de leitura para a lógica PLB através da interface de dados OPB-to-OPB actua como uma FIFO para separar os dados do caminho de retorno e de flags de status do OPB para a lógica PLB. Seguem-se os parâmetros de implementação utilizados, mostrados na Tabela 9. Tabela 9 Parâmetros de Implementação do Core PLB to OPB Bridge Parâmetro Valor Descrição C_DCR_INTFCE 0 Não incluir módulo DCR C_NUM_ADDR_RNG 1 Nº de gamas de endereço C_RNG0_BASEADDR 0x Endereço base da instância C_RNG0_HIGHADDR 0x7fffffff Endereço máximo da instância 37

55 Visto haver comunicação por RS232 e Ethernet, serão usadas interrupções aquando da interacção com estes elementos. Assim também é necessário instanciar um outro Core para controlar as interrupções opb_intc (OPB Interrupt Controller v1.00c). Este Core é composto por um Wrapper que contém um núcleo IntC e uma interface com o bus. São algumas das suas funcionalidades: Suporta larguras de bus OPB de 8, 16 e 32 bits - usada largura 32 bits O número de interrupções é configurável até ao número de bits correspondentes à largura do bus a que está ligado 2 interrupções usadas A prioridade entre interrupções é determinada pela posição dos bits (bit 0 com maior prioridade) Tratamento das interrupções por flancos (ascendente ou descendente) ou por nível (high ou low) Na Figura 28 está representado o diagrama de blocos deste Core [6]: Figura 28 - Diagrama de blocos do IP Core Interrupt Controller v1.00c Este Core está organizado em 3 unidades funcionais: Detecção de interrupções e geração de pedidos Registos de programação Interface com o Bus. 38

56 Seguem-se os parâmetros de implementação da instância deste Core, descritos pela Tabela 10. Tabela 10 Parâmetros da instância do Core Interrupt Controller v1.00c Parâmetro Valor Descrição C_NUM_INTR_INPUTS 2 2 Entradas de interrupções C_BASEADDR 0x Endereço base da instância C_HIGHADDR 0x4120ffff Endereço máximo da instância Os IP s referidos não são suficientes por si só, é necessário incluir outros IP s auxiliares, indicados na Figura 29 com diversas funcionalidades. Em cima a negrito está indicado o nome do IP e em baixo o nome da Instância. Figura 29 - IP Core s auxiliares utilizados O IP proc_sys_reset (Processor System Reset Module) trata dos diversos sinais de reset que o utilizador pretenda usar/controlar, por exemplo o reset inicial no power on, sequência de sinais de reset (por exemplo, 1º aos barramentos, passados 16 ciclos a periféricos e passados outros 16 ciclos ao processador). São algumas das suas características: Sincronização com o relógio da entrada externa (e também da auxiliar) de reset Seleccionável high ou low o nível de activo das entradas Largura do impulso de reset configurável Geração do sinal de reset no power-on 39

57 Na figura 27 está o Diagrama de blocos deste Core [6]. Figura 30 - Diagrama de blocos do Core Processor System Reset Module Este módulo tem 7 entradas e 5 saídas. Também existem 6 sinais genéricos que podem ser definidos pelo utilizador. Neste Core apenas foi definido um parâmetro de implementação, como mostrado na Tabela 11 Tabela 11 Parâmetro da Instância do IP Core Processor System Reset Module Parâmetro Valor Descrição C_EXT_RESET_HIGH 0 Geração de reset quando reset externo de entrada = 0 Com o Core util_vector_logic (Utility Vector Logic), dados 2 vectores de bits de entrada, é aplicado uma função lógica ( and, or, xor ) bit a bit entre os vectores, de forma a gerar um vector de bits à saída como resultado dessa função. Na Figura 31 está o diagrama de implementação deste Core num sistema [6]. 40

58 Figura 31 Cenário de implementação do Core Utility Vector Logic Estes Cores também podem ser usados para negar um vector bit a bit. Foram criadas 3 instâncias para negar alguns sinais de relógio, necessários pela memória DDR. Esta operação é mostrada na Figura 32. Figura 32 Operação executada pelas Instâncias do Core Utility Vector Logic O IP Core util_bus_split (Utility Bus Split) v1.00a serve apenas para dividir em 2 barramentos um barramento de entrada. A Figura 33, compreende 2 diagramas deste Core. Figura 33- Diagramas do IP Core Utility Bus Split O Diagrama em cima representa o cenário de utilização do Core num sistema. O Diagrama em baixo, representa com maior detalhe a função do Core, onde C_SIZE_IN é a largura do Bus de 41

59 entrada; C_LEFT_POS é o bit mais significativo do bus resultante 1 e C_SPLIT é o bit menos significativo do barramento de saída 1. Seguem-se os valores destes parâmetros para a instância presente neste projecto na Tabela 12. Tabela 12 Parâmetros da Instância do Core Utility Bus Split Parâmetro Valor Descrição C_SIZE_IN C_LEFT_POS C_SPLIT 32 Bus de entrada de 32 bits 9 Bit mais significativo do bus de output 30 Bit menos significativo do bus de output Esta instância deve-se ao facto dum caso pontual da memória SRAM, que não é relevante para o projecto. Esta instância é gerada automaticamente pelo EDK, quando seleccionamos a Memória SRAM da placa ML403. O IP Core dcm_module (Digital Clock Manager Module) como foi referenciado no capítulo 3 tem várias utilizações para trabalhar um sinal de relógio, tanto para implementar um sintetizador digital de frequência como para implementar um deslocamento digital de fase (digital phase shifter). Neste caso é usado para gerar os sinais de relógio do sistema, tanto o sinal de clock necessário pelo processador (3 x superior à do resto do sistema) como o sinal que liga aos restantes elementos do sistema. Este IP Core é uma interface com hardware dedicado existente na FPGA Virtex-4. Na Figura 34 está o diagrama de blocos do IP Core DCM Module [6]. Figura 34 Diagrama de Blocos do IP Core DCM Module 42

60 Nas Tabelas 13 e 14 estão os valores dos parâmetros de implementação relevantes. Tabela 13 Valores dos parâmetros de implementação da Instância 1 DCM Parâmetro Valor Descrição C_CLK0_BUF TRUE Inserção de BUFG à saída do relógio CLK0 C_CLK90_BUF TRUE Inserção de BUFG à saída do relógio CLK90 C_CLKFX_BUF TRUE Inserção de BUFG à saída do relógio CLKFX C_CLKFX_DIVIDE 1 Denominador da relação do relógio entrada(clkin)/ CLKFX C_CLKFX_MULTIPLY 3 Numerador da relação do relógio entrada(clkin)/ CLKFX C_CLKIN_PERIOD 10, Período do relógio de entrada C_CLK_FEEDBACK 1X Feedback do relógio de saída C_EXT_RESET_HIGH 1 Reset externo activo a high Esta instância deve-se ao facto da necessidade de geração do Relógio do processador (sinal de saída CLKFX desta instância - e do relógio do sistema - sinal de saída CLK0. Tabela 14 Valores dos parâmetros de implementação da Instância 2 DCM Parâmetro Valor Descrição C_CLK0_BUF TRUE Inserção de BUFG à saída do relógio CLK0 C_CLK90_BUF TRUE Inserção de BUFG à saída do relógio CLK90 C_CLKIN_PERIOD Período do relógio de entrada C_CLK_FEEDBACK 1X Feedback do relógio de saída C_EXT_RESET_HIGH 0 Reset externo activo a low Esta instância DCM, gera os relógios de entrada na memória DDR. É possível criar uma memória, ligada ao barramento PLB, de forma a estar acessível ao processador. Isto é possível instanciando o IP Core Block RAM (BRAM) v1.00a, com o controlador (interface com o barramento) PLB Block RAM (BRAM) Interface Controller v1.00b. Na Figura 35 está o Diagrama do controlador BRAM [6]. 43

61 Figura 35 Diagrama do Controlador PLB BRAM Esta memória pode conter o código de pequenas aplicações (como por exemplo a aplicação de teste da memória gerada automaticamente pelo EDK), ou apenas os dados de boot do processador. A associação entre os pinos da FPGA e os sinais internos dos vários blocos - instâncias dos IP Cores, é feita de forma automática pelo programa de desenvolvimento EDK, aquando da especificação inicial (na criação do projecto) dos componentes de hardware físico presentes na placa que desejamos utilizar no nosso sistema. 44

62 A Tabela 15 contém um resumo de alguns dos componentes utilizados no design do Web server que formam a parte constituinte de hardware. Tabela 15 - Alguns componentes do design do Web Server Dispositivo Versão Endereço Low High Instância Bus Processador embebido PowerPC a N/D ppc405_0 PLB OPB UARTLite 1.00.b 0x x4060ffff RS232_Uart OPB PLB DDR 1.11.a 0x x03ffffff DDR_SDRAM_ 64Mx32 PLB Ethernet 1.01.a 0x x8040ffff Ethernet_MAC PLB EMC 2.00.a 0x x060fffff SRAM_256Kx32 PLB Controlador PLB BRAM IF 1.00.b 0xffff8000 0xffffffff plb_bram_if_cntlr_ 1 N/D Controlador Conecta o 2.00.a N/D jtagppc_0 JTAGPPC_CNTLR PowerPC à cadeia JTAG OPB INTC 1.00.c 0x x4120ffff opb_intc_0 OPB Esta secção termina a parte da implementação relativa ao Servidor Web. Segue-se a implementação relativa ao Módulo de interacção com a câmera digital Módulo de interacção com a câmara O Core existente do grupo SIPS, não é suficiente por si só para ser possível ao servidor web obter as imagens. Foram necessárias alterações ao IP existente e também foi necessário criar um novo IP. Para a aplicação conseguir ler a frame do módulo criou-se um Core novo (FIFO BRIDGE fifo_bridge no EDK) que funciona como intermediário entre o Core VHDL e o sistema (ligado ao bus partilhado OPB) ver Figura

63 FIFO BRIDGE Bus OPB OPB IPIF Lógica do Utilizador Módulo do SIPS (alterado) Figura 36 Diagrama de Blocos ilustrativa da inclusão da Câmara no Servidor Web O IP Core criado, além da lógica do utilizador, é também constituído por um módulo OPB IPIF (OPB IP Interface) - que liga este Core ao bus OPB (como slave) e inclui serviços como de FIFOs de Escrita/Leitura. Este módulo é criado pelo EDK com uma interface de alto nível, que permite ao programador incluir as funcionalidades desejadas de forma amigável. O diagrama de blocos do IP Core OPB IPIF é representado pela Figura 37. Bus OPB Figura 37 Diagrama de blocos do IP Core OPB IPIF 46

64 Este Core oferece serviços como os representados a linha tracejada ao utilizador, os quais na sua maior parte são de entrada ou saída de dados. O elemento de base do componente é a ligação slave (Slave Attachement) que permite a funcionalidade base de operação slave OPB. O módulo IPIC (IP InterConnect) é uma interface que permite a ligação de um Core a uma interface de bus (PLB IPIF ou OPB IPIF). Na Figura 38 está uma representação ilustrativa da relação entre o Core do utilizador; IPIC e IPIF. Figura 38 Cenário de utilização do IP Core IPIC Na Figura 39 está o diagrama de blocos do IP Core IPIF que foi instanciado neste projecto. Figura 39 Diagrama de Blocos do IP Core IPIF associado ao IP FIFO BRIDGE Como se pode observar, o único serviço escolhido foi a READ FIFO. Este Core FIFO BRIDGE inclui uma FIFO com 512 posições e largura de 32 bits (igual à largura do barramento OPB), a qual será lida pela aplicação. Contém um contador, de 0 a 8192, que corresponde ao número de pixeis de uma frame sendo assim de 13 bits - e um sinal de habilitação - enable. Sempre que existe um impulso de relógio, se a FIFO não estiver cheia será escrito um novo valor na FIFO (levando a high um sinal para o efeito), o contador incrementado de uma unidade e o sinal enable a high. Os dados são obtidos de uma block 47

65 RAM do Core main do SIPS, em que o contador da FIFO BRIDGE é o endereço de leitura e o enable é o Enable de Leitura. A Figura 40 contém um fluxograma que representa o algoritmo de inserção de um novo elemento na FIFO. Rising_Edge(Clock) N S FIFO CHEIA == 0 N S Escrever na FIFO (IP2RFIFO_WrReq= 1 ) Endereço de Leitura+=1 enable= 1 IP2RFIFO_WrReq= 0 enable= 0 Figura 40 Algoritmo de inserção de um elemento na FIFO do IP Core FIFO BRIDGE O formato de cada elemento da FIFO é o representado na Figura 41. Figura 41 Formato dos dados da FIFO do IP FIFO BRIDGE O bit 22, o enable, apenas é escrito para efeito de debug não tendo qualquer aplicação depois no servidor Web. O facto de existirem bits não utilizados, deve-se ao facto de que a FIFO terá de ter a mesma largura que o bus a que está ligado - 32 bits. O módulo físico do SIPS inclui um conector representado pela Figura

66 Figura 42 Esquema do conector físico do SIPS Conector VGA O pino 1 é a entrada de GND e o pino 3 a alimentação de 3,3 V. Na Tabela 16 estão feitas as associações entre os pinos do conector do SIPS e os pinos da FPGA Virtex-4 FX12. Tabela 16 Associação dos sinais de interacção com a câmara a pinos Nome do sinal Descrição Direcção Pino no Conector do SIPS Pino da Virtex-4 FX Pino no Conector de expansão da ML403 exclk_o_pin Relógio para a câmera O 5 AA24 2 Comando de config_reg_i_pin 1 configuração de registos da I - V20 4 câmara vsync_i_pin I 8 AC25 6 href_i_pin I 10 AC24 8 Sincronização pwdn_o_pin O 11 W25 10 da Câmera cam_rst_o_pin O 12 Y24 14 pxl_clk_i_pin I 14 AB23 16 vs_o_pin Sincronização O 31 W26 18 hs_o_pin VGA O 32 Y26 20 SCL_o_pin SCL O 7 Y25 22 board_reset_i_pin 1 Comando de Reset I - AA26 24 yi_i_pin<7> I 13 AA23 26 yi_i_pin<6> I 16 AC21 28 yi_i_pin<5> I 15 AB26 30 yi_i_pin<4> Informação I 18 AC23 32 de bit da yi_i_pin<3> câmara I 17 AB25 34 yi_i_pin<2> I 20 AC26 38 yi_i_pin<1> I 19 AD26 40 yi_i_pin<0> I 22 AC22 42 y_o_pin<7> O 21 V21 46 y_o_pin<6> O 24 W22 48 y_o_pin<5> O 23 AD25 50 y_o_pin<4> Informação O 26 AB22 52 de bit para y_o_pin<3> VGA O 25 W21 54 y_o_pin<2> O 28 AB21 58 y_o_pin<1> O 27 AD22 60 y_o_pin<0> O 30 AE24 62 SDA_io_pin SDA IO 9 AF Estes sinais são sinais externos para dar os impulsos de comando de reset e configuração dos registos da câmera Esta secção termina a fase de implementação relativa ao hardware. Segue-se a implementação a nível de software. 49

67 3.2 Software Após o projecto da plataforma de hardware estar concluído, podemos iniciar o projecto do software. Os pontos de implementação do projecto de software são os seguintes: Sistema Operativo para permitir ligações simultâneas (através de threads) Aplicação Servidor Web Sistema de ficheiros para albergar os ficheiros html, entre outros Captura e processamento de frames de imagem Na Figura 43 está um diagrama que representa o fluxo de execução do software. Inicialização do Sistema de Ficheiros Início de Execução do Sistema Operativo Início do Servidor Web N Ligação de Cliente S Lançamento de Thread Figura 43 Fluxo de Execução do Software Após se iniciar o processamento do programa, o sistema de ficheiros em memória é inicializado e logo em seguida é iniciado o Sistema operativo. Por fim inicia-se o Servidor Web, que lança threads para satisfazer pedidos de clientes. As secções seguintes descrevem a implementação do software por pontos, como descrito anteriormente. 50

68 3.2.1 Sistema Operativo e Sistema de Ficheiros Dada a especificidade do sistema é suficiente um sistema operativo relativamente simples, que suporte pseudo-paralelismo de processamento, isto é escalonamento de threads e processos, assim como mecanismos de coordenação - IPC. O fabricante, disponibiliza juntamente com o EDK o sistema operativo Xilkernel que apresenta todos os requisitos referidos no parágrafo anterior. O Xilkernel é configurável, indicando os parâmetros de acordo com a especificidade do projecto. Na Tabela 17 estão os parâmetros definidos para o kernel embebido utilizado neste projecto Xilkernel. Tabela 17 Parâmetros de implementação do Kernel Embebido Xilkernel Parâmetro Valor Descrição PROC_INSTANCE ppc405_0 Processador embebido do sistema PPC405 SYSMR_FREQ Frequência do timer do sistema, igual à frequência do processador MAX_PTHREADS 100 Máximo de 100 threads que podem ser alocadas em qualquer momento PTHREAD_STACK_SIZE Dimensão do stack para threads alocadas (em bytes) MAX_READYQ processos que podem estão no estado activo em qualquer momento CONFIG_TIME true Inclusão de timers e inclusão de módulos de gestão de tempo MAX_TMRS 100 Número máximo de timers CONFIG_SEMA true Inclusão do módulo de semáforos MAX_SEM 25 Número máximo de semáforos MAX_SEM_WAITQ 100 Dimensão da fila de espera de cada semáforo DEBUG_MON true Mensagens de debug do kernel activas STDIN RS232_Uart stdin da Aplicação STDOUT RS232_Uart stdout da Aplicação SYSINTC_SPEC opb_intc_0 Nome da instância do controlador de interrupções CONFIG_DEBUG_SUPPORT true STATIC_PTHREAD_TABLE ((serverthread,1)) Tabela de threads lançadas no arranque do sistema operativo, com a respectiva prioridade 51

69 Com estes parâmetros define-se o stdin e stdout do sistema assim como as threads iniciais de execução aquando do lançamento do Kernel. Os valores definidos foram determinados com uma estimativa de utilização arbitrária - também o facto de termos memória disponível relativamente elevada (64MB) contribui para uma maior flexibilidade de implementação. Na prioridade entre threads o valor (inteiro, não negativo) de prioridade mais alta corresponde ao número 0. O sistema de ficheiros MFS (referido anteriormente) faz parte da entidade XMK e é o sistema de ficheiros escolhido, visto este assentar sobre memória volátil Servidor Web O servidor Web assenta sobre serviços do kernel Xilkernel serviços de rede, acesso ao sistema de ficheiros (criação, eliminação e de escrita/leitura) e mecanismos de IPC, nomeadamente semáforos. Na Figura 44 contém o fluxograma relativo à aplicação do Servidor Web. 52

70 Inicialização da Biblioteca lwip Criação do Socket de escuta no porto 80 Aguardar por ligações (accept) N Ligação de Cliente S Incrementar número de Ligações Lançamento de Thread (prioridade igual ao número de ligações) Pedido de HTML N Processar e Executar accção S Abrir e enviar Ficheiro Erro S Abrir ficheiro 404.html e enviar N N Erro S Enviar apenas mensagem HTTP/ NOT FOUND Terminar Thread Decrementar número de Ligações Figura 44 Fluxo de execução da aplicação do WebServer 53

71 O servidor Web ao ser iniciado, inicializa a biblioteca lwip, para a comunicação por sockets ficar disponível. Em seguida cria o socket de escuta, que ficará à espera de ligações. O Web Server aguarda por ligações no porto 80 (porto por defeito do http). Aquando da existência de uma conexão, uma variável que guarda o número de ligações activas será incrementa e a aplicação procurará responder ao pedido lançando uma nova thread, procurando o ficheiro respectivo (índex.html por defeito), caso seja um pedido de ficheiro html, no seu sistema de ficheiros residente em memória ou executando o comando correspondente (para processamento de imagem explicado na secção seguinte). Os comandos são do tipo GET. Se não puder satisfazer o pedido enviará a página de erro 404 ao utilizador. Caso não seja possível enviar o ficheiro 404.html, será enviada apenas uma mensagem http de código 404 Not Found. Na Tabela 18 estão os parâmetros relevantes de implementação da Biblioteca LwIP. Tabela 18 Parâmetros de implementação da biblioteca LwIP Parâmetro Valor Descrição API_MODE SOCKETS_API Modo de operação sockets (em conjunto com Xilkernel) PROC_INSTANCE ppc405_0 Instância do processador PPC405 MEM_SIZE Tamanho da memória heap (bytes) MEMP_NUM_TCP_SEG 510 Número de segmentos TCP em fila simultaneamente EMAC_INSTANCES ((Ethernet_MAC,0x01,0x02, 0x03,0x04,0x05,0x06)) Instâncias do Core Ethernet, referenciando o MAC address associado O cliente após receber a página index.html, visualizará a imagem da câmara, imagem esta que será actualizada automaticamente com um período de 1 s. A actualização automática é conseguida através da TAG de html: <META HTTP-EQUIV= Refresh CONTENT= 1; URL=index.html > 54

72 Esta forma de actualização automática foi escolhida por razões de simplicidade e funcionalidade, aliada ao facto que não sobrecarga o servidor o que aconteceria se estivesse a fazer streaming de video. Esta taxa de actualização deve-se à especificidade do projecto, não sendo necessário uma frame rate superior, evitando-se assim a sobrecarga do servidor Web e da rede Captura de imagem A captura de imagem é conseguida através da leitura sequencial de 8192 elementos da FIFO correspondentes ao número de pixeis de uma frame. O XMK oferece a possibilidade de aceder à FIFO do IP Core FIFO BRIDGE através de software, usando a primitiva XIo_In32(Endereço), bastando fornecer o endereço por argumento corresponente à FIFO endereço base do IP somado de 0x200 (como definido pelo módulo IPIF). Para demonstração da funcionalidade e potencialidade do sistema, a imagem correspondente à frame capturada é apresentada na página index.html, e são apresentadas opções de processamento de imagem, relativamente à cor e modo de imagem imagem de tempo real e detector de presença em relação a um estado inicial. Quando é pedida a página index.html, é necessário capturar uma frame, assim a aplicação irá ler a FIFO do core FIFO BRIDGE, que irá conter a informação dos pixeis. Cada elemento da FIFO contém a informação do pixel, luminância e endereço. A FIFO será lida enquanto não forem lidos 8192 pixeis diferentes. Na Figura 45 está representado um fluxograma que representa o fluxo de execução relativo à parte do software respeitante à captura de imagem. 55

73 Captura de Imagem sem perturbação Início do Servidor Web N Ligação de Cliente S Executar comando N Pedido de index.html S Capturar imagem de tempo real Modo de detector S Executar algoritmo de detecção N Escrever ficheiro de imagem Figura 45 Algoritmo relativo ao software de captação de imagem Visto o Core FIFO BRIDGE inserir pixeis na sequência correspondente ao endereço, não serão lidos pixeis repetidos, no entanto para uma independência da sequência de escrita na FIFO, existe um contador que indica o próximo pixel a ser lido, repetindo-se assim a leitura até se ler o pixel correspondente visto a frequência de amostragem dos pixeis e escrita na FIFO ser elevada, esta decisão de projecto não tem inconvenientes. O comandos podem ser de alteração de cor ou de alteração de luminosidade. Após capturar a frame será construído o ficheiro de imagem que integra a página Web. Visto só termos informação de luminância (256 níveis), a apresentação da imagem resume-se a tonalidades de uma cor arbitrária. 56

74 O formato de ficheiro escolhido a incluir na página Web foi o BMP, pela sua relativa simplicidade. O ficheiro BMP tem o formato representado na Figura 46. Cabeçalho Tabela RGB Dados Figura 46- Formato do ficheiro BMP O cabeçalho do ficheiro BMP diz respeito a formato da imagem, resolução, offset para os dados, etc. A tabela RGB, indica os valores de Red, Green e Blue para os 256 valores possíveis de cada pixel 8 bits de informação de cor. Para rentabilizar os recursos, são carregados ficheiros que contém o cabeçalho e tabela RGB para algumas cores. As tabelas RGB disponíveis são: Tons de cinzento Tons de vermelho Tons de verde Tons de azul Na Figura 47 está uma imagem exemplo em tons de cinzento retirada da câmara e na Figura 48 uma imagem em tons de verde. Figura 47 Imagem exemplo da câmara em tons de cizento Figura 48 - Imagem exemplo da câmara em tons de verde O outro modo de apresentação da imagem é o modo de detecção de presença. Este modo destina-se a apenas a mostrar a potencialidade do sistema em termos de processamento de imagem. Este modo utiliza um algoritmo relativamente simples aplicado sobretudo a imagens de escala de luminância que envolve a imagem obtida no momento com uma imagem considerada sem perturbação. O cenário de utilização deste modo de funcionamento será a vigilância de várias câmeras estáticas em que apenas será mostrada imagem aquando de alteração do background conhecido. 57

75 Como mostrado no fluxograma da Figura 45, é guardada em memória uma imagem de referência considerada sem perturbação antes da aceitação de ligações de clientes. Pretende-se determinar se a imagem capturada em tempo real contém a presença de alguém (ou algo). Esta determinação não pode ser trivial, comparando simplesmente pixel a pixel. Isto deve-se ao facto da imagem estar sujeita a ruído impulsivo 2 que deve ser filtrado como por exemplo as pequenas diferenças de luminosidade no tempo reduzindo falsos alarmes num cenário de vigilância. Sendo a sensibilidade do detector configurável, este modo pode ser adaptado consoante a especificidade de utilização. O algoritmo de filtragem é conhecido por filtro de média e compreende 4 passos: diferença e binarização; cálculo de média X; cálculo da média Y e classificação final. Na Figura 49 está um esquema representativo dos passos deste algoritmo. Imagem sem perturbação Imagem de tempo real Passo 2 Passo 3 Diferença e Binarização Média X Média Y Passo 4 Classificação Final Passo 1 Imagem Processada Figura 49 Esquema do algoritmo de Filtro de Média O Passo 1 consiste na criação de um vector (com 8192 elementos nº de pixeis de uma frame), que guarda o resultado da comparação pixel a pixel da imagem sem perturbação com a imagem obtida em tempo real 0 para igual; 1 para diferente. Visto a informação de pixel ser uma escala de luminância (0 255), podemos dar uma tolerância na diferença entre pixeis contribuindo para uma filtração do ruído. A implementação do filtro de média em duas componentes - X e Y - corresponde à implementação de dois filtros FIR 3 representados respectivamente por uma máscara horizontal e por uma máscara vertical. Segue-se um exemplo de filtragem de média 3x3 sobre uma imagem binarizada I, de dimensão 3x3 com elementos de valor constante 1. 2 Ruído Impulsivo - Forma particular de ruído que consiste de impulsos eléctricos não prognosticáveis, que superam a amplitude do sinal de informação. 3 Filtro FIR (Finite Impulse Response) - tipo de filtro digital caracterizado por uma resposta ao impulso que se torna nula após um tempo finito. 58

76 MédiaX MédiaY ImagemI = No exemplo foram utilizadas máscaras com somatórios não unitários, pelo que o resultado tem um ganho não unitário. Verifica-se que o valor máximo do resultado corresponde ao somatório da máscara conjunta Médiax*Médiay. Há que notar que a convolução considera margens com valores nulos na imagem original e produz um resultado de dimensão maior. Para uma abordagem mais simplista, a operação de média corresponde, para cada elemento, à soma dos valores vizinhos (na horizontal para a média X e na vertical para média Y) e do valor do próprio elemento o número de parcelas corresponde ao número de elementos da máscara. O Passo 4 Classificação consiste na classificação elemento a elemento como sendo evento ou não evento por exemplo 255 e 0 respectivamente. O critério tem a seguinte fórmula: Classificação i = SENSIBILIDADE * Elemento i / MASCARA 2 (1) Sendo SENSIBILIDADE um valor real de 0 a 1 (notar que aumenta a sensibilidade com a diminuição deste valor) e MASCARA uma valor ímpar maior que zero a máscara horizontal e vertical são iguais. Após o último passo, é criada uma imagem com base no vector contendo o resultado da classificação. No algoritmo implementado, a classificação de evento de um elemento é igual ao valor de luminância do elemento de tempo real, e a classificação de não evento, é igual a 0. Assim, apenas os pixeis de evento serão mostrados na imagem gerada, ficando o resto da imagem a preto desta forma num cenário de vigilância só a parte da imagem correspondente a alterações significativas será mostrada. Os parâmetros de detecção iniciais são os seguintes: Máscara para realização das médias 11 Sensibilidade 0,7 Tolerância de diferença de luminância entre pixeis 6 Seguem-se as imagens ilustrativas deste modo de funcionamento. Na Figura 50 está uma imagem que corresponde à imagem sem perturbação. Na Figura 51 está a imagem processada no modo de detector sem perturbações e na Figura 52 está a imagem com perturbações. 59

77 Figura 50 Imagem de background sem perturbações Figura 51 Imagem apresentada no modo detector (ausência de perturbações) Como se pode observar a imagem resultante é toda preta na ausência de perturbações. Figura 52 Imagem apresentada no modo detector com perturbações Esta imagem resultante do processamento apenas mostra a perturbação uma mão aberta. Esta secção termina o capítulo relativo à implementação do sistema. 60

78 4. Desempenho e utilização de recursos Este capítulo apresenta resultados do sistema hardware realizado, nomeadamente a ocupação de recursos na FPGA, e a frequência máxima de funcionamento (desempenho). A Tabela 19 resume a ocupação dos recursos dos núcleos utilizados (IP Cores). Tabela 19 Utilização dos recursos por instância de IP Core Slices Slice FlipFlops LUTs de 4 entradas Block RAM DCM s Instância usadas % de utilização usadas % de utilização usadas % de utilização Entradas/ Saídas usadas % de utilização usadas % de utilização ppc405_ jtag reset_block plb opb plb2opb rs232_uart ddr_sdram_ ethernet_mac sram_256k plb_bram_if_cntlr_ plb_bram_if_cntlr_1_bram opb_intc_ sram_256kx32_util_bus_split sysclk_inv clk90_inv ddr_clk90_inv Dcm_ Dcm_ main(modulo SIPS alterado) fifo_bridge Nota: Os valores em percentagem estão arredondados à unidade. Há que relembrar que a instância main é referente ao módulo alterado do SIPS. É importante notar que a instância relativa ao processador não tem qualquer utilização de lógica devido à existência do processador embebido na FPGA, como foi referido no Capítulo 3. O IP Core que utilizou mais recursos foi o núcleo relativo à Ethernet. 61

79 É possível ver o resumo da utilização da FPGA na Tabela 20. Tabela 20 Utilização dos recursos da FPGA Slices Slice FlipFlops LUTs de 4 entradas Block RAM DCM s FPGA usadas % de utilização usadas % de utilização usadas % de utilização Entradas/ Saídas externas usadas % de utilização usadas % de utilização Virtex-4 FX A Tabela 21 resume as frequências máximas de funcionamento de algumas instâncias de IP Cores. Tabela 21 Frequência máxima de trabalho de algumas instâncias instância Frequência máxima de funcionamento (MHz) reset_block 299,796 plb 186,235 opb 385,505 plb2opb 166,305 rs232_uart 221,912 ddr_sdram_64 149,454 ethernet_mac 112,355 sram_256k 150,808 plb_bram_if_cntlr_1 165,986 opb_intc_0 204,497 main 140,365 fifo_bridge 130,124 Estes valores são estimativas indicadas pela ferramenta de síntese de hardware do EDK. A Tabela 22 contém a informação relativa à frequência de trabalho do sistema e frequência interna do processado embebido. Tabela 22 Frequências de trabalho e utilização das memórias Frequência de trabalho (Mhz) Processador PPC Relógio do Sistema Global

80 Embora o sistema global esteja limitado a 100 MHz, a frequência elevada do processador contribui para um incremento da performance visto a frequência de processamento ser elevada. Na Tabela 23 é apresentada a ocupação das memórias físicas. A memória SRAM contém o sistema de ficheiros e a memória DDR, sendo a memória principal, contém o código da aplicação. Tabela 23 Ocupação das memórias físicas Sistema de Ficheiros MFS (Memória SRAM) Máxima disponível (KB) 1024 Tamanho de bloco (bytes) 532 Blocos usados/total 43/700 Tamanho total da memória do sistema de ficheiros (bytes) Memória Principal (DDR SDRAM) Máxima disponível (MB) 64 Usada (bytes) A memória SRAM é usada exclusivamente para o sistema de ficheiros o que torna de certa forma irrelevante a sua ocupação desde que o espaço definido para o sistema de ficheiros seja suficiente para albergar os ficheiros integrantes do sistema. A memória DDR contém o código da aplicação do servidor Web. Esta ocupação não é definida directamente em projecto. A ocupação da memória está dividida em segmentos (por exemplo o stack e o heap) e estes segmentos são definidos automaticamente pelo EDK com base nos parâmetros de implementação do sistema operativo e da biblioteca LwIP. Relativamente ao desempenho do sistema este é condicionado como seria de esperar pelas condições da rede em que está inserido. Foram realizados testes em condições ideais de ausência de congestionamento da rede - sistema ligado a 1 PC através de cabo cruzado que revelaram que os tempos de resposta aos pedidos do utilizador são desprezáveis face ao intervalo de actualização da página (1 s). 63

81 64

82 5. Funcionalidades e Manual do Servidor Web Este capítulo pretende mostrar e explicar a interface com o utilizador do sistema desenvolvido. Na Figura 53 está a página principal (index.html) do servidor Web. Figura 53 - Página HTML principal (index.html) do Web Server Esta é a página HTML principal do sistema, onde são apresentados a imagem da câmara e os mecanismos de interacção com o sistema. Como é visível na Figura 53 é possível o utilizador remotamente alterar o modo de funcionamento do servidor Web modo de apresentação de imagem real ou modo de detector de presença e também as características relativamente à apresentação da imagem luminosidade e cor de base. Na Figura 54 está a página html 404.html. 65