Sistema de Comunicação para o Sistema PET Mamografia

Transcrição

1 Sistema de Comunicação para o Sistema PET Mamografia Baseado nos Protocolos PCI e USB Vasco Miguel Bexiga António Dissertação para obtenção do Grau de Mestre em Engenharia Electrotécnica e de Computadores Júri Presidente: Prof. José Beltrán Gerald Orientador: Profª. Isabel Maria Silva Parreira Cacho Teixeira Co-orientador: Prof. João Paulo Cacho Teixeira Vogais: Prof. Marcelino Santos Setembro de 2008

2

3 NOTA Neste documento, utilizam-se em determinadas circunstâncias os termos anglo-saxónicos embora se proponha uma tradução para o Português. Esta decisão fundamenta-se no facto de que há termos para os quais não há em Português, tanto quanto é do conhecimento do autor, uma designação consensual e cujas designações anglo-saxónicas são amplamente conhecidas e cuja semântica é incontroversa no âmbito da Engenharia Electrotécnica e de Computadores. Os termos em inglês são apresentados, na dissertação, em itálico. Por outro lado, tendo este trabalho sido desenvolvido no âmbito de um projecto em que a documentação e todas as publicações em conferências e revistas internacionais são obrigatoriamente escritas em Inglês, utilizam-se na dissertação as siglas em inglês que referem os diferentes módulos constituintes do sistema. Evita-se desta forma ambiguidades de notação se se pesquisar alguma das referências bibliográficas incluídas neste documento. Alguns dos diagramas detalhados das arquitecturas dos vários módulos que foram desenvolvidos são de dimensões relativamente grandes. Para permitir a leitura desses diagramas optou-se por incluí-los em anexo (por vezes em formato A3), incluindo no texto da Dissertação os diagramas de blocos das referidas arquitecturas. I

4 II

5 Agradecimentos Gostaria de expressar o meu profundo agradecimento à Professora Isabel Cacho Teixeira, pelo seu precioso auxílio e encorajamento ao longo de todo o trabalho realizado e principalmente pela enorme paciência demonstrada na revisão desse documento. Queria também agradecer o apoio prestado pelo Professor João Paulo Teixeira durante a realização deste projecto. Gostaria de agradecer ao Professor João Varela pela oportunidade de participar num projecto desta dimensão. Queria agradecer ao meu colega e amigo Pedro Machado pela sua cooperação neste projecto e pelo espírito de equipa demonstrado. Queria agradecer aos meus amigos e aos meus colegas do INESC-ID (Carlos Leong) e INOV (Joel Rego, Fernando Piedade, Pedro Neves e Pedro Lousã) por todo o apoio, amizade e compreensão. Gostaria de deixar uma palavra de apreço a todos os colegas que pertencem ao consórcio em que se insere este projecto. Gostaria de agradecer à minha família que nunca deixou de acreditar em mim e de me apoiar ao longo de todos os meus projectos pessoais e profissionais. III

6 IV

7 Resumo O trabalho que se apresenta nesta Dissertação foi desenvolvido no âmbito do Projecto PET. Este projecto tem como objectivo desenvolver um sistema de detecção de cancro da mama, baseado em tecnologia PET (Positron Emission Tomography), que permita detectar lesões de dimensões tão reduzidas quanto 2 mm. Esta resolução é bastante superior à conseguida através de sistemas PET de corpo inteiro e também superiores à conseguida através de métodos tradicionais baseados no Raio-X. Um sistema deste tipo envolve a geração de uma grande quantidade de dados. Por tal, o sistema deve ser de elevado desempenho. Adicionalmente, deve ser tão robusto e tão preciso quanto possível. Os dados gerados no exame são detectados por um scanner e processados por um sistema electrónico. Estes dados são posteriormente enviados para um computador para reconstituição de imagem. O sistema que constitui o principal objecto deste trabalho é o desenvolvimento do sistema de comunicação entre o sistema electrónico e o computador. Neste trabalho são apresentadas duas soluções para este sistema de comunicação, baseados em dois protocolos de comunicação, nomeadamente, os protocolos PCI e o protocolo USB. A primeira solução é baseada na utilização de um circuito integrado dedicado e implementa um conjunto de funções do protocolo PCI. A segunda solução baseia-se na utilização do protocolo USB em conjunto com um protocolo proprietário do CERN. Na dissertação apresentam-se os estudos realizados, o projecto, a implementação e a sua validação por simulação e por testes laboratoriais realizados no enquadramento do sistema completo. Palavras-chave Sistema PEM, Transmissão de Dados, Fiabilidade, Desempenho, PCI, USB. V

8 VI

9 Abstract The work presented in this Dissertation has been developed in the context of the project PET. This project aims at the development of a PET (Positron Emission Tomography) based system for detection of breast cancer that allows the identification of lesions with dimensions as small as 2 mm. This resolution is far superior to the resolution of whole body PET systems, and is also superior to the one obtained with traditional X-Ray based methods. Such a system involves the generation of a huge amount of data. Therefore, a high performance system is required. Additionally, it should be as robust and as accurate as possible. Data generated in the exam is detected by a scanner and processed by an electronic system. These data are afterwards sent to a computer for image reconstruction. The system that constitutes the object of this work is the development of a system that establishes the communication between the electronics system and the computer. Two solutions, based on two distinct communication protocols, in particular, the PCI protocol and the USB protocol are presented for this communication system. The first solution is based on the use of a dedicated electronic device and implements a set of the PCI functions. The second solution is based on the use of the USB protocol together with a proprietary protocol developed by CERN. This dissertation presents the studies, design, implementation, validation by simulation and laboratorial tests conducted in the framework of the complete system. Keywords PEM System, Data Transmission, Reliability, Performance, PCI, USB. VII

10 VIII

11 Índice NOTA... I Agradecimentos... III Resumo... V Abstract... VII Índice... IX Lista de Figuras... xiii Lista de Tabelas... xv Lista de Acrónimos Introdução Contexto e Motivação Enquadramento do Sistema de Comunicação Objectivos do Trabalho Contribuições Relevantes Organização da Dissertação Sistema PEM Princípio de Funcionamento do Sistema PEM Arquitectura do Sistema PEM Organização dos Planos de Cristais Electrónica de Front-End Caracterização dos Sinais Tipos de Eventos Electrónica de Aquisição de Dados Requisitos do sistema DAE Cenários de Funcionamento do DAE Arquitectura do sistema DAE Subsistema de Qualificação e Filtragem de Dados Módulo de Aquisição de Dados Módulo de Filtragem Módulo Trigger Subsistema de Organização e Encaminhamentos de Dados IX

12 3.5.1 Unidade de Memória Concentrator de Dados Interface de Comunicação DAE PC Requisitos da Interface de Comunicação Requisitos de Desempenho Requisitos Funcionais Formato dos Comandos Dados de Calibração do Sistema Dados Relevantes (amostras associadas a fotoeventos) Protocolos de Comunicação Solução PCI Ponte PCI-to-PCI Dispositivo QL Arquitectura do Dispositivo QL Arquitectura da Interface PCI / TGR Arquitectura da FPGA do QL Controlador Blast Mode FIFO Blast Mode Controlador das FIFOs Protocolo de Comunicação Registos de Configuração Simulação da Interface de Comunicação Ambiente de Simulação Validação Funcional e de Desempenho Resultados de Simulação Implementação Física e Teste Testes de Laboratório Emulação de um Barramento PCI Secundário Árbitro Gestão RST/REQ Modelo (firmware) da TGR/DCC X

13 Módulo de Entrada FIFO de Resposta a Comandos Módulo de simulação de exame FIFO de simulação de exame Módulo de Saída Resultados da Solução PCI Solução USB/S-LINK Interface USB Cenários de Comunicação USB Arquitectura do Módulo de Comunicação Microcontrolador Cypress FX2LP Comunicação FX2LP-TGR/DCC Operação de Leitura Operação de Escrita Módulo de Comunicação Módulo de Comunicação via USB Memórias FIFOs do Módulo de Comunicação via USB Controlador do Módulo de Comunicação via USB Alterações ao DCC ROC Implementação Física do Módulo de Comunicação Simulação e Teste Simulação do Modulo de Comunicação via USB Teste Laboratorial do Módulo de Comunicação via USB Simulação do Sistema DAE com o Módulo de Comunicação via USB Teste Laboratorial do Sistema DAE com o Módulo de Comunicação via USB Resultados do Teste Laboratorial Conclusões e Trabalho Futuro Referências XI

14 XII

15 Lista de Figuras Figura Mamografia obtida: com Raios-X (a) e com PET (b)... 1 Figura Arquitectura de Topo do sistema PEM... 3 Figura 2-1 Conceito PEM (a) e fotografia do robot (b)... 7 Figura 2-2 Princípio de funcionamento dos detectores... 8 Figura 2-3 Detecção da posição do tumor pela intersecção de várias trajectórias... 8 Figura Arquitectura do sistema PEM... 9 Figura 2-5 Módulo de 32 cristais Figura 2-6 Cristal associado a dois APD s Figura 2-7 Matriz de 32 células fotossensíveis Figura 2-8 Formato do sinal produzido pelo ASIC Figura 2-9 Efeito de Compton Figura 3-1 Arquitectura de alto-nível do sistema DAE Figura 3-2 Subsistemas e blocos constituintes do sistema DAE Figura 3-3 Exemplo de um sinal de entrada e uso do parâmetro Delta Figura 4-1 Arquitectura detalhada do Sistema DAE Figura 4-2 Arquitectura da Interface entre DCC e PC Figura 5-1 Arquitectura da solução PCI implementada na TGR/DCC Figura 5-2 Arquitectura da solução PCI Figura 5-3 Placa PCI-SB (a) Placa PMC-SB (b) Figura 5-4 Diagrama de blocos do QL Figura 5-5 Sinais das interfaces entre o core PCI e a FPGA e PCI Figura 5-6 Sinais das interfaces entre a FPGA do QL5064 e o módulo TGR/DCC Figura 5-7 Arquitectura da FPGA do QL Figura 5-8 Controlador Blast Mode Figura 5-9 Máquina de estados do controlador Blast Mode Figura 5-10 FIFO Blast mode Figura 5-11 Controlador das FIFOs Figura 5-12 Protocolo de comunicação TGR/DCC QL Figura 5-13 Ambiente de simulação Figura 5-14 Placa TGR com o QL5064 (a) e com a PMC-SB (b) Figura 5-15 Bancada de teste Figura 5-16 Medição dos sinais da FIFO Single Mode Figura 5-17 Medição dos sinais da FIFO Blast Mode Figura Diagrama temporal do uso dos sinais RST# e REQ64# na inicialização Figura 5-19 Esquema do módulo REQ64# Figura 5-20 Arquitectura do emulador da TGR/DCC Figura 5-21 Módulo de entrada Figura 5-22 FIFO de resposta a comandos XIII

16 Figura 5-23 Módulo de simulação de exame Figura 5-24 FIFO de simulação de exame Figura 5-25 Módulo de saída Figura 5-26 Detecção do sistema pelo Sistema Operativo Figura 5-27 Diagrama de blocos da solução USB & S-LINK Figura 6-1 Arquitectura TGR/DCC com o módulo de comunicação Figura 6-2 Diagrama de blocos do microcontrolador Cypress FX2LP Figura 6-3 Diagrama de blocos da interface de comunicação com o Cypress FX2LP Figura Interface das FIFOs do FX2LP Figura 6-5 Interface de leitura entre a FPGA TGR/DCC e o FX2LP Figura 6-6 Diagrama temporal da operação de leitura na FIFO do FX2LP Figura Interface de escrita entre a FPGA TGR/DCC e o FX2LP Figura Diagrama temporal da operação de escrita na FIFO do FX2LP Figura 6-9 Diagrama de blocos do módulo de comunicação na FPGA TGR/DCC Figura 6-10 Interface do módulo USB Figura 6-11 Memórias FIFO (a) dados para o PC; (b) dados do PC Figura 6-12 Sinais usados no controlador USB Figura Solução Óptica para a comunicação entre o DAE e o PC XIV

17 Lista de Tabelas Tabela 4-1 Protocolos de comunicação mais usuais em PCs comerciais Tabela 5-1 Configuração dos DIP Switch das placas Starfabric Tabela 5-2 Modos de funcionamento dos blocos de memória RAM Tabela Descrição dos sinais do controlador Blast mode Tabela 5-4 Descrição dos sinais da FIFO Blast Mode Tabela 5-5 Descrição dos sinais do controlador das FIFOs Tabela 5-6 Registos de configuração do QL Tabela 5-7 Medições dos sinais das FIFOs Tabela 5-8 Requisitos de tempo dos sinais RST# e REQ64# Tabela 5-9 Sinais do módulo de entrada da TGR/DCC Tabela 5-10 Sinais da FIFO de resposta a comandos Tabela 5-11 Sinais do módulo de exame Tabela 5-12 Sinais da FIFO de simulação de exame Tabela 5-13 Sinais do módulo de saída da TGR/DCC Tabela 6-1 Parâmetros da operação de leitura da FIFO do FX2LP Tabela Parâmetros da operação de escrita da FIFO do FX2LP Tabela 6-3 Sinais da interface do DCC ROC com o módulo USB Tabela 6-4 Sinais usados pelas FIFOs do módulo USB Tabela 6-5 Descrição dos sinais usados pelo controlador USB XV

18 XVI

19 Lista de Acrónimos ADI Agência de Inovação APD Avalanche Photo Diodes ASIC Application Specific Integrated Circuit BAR - Base Address Regions BIST Built-In Self-Test DAE Data Acquisition Electronics DAQ Data Acquisition Module DBUS - Dedicated Bus DCC Data Concentrator DIP Switches - Dual-in Line Package Switches DMA Direct Memory Access FE Front-End electronics FE-EMU - Front End Emulator FIFO First In First Out FLT Filter Module FPGA Field Programmable Gate Array GBUS - Generic Bus IBEB Instituto de Biofísica e Engenharia Biomédica IBILI Instituto Biomédico de Investigação em Luz e Imagem INEGI Instituto de Engenharia e Gestão Industrial INESC Instituto de Engenharia de Sistemas e Computadores INESC-ID INESC Investigação e Desenvolvimento INOV INESC Inovação IPO - Instituto Português de Oncologia IST - Instituto Superior Técnico LIP Laboratório de Instrumentação e Física Experimental de Partículas PC Personal Computer PCI Peripheral Component Interconnect PEM Position Emission Mammography PET Position Emission Tomography RIC - Read-In Controller ROC Read Out Controller S-LINK - Simple Link Interface SIE Serial Interface Engine TGR Trigger Module USB - Universal Serial Bus VHDL Very high-level Hardware Description Language XVII

20 XVIII

21 1. Introdução 1.1. Contexto e Motivação A investigação científica no meio médico tem evoluído significativamente nos últimos anos, praticamente em todos os domínios de intervenção médica. Um dos aspectos que tem sido particularmente considerado tem a ver com a procura de soluções e meios de diagnóstico para a detecção de doenças de índices de mortalidade elevados. Uma das causas porque se procuram tão afincadamente meios de diagnósticos precisos, que permitam identificar as várias doenças nos seus estágios iniciais de desenvolvimento é que a cura de tais doenças depende da sua detecção precoce. Está neste caso o cancro da mama, que é, no mundo desenvolvido, uma das primeiras causas de morte entre as mulheres [1] [2] [3]. A cura desta doença, ou pelo menos a redução dos seus efeitos, é tanto mais provável quanto mais cedo for realizado o seu diagnóstico. De facto, o número de mortes provocadas por este tipo de lesão têm vindo a descer ao longo dos anos, em grande parte devido à combinação da existência de tratamentos mais efectivos e meios de diagnóstico mais eficazes, nomeadamente no que se refere à capacidade de detecção do tumor nos seus estágios iniciais. Actualmente, o método mais usado na detecção do cancro da mama é a mamografia [3], baseada na utilização de Raios X. Essa técnica não fornece, contudo, a precisão necessária para uma detecção do tumor quando as suas dimensões são muito reduzidas, permitindo detectar tumores com dimensões mínimas da ordem dos 10 mm [3]. Assim embora permita a detecção de cerca de 80% dos casos, o diagnóstico é sempre confirmado com a realização de uma biopsia a fim de eliminar falsos casos. Uma técnica alternativa de exame é o recurso a sistemas PET (Positron Emission Tomography). Esta última tecnologia permite obter imagens de resolução consideravelmente maior. Na Figura 1-1, ilustram-se imagens obtidas com sistemas de Raios X e PET. Como pode observar-se, a diferença de nitidez entre as duas imagens é significativa. (a) (b) Figura Mamografia obtida: com Raios-X (a) e com PET (b) - 1 -

22 A utilização de sistemas PET de corpo inteiro para mamografia, apesar de conduzir a resultados melhores que os obtidos com Raios X, não têm ainda a resolução necessária para uma detecção de tumores de dimensão significativamente inferiores. Porém, estudos teóricos indicam que aproximando os sistemas de detecção de radiação (scanners) do órgão sob observação é possível aumentar a resolução do diagnóstico [5] [6] [7], isto é, detectar células cancerosas de dimensões da ordem de poucos mm. Este conhecimento criou a motivação necessária para se tentar desenvolver um sistema em tecnologia PET dedicado à detecção de cancro da mama 1. Para este efeito, foi criado o consórcio PEM 2, com o objectivo de desenvolver o sistema PEM (Positron Emission Mammography) [8] [9] [10] [11] [12] [13] [14] [15] para a detecção de cancro da mama. A resolução de diagnóstico esperada com este sistema é da ordem de 1 a 2 mm. Para a realização de tal sistema, o consórcio PET tem submetido vários projectos à ADI (Agência de Inovação). Foi no âmbito destes projectos que se iniciaram de forma concertada todos os trabalhos para o desenvolvimento do sistema PEM. O trabalho que é objecto desta dissertação insere-se no sistema de comunicação de dados entre a componente electrónica de aquisição e processamento de sinais e um computador externo responsável pela reconstituição de imagem, dois subsistemas fundamentais do sistema PEM Enquadramento do Sistema de Comunicação Os sistemas de tecnologia PET baseiam-se na detecção de fotões de raios gama emitidos pelo corpo humano quando injectado por uma substância radioactiva (marcador). Cada colisão ocorrida numa célula entre partículas da célula e partículas do marcador emite 2 fotões que se deslocam em trajectórias rectilíneas e em direcções opostas. Os fotões emitidos são detectados por cristais cintilantes, que reagem com os fotões libertando energia sob a forma de luz. A energia dos impulsos luminosos é proporcional à intensidade da emissão detectada pelos cristais. Essa energia luminosa pode ser transformada em impulsos eléctricos através de transdutores adequados. Estes sinais eléctricos são adquiridos e processados por um sistema electrónico de grande complexidade, DAE (Data Acquisition Electronics), que tem como objectivo identificar e separar os dados significativos ou relevantes, isto é, os dados que possam indiciar a presença de células cancerígenas. Posteriormente, estes dados relevantes são enviados para um computador externo, onde através de algoritmos adequados se procede à reconstituição da imagem que por sua vez constitui a base do diagnóstico. 1 A iniciativa partiu do Prof. João Varela, docente do IST (Instituto Superior Técnico) e investigador do LIP (Laboratório de Instrumentação e Física Experimental de Partículas) e do CERN (Centre European de Recherche Nucleaire). É actualmente o coordenador científico deste projecto. 2 O consórcio é constituído pelas Instituições seguintes: Tagus Parque, (LIP), INESC Inovação (INOV), INESC Investigação e Desenvolvimento (INESC-ID), Instituto de Engenharia e Gestão Industrial (INEGI), Instituto de Biofísica e Engenharia Biomédica (IBEB) da Faculdade de Ciências Universidade de Lisboa, Instituto de Biomédico de Investigação em Luz e Imagem (IBILI) da Faculdade de Medicina Universidade de Coimbra, e Hospital Garcia da Orta

23 Assim, e muito sucintamente, o sistema PEM é composto por 3 grandes subsistemas (ver Figura 1-2). Um scanner constituído por planos paralelos de cristais cintilantes detecta a radiação emitida pelas células humanas. O sistema DAE é responsável pela aquisição e processamento electrónico dos dados adquiridos. Finalmente, um ou mais computadores recolhem os dados processados electronicamente e utilizam-nos para reconstituição de imagem. Figura Arquitectura de Topo do sistema PEM É necessário que os dados provenientes de FE (Front-End Electronics) e processados pelo sistema electrónico sejam transmitidos de forma fiável e tão rapidamente quanto possível para os computadores de reconstituição de imagem. O primeiro requisito, a fiabilidade, advém do facto de que não são admissíveis diagnósticos incorrectos. De facto, trata-se de uma doença muito séria, pelo que um diagnóstico errado poderia ter efeitos devastadores na pessoa que o ouve. Daí a necessidade de garantir uma comunicação fiável e segura. O segundo requisito, a rapidez, resulta do facto de que o exame deve ser realizado tão rapidamente quanto possível, na medida em que se trata de um exame traumático para a paciente [16]. Estes requisitos justificam a necessidade de se dispor de um sistema eficiente e fiável de comunicação entre o DAE e o computador de reconstituição de imagem. O sistema de comunicação entre a electrónica de aquisição e processamento de sinais e o computador externo é pois um componente crítico do sistema PEM. O trabalho que se descreve nesta Dissertação refere-se ao desenvolvimento deste sistema de interface e comunicação entre o sistema de processamento electrónico de dados e os computadores para reconstituição de imagem Objectivos do Trabalho O trabalho que se descreve nesta dissertação visa genericamente, o estudo, desenvolvimento, implementação e validação de um sistema de comunicação bidireccional entre o sistema DAE do sistema PEM, e um PC exterior. O sistema de comunicação deve assegurar: - 3 -

24 Transferência de dados e de comandos, quer de configuração quer de controlo, do PC para o sistema DAE, relativa a: o Dados de calibração; o Indicação do modo de operação do sistema; o Ordem de inicio de auto-teste; o Pedido de indicação de relatório de erros; o Pedido de indicação de status. Transferência de dados entre o sistema DAE e o PC relativamente a: o Dados relativos ao exame médico; o Respostas a comandos do PC. Pretende-se ainda que: As soluções desenvolvidas se baseiem em componentes e protocolos standards ou compatíveis com os standards de comunicação mais usuais; Os tempos de desenvolvimento do sistema não prejudiquem o andamento do projecto; Os custos das soluções sejam tão reduzidos quanto possível; A arquitectura desenvolvida seja flexível para ser adaptável a actualizações; No sistema final, se atinja uma taxa de transferência mínima de 250 MB/s Contribuições Relevantes O desenvolvimento de um sistema de comunicação, que não é meramente um sistema genérico a ser configurado depois para aplicações específicas, mas um sistema de comunicação que deve funcionar inserido num sistema maior, e que deve ser desenvolvido dentro de prazos constitui um trabalho de vulto que exige uma equipa de desenvolvimento. Neste caso, duas pessoas trabalharam no estudo de soluções possíveis para o problema em análise. Desenvolveram arquitecturas, validaram a sua funcionalidade e avaliaram o seu desempenho. O trabalho que constitui objecto desta Dissertação refere-se ao trabalho efectuado, pelo autor, no desenvolvimento do sistema de comunicação. No entanto e de forma a facilitar a compreensão do que foi feito, irão ser feito algumas referências e breves descrições do trabalho realizado pelo segundo membro da equipa, no âmbito do mesmo trabalho. Destacam-se nesta secção, as contribuições relevantes para o desenvolvimento do sistema de comunicação do sistema PEM

25 Estudo da viabilidade da implementação de um sistema de comunicação baseado no protocolo PCI. Este estudo envolveu: o o o o Procura de soluções tecnológicas para a implementação do protocolo PCI; Estudo do dispositivo QL5064; Desenvolvimento (desenho e simulação) do sistema de comunicação PC DAE; Implementação física e teste laboratorial do sistema de comunicação PC DAE inserido na placa TGR/DCC do sistema DAE. Estudo da viabilidade da implementação de um sistema de comunicação baseado nos protocolos USB e S-LINK: o o o o Desenvolvimento e implementação física de um sistema de comunicação baseado no protocolo USB e S-LINK. Neste âmbito, foi desenvolvido, na FPGA da TGR/DCC, o módulo de comunicação via canal USB e S-LINK, que permite, enviar os dados gerados quer na TGR/DCC quer no PC; Desenvolvimento do ambiente de simulação e teste laboratorial deste sistema como elemento genérico; Inserção do sistema de comunicação no sistema DAE; Desenvolvimento do ambiente de simulação deste sistema com dados reais Organização da Dissertação Esta Dissertação está organizada do seguinte modo. No capítulo inicial apresentam-se o problema, o seu contexto e a motivação para a procura de soluções. Nos capítulos 2 e 3 descreve-se brevemente o sistema PEM, no âmbito do qual se enquadra o trabalho desenvolvido e ainda o sistema electrónico de aquisição e processamento de dados do sistema PEM, destacando-se a subsistema electrónico que mais directamente condiciona o sistema de comunicação a desenvolver. No capítulo 4 descreve-se a interface de comunicação que se pretende desenvolver, na perspectiva da identificação dos seus requisitos funcionais e de desempenho e analisam-se protocolos que podem satisfazer tais requisitos. No capítulo 5 descreve-se o trabalho realizado em torno da implementação do protocolo PCI, nomeadamente, as tecnologias de implementação possíveis, o desenvolvimento da arquitectura, os resultados de simulação, a sua realização física e os resultados dos testes laboratoriais. No capítulo 6 descreve-se o trabalho realizado em torno da implementação do protocolo USB, o desenvolvimento da arquitectura, os resultados de simulação, a realização física e os resultados dos testes laboratoriais. Nos capítulos 7 e 8 apresentam-se as conclusões e o trabalho futuro. Apresentam-se seguidamente as referências e finalmente um conjunto de anexos contendo informação importante mas não crítica para a compreensão do trabalho descrito

26 - 6 -

27 2. Sistema PEM O sistema PEM baseia-se no princípio de funcionamento da tecnologia PET aplicada tradicionalmente a sistemas de exame de corpo inteiro. Como foi referido anteriormente, o âmbito de aplicação do sistema PEM é o exame da glândula mamária e também da axila. Estudos teóricos, baseados em modelos estatísticos, demonstram que por aproximar os detectores de radiação (scanners) do órgão sob exame se obtêm imagens com resolução consideravelmente mais elevada que nos sistemas PET tradicionais, e consequentemente, permitindo diagnósticos mais precisos, em tempos de exame bastante mais curtos. As simulações realizadas com os modelos referidos, e o recurso a algoritmos inovadores de reconstrução de imagem [17][18][19][20][21], indicam que é possível detectar tumores com dimensões tão diminutas quanto a 1-2 mm (com tempos de exame satisfatórios). Na Figura 2-1 pode-se observar o conceito subjacente ao sistema de mamografia PEM e ainda uma fotografia do robot construído 3 para este primeiro protótipo. (a) (b) Figura 2-1 Conceito PEM (a) e fotografia do robot (b) 2.1. Princípio de Funcionamento do Sistema PEM A fim de avaliar a natureza e a quantidade de dados a processar e transmitir num sistema deste tipo, justifica-se a descrição breve do seu princípio de funcionamento. Assim, num sistema PET, a possível presença de células cancerígenas é assinalada pela emissão de radiação emitida pelas células humanas quando reagem com uma solução radioactiva, designada genericamente por marcador. No sistema PEM, o paciente é injectado com uma solução radioactiva, composta por moléculas similares à glicose agregada ao marcador F18 (fluorodeoxyglucose F18) ( 18 F-FDG) [3][7][22]. Todas as células do corpo humano reagem com esta solução e em consequência emitem radiação. Porém, o metabolismo de células cancerígenas faz com que estas células absorvam uma quantidade de glicose maior do que as células saudáveis e por conseguinte uma maior quantidade da 3 O robot foi realizado pelo INEGI (Instituto de Engenharia e Gestão Industrial) do Porto

28 solução. A emissão de fotões pelas células cancerígenas é pois consideravelmente superior à originada em células normais. Quando a 18 F-FDG é introduzida no paciente, os positrões libertados colidem com os electrões das células. Essa colisão dá origem à libertação de dois fotões gama de 511KeV de energia que se movem numa trajectória rectilínea mas em sentidos opostos. A detecção desses fotões é realizada, no sistemas PEM, através de cristais cintilantes LYSO[23][24], que transformam a energia dos fotões em energia luminosa. A transdução dessa energia luminosa em energia eléctrica é conseguida através de células fotossensíveis, especificamente, através de fotodíodos de avalanche (APD Avalanche Photo Diodes). O par cristal/apd comporta-se como um sensor de radiação. Como se pode observar na Figura 2-2, usando duas células fotossensíveis pode-se determinar a trajectória do par de fotões libertado na colisão. Figura 2-2 Princípio de funcionamento dos detectores Usando planos de sensores podem-se detectar as trajectórias de vários pares de fotões libertados pela mesma célula. Diz-se que foi detectada uma coincidência. A intersecção das trajectórias de fotões permite identificar a presença de lesões. Este mecanismo é ilustrado na Figura 2-3. Figura 2-3 Detecção da posição do tumor pela intersecção de várias trajectórias - 8 -

29 Um dos objectivos da electrónica de aquisição e processamento de sinal, DAE, do sistema PEM é identificar a ocorrência de coincidências e os dados a ela associados. Estes dados, que correspondem à emissão simultânea de fotões, são considerados dados relevantes. Os sistemas de reconstituição de imagem permitem identificar os pontos de maior luminosidade. Estes pontos podem indiciar a presença de células cancerígenas Arquitectura do Sistema PEM Como foi referido, o sistema PEM tem 3 grandes subsistemas, nomeadamente, o scanner, o sistema electrónico de aquisição e processamento de sinais e o computador de reconstituição de imagem (Figura 2-4). O sistema electrónico de aquisição e processamento de sinais está distribuído em dois subsistemas, nomeadamente, o sistema de electrónica de FE (Front End) que é acoplado aos planos de cristais e o sistema DAE (Data Acquisition Electronics) que está separado do scanner. Figura Arquitectura do sistema PEM O sistema FE é responsável pelo processamento dos sinais analógicos gerados pelos APD em resultado da detecção dos fotões. Para se obter uma boa resolução na reconstrução da imagem, esses sinais têm que ser amplificados e processados. Após serem amplificados, os sinais são amostrados e são identificados os sinais de maior energia. Em seguida essa informação é digitalizada e enviada para a electrónica de aquisição de dados (DAE), juntamente com a identificação do cristal onde ocorreu a detecção. Uma descrição mais detalhada encontra-se na secção 2.4 deste documento. O sistema DAE é o responsável pela aquisição e processamento dos sinais provenientes do Front End. Esses sinais são classificados e filtrados, para que só os dados relevantes sejam enviados para o computador de reconstrução de imagem. Esse sistema e os seus constituintes são descritos em mais detalhe na secção 0 deste documento

30 2.3. Organização dos Planos de Cristais Os cristais que constituem o scanner PEM estão distribuídos por dois planos paralelos. Cada plano tem 3072 cristais organizados em módulos de 32 (Figura 2-5). Estes módulos, por sua vez estão agrupados em super-módulos. Cada super-módulo é constituído por 6 módulos. Existem 16 super-módulos em cada plano de cristais. Figura 2-5 Módulo de 32 cristais Cada cristal tem associado a si dois APDs (Figura 2-6), um no topo e outro na base. Os APDs estão organizados em matrizes de 32 (ver Figura 2-7). Cada módulo de 32 cristais tem associado a si 64 APDs (2 matrizes de 32 APDs, uma na base e outra no topo do módulo). Sinal eléctrico APD LYSO APD Sinal eléctrico Figura 2-6 Cristal associado a dois APD s Figura 2-7 Matriz de 32 células fotossensíveis A utilização de dois APDs por cristal permite determinar com mais precisão a localização do ponto em que no cristal se deu a reacção com o fotão. Este processo permite determinar com mais precisão a localização da célula emissora de radiação. A interacção dos raios gama com o cristal não é uniforme ao longo do cristal. Assim, a luminosidade detectada pelos dois APDs associados não será igual. Medindo a diferença de energia

31 detectada por cada APD e usando posteriormente essa informação em algoritmos de reconstrução de imagem, consegue-se melhorar a resolução de imagem Electrónica de Front-End Os sinais eléctricos gerados pelos APDs não podem ser enviados tal como são captados dos cristais para o DAE. De facto, esses sinais são condicionados a uma dada forma (conforme sugerida pelos estudos teóricos), são amostrados, digitalizados, filtrados e finalmente enviados para o DAE. A filtragem elimina todos os sinais cujo valor da energia é inferior a determinado valor, abaixo do qual os sinais são considerados ruído. A filtragem e o pré-processamento dos sinais gerados em cada super módulo são realizados por um circuito integrado de aplicação específica (ASIC Application Specific Integrated Circuit) [25][31] desenvolvido para esta aplicação. Além dessas tarefas o ASIC é responsável também pela identificação do APD que gerou o sinal. Essa informação é em seguida enviada digitalmente, em série, para a electrónica de aquisição de dados (DAE). Cada ASIC é responsável pela informação gerada pelos APD s de uma das faces de um super-modulo, ou seja, existem 32 ASICs por cada plano de cristais, 64 ASICs no total. Os estudos teóricos realizados demonstram que numa janela de observação de 10 ns não é de esperar mais do que duas interacções para cada conjunto de 192 cristais. Parte do processamento realizado pelos ASICs, consiste na escolha dos dois sinais de maior energia provenientes de cada super-modulo. Pelo que são escolhidos 64 sinais em cada plano de cristais, ou seja, no total são enviados para o DAE 128 sinais Caracterização dos Sinais Como resultado do processamento de um sinal eléctrico proveniente de um APD, o ASIC gera um sinal analógico com a forma representada na Figura 2-8. Esse sinal é em seguida amostrado, e a representação digital das amostras agrupada em pacotes os quais são enviados para o DAE. Figura 2-8 Formato do sinal produzido pelo ASIC

32 Cada pacote é composto por um conjunto de 10 amostras de 10 bits cada, e por uma identificação do APD que gerou essa informação. A identificação é composta por 11 bits (1 bit de inicio, 8 bits de identificação, 1 bit de erro e um bit de stop). Cada cristal tem 2 APDs, com a mesma identificação espacial, pelo que, por cada cristal, são enviados 2 pacotes para o DAE. No decorrer das interacções entre os raios gama e os cristais, pode acontecer que a energia de um raio gama não seja detectada por um único cristal, mas se distribua por vários. Esse efeito é denominado por efeito de Compton (Figura 2-9). Dependendo da forma como a interacção se dá, a energia detectada pelos vários cristais pode ser diferente, pelo que a intensidade do sinal eléctrico gerado pelos APDs dos cristais que partilham essa energia será também diferente. Figura 2-9 Efeito de Compton A interacção, ou colisão, entre um fotão gama e um cristal é denominado por hit. O conjunto de hits associados à mesma colisão entre um positrão e um electrão, designa-se por evento. Dito de outro modo, considera-se que existe um evento quando é detectada uma coincidência A tecnologia PET baseia-se na identificação e caracterização de eventos. A energia associada a cada hit não é necessariamente igual em todas as circunstâncias. Os hit associam-se no sistema PEM, a dois tipos de situações. O fotoevento corresponde ao hit cuja interacção produz o maior nível de energia. Todos os outros designam-se por Compton. A distinção entre os dois tipos de hits descritos anteriormente é feita, usando valores de energia específicos, designados limiar de fotoevento e limiar de Compton, respectivamente. Todos os hits que geram valores de energia inferior ao limiar de Compton são considerados ruído, e automaticamente rejeitados. Para que vários hits possam ser associados ao mesmo fotão gama, é necessário que sejam simultâneos, isto é, que ocorram num determinado intervalo de tempo. Tratando-se de um sistema síncrono, o tempo é medido em ciclos de relógio, donde é necessário definir simultâneo neste contexto

33 2.4.2 Tipos de Eventos No sistema PEM, distinguem-se 3 tipos de eventos: Evento Normal é um evento associado a uma coincidência. A informação associada a este tipo de evento é a informação relevante para o diagnóstico. Evento Single se somente um dos fotões originados na colisão interagir com um ou mais cristais num plano de cristais. A informação gerada por esse tipo de evento é utilizada para calibrar o sistema PEM [31]. Evento Aleatório Esse tipo de evento é uma abstracção, que corresponde a um pseudo Evento Normal. Consiste em associar no mesmo evento, dados resultantes de ocorrência de hits num dos planos de cristais, com os dados associados à ocorrência de hits no outro plano de cristais, embora a ocorrência dos dois conjuntos de hits estejam separados por um determinado intervalo de tempo (designado por Atraso Aleatório). Como se referiu um evento normal está associado a uma coincidência. O intervalo de tempo associado a simultaneidade é definido em termos de janelas temporais de aceitação e rejeição de hits. O intervalo de tempo máximo para que hits, que ocorram em ambos os planos de cristais, sejam considerados como pertencentes ao mesmo evento, designa-se por Janela de Aceitação. O intervalo de tempo mínimo para que hits, que ocorram em ambos os planos de cristais, não sejam considerados como pertencentes ao mesmo evento, designa-se por Janela de Rejeição. Quando vários hits ocorrem num único plano de cristais, eles são considerados pertencentes ao mesmo evento se ocorrerem dentro de um intervalo de tempo designado por Janela de Compton

34 - 14 -

35 3. Electrónica de Aquisição de Dados Como foi referido, o objectivo trabalho que é a base desta dissertação é o desenvolvimento de uma interface de comunicação entre a electrónica de aquisição de dados, DAE, e o PC de reconstituição de imagem. Torna-se, pois, necessário descrever com algum detalhe o sistema DAE, destacando os aspectos que podem influenciar o trabalho que se descreve nesta dissertação. Assim, referem-se os requisitos funcionais e de desempenho a que deve satisfazer o sistema DAE, os seus modos de funcionamento e apresenta-se ainda uma descrição breve da arquitectura, na medida em que condiciona a interface de comunicação Requisitos do sistema DAE Os requisitos que o sistema DAE deve satisfazer são os seguintes: 128 canais de dados correspondentes aos 2 planos de cristas; Frequência de trabalho: 100MHz; Taxa de eventos Single: 10M eventos; Taxa de eventos Normais: 1M eventos; Detecção de eventos Aleatórios; Parâmetros de calibração programáveis; Aceitação de 2 Compton por plano de cristais; Normalização de energia Cenários de Funcionamento do DAE As funcionalidades que devem ser realizadas pelo sistema DAE estão organizadas em diversos modos de operação. Cada modo de operação é designado cenário. Podem identificar-se no PEM 6 cenários correspondentes aos 6 modos de operação do sistema: Modo Normal/Aleatório; Modo Single; Carregamento de constantes; Carregamento do modo de funcionamento; Pedido de erros; Modo de teste. No modo Normal/Aleatório o sistema deve detectar eventos normais ou aleatórios eliminando os eventos Single, que nesse modo de funcionamento são considerados ruído. Esse modo de funcionamento é usado durante um exame PEM. Os dados obtidos neste modo de

36 funcionamento são relevantes e consequentemente, enviados para o PC para reconstituição da imagem. O modo de funcionamento Single é usado quando se procede à calibração do sistema. Neste modo só são detectados eventos Single. A informação recolhida nesse modo de funcionamento, é enviada para o PC e posteriormente usada no cálculo das constantes de calibração do sistema. No modo de carregamento de constantes, o PC descarrega para a memória do DAE as constantes K necessários para calibrar o sistema. No total são descarregadas constantes, uma por cada APD do sistema. No carregamento do modo de funcionamento do sistema, o PC indica ao DAE em que modo de funcionamento o mesmo irá funcionar. No pedido de erros, é pedido ao sistema, por meio do PC, os erros ocorridos no sistema em determinado modo de funcionamento e em determinado intervalo de tempo. Os erros são em seguida enviados para o PC. No modo de teste, o PC envia um pedido para que o sistema execute um auto-teste funcional (BIST Build-In Self Test). O resultado desse auto-teste é enviado em seguida para o PC Arquitectura do sistema DAE Apresenta-se na Figura 3-1 a arquitectura de alto-nível do DAE. Genericamente, o sistema DAE é responsável pela recepção dos dados provenientes do FE, tratamento e filtragem dos mesmos, e pelo envio dos dados relevantes para o PC de reconstituição de imagem. Detalhes de desenho e implementação do sistema DAE podem encontrar-se em [26] a [30]. Face A Plano de Cristais A Face B Face C Plano de Cristais B Face D Electrónica Front End Electrónica Front End Electrónica Front End Electrónica Front End DAQ + FLR (8x) TGR DCC DAE Figura 3-1 Arquitectura de alto-nível do sistema DAE Numa perspectiva de alto-nível, o sistema DAE realiza duas grandes funcionalidades, nomeadamente: Qualificação e filtragem de dados [33]; Organização e encaminhamento de dados [34]

37 A cada uma destas grandes funcionalidades corresponde um subsistema do DAE. Na Figura 3-2 pode-se observar, em representação mais detalhada, o diagrama de blocos do sistema DAE, destacando os subsistemas responsáveis pela Qualificação e Filtragem de Dados e pela Organização e Encaminhamento de Dados. Figura 3-2 Subsistemas e blocos constituintes do sistema DAE 3.4. Subsistema de Qualificação e Filtragem de Dados Como o nome indica, o Sistema de Qualificação e Filtragem de Dados identifica e filtra os dados provenientes do FE. Os dados resultantes deste processamento são posteriormente enviados para o PC de reconstrução de imagem. Esse subsistema é composto por 3 módulos principais: Módulo de Aquisição de Dados (DAQ Data Acquisition Module); Módulo de Filtragem (FLT Filter Module); Módulo Trigger (TGR Trigger Module)

38 O módulo de aquisição de dados filtra os dados enviados pelo FE e normaliza os sinais de entrada. Essa normalização é necessária para compensar os diferentes comportamentos dos cristais e dos APDs [34]. O módulo Filtro identifica e elimina todos os eventos com mais de 3 hits em qualquer dos planos de cristais. O módulo Trigger detecta os eventos Normais e Aleatórios com coincidências em ambos os planos de cristais Módulo de Aquisição de Dados O módulo DAQ [33] tem três funções distintas: a filtragem dos dados, a normalização da energia dos sinais de entrada e a determinação da fase do sinal de entrada. Assim, os dados provenientes da electrónica do Front End são filtrados por comparação do valor da energia que lhe está associada com os valores de limiar de energia, previamente carregados no sistema. Dependendo do valor da sua energia, os dados podem ser considerados pertencentes a um fotoevento ou a um Compton. Os valores de limiar correspondentes designam-se, respectivamente, por Limiar de Fotoevento e o Limiar de Compton. A normalização dos sinais de entrada é efectuada para compensar a diferença de comportamento dos cristais na presença de fotões e de todos os componentes electrónicos do Front End. Deste modo garante-se que as diferenças de energia detectadas nos diversos cristais se devem, de facto, a diferentes energias associadas às reacções fotão/cristal e não às diferenças tecnológicas dos cristais/apds entre si. Essa normalização é efectuada multiplicando o valor das amostras por uma constante K. Existe um valor K diferente para cada APD. O sinal recebido é composto por 10 amostras de 10 bits cada. No instante em que chega a primeira amostra é associada a esses dados uma etiqueta temporal que indica o instante da aquisição da amostra. No entanto de forma a identificar o instante correcto, é necessário saber a diferença entre o sinal real (analógico) e o sinal amostrado Para isso recorre-se ao uso de um parâmetro Delta [8] [35] [36] (ver Figura 3-3). Essa última operação corresponde ao cálculo da fase do sinal de entrada

39 Figura 3-3 Exemplo de um sinal de entrada e uso do parâmetro Delta Módulo de Filtragem O módulo Filtro [33] detecta e elimina todos os eventos que tenham mais de três hits por plano de cristais. Para tal tem que identificar todos os hits que pertencem ao mesmo evento, i.e., que tenham a mesma etiqueta temporal e que a diferença entre os valores Delta, correspondentes, seja inferior ao parâmetro Janela de Aceitação de Compton Módulo Trigger O módulo Trigger [33] é responsável pela detecção de coincidências do tipo Normal ou Aleatório, e consequentemente, pela detecção de dados relevantes para a reconstrução de imagem. Para que os hits detectados nos dois planos de cristais possam ser considerados pertencentes ao mesmo evento têm que se verificar as seguintes condições: Ter a mesma etiqueta temporal; A diferença dos valores de Delta dos hits pertencentes ao mesmo plano tem que ser superior ao parâmetro Reject Window; A diferença dos valores de Delta dos hits de planos diferentes tem que ser inferior ou igual ao parâmetro Accept Window Subsistema de Organização e Encaminhamentos de Dados O subsistema de Organização e Encaminhamento de Dados é responsável pela gestão do tráfego de dados no sistema DAE e pelo envio dos mesmos para o PC de reconstituição de imagem. Esse sistema é composto por dois blocos principais: Unidade de Memória; Concentrador de Dados (DCC Data Concentrator)

40 3.5.1 Unidade de Memória A unidade de memória armazena os dados que passaram na filtragem inicial feita pelo DAQ e que foram seleccionados pelo módulo Trigger, como dados relevantes a ser enviados para o PC de reconstituição de imagem. É composta por uma memória FIFO e por uma memória de duplo porto. A memória FIFO é usada para guardar os dados provenientes do sistema quando o mesmo se encontra a funcionar no modo Single e a memória de duplo porto é usada para guardar os dados provenientes do sistema quando o mesmo se encontra a funcionar em modo Normal/Aleatório Concentrator de Dados O módulo concentrador de dados agrupa os dados armazenados na memória e que têm a mesma etiqueta temporal, isto é, que foram gerados em simultâneo e consequentemente, pertencem ao mesmo evento, formatando-os em seguida para serem enviados para o PC de reconstituição de imagem. O concentrador de dados é responsável pelo agrupar todos os dados de amostras pertencentes ao mesmo evento. Os dados provenientes de cada plano não chegam ao mesmo tempo, pelo que os dados relativos ao primeiro conjunto de hits são armazenados numa memória temporária. Quando os dados relativos ao segundo conjunto de hits chegam, o DCC agrupa-os com os do primeiro e envia-os para o PC. O DCC é o módulo com o qual a interface de comunicação dialoga

41 4. Interface de Comunicação DAE PC Com foi referido, a interface de comunicação estabelece o diálogo entre o sistema DAE e o PC. A fim de identificar os módulos do sistema DAE que interagem com o sistema de comunicação, apresenta-se na Figura 4-1 a arquitectura detalhada do sistema DAE. FE FE Placa DAQ DAQ Board LVDS C O N LVDS DAQ DAQ FPGA FPGA DAQ DAQ DAQ ROC Filter Módulo Test Module de Teste DAQ FPGA DAQ DAQ ROC B U F F E R S G B U S D B U S B U F F E R S TGR/DCC TGR/DCC FPGA FPGA DCC TGR/ DCC ROC DCC ROC TGR Módulo Test Module de Teste DB Arb. C O N C O N Filtro Filter Módulo Test Module de Teste Placa TGR/ TGR/ DCC DCC Board PCI PCI Interface FPGA PCI FPGA De Controller Comunicação PC PC PCI PCI BUS BUS Figura 4-1 Arquitectura detalhada do Sistema DAE Como é ilustrado na Figura 4-1, o sistema é implementado em 5 placas; nomeadamente, 4 placas DAQ (Data Acquisition) e uma placa Trigger que comunicam entre si, através de 2 barramentos dedicados, o GBUS e o DBUS. Detalhes deste sistema podem encontrar-se em [31][33][34]. Está fora do âmbito desta dissertação entrar nesse detalhe. Pode observar-se na Figura 4-1 que a interface de comunicação está localizada na placa TGR/DCC, dialogando com o módulo DCC ROC da TGR/DCC FPGA e com o PC, numa configuração genérica como a que se ilustra na Figura 4-2. Figura 4-2 Arquitectura da Interface entre DCC e PC

42 No que se refere às funcionalidades relevantes para o bloco de comunicação, o bloco DCC efectua ainda as seguintes tarefas: Recebe dados relativos aos diversos modos de funcionamento do sistema e envia-os para o PC; Recebe do PC os parâmetros de calibração e envia-os para o módulo TGR; Recebe do PC os comandos referentes à mudança de modo de operação do sistema; Recebe do sistema sinais de controlo e envia-os para o PC Requisitos da Interface de Comunicação Requisitos de Desempenho No início do desenvolvimento do presente trabalho, estimava-se que a taxa de transferência necessária entre o DAE e o PC tivesse um valor máximo de 250MB/s. Este valor foi obtido com base em modelos de MonteCarlo [8] e o simulador Geant4 [18] [20]. Embora, ao longo do desenvolvimento do protótipo se tenha verificado que na primeira versão seria suficiente uma taxa de transferência da ordem dos 150MB/s, o presente trabalho foi desenvolvido usando como referência o primeiro valor, ou seja, 250MB/s. Outro requisito exigido refere-se à frequência de trabalho. Esta frequência é imposta pelo DAE, dado que o sinal de relógio que alimenta a interface de comunicação é proveniente deste módulo, e também pelo barramento de dados entre os dois sistemas funciona à mesma frequência. O valor da frequência de trabalho foi fixado em 100MHz. Assim, os requisitos de desempenho do sistema de comunicação são os seguintes: Taxa de transferência de dados 250MB/s; Frequência de trabalho 100MHz Requisitos Funcionais Os dados transferidos entre o DAE e o PC podem ser agrupados em três categorias: Comandos e correspondentes resposta do sistema; Dados de calibração do sistema; Dados relevantes (amostras associadas a fotoeventos). A interface tem que reconhecer as diversas categorias de dados a fim de encaminhá-los correctamente. Os que não se enquadram em nenhuma das categorias anteriores são descartados. Todas as categorias de dados contêm um cabeçalho, composto por vários bits, com a sua identificação. Apresenta-se seguidamente os formatos das diversas categorias de dados

43 Formato dos Comandos Os comandos são usados para controlar o funcionamento de todo o sistema ou para requerer informação do sistema. Apresenta-se de seguida a descrição desses comandos. Modo de funcionamento (CNT=110) Indica ao DAE que tipo de eventos este deverá capturar. As duas opções são eventos Normal/Aleatório ou eventos Single. Formato do pacote: CNT=110 X X X S.M. S.M. S.M S.M = 1 Modo Normal/Aleatório; S.M = 0 Modo Single. Iniciar/terminar exame (CNT=11110) Permite ou inibe a aquisição de dados obtidos durante o exame. Formato do pacote: CNT=11110 X X X OnOff OnOff OnOff OnOff = 1 Ligado OnOff = 0 Desligado Pedido de Erros ocorridos nos Módulos DAQ (CNT=1110) Esse comando permite inquirir o DAE acerca de erros ocorridos no modo de funcionamento em curso. É enviado ao PC uma resposta com esses erros. Formato do pacote PC -> DAE: CNT=1110 X X X Formato do pacote (resposta ao pedido de erros) DAE-> PC (CNT=001) CNT=001 XXX Err CTE Err Flag Err GBUS Err Sat Err FE Par

44 Existem 5 tipos de erros: Err CTE - Erro no Carregamento das constantes Ks; Err Flag - Erros na transmissão pelo Barramento Genérico dos dados entre FPGAs DAQ e FPGA TGR/DCC; Err GBUS - Erros no Barramento Genérico; Err SAT - Erros de Saturação das Amostras; Err FE - Erros no Front-End. Teste do Sistema (CNT=111110) Este comando pede ao DAE que inicie o auto-teste. No final é enviado ao PC uma resposta com o resultado desse auto-teste. Formato do pacote PC -> DAE: CNT= X X X O sistema faz o Auto-Teste e envia o resultado para o PC. Os diversos tipos de resultados são: DAQ Resultado do teste a cada FPGA DAQ; TD - Resultado do teste à FPGA TRG/DCC; GBUS Resultado dos testes ao barramento genérico; DBUS - Resultado dos testes ao barramento dedicado; TBUS_Error Resultado do teste à comunicação da FPGA TGR/DCC com as FPGAs DAQ. Para que o sistema esteja sem falhas é necessário que os bits 0 a 34 estejam todos a 1 e o bit 35 a 0. Formato do pacote DAE->PC (CNT=0001): CNT=0001 X X X TBUS_Error DBUS GBUS TD DAQ

45 Dados de Calibração do Sistema Os dados de calibração referem-se ao carregamento de constantes de calibração. Este carregamento consiste no envio de dados, do PC para o DAE, para calibração do sistema. Existem 2 tipos de constantes: Particulares (para cada cristal), num total de 6144 e Gerais (relativamente ao sistema). Formato dos pacotes: Constantes particulares (CNT=0) o Cristal ID Identificação do cristal; o KA Sup KA superior; o KA Inf KA inferior; o KB Sup KB superior; o KB Inf KB inferior; o K Sup K superior; o K Inf K inferior. CNT=0 X Crystal ID KA Sup KB Sup K Sup KA Inf KB Inf K Inf Par Constantes gerais (CNT=10) o FETh - FotoEvent Threshold; o CmpTh - Compton Threshold; o CmpWin - Compton Window; o AcpWin - Accept Window; o RejWin - Reject Window; o DelayLng - Delay Length. CNT=10 X X X FETh CmpTh CmpWin AcpWin RejWin DelayLng Par Dados Relevantes (amostras associadas a fotoeventos) A informação relativa a fotoeventos é enviada para o PC. Esses dados podem ser provenientes de um exame (Modo Normal/Aleatório), e nesse caso serão usados na reconstrução da imagem, ou originados no Modo Single, e nesse caso a informação é usada no cálculo das constantes de calibração do sistema. Por cada coincidência são enviados tramas com 1+4N pacotes de 64 bits, onde N é o número de hits

46 Formato dos pacotes: Inicio da trama (CNT= 01) CNT=01 EventNumber EventTime1/ Inicio de um conjunto de 4 pacotes (se pertencer ao primeiro hit) (CNT= 10) CNT=10 EventTime 2/2 00 # Hit Tgr Type Comp TimeTag Orig ID Sample 1/ Inicio de um conjunto de 4 pacotes (se pertencer aos restantes hits) (CNT= 10) CNT=10 X X 00 # Hit Tgr Type Comp TimeTag Orig ID Sample 1/ Pacotes seguintes (CNT= 10) CNT=10 Sample 2/ CNT=10 Sample 3/ CNT Sample 4/ Nesse último pacote os dois bits mais significativos (CNT) podem ter dois valores: o 11 - No caso de ser o último pacote da trama; o 01 - Caso contrário Protocolos de Comunicação A fim de identificar os protocolos que podem satisfazer os requisitos do sistema, bem como as tecnologias de implementação possíveis e as correspondentes vantagens e desvantagens, apresenta-se seguidamente, uma breve panorâmica dos protocolos de comunicação existentes. Na Tabela 4-1 apresentam-se os protocolos mais utilizados em sistemas ligados a computadores pessoais (PC Personal Computer) destacando-se como características de avaliação as seguintes: largura da palavra (número de bits), frequência de trabalho, taxas de transferência máximas e tipo de interface

47 Número de bits Freq. de trabalho Taxa de transferência máxima Interface RS ,2 Kb/s Serie Paralelo 8 2 MHz 2,5 MB/s Paralelo USB v MHz 60 MB/s Serie Firewire MB/s Serie PCI v2.2 32/64 33,33 e 66,66 MHz 533 MB/s Paralelo PCI-X e 133 MHz 1024 MB/s Paralelo PCI-X e 533 MHz 4,3 GB/s Paralelo PCI-E v1.1 1 a 32 (1x 32x) 2,5 GHz 8 GB/s (16 GB/s full-duplex) Tabela 4-1 Protocolos de comunicação mais usuais em PCs comerciais Serie Entre os protocolos mais antigos utilizados neste âmbito estão os protocolos RS-232 [37] e o Paralelo (IEEE 1284) [38]. O protocolo RS-232 é um protocolo série constituído por dois sinais de dados, um de envio e outro de recepção. O envio de dados pode ser feito simultaneamente nos dois sentidos (full-duplex). Os restantes sinais são usados para controlo. O protocolo paralelo é um protocolo, como o nome indica, em que os dados são enviados em paralelo. É constituído por 8 sinais de dados (1 byte). Esses sinais podem referir-se a dados que podem ser enviados nos dois sentidos mas não ao mesmo tempo (half-duplex). Os restantes sinais são maioritariamente de controlo. Esses dois protocolos são de fácil utilização e amplamente aplicados nos PCs actuais. Porém, apresentam contudo uma taxa de transferência muito inferior ao desejado (250MB/s), pelo que não podem ser utilizados neste sistema. Entre os protocolos mais modernos e com taxas de transferência mais elevadas estão os protocolos USB [39], Firewire (IEEE 1394b) [38] e PCI [40], este último nas suas várias versões. O protocolo USB é de razoável simplicidade e com taxas de transferências na ordem das dezenas de megabytes, pelo que ainda se encontra em valores inferiores aos pretendidos. O mesmo acontece com o protocolo Firewire. Tendo em conta que se deveriam utilizar interfaces existentes em PC comerciais, a escolha recaiu sobre a interface PCI. Contudo, na fase de desenvolvimento do protótipo pretendiam-se soluções de desenvolvimento rápido. Dadas as dificuldades com a tecnologia escolhida para implementar a solução PCI (como se verá no capítulo seguinte, chegou-se à conclusão que muitas das funcionalidades do sistema poderiam ser validadas a taxas de transferência menores. Assim, dada a simplicidade e a divulgação do protocolo USB, implementou-se uma solução baseada nesse protocolo e que se apresenta no capítulo

48 - 28 -

49 5. Solução PCI O barramento PCI foi escolhido inicialmente como protocolo de comunicação, devido á sua ampla utilização nos actuais PCs e por ser dos poucos protocolos que consegue garantir a largura de banda exigida no sistema. Das diversas versões do protocolo PCI existentes a mais utilizada é a versão simples, que tem como principais características poder trabalhar a 32bits/33,33MHz ou a 64bits/66,66MHz. Esta última configuração corresponde a uma largura de banda teórica de 533MB/s. Neste trabalho adoptou-se a solução 64bits/66,66MHz. Como o sistema de aquisição de dados está no exterior do PC, na solução implementada a comunicação entre os dois é conseguida por intermédio de uma ponte PCI-to-PCI. Essa ponte é composta por um conjunto de duas placas: a PCI-SB [41] e a PMC-SBF [42], da empresa Carlo Gavazzi Computing Solutions [43] (anteriormente AuroraTech). Essas placas têm como função transportar o barramento PCI do PC para o exterior, criando assim um barramento PCI secundário. No lado da placa TGR\DDC a comunicação entre a FPGA e a ponte PCI-to-PCI consegue-se usando um circuito integrado comercial, o QL5064 [50] [51], fornecido pela empresa QuickLogic Corporation [49]. A decisão de se usar essa solução, assim como a escolha das placas que constituem a ponte PCI-to-PCI e o dispositivo QL5064 foram feitas por terceiros antes da entrada do autor no projecto. Deste modo não se discute nessa Dissertação as considerações que foram tomadas, as várias soluções encontradas nem os motivos que levaram à escolha desses dispositivos. O QL5064 é composto por um core PCI, que comunica com a PMC-SB, e por uma FPGA. Nesta FPGA é implementado a arquitectura que permite a comunicação com a FPGA TGR/DCC. Na Figura 5-1 destaca-se a interface entre FPGA TGR/DCC e o PC através do QL5064. FPGA TGR/DCC DCC BU FF ER S TGR/DCC ROC DCC ROC TGR Placa TGR/DCC QL5064 PC Figura 5-1 Arquitectura da solução PCI implementada na TGR/DCC

50 Este circuito foi a solução escolhida no presente trabalho para implementar o protocolo PCI. O trabalho realizado descreve-se em detalhe na secção 5.3. Na Figura 5-2 apresentam-se detalhes da arquitectura da solução PCI, indicando a sombreado o âmbito desta solução. Nas secções que se seguem, descrevem-se os vários componentes utilizados na solução implementada. Figura 5-2 Arquitectura da solução PCI 5.1. Ponte PCI-to-PCI A ponte PCI-to-PCI tem como objectivo criar um barramento PCI secundário no exterior do PC. Essa tarefa é realizada pelas 2 placas comerciais representadas na Figura 5-3, nomeadamente, a PCI-SB (a) e a PMC-SBF (b). A comunicação entre estas duas placas é efectuada utilizando o protocolo Starfabric[44] (Figura 5-2) desenvolvido pela Stargen, Inc. [45]. Essa comunicação é totalmente gerida pelas placas referidas e transparente para o utilizador. Cada uma das placas contém um circuito integrado, o SG2010 da Stargen, Inc. que faz a ponte PCI-Starfabric. Esse circuito integrado juntamente com o protocolo Starfabric permite criar uma rede de dispositivos de alto desempenho. Na configuração usada nesse trabalho, o conjunto composto pelas referidas placas permite criar a ponte PCI-to-PCI necessária. (a) (b) Figura 5-3 Placa PCI-SB (a) Placa PMC-SB (b)

51 Cada uma das placas tem integrado dois links full-duplex de 2.5Gbps. A ligação entre elas é feita por intermédio de cabos Ethernet blindados Cat 5 [46]. A comunicação pode ser feita a uma distância máxima 10 metros sem perda de desempenho. Os dois links podem ser usados em conjunto, criando deste modo redundância na transmissão dos dados, e consequentemente, aumentando a fiabilidades, ou por forma a aumentar a taxa de transferência, duplicando assim o valor máximo da transferência de dados. As interfaces PCI dessas placas são compatíveis com a norma PCI 2.2 [47], e podem funcionar 64bits/66,66MHz ou a 32bits/33,33MHz. A configuração dessas placas é bastante simples, no sentido em que cada placa contém um conjunto de 4 DIP Switches (Dual-in Line Package Switches) que indicam à placa como funcionar. No que respeita ao modo de funcionamento, o protocolo define que numa topologia Starfabric, as placas possam funcionar em modo Bridge ou Gateway. O modo Bridge permite criar a ponte PCI-to-PCI necessária para o presente trabalho, pelo que será a configuração escolhida. O modo Gateway permite usar as funcionalidades avançadas do SG2010, quando a placa está inserida numa rede Starfabric. Em relação ao comportamento, a placa que está inserida no barramento PCI primário tem que ser configurada para funcionar no modo Root, as restantes no modo Leaf. A configuração utilizada neste sistema é a descrita na Tabela 5-1. Função Numero On Off PCI-SB PMC-SBF 1 Root Leaf On Off 2 Bridge Gateway On On 3 4 Modo Teste Tabela 5-1 Configuração dos DIP Switch das placas Starfabric 5.2. Dispositivo QL5064 Para efectuar a comunicação entre a FPGA da TGR/DCC e a PMC-SBF foram consideradas inicialmente duas soluções. A primeira solução consistia na aquisição de um core PCI da empresa Xilinx [48]. A segunda opção consistia na aquisição de um circuito integrado, o QL5064, composto por um core PCI embebido e por uma FPGA. Do ponto de vista de funcionamento no que respeita ao protocolo PCI, ambas as soluções eram semelhantes. No entanto a diferença de custo de cada produto era significativa 5, pelo que os responsáveis pelo projecto decidiram pela aquisição do QL5064. Para desenvolver as diversas aplicações nesse dispositivo, o fabricante disponibiliza, um pacote de ferramentas desenhadas especificamente para os seus produtos. O pacote em questão é o 4 Para uso interno do pessoal da Aurora Technologies. 5 O preço do core PCI da XIlinx rondava os ,00, enquanto que o preço da aquisição de cada QL5064 era de aproximadamente 100,

52 QuickWorks v [52] [53]. Esse pacote inclui ainda um software de simulação desenvolvido por terceiros, o Active-HDL Expert Edition v.6.3 [54] da empresa Aldec, Inc. [55]. Mais informações sobres esses estas duas ferramentas pode ser encontrado no Anexo Arquitectura do Dispositivo QL5064 O QL5064 é um dispositivo composto por um core PCI e uma FPGA. O encapsulamento é do tipo PBGA e pode ser com 456 ou 484 pinos, sendo que 192 desses pinos são para uso do utilizador e podem ser usados como entrada e/ou saída. Na Figura 5-4 pode ser observado o diagrama de blocos do QL5064 (conforme a datasheet). Figura 5-4 Diagrama de blocos do QL5064 O core (PCI Controller na Figura 5-4) é o responsável por gerir toda a comunicação com o BUS PCI, sendo esse trabalho transparente para o utilizador. Toda a comunicação com o BUS PCI é compatível com a especificação PCI 2.2 [47]. A comunicação entre esse dispositivo e o BUS PCI pode ser feita a 32 bits e/ou 64 bits, a uma frequência de 33,33 MHz ou 66,66 MHz (o QL5064 tem a capacidade de trabalhar a uma frequência de 75MHz, mas isso já não é contemplado na norma PCI usada). A taxa de transferência máxima é atingida em modo burst quando a comunicação é feita a 64bits/66,66 MHz, sendo o seu valor teórico de 533 MB/s. A especificação PCI define que numa comunicação entre dois dispositivos no barramento PCI, aquele que inicia a transacção é o dispositivo Master, enquanto o outro é o Target. O QL5064 pode funcionar em modo Target ou Master. A transferência de dados entre o BUS PCI e a FPGA é realizada usando memorias FIFOs. Existem duas FIFO s de leitura e duas FIFOs de escrita no modo Master, uma FIFO de leitura e uma

53 de escrita no modo Target. Todas as FIFOS são assíncronas, i.e., a escrita e a leitura podem funcionar a velocidades diferentes, permitindo desse modo que a comunicação entre essas FIFOs e a arquitectura implementada possa ser efectuada à velocidade máxima, ou seja, a 100 MHz. A sincronização é feita totalmente pelo core PCI. Cada FIFO do modo Master contém um controlador DMA (Direct Memory Access) de forma a suportar a taxa de transferência máxima. A comunicação entre a FPGA e o core feita por intermédio de 3 barramentos de dados de 64 bits, nomeadamente, DataIN, DataOUT e Control_DATA. O barramento DataIN permite transferir dados do barramento PCI para o back-end. O barramento DataOUT permite transferir dados do backend para o barramento PCI. O barramento Control_DATA é bidireccional, além disso permite aceder aos registos de configuração. A FPGA é composta por 74K portas lógicas. Além disso estão também, disponível para uso do utilizador, 11 blocos de memória dual-port com uma capacidade total de bits. Cada bloco de memória tem 18 bits de dados e 9 bits de endereços. Dependendo do modo de seleccionado a capacidade dessas memorias varia, como se pode ver na Tabela 5-2. Essas memórias podem ainda ser agrupadas de forma a gerar memórias com configurações diferentes das descritas. Modo 64x18 128x9 256x4 512x2 Endereços [a:0] [5:0] [6:0] [7:0] [8:0] Dados [w:0] [17:0] [8:0] [3:0] [1:0] Tabela 5-2 Modos de funcionamento dos blocos de memória RAM O QL5046 contém ainda dois conjuntos de registos de configuração de 256 bytes cada um. O primeiro conjunto, Registos de Configuração ou Configuration Header Space, é somente acessível pelo barramento PCI. De facto, é obrigatório em todos os dispositivos PCI para que sejam compatíveis com a especificação PCI. O segundo conjunto, Registos de Controlo, é acessível quer pelo barramento PCI quer pelo barramento Control_DATA e contém toda a informação relativa ao funcionamento do QL5064. O acesso a esse conjunto de registos por parte do barramento PCI pode ser feita usando o BAR[0] (Base Address Regions) no deslocamento 0x00-0xFF. Uma descrição resumida dos registos de configuração é incluída no Anexo 2. A descrição detalhada da totalidade dos registos pode ser consultada no manual do QL5064 [51]. Todos os registos que foram utilizados são descritos em pormenor nas respectivas secções Arquitectura da Interface PCI / TGR A transmissão de dados de/e para o PC é feita, como já foi referido, por intermédio de uma ponte PCI-to-PCI, recorrendo ao dispositivo QL5064, que é responsável pela comunicação com barramento PCI é o Core PCI. No Anexo 3 encontra-se uma tabela com os sinais usados na interface PCI

54 No entanto esse core tem de ser controlado, isto é, necessita que lhe digam quando deve receber ou enviar dados, e como deve fazê-lo. A adaptação do QL5064 para realizar as funções necessárias ao sistema de comunicação DAE PC foi realizada utilizando o bloco Programmable Logic and Dual-Port RAM da Figura 5-5. O controlo do Core PCI é a principal função da arquitectura implementada, neste bloco. Na Figura 5-5 indicam-se os sinais usados no bus PCI e entre o Core PCI e a FPGA do QL5064. Os sinais usados, na comunicação com o core PCI, pela arquitectura implementada nesse trabalho, serão descritos em pormenor nas respectivas secções. Uma descrição mais detalhada pode ser consultada em [51]. Figura 5-5 Sinais das interfaces entre o core PCI e a FPGA e PCI

55 Na Figura 5-6 detalha-se a comunicação entre a FPGA do QL5064 e o módulo TGR/DCC. Como referido anteriormente, um dispositivo num barramento PCI pode-se comportar como Master ou Target, dependendo se inicia ou não a transmissão. O QL5064 permite ambos os modos. Foi decidido usar unicamente o modo Target por ser o mais simples e porque houve indicação do fabricante de que este modo permitiria cumprir os requisitos de desempenho requeridos. A simplicidade de desenvolvimento era um requisito importante, dado que, permitiria mais facilmente uma solução correcta à primeira (right first time). FiFO_Full FIFO_AlmostFull Write FPGA QL5064 Data_Out[63:0] tgr_fifo_full FPGA TGR/DCC data_out_valid Data_In[63:0] Figura 5-6 Sinais das interfaces entre a FPGA do QL5064 e o módulo TGR/DCC No lado do barramento PCI a comunicação com o QL5064 pode ser feita usando os 6 BARs disponíveis. A configuração desses BARs, assim como a dos restantes registos de configuração, está descrito em pormenor na secção A gestão do fluxo de dados deve ser realizada de forma a não comprometer a largura de banda exigida. Para tal foram implementadas memórias FIFOS, o que além de aumentar a capacidade de armazenamento do sistema, permite um maior controlo do fluxo de dados. Cada memória é utilizada por determinado tipo de dados, nomeadamente, dados relativos a respostas a comandos (FIFO associada ao Single Mode) e dados associados a um evento (FIFO associada ao Blast Mode). Todo a gestão das FIFOS e dos sinais de controlo do Core PCI são da responsabilidade de dois controladores, o Single Mode Controller, responsável pela gestão dos dados, referentes a pedidos vindos do PC e a respostas vindas do TGR/DCC FPGA, e o Blast Mode Controller, responsável pela gestão do elevado fluxo de dados provenientes de um exame. O Test Module, como o nome indica, é um módulo de teste. Esse bloco tem papel importante no desenvolvimento do trabalho, dado que permite também detectar problemas durante esta fase. O uso desse módulo permite observar do exterior, alguns sinais usados na arquitectura

56 Um esquema de blocos da arquitectura do sistema de comunicação TGR/DCC Core PCI (implementada na FPGA do QL5064) está representado na Figura 5-7 (o esquema detalhado pode ser consultado no Anexo Arquitectura da FPGA do QL5064 Como foi referido, a funcionalidade implementada na FPGA do QL5064 é o controlo do Core PCI. Esta funcionalidade foi decomposta em duas funcionalidades mais simples, nomeadamente: Recepção de comandos do PC e envio de respostas; Envio dos dados do exame (dados associados a eventos). A primeira destas funcionalidades está associada ao Single Mode Controller e foi implementada por outro membro da equipa de desenvolvimento. A descrição detalhada desta implementação pode encontrar-se em [56]. A segunda funcionalidade está associada ao Blast Mode Controller, foi desenvolvida pelo autor desta dissertação e a sua descrição encontra-se nas secções seguintes. FIFO Dados de Exame Watch Dog Controlador Blast Mode FPGA TGR/DCC FIFO Dados de Status Core PCI Watch Dog Controlador Single Mode Pedidos Módulo de Teste Conector de Teste Figura 5-7 Arquitectura da FPGA do QL5064 Como se pode ver na Figura 5-7, a comunicação com a TGR/DCC FPGA é feito por intermédio de 2 barramentos. A dimensão de cada barramento é de 64 bits. Além disso existe um

57 conjunto de sinais de informação do estado e controle das FIFOS. A descrição detalhada desses sinais pode ser encontrada na Nas secções seguintes descrevem-se em pormenor os modos de funcionamento e os diversos blocos que constituem a arquitectura, as configurações usadas e o protocolo de comunicação desenvolvido Controlador Blast Mode Uma transacção PCI é definida como uma transferência de dados em burst com incremento automático de endereço. No entanto o endereço não é importante, quando se trata de dados transferidos de/para uma FIFO. Isto é o que acontece no sistema PEM em que existe um grande fluxo de dados que têm de ser transferidos de uma FIFO do sistema para outra FIFO no PC. Nesta situação, o QL5065 pode funcionar como Target FIFO Blast, utilizando-se neste caso as duas FIFOs do Core PCI, a Receive FIFO 1 e Transmit FIFO. Do lado do barramento PCI essas FIFOs podem ser acedidas usando o BAR(2). O controlador descrito nessa secção trabalha em modo burst. Este controlador é o responsável pelo envio dos dados, provenientes de um exame, para o PC. Na Figura 5-8 pode ser observado os sinais intervenientes nesta interface. A descrição dos sinais usados está na Tabela 5-3. Figura 5-8 Controlador Blast Mode A principal função desse bloco é comandar a transferência de dados entre as FIFOs Blast Mode FIFO, e a Transmit_FIFO_1. Neste modo, as flags FIFO_Empty da primeira e a XMT1_fifo_almostfull da segunda são constantemente monitorizadas. Sempre que a flag FIFO_Empty e a XMTt1_fifo_almostfull estiverem a '0', o controlador inicia a transferência de dados. A escrita na FIFO do Core PCI tem que ser acompanhada por uma monitorização permanente do seu estado, para evitar o envio de dados quando a FIFO está cheia. A monitorização

58 é feita observando o valor das flags XMT1_fifo_full, que é activada quando a FIFO se encontra cheia, e da flag XMT1_fifo_almostfull, que indica que só está disponível um determinado número de posições de memória. Sinal Tipo Descrição clk I Sinal de relógio. reset I Sinal de reset. Estado da FIFO do core que recebe os dados provenientes de um exame. xmt1_fifo_full cntl_addr[7:3] I O 0 tem espaço. 1 está cheia. Endereço do registo de controlo do core, que se quer aceder. x 68 Flag de almost full da Transmit FIFO 1 x C8 Transmit FIFO 1 cntl_be[7:0] O Byte activo do bus. Indica qual o/os bytes com significado no bus. cntl_cs O Activa o escrita nos registos. Ciclo de escrita ou leitura. cntl_wrt_nrd mux_sel O O 0 Escrita 1 Leitura Selecciona a origem dos dados, que são enviados para a Transmit FIFO 1 0 blast controller fifo 1 data_out do blast controller data_out[63:0] O Dados de configuração. fifo_empty I Indica se a blast mode fifo contem dados. Activo a high. pop_fifo O Incrementa o ponteiro de leitura de blast mode fifo. times_up I Sinal enviado pelo watchdog para reinicializar a máquina de estados. clear_watchdog O Inicializa o contador do watchdog. Activo a high. enable_watchdog O Activa o watchdog. Activo a high. state_machine[2:0] O Palavra de código com indicação do estado actual. Tabela Descrição dos sinais do controlador Blast mode No entanto, existe um atraso de propagação dessas flags que tem que ser tomado em consideração. Para garantir que a informação indicada pelo valor das flags corresponde ao estado real da FIFO, o controlador deve esperar um determinado número de ciclos de relógio. Esse processo implica uma degradação no desempenho do sistema. Para evitar esta degradação, foi utilizada unicamente a flag Almost-Full, devidamente configurada para compensar os atrasos de propagação. Assim quando esta flag fica activa o controlador pára de enviar dados. A configuração dessa flag é executada quando o sistema arranca ou há um reset. O valor configurado é de duas posições e foi

59 calculado por meio de simulação. Usando essa técnica, no pior caso, desperdiça-se algumas posições de memória. Como o barramento de dados para configurar a flag é também usado para envio dos dados provenientes da FIFO Blast mode FIFO, foi necessário implementar um multiplexer de duas entradas de 64bits cada, uma usada pela FIFO e a outra pelo controlador. A saída do multiplexer está ligada ao barramento Control_DATA. O controlo do multiplexer é realizado pelo controlador. A máquina de estados que descreve o funcionamento do controlador está representada na Figura 5-9. Inicio Flag_configuration Configuração da flag almost-full do core PCI Sem dados ou FIFO do core PCI cheia Data_wait Espera chegada de dados Chegada de dados e FIFO do core com espaço Reset ao Watchdog Envio de dados para o core PCI Clock_wait Estado de espera Figura 5-9 Máquina de estados do controlador Blast Mode Todos os estados são codificados por uma palavra de dois bits, sendo que pode ser observada no exterior através do conector de teste existente no sistema para validação do protótipo em fase de desenvolvimento. Para garantir que a máquina de estados não bloqueia, existe um watchdog ligado ao controlador. O watchdog incorpora um contador de 8 bits, o que permite que um estado esteja bloqueado somente 256 ciclos de relógio FIFO Blast Mode Para uma melhor gestão do tráfego de dados entre a TGR/DCC e o core PCI, foi utilizada uma memória FIFO implementada com a QuickWorks. A Figura 5-10 ilustra os sinais na Blast Mode FIFO. A descrição desses sinais encontra-se na Tabela

60 A QuickWorks disponibiliza um assistente, que recebe alguns parâmetros relativos ao tipo e dimensão da FIFO que se pretende e que com base nessa informação gera os ficheiros necessários à instanciação das memórias dentro do projecto. Para a geração de FIFOS, o assistente usa sempre que possível os blocos de memória RAM disponíveis no dispositivo. Essa solução permite aumentar o desempenho e reduzir o espaço usado na FPGA. Figura 5-10 FIFO Blast mode Como a frequência de leitura é igual á frequência de escrita, optou-se por usar uma FIFO síncrona que é de arquitectura mais simples, ocupa menos espaço e é mais rápida. Em relação à disponibilidade dos dados, essa FIFO é do tipo First-Word-Fall-Through, ou seja, o primeiro bloco de dados a entrar fica logo disponível à saída da mesma. Sinal Tipo Descrição clk I Sinal de relógio. reset I Sinal de reset. push I A activação desse sinal armazena os dados à entrada da FIFO. pop I A activação desse sinal disponibiliza o próximo bloco de na saída da FIFO. Fifo_almost_full O A activação desse sinal indica que a FIFO tem menos de 25+4 blocos de dados disponível. Fifo_empty O Indica que a FIFO está vazia. Data_IN(63:0) I Entrada de dados. Data_OUT(63:0) O Saída de dados. Tabela 5-4 Descrição dos sinais da FIFO Blast Mode A indicação da existência de dados na FIFO é feita por intermédio de uma flag, a FIFO_empty, que indica ao Blast Mode Controller o estado da FIFO. A indicação de espaço disponível é feita pela flag, FIFO_almost_full, que indica à TGR/DCC FPGA se há espaço para armazenar dados. O envio de dados por parte de TGR/DCC FPGA só è efectuada se a FIFO tiver capacidade para armazenar pelo menos um evento inteiro, ou seja, 25 pacotes de 64 bits (dimensão

61 máxima de um evento). Deste modo a flag FIFO_almost_full é activada quando o espaço disponível for inferior a 25+4 eventos. Os 4 eventos extra são necessários para compensar atrasos de propagação da flag. A FIFO gerada pelo assistente não contempla o uso de uma flag almost_full configurável. Sendo assim essa função teve que ser desenvolvida com lógica adicional. Para o efeito foi adicionado um contador e um comparador. A arquitectura detalhada pode ser consultada no Anexo 5. Como o intuito dessa FIFO não é aumentar a capacidade de armazenamento do sistema, mas sim, facilitar a gestão do fluxo de dados entre a TGR/DCC FPGA, usou-se a dimensão mínima permitida pelo assistente e que respeite o requisito anterior. A dimensão escolhida foi 64 palavras de 64 bits Controlador das FIFOs Como foi referido, os dados provenientes da TGR/DCC FPGA podem ser de 3 tipos: Resposta a pedidos feitos pelo PC; Calibração do sistema; Dados relativos a um evento. Como todos os dados provêm de um único barramento torna-se necessário identificar os tipos de dados e encaminhá-los para a respectiva FIFO. No caso de serem resposta a pedidos, os dados são encaminhados para a Single Mode FIFO, caso contrário são encaminhados para a Blast Mode FIFO para que possam ser acedidos pelo PC em endereços separados. Na Figura 5-11 pode-se observar a interface dos sinais desse bloco. No Anexo 6 encontra-se a arquitectura, deste bloco, em detalhe. Figura 5-11 Controlador das FIFOs. O protocolo de comunicação entre a TGR/DCC FPGA e o QL5064, exige que aquando da escrita de dados nas FIFOs, o sinal de escrita esteja activo durante dois ciclos de relógio, pelo que, os dados só serão considerados validos no 2º ciclo. Como a escrita nas FIFOs não é compatível com esse protocolo, a segunda função do FIFO Controller é fazer a conversão de protocolos. Na Tabela 5-5 encontra-se uma descrição dos sinais usados para este efeito

62 Sinal Tipo Descrição clk I Sinal de relógio. push I Activação da escrita. header(1:0) I Identificação do tipo de dados. cmd_fifo_push O Activação da escrita na Single Mode FIFO. test_fifo_push O Activação da escrita na Blast Controller FIFO. Tabela 5-5 Descrição dos sinais do controlador das FIFOs Protocolo de Comunicação A comunicação entre a TGR/DCC FPGA e o QL5064 é feita por intermédio de dois barramentos de dados de 64 bits cada. O Data_IN transporta os dados da TGR/DCC FPGA para o QL54064 e o Data_OUT no sentido inverso. Existe ainda um conjunto de sinais necessários para o controlo do fluxo de dados nos barramentos. O uso desses sinais respeita um protocolo que foi criado especialmente para o presente caso. Na elaboração desse protocolo foram respeitados três aspectos importantes, nomeadamente, a taxa de transferência máxima, a fiabilidade e ainda a simplicidade da arquitectura das interfaces usadas, tanto do lado da TGR/DCC FPGA como do lado do QL5064. Na Figura 5-12 encontra o diagrama temporal dos sinais presentes no protocolo implementado. Nesta pode-se observar os sinais usados na transmissão de dados nos dois sentidos. Figura 5-12 Protocolo de comunicação TGR/DCC QL

63 No sentido TGR/DCC FPGA para o QL5064 os dados são enviados para duas FIFOs distintas, a FIFO Blast Mode e a FIFO Single Mode. O envio para a FIFO Blast Mode é feito evento a evento, ou seja, só se inicia uma transmissão se o espaço disponível na respectiva FIFO permitir armazenar um evento completo. Deste modo reduz-se os ciclos de espera no lado da TGR/DCC, pois a necessidade de monitorizar a flag da FIFO é menor. A flag a usar nesse caso é a Transmit_FIFO_Almost_Full e a sua activação é feita sempre que o espaço disponível for inferior a 25 palavras de 64 bits, que é o tamanho máximo que um evento pode ter. Se os dados a enviar forem uma resposta a um pedido do PC, a FIFO a usar é a FIFO Single Mode. O envio para essa FIFO é feito palavra a palavra, (dimensão máxima de uma resposta). A flag a usar é a Transmit_FIFO_Full, que quando activa, indica que a FIFO está cheia. No sentido QL5064 para a TGR/DCC FPGA a transmissão é semelhante à usada para a Transmit_FIFO_Full. De forma a garantir a estabilidade dos sinais à entrada das FIFOs, e garantir que os bits armazenados correspondem todos à mesma palavra de dados, foi decidido usar dois ciclos de relógio por cada escrita. Deste modo os dados só são considerados válidos e armazenados, no segundo ciclo de relógio. Esse procedimento apesar de reduzir o desempenho global da transmissão, permite taxas de transferência acima da requerida. De facto, numa transmissão de 64 bits a 100MHz usando a técnica descrita acima, obtêm-se um valor teórico de 400MByte/s. 64 bbbbbbbb xx 100 MMMMMM 2 = 3200 MMMMMMMM/ss = 400 MMMMMMMMMM/ss Registos de Configuração Como falado anteriormente, o QL5064 contêm um conjunto de registos, que definem o seu comportamento e onde se pode obter algumas informações do seu estado. Foi dada grande importância a esse aspecto, pois o funcionamento correcto do QL depende muito de uma configuração correcta desses registos alguns dos quais não podem ser modificados após a programação do dispositivo. Na Tabela 5-6 encontra-se uma lista desses registos, com os valores usados e uma breve descrição. Uma descrição mais detalhada pode ser obtida em [51]. Função Valor binário Descrição AF_DEVICE_ID [15:0] Identificação do dispositivo AF_VENDOR_ID [15:0] Identificação do vendedor (foi usado o ID da QuickLogic, Inc) AF_STATUS_IN [7:0] Registos de estado (ver Anexo 2). AF_COMMAND_IN [15:0] Registos de commando (ver Anexo 1). Tabela Registos de configuração do QL5064 (continua)

64 Função Valor binário Descrição AF_CLASS_CODE [23:0] Classe do dispositivo. Apresente configuração pertence à classe Other data acquisition/signal processing controllers (consultar regras em [47]) AF_REVISION_ID [7:0] Identificação da revisão AF_HEADER_TYPE [7:0] AF_BASE0_IN [31:0] AF_BASE1_IN [31:0] AF_BASE2_IN [31:0] AF_BASE3_IN [31:0] AF_BASE4_IN [31:0] Como o QL5064 funciona em modo Target deve estar tudo a zeros Configuração do espaço de endereçamento para cada BAR. O BAR[0] é usado para o envio e resposta de comandos. O BAR [2] é usado na transmissão de dados de um exame. O BAR[1] não é usado mas, tendo em conta a nossa configuração, a especificação PCI obriga a que esteja activo AF_BASE5_IN [31:0] AF_CIS_PNTR [31:0] Apontador para Cardbus CIS (N/A) AF_SUBSYSTEM_ID [15:0] Identificação do subsistema AF_SUBSYSTEM_VID [15:0] Identificação do subsistema do vendedor AF_ROMBADDR_IN [31:11] Usado na expansão do ROM (N/A) AF_ROMBADDR_IN_0 0 Activa a expansão ROM (N/A) AF_PME_IN [31:0] Funções de capacidade estendidas (N/A) AF_CFIG_RESERVED1_IN [31:0] AF_MAX_LAT [7:0] AF_MIN_GNT [7:0] Reservado Frequência com que o dispositivo acede ao barramento (N/A) Período mínimo de uma transmissão em rajada, em incrementos de 250ns (valor aconselhado). AF_INT_PIN [7:0] Usado em interrupções (N/A) AF_BAR_ZERO_VALID 0 Activa ou desactiva os BARs com endereços a 0 AF_BAR_EN [5:0] Selecciona os BARs usados. AF_USER_REV_ID [7:0] Identificação da revisão do utilizador AF_TARGET_ENA_MASTER _FIFO AF_WAIT_TIMEOUT_WRITE 1 AF_WAIT_TIMEOUT_READ 1 AF_ENABLE_16_8_TIMEOU T AF_MASTER_ALWAYS_ENA BLE Atribui a Transmit FIFO 1 e a Received_FIFO_1 ao modo Target Blast Mode Espera por um período de 16/8 ciclos até que aja espaço na FIFO Espera por um período de 16/8 ciclos até que aja dados na FIFO Active o tempo de repetição de uma operação falhada em 16 ciclos de relógio para a primeira palavra e 8 para as restantes Permite que a activação do modo Master seja feita usando o espaço de configuração. AF_PCI_ALLOW_64_BIT 1 O dispositivo pode funcionar a 64 bits AF_READ_RETRY_TIMEOU T [1:0] 00 Configura o tempo de repetição de uma leitura falhada em 2 15 ciclos de relógios Tabela Registos de configuração do QL5064 (continua)

65 Função Valor binário Descrição AF_PCI_FORCE_64_BIT 0 AF_32PCIBUS_HOLDUPPER 1 AF_PASS_HIGH_CONFIG 0 O dispositivo comuta automaticamente entre 32 e 64 bits de comunicação Activa ou desactiva os AD[63:32] e C/BE[7:4]# quando inseridos numa slot de 32 bits O espaço de endereçamento 0x40-07ff retorna sempre zeros AF_BIST_EN 0 Indica se a FPGA suporta BIST Tabela 5-6 Registos de configuração do QL Simulação da Interface de Comunicação Como referido anteriormente, a ferramenta usada para simular a arquitectura desenvolvida, foi a Active-HDL [54] da Aldec, Inc [55]. Esse software é fornecido no pacote de ferramentas da QuickLogic [52] e por tal aconselhada por esta. Foi dada especial importância a essa fase do projecto, pois como a reprogramação do QL5064 não era possível, toda a validação, quer funcional quer de desempenho, foi feita em simulação. Deste modo a recriação do barramento PCI foi feita de forma a aproximar a simulação tanto quanto possível da realidade Ambiente de Simulação Para simular a arquitectura, foi emulado um barramento PCI. Para tal foram utilizados modelos de simulação fornecidos pela QuickLogic. Estes modelos são fornecidos em ficheiros VHDL, podem ser instanciados no testbench e simulam os vários tipos de transacção. Os modelos usados simulam um dispositivo em modo Master e um árbitro PCI. Esse último é responsável pela gestão do tráfego no barramento, emulando a realidade. Um terceiro modelo, referido como módulo de teste, na Figura 5-13, informa o utilizador sobre o que se passa no barramento PCI. Um modelo mais detalhado do ambiente de simulação é incluído no Anexo 7. Barramento PCI Dispositivo Master TGR/DCC QL5064 ( Target ) Árbitro Módulo de teste Figura 5-13 Ambiente de simulação

66 Além dos modelos descritos anteriormente, foi necessário desenvolver um modelo da interface da TGR/DCC FPGA com o QL5064. Esse modelo tem como função enviar e receber dados do QL5046. Esta comunicação segue o protocolo descrito na secção e o formato dos dados descrito na secção Validação Funcional e de Desempenho Para validar a funcionalidade e o desempenho da arquitectura implementada, foram simulados cenários reais, usando os comandos descritos na secção Foram simulados os seguintes cenários: Dados enviados do PC para o DAE: o Envio de constantes de calibração do sistema; o Pedido de erros; o Pedido de início de BIST (Built In Self Test); o Alteração do modo de funcionamento (Single e Normal/Aleatório); o Pedido de início/paragem de exame. Dados enviados do DAE para o PC: o Envio da resposta ao pedido de erros; o Envio do resultado do BIST; o Envio de dados provenientes de um exame Resultados de Simulação Embora a frequência de trabalho seja de 100 MHz, todas as simulações foram realizadas a uma frequência de 50 MHZ, que é a frequência de trabalho fornecida pela placa onde será inserida (no protótipo actual) o circuito QL5064. Obtiveram-se os seguintes resultados de simulação: A transmissão de dados, nos dois sentidos, foi validada do ponto de vista funcional; A taxa de transferência máxima obtida foi de 185 MB/s; A frequência máxima de trabalho da arquitectura é de 76MHz; Aumentando a frequência do sinal de relógio para os 76 MHz, a taxa de transferência aumenta para 304MB/s, sem prejuízo da funcionalidade; Os valores obtidos para as taxas de transferências são ligeiramente inferiores aos valores teóricos, devido às características do protocolo PCI. Os recursos ocupados pela arquitectura na FPGA do QL5064 são os seguintes: Espaço total ocupado: 55.7%; Número de células de memória usados: 8 de 11 disponíveis; Número de entradas/saídas usadas: 149 de 192 disponíveis

67 5.6. Implementação Física e Teste Após a programação do QL5064 6, este foi montado na placa TGR/DCC. Na Figura 5-14 apresenta-se a fotografia da placa TGR/DCC com o QL5064 montado (a) e com a placa PMS-SB (b). (a) (b) Figura 5-14 Placa TGR com o QL5064 (a) e com a PMC-SB (b) Testes de Laboratório Os testes laboratoriais decorreram nos laboratórios do INOV- INESC Inovação. Na (Figura 5-15) mostra-se a mesa de teste 7 utilizada nos ensaios laboratoriais. Figura 5-15 Bancada de teste 6 A programação do QL5064 foi executada pelo fabricante, a QuickLogic, Inc. 7 A mesa de teste foi montada no INOV, e todos os aparelhos fornecidos por este. Foi também fornecida uma preciosa ajuda por parte dos elementos desta instituição, que pertencem ao projecto

68 Para realizar o teste funcional e de desempenho foi necessário implementar um firmware de teste para a TGR/DCC FPGA. Esse firmware tem como objectivo a simulação da interface entre o firmware original e o QL5464. A selecção do tipo de dados a enviar foi feita através de um botão existente na placa TGR/DCC. Para observar os sinais existentes na FPGA do QL5064 foi construída uma placa de teste 8. Essa placa foi ligada ao conector de teste existente na placa TGR/DCC, que por sua vez permitiu controlar o módulo de teste existente na arquitectura. Foi possível observar os sinais de controlo e de estado das FIFOs internos do QL5064. Esses sinais permitiam saber se os dados estavam a chegar às FIFOs e se eram correctamente interpretados, O primeiro teste foi o envio de dados correspondentes a respostas a comandos. Para esse teste foram monitorizados os sinais da FIFO correspondente (FIFO Single Mode). Os sinais observados encontram-se na Figura Nesta figura podem observar-se dois sinais. No canal 1 encontra-se o sinal de escrita na FIFO e no canal 2 observa-se o instante em que a mesma enche. Figura 5-16 Medição dos sinais da FIFO Single Mode No segundo teste, o envio de dados simulava o envio de dados de amostras provenientes de um exame. Nesse caso a FIFO a observar foi a FIFO Blast Mode. Neste caso fazia sentido observar o sinal XMT1_fifo_full da FIFO do core PCI. Os sinais observados estão visualizados na Figura Figura 5-17 Medição dos sinais da FIFO Blast Mode 8 A placa de teste foi desenvolvida pelo INOV, a nosso pedido

69 No canal 1 do osciloscópio está o sinal de escrita na FIFO Blast Mode. Assim que os dados começam a chegar a essa FIFO, o respectivo controlador transfere-os para a FIFO do core. Como do lado do PC não há qualquer tipo de leitura, essa a FIFO do core vai encher, como se pode observar no canal 2. Assim que isso acontece o controlador Blast Mode pára de transferir dados pelo que a FIFO Blast Mode acaba por encher também (canal 3). Na Tabela 5-7 encontra-se os tempos medidos experimentalmente e os obtidos por simulação relativos aos sinais descritos anteriormente. Essas medidas foram efectuadas desde o instante em que foi activado a escrita nas FIFO respectivas, por parte da TGR/DCC, até à activação das diversas flags. A diferença de tempos entre o simulado e o experimental é bastante reduzido, permitindo concluir que a arquitectura funciona como esperado. Tempo (ns) Simulação Experimental FIFO Full Core FIFO Full FIFO Almost Full Tabela 5-7 Medições dos sinais das FIFOs Com esses dois testes foi possível verificar que a arquitectura implementada na FPGA do QL5064 funcionava e que as seguintes funções estavam a funcionar correctamente: Os dados enviados pela TGR/DCC FPGA eram recebidos; A identificação do tipo de dados estava a ser feita correctamente; Os dados estavam a se enviados para as FIFO correctas; O controlador da Blast Mode FIFO funciona correctamente Emulação de um Barramento PCI Secundário Após iniciar os testes físicos com a placa TGR/DCC, verificou-se que não existia comunicação entre o Core PCI do QL5064 e a PMC-SB. Essa falha de comunicação devia-se a um erro no desenho da placa, que não respeitava os requisitos exigidos pelos dois componentes. De uma forma geral, tanto o QL5064 como a PMC-SB foram desenvolvidos para trabalhar num barramento PCI, o que na realidade não estava a acontecer, pois o que estava construído na placa TGR/DCC era um canal dedicado entre esses dois componentes. Deste modo a placa TGR/DCC teve que ser modificada para possibilitar esta comunicação. De facto, a ponte PCI-to-PCI, permite fazer a ligação entre dois barramentos PCI, um primário, que se encontra no PC, e um secundário, que se encontra no exterior

70 No presente caso foi necessário efectuar um conjunto de alterações na placa TGR/DCC, de forma a criar o barramento secundário. As especificações que definem o comportamento do barramento secundário podem ser consultadas em [47] e [57]. Um primeiro conjunto de alteração consistiu na implementação de um sinal de relógio que alimentasse todos os dispositivos, na alteração de algumas ligações entre o QL5064 e a PMC-SB e na implementação de alguns pull-ups. A descrição dessas alterações pode ser consultada em pormenor em [56]. O segundo conjunto de alterações consistiu na criação de um árbitro que garante a gestão do acesso ao barramento secundário, à semelhança do que acontece no barramento primário, e de um controlador necessário para a configuração inicial dos dispositivos. Essas alterações estão descritas em pormenor nas secções seguintes Árbitro O protocolo PCI define o acesso ao barramento é controlado por um árbitro. O algoritmo a utilizar para esse efeito não é especificado pelo protocolo, ficando ao critério dos fabricantes dos dispositivos que implementem o protocolo. Os sinais usados para esse controlo são REQ# e GNT#, individuais para cada dispositivo. O REQ# é usado pelo dispositivo para pedir acesso ao bus e o GNT# é usado pelo árbitro para conceder ao dispositivo o acesso a bus. No presente caso o barramento PCI secundário só é usado por dois dispositivos: o QL5064 e a PMC-SB. Cada um tem um modo de funcionamento distinto, O QL5064 só funciona em modo Target, nunca pede acesso ao barramento, e a PMC-SB só funciona em modo Master. Deste modo, basta atribuir acesso permanente á PMC-SB. Para tal o sinal GNT# da PMC-SB foi ligado a ground e o GNT# do QL5064 a VCC. Os sinais de REQ# dos dois dispositivos foram deixados em alta impedância, pois na configuração em estudo não foram usados Gestão RST/REQ64 O protocolo PCI permite que a comunicação entre os dispositivos seja feita a 32 ou 64 bits. Tanto o QL5064 como a PMC-SB têm a capacidade de comunicar nos dois formatos. Para conseguir uma maior largura de banda, a comunicação entre esses dispositivos é feita a 64 bits. O protocolo PCI define como a comunicação é feita por indicar aos dispositivos a capacidade do barramento de comunicar a 64 bits. Para isso utiliza o sinal REQ64#. Se no arranque do sistema, esse sinal estiver activo aquando da subida do sinal RST#, indica aos dispositivos que o barramento é de 64 bits. No entanto essa operação deve respeitar algumas regras no que toca aos valores temporais dos dois sinais. O diagrama temporal dessa operação está representado na Figura

71 Figura Diagrama temporal do uso dos sinais RST# e REQ64# na inicialização. Na Tabela 5-8 encontra-se os valores temporais mínimos e máximos permitidos. Símbolo Valor mínimo Valor máximo Unidades Descrição T RST 1 -- ms Tempo de reset activo depois de a alimentação estabilizar T RST-CLK µs Tempo de reset activo depois do sinal de relógio estabilizar T RRH 0 50 ns Tempo de espera desde a activação de RST# até ao REQ64# T RRSU 10xTciclo -- ns Tempo de permanência do REQ64# até à desactivação do RST# T RST-OFF 40 ns Tempo máximo de uso do RST# na inicialização Tabela 5-8 Requisitos de tempo dos sinais RST# e REQ64# Foi implementado um módulo na FPGA da TGR/ DCC que recebe como entrada o sinal RST# e tem como saída o sinal REQ64# (Figura 5-19). Figura 5-19 Esquema do módulo REQ64# Como se pode ver pela Tabela 5-8, os valores importantes para o desenvolvimento desse bloco são T RRH e T RRSU. Para que os tempos sejam respeitados com a comunicação trabalhar a 33MHz ou a 66MHz, e tendo em conta que a frequência de trabalho da FPGA é de 50 MHz, foram escolhidos os seguintes timings:

72 T RRH = 0 ns; T RRSU = 20 ciclos de relógio (de 50MHz) Modelo (firmware) da TGR/DCC Para testar a arquitectura foi desenvolvido um firmware de teste para a TGR/DCC FPGA, com o objectivo de emular, do ponto de vista funcional e de desempenho, a interface da TGR/DCC com o QL5064. Foi ainda necessário desenvolver um driver para o PC com rotinas que permitissem o envio e recolha de dados do QL5064. No presente documento só se irá descrever o firmware. Detalhes acerca das rotinas implementas podem ser consultadas em [56]. A emulação do firmware da TGR/DCC incidiu basicamente no módulo de comunicação entre a TGR/DCC FPGA e o QL5064. Testaram-se os seguintes cenários: Comunicação QL5064 -> TGR/DCC; Comunicação TGR/DCC -> QL5064; Identificação correcta dos cabeçalhos; Taxa de transferência. Para simplificar o desenho e permitir alterações rápidas, implementou-se uma arquitectura modular (ver Figura 5-20). A descrição detalhada de cada um desses módulos encontra-se nas secções seguintes. O esquema detalhado da arquitectura pode ser encontrado no Anexo 8. FPGA TGR/DCC FIFO de Resposta Módulo de Entrada QL5064 FIFO de Exame Módulo de Exame Módulo de Saída Figura 5-20 Arquitectura do emulador da TGR/DCC. Na Figura 5-20 destacam-se os módulos: Entrada, Teste, Saída, FIFOS e Multiplexer

73 Módulo de Entrada A função deste módulo (Figura 5-21) é receber os dados do QL5064 e interpretar os respectivos cabeçalhos. Dependendo do tipo de comando que recebe, há três tipos de acção a executar. Se for um comando de início/fim de um exame, essa indicação é passada ao módulo de simulação de exame através de um sinal ON/OFF. Se for um dos restantes comandos, definidos anteriormente, que exige uma resposta por parte da TGR, essa resposta é enviada à FIFO de saída correspondente. Se a cadeia de bits recebida for exactamente igual a uma cadeia predefinida anteriormente, é activado um dos LEDs da placa. Figura 5-21 Módulo de entrada Com esse conjunto de acções consegue-se validar a interpretação correcta dos cabeçalhos e posicionamento correcto dos bits de toda a cadeia. A descrição dos sinais deste módulo encontra-se a na Tabela 5-9. Sinal Tipo Descrição Ready_IN I Indica que o QL5064 está a enviar dados. Data_IN(63:0) I Dados de entrada. FIFO_Full I FIFO de saída cheia. RST I Sinal de reset. CLK I Sinal de relógio. DAE_Full O Indica ao QL5064 que não pode enviar dados. Test_ON_OFF_req O Inicia ou pára o exame. Data_Out(63:0) O Dados de saída. Write_FIFO O Activa a escrita na FIFO de saída. Status_LED O Flag que indica que o comando recebido é igual a x ou ABCDEF Tabela 5-9 Sinais do módulo de entrada da TGR/DCC

74 FIFO de Resposta a Comandos Esta FIFO (Figura 5-22) tem a capacidade de armazenar 16 respostas a comandos, ou seja, 16 pacotes de 64 bits. Tem como função guardar as respostas a comandos antes de esses dados serem enviados para o QL5064. Figura 5-22 FIFO de resposta a comandos O envio posterior desses dados para o QL5064 é feito pelo módulo de saída. Para gerar a FIFO usou-se o Xilinx Core Generator. A descrição dos sinais usados encontra-se na Tabela Sinal Tipo Descrição Din(63:0) I Dados de entrada. Wr_en I Activa a escrita na FIFO. Rd_en I Activa a leitura na FIFO. RST I Sinal de reset. CLK I Sinal de relógio. Dout(63:0) O Dados de saída. full O Flag que indica que a FIFO está cheia. empty O Flag que indica que a FIFO está vazia. Tabela 5-10 Sinais da FIFO de resposta a comandos Módulo de simulação de exame Este módulo simula os dados provenientes de um exame, particularmente, a elevada taxa de transferência de dados gerados

75 Figura 5-23 Módulo de simulação de exame O módulo gera pacotes de 64 bits, cujo cabeçalho respeita o especificado para esse tipo de dados. Essa geração começa ou pára quando o módulo de entrada dá indicação para tal. Esse módulo consegue enviar um pacote de 64 bits por cada ciclo de relógio. Deste modo a taxa de transferência máxima teórica dos dados produzido é de 400MB/s. Esse aspecto é muito importante, porque tem que se garantir que o valor da taxa de transferência medida depende da arquitectura implementada no QL5064 e não do firmware de teste. Os dados produzidos são encaminhados para uma FIFO destinada unicamente a esse tipo de pacotes. Na Figura 5-23 pode-se observar os sinais usados, e a sua descrição encontra-se na Tabela Sinal Tipo Descrição FIFO_Full I Indicação do estado da FIFO de saída. Exame_ON_OFF I Activa/Desactiva envio de dados. RST I Sinal de reset. CLK I Sinal de relógio. Data_OUT(63:0) O Dados de saída. Write_FIFO O Activa escrita na FIFO de saída. Tabela 5-11 Sinais do módulo de exame FIFO de simulação de exame Essa FIFO tem a capacidade de armazenar 32 pacotes de 64 bits. Tem como função guardar os dados provenientes da simulação de um exame antes de esses serem enviados para o QL

76 Figura 5-24 FIFO de simulação de exame Nessa FIFO foi implementado um sinal extra, o Prog_Full, configurado para assinalar a existência de um evento completo. Nessa arquitectura considerou-se que os eventos seriam sempre de 25 pacotes de 64 bits. O controlo do envio desses dados para o QL5064 é feito pelo módulo de saída. Para gerar a FIFO usou-se o Xilinx Core Generator. Os sinais usados podem ser observados na Figura 5-24 e a sua descrição na Tabela Sinal Tipo Descrição Din(63:0) I Dados de entrada. Wr_en I Activa a escrita na FIFO. Rd_en I Activa a leitura na FIFO. RST I Sinal de reset. CLK I Sinal de relógio. Dout(63:0) O Dados de saída. full O Flag que indica que a FIFO está cheia. empty O Flag que indica que a FIFO está vazia. prog_full O Flag que indica que há pelo menos um evento armazenado. Tabela 5-12 Sinais da FIFO de simulação de exame Módulo de Saída O módulo de saída (Figura 5-25) é o responsável por enviar dados para o QL5064, para posterior envio para o PC. Há dois tipos de dados possíveis, dados de simulação de um exame ou resposta a comandos. Estes dados são armazenadas em FIFOs distintas

77 Figura 5-25 Módulo de saída. O modo de funcionamento desse módulo consiste basicamente em verificar o estado das duas FIFOs. Caso a FIFO do exame contenha dados e o QL5064 esteja disponível para os receber, esses são enviados para o mesmo. O envio é efectuado quando a FIFO tiver pelo menos 25 pacotes (numero máximo de pacotes por evento) e o QL5064 tiver disponibilidade para receber pelo menos um evento inteiro. Se a FIFO de resposta a comandos não estiver vazia e o QL5064 tiver disponibilidade para receber, essa resposta é enviada. Os dados dessa FIFO têm prioridade sobre os dados da anterior, dado que o tempo associado à simulação de um exame é elevado e poderia provocar o enchimento da FIFO. Todas as verificações do estado das FIFOs e da disponibilidade do QL5064 são feitas por intermédio de flags, que indicam os seus estados. O módulo de saída comanda ainda o multiplexer de saída. Na Tabela 5-13 encontra-se uma descrição dos sinais usado por este módulo. Sinal Tipo Descrição RST I Sinal de reset. CLK I Sinal de relógio. QL_fifo_full QL_fifo_almost_full I I Flag que indica que a FIFO de respostas do QL5064 está cheia. Flag que indica que a FIFO do QL5064 que recebe os dados de um exame não tem espaço para um evento completo. fifo_empty I Indica que a FIFO de respostas está vazia. event_in Ql_write I O Indica que existe pelo menos um evento na FIFO de exame. Sinal que indica ao QL5064 que os dados presentes são validos. read_response_fifo O Activa a leitura na Single Mode FIFO. read_exame_fifo O Activa a leitura na Blast Mode FIFO. sel_mux O Selecciona a entrada do multiplexer da saída. 0 Single Mode FIFO 1 Blast Mode FIFO Tabela 5-13 Sinais do módulo de saída da TGR/DCC

78 5.7. Resultados da Solução PCI Após a realização das alterações indicadas anteriormente foi possível por o sistema a funcionar e o sistema operativo detectar correctamente, a presença quer do QL5064 quer da ponte PCI-to-PCI. Os drivers que foram desenvolvidos para o efeito foram instalados de forma a possibilitar o uso das rotinas descritas em [56] (Figura 5-26). Figura 5-26 Detecção do sistema pelo Sistema Operativo Fazendo uso do firmware de teste desenvolvido para a TGR/DCC FPGA (secção 5.6.3), foi possível enviar e receber dados provenientes do PC. O esquema de teste usado foi o mesmo que foi usada na simulação (secção 5.5.2). Do ponto de vista funcional o sistema funcionou correctamente em todos os testes realizados. Foi possível a transmissão de dados entre a TGR/DCC FPGA e o PC. No entanto em relação ao desempenho do sistema só foi possível atingir uma taxa de transferência de 5 MB/s, quando o esperado era de aproximadamente 180 MB/s. Para perceber o problema, e tendo em conta que os testes à arquitectura indicavam que a mesma estava a funcionar correctamente, foi necessário perceber o que se passava entre o barramento PCI primário e o secundário, ou seja, como estava realmente a funcionar a ponte PCI-to- PCI. Após analisar alguns sinais dos dois barramentos, chegou-se à conclusão que a enorme latência dos sinais que percorriam a ponte PCI, impossibilitava a transferência de dados em burst, ou seja, a transmissão estava a ser executada palavra a palavra. A solução para o problema anterior passava pela alteração do modo de funcionamento do QL5064, ou seja, esse deveria funcionar em modo Master, permitindo assim o uso de transferências em modo DMA. A implementação desse modo de funcionamento poderia ser realizada com poucas alterações ao firmware actual (Target). No entanto, o anúncio do fim de produção do QL5064, obrigou a repensar a comunicação entre a TGR/DCC e o PC. Seria possível substituir o dispositivo QL5064 por outro dispositivo

79 semelhante, se existisse um com capacidade de comunicação a 64 bits. Não era o caso. Foi pois necessário averiguar outras soluções Solução USB/S-LINK Uma solução que foi ponderada para assegurar a comunicação TGR/DCC PC, foi a utilização do S-LINK [58]. Trata-se de um protocolo de comunicação desenvolvido pelo CERN e que já tinha sido considerada no início do projecto, mas rapidamente desconsiderada por ser unidireccional e não haver um fornecedor comercial que a suportasse. No entanto, quando se abandonou (pelo menos temporariamente) a solução PCI, o S-LINK já se encontrava numa fase de desenvolvimento mais avançada e com alguns produtos comerciais disponíveis, pelo que se decidiu pelo seu uso. A elevada taxa de transferência permitida pelo S-LINK, permitia a transferência de dados provenientes de um exame PEM para o PC de reconstituição de imagem, mas esse envio só era possível numa direcção, pois o S-LINK continua unidireccional. Para contornar esta limitação decidiuse usar um segundo sistema de comunicação para o envio de comandos por parte do PC, o USB 2.0. O USB foi escolhido por várias razões. Tem uma taxa de transferência aceitável para o envio de pedidos do PC 9, e é amplamente usado nos PCs comerciais actuais. Adicionalmente, na placa TGR/DCC já existia um microcontrolador, o Cypress FX2LP [59] [60], usado para monitorizar temperaturas, correntes e tensões das placas DAC. Este controlador usa o protocolo USB 2.0 para comunicar com o PC, pelo que foi utilizado para receber pedidos e enviar respostas para o PC, com algumas alterações no firmware da TGR/DCC. Inicialmente foi desenvolvida uma solução USB temporária, que recorria a um firmware de comunicação específico na FPGA TGR/DCC. Este firmware destinava-se a converter os sinais usados na comunicação com o QL5064, em sinais usados na comunicação com o microcontrolador USB. Esta solução foi desenvolvida para apoio ao teste do sistema, nas fases iniciais. Permitia a comunicação entre o DAE e o computador exterior, através de um conector de teste desenvolvido para o efeito. O barramento de dados usado na solução inicial era de 8 bits, embora, o microcontrolador permita uma comunicação de 16 bits. Além disso, a solução não respeitava os requisitos temporais exigidos pelo fabricante do microcontrolador e também não efectuava a monitorização do estado das flags do microcontrolador. Essas inconsistências poderiam criar problemas durante a utilização real do sistema. Deste modo, foi decidido desconsiderar aquela solução e foi decidido desenvolver um módulo de comunicação, com uma solução inteiramente nova, para assegurar a comunicação entre a FPGA da TGR/DCC e o microcontrolador. Esta solução utiliza um barramento de dados de 16 bits, e respeita os requisitos de temporização do microcontrolador Cypress FX2LP. Assegura de igual modo a monitorização do estado das flags do microcontrolador. 9 Como foi referido, o valor teórico da taxa de transferência máxima do USB 2.0 é de 60MB/s

80 A solução S-LINK é objecto do trabalho descrito em [56]. Nesta Dissertação descreve-se o trabalho desenvolvido pelo autor na implementação da solução USB. O diagrama de blocos da arquitectura usada nesta solução pode ser visualizado na Figura Protocolo proprietário Placa TGR/DCC 16 Microcontrolador USB Protocolo USB Controlador USB PC FPGA TGR/DCC 64 Placa S-LINK (mezannine) Protocolo proprietário Placa S-LINK (PCI) Protocolo S-LINK Figura 5-27 Diagrama de blocos da solução USB & S-LINK

81 6. Interface USB Como foi descrito anteriormente, adoptou-se neste sistema, uma solução baseada no protocolo USB para assegurar a comunicação no sentido PC TGR/DCC. Esta solução assegura ainda o envio de respostas a comandos do PC por parte do DAE. Apesar da taxa de transferências desse tipo de interfaces ser bastante inferior à usada em outras soluções, nomeadamente, baseadas nos protocolos PCI ou S-LINK, é suficiente para o tipo de comunicação a que se destina, caracterizada por dados enviados em blocos de pequena dimensão, e consequentemente, não exigindo grandes taxas de transferências Cenários de Comunicação USB A interface USB é responsável pelo envio de dados nos seguintes cenários: Dados enviados do PC para o DAE: Envio de constantes de calibração do sistema; Pedido de erros; Pedido de inicio de BIST; Alteração do modo de funcionamento (Single e Normal/Aleatório); Pedido de inicio/paragem de exame. Dados enviados do DAE para o PC: o Envio da resposta ao pedido de erros; o Envio do resultado do BIST Arquitectura do Módulo de Comunicação Como foi descrito anteriormente o modulo DCC ROC da TGR/DCC, é o responsável pelo envio e recepção de dados para e do PC, respectivamente. Assim, e à semelhança do que se fez para o desenvolvimento da solução PCI, foi necessário desenvolver um módulo de comunicação que estabeleça a interface entre o TGR/DCC e os dois canais de comunicação, S-LINK e USB. Na Figura 6-1 apresenta-se a inserção do módulo de comunicação na placa TGR/DCC do sistema PEM

82 FPGA TGR/DCC DCC Buffers TGR/DCC ROC DCC ROC TGR Módulo de Comunicação Placa TGR/DCC Microcontrolador USB Placa S-LINK PC Figura 6-1 Arquitectura TGR/DCC com o módulo de comunicação Uma vez que a comunicação via USB é realizada por intermédio do microcontrolador Cypress FX2LP [59] [60], descrevem-se de seguida, muito brevemente, os blocos deste microcontrolador, com os quais o módulo de comunicação dialoga Microcontrolador Cypress FX2LP O microcontrolador USB usado para efectuar a interface entre a TGR/DCC FPGA e o PC é o Cypress FX2LP que permite implementar todas as funcionalidades do protocolo USB 2.0. A gestão da comunicação é realizada automaticamente pelo microcontrolador. A Figura 6-2 mostra o diagrama de blocos da arquitectura deste microcontrolador. Em [61] podem obter-se informações mais detalhadas sobre a implementação desse microcontrolador na placa TGR/DCC e também sobre as configurações aí desenvolvidas. O objectivo desta descrição breve é identificar os blocos do microcontrolador utilizados na implementação do módulo de comunicação via USB

83 Figura 6-2 Diagrama de blocos do microcontrolador Cypress FX2LP Duas das quatro (Figura 6-2) memórias FIFOs de 4 Kbytes (cada) são utilizadas para enviar/receber os dados para/da FPGA TGR/DCC. Estas duas FIFOs são associadas aos USB Endpoints, (buffers usados nos dispositivos USB). Os USB Endpoints permitem enviar dados pela FPGA TGR/DCC directamente para o SIE (Serial Interface Engine) sem ser necessário que passem pelo core Isto é muito vantajoso, na medida em que a frequência de trabalho do core (48MHZ) degradaria o desempenho. Na Figura 6-3 mostram-se os blocos do microcontrolador USB utilizados pelo módulo de comunicação na transferência de dados para o PC. Figura 6-3 Diagrama de blocos da interface de comunicação com o Cypress FX2LP

84 Na Figura 6-4 representam-se os sinais usados na interface das FIFOs do FX2LP. Figura Interface das FIFOs do FX2LP As operações de leitura e escrita nestas FIFOs são idênticas operações de escrita/leitura em qualquer FIFO, ou seja, existe um canal de dados, sinais de escrita e leitura, flags com indicação do seu estado e sinal de relógio. A escrita e leitura são síncronas, sendo o sinal de relógio, de 48 MHz, fornecido pelo FX2LP. Os sinais de endereçamento permitem escolher a FIFO pretendida. O sinal de PKEND indica o fim de envio de um conjunto de dados e que os mesmos podem ser enviados para o PC Comunicação FX2LP-TGR/DCC A comunicação com a TGR/DCC FPGA pode ser realizada por um barramento de 8 ou um de 16 bits. Como foi referido anteriormente, no presente trabalho foi utilizado o barramento de 16 bits na medida em que simplificava a arquitectura a desenvolver e aumentava a largura de banda da transmissão de dados. A comunicação entre o FX2LP e a FPGA TGR/DCC é feita usando as FIFOs associados aos endpoint 2 e 6 do microcontrolador USB. O endpoint 2 é usado para receber comandos do PC; O endpoint 6 serve para enviar dados para o PC. Todas as operações de acesso a essas duas FIFOs são síncronas, com o sinal de relógio (IFCLK) a ser fornecido pelo FX2LP. A escolha da FIFO pretendida é feita pelos sinal de endereçamento FIFODR[1:0]. O acesso a essas FIFOs é feita pelas linha de dados, FD[15:0]

85 6.4.1 Operação de Leitura Do ponto de vista do módulo de comunicação, a FIFO associada ao endpoint 2, só é acessível para operações de leitura. As acções que têm lugar na operação de leitura ocorrem na sequência seguinte: 1. A flag empty indica que existem dados para ser lidos; 2. Quando recebe essa indicação, a FPGA TGR/DCC actua sobre o sinal SLOE (Slave Output enable); 3. Esse sinal faz com que os dados da FIFO endereçada apareçam no barramento de dados; 4. O SLRD (Slave Read) incrementa o apontador da FIFO; 5. Os dados seguintes são disponibilizados à saída da FIFO. Os sinais SLOE e o SLRD são activos a low. A actuação dos sinais SLOE e o SLRD tem restrições de temporização. Na Figura 6-5, ilustram-se os sinais envolvidos na operação de leitura. O diagrama temporal dos sinais e as restrições de temporização são indicados na Figura 6-6 e na Tabela 6-1, respectivamente. Figura 6-5 Interface de leitura entre a FPGA TGR/DCC e o FX2LP Figura 6-6 Diagrama temporal da operação de leitura na FIFO do FX2LP

86 Símbolo Min. Max. Unidades Descrição T IFCLK 20,83 -- ns Período do sinal de relógio T SRD 18,7 -- ns Tempo de setup do SLRD -> IFCLK T RDH 0 -- ns T OEon -- 10,5 ns T OEoff -- 10,5 ns Tempo de permanência do IFCLK -> SLRD Tempo desde a activação do SLOE até haver dados validos Tempo de permanência dos dados desde a desactivação do SLOE T XFLG -- 9,5 ns Atraso da propagação das flags T XFD ns Atraso de propagação dos dados Tabela 6-1 Parâmetros da operação de leitura da FIFO do FX2LP Operação de Escrita A FIFO associada ao endpoint 6 é acedida, do ponto de vista do sistema de comunicação, para operações de escrita. Essa operação só é efectuada quando a flag full não estiver activa. As acções envolvidas numa operação de escrita são as seguintes: A flag full indica que existem a FIFO tem espaço disponível; O sinal SLWR (Slave Write) activa a operação de escrita na FIFO endereçada; É activado o sinal PKTEND que indica ao microcontrolador que não há mais dados para enviar. O sinal SLWR é activo a low. Os sinais usados na operação de escrita são os indicados na Figura 6-7. Figura Interface de escrita entre a FPGA TGR/DCC e o FX2LP Esta operação tem restrições de temporização. O diagrama temporal da operação de escrita encontra-se na Figura 6-8 e as restrições de temporização na Tabela

87 Figura Diagrama temporal da operação de escrita na FIFO do FX2LP Símbolo Min. Max. Unidades Descrição T IFCLK 20,83 -- ns Período do sinal de relógio T SWR 18,1 -- ns Tempo de setup do SLWR -> IFCLK T WRH 0 -- ns Tempo de permanência do IFCLK -> SLRD T SFD 9,2 -- ns Tempo de setup dos Dados -> IFCLK T FDH 0 -- ns Tempo de permanência IFCLK -> Dados T XFLG -- 9,5 ns Atraso da propagação das flags Tabela Parâmetros da operação de escrita da FIFO do FX2LP 6.5. Módulo de Comunicação O diagrama de blocos do módulo de comunicação encontra-se representado na Figura 6-9. No Anexo 9 apresentam-se os diagramas detalhados desses dois blocos. Módulo USB Módulo S-LINK 64 Módulo Comunicação FIFO Assíncrona Controlador USB FIFO Assíncrona FIFO Síncrona 64 Controlador S-LINK 16 Microcontrolador USB Placa S-LINK Figura 6-9 Diagrama de blocos do módulo de comunicação na FPGA TGR/DCC

88 O módulo de comunicação desenvolvido na FPGA TGR/DCC é constituído por dois módulos. O módulo de comunicação via USB, simplesmente designado módulo USB e o módulo de comunicação via S-LINK, simplesmente designado, módulo S-LINK. O módulo S-LINK é constituído por uma memória FIFO e um controlador S-LINK. A memória FIFO é síncrona com a restante arquitectura e com o controlador, que por sua vez é responsável pelo envio dos dados armazenados na FIFO para a placa S-LINK. Uma descrição mais detalhada deste módulo encontra-se em [56]. Na secção seguinte descreve-se o módulo USB em pormenor Módulo de Comunicação via USB O módulo USB é constituído por duas memórias FIFOs assíncronas e um controlador. Uma das FIFOs é utilizada para o envio de dados para o PC e a outra para receber os dados provenientes do PC. O controlador gere o fluxo de dados entre essas FIFOs e o microcontrolador USB. A comunicação entre esse bloco e a TGR/DCC FPGA é controlada pelo módulo DCC ROC. A comunicação do lado da TGR/DCC é realizada à frequência do sinal de relógio da FPGA da TGR/DCC e a comunicação com o microcontrolador USB é realizada à frequência do sinal de relógio fornecido pelo microcontrolador USB, o IFCLK. Estas duas frequências são diferentes, pelo que foi necessário sincronizar as duas comunicações. Para tal, utilizaram-se FIFOs assíncronas, isto é, memórias em que as operações de leitura e escrita são realizadas com sinais de relógio distintos. A comunicação entre o DCC ROC e o módulo USB é realizado por meio de dois barramentos de 64 bits, um para enviar dados e outro para receber dados. A comunicação é feita directamente para as duas FIFOs do módulo USB. Duas flags indicam o estado das FIFOs, e dois sinais são usados para activar as operações de escrita e de leitura. Na Tabela 6-3 encontra-se a lista desses sinais e a sua descrição individual. Sinal Tipo Descrição ROC_DataOut[63:0] O Barramento de dados do DCC ROC para o módulo USB. ROC_FIFO_Read I Activação da leitura na FIFO do módulo USB. ROC_FIFO_Empty O Flag que indica que a FIFO do modulo USB está vazia. ROC_DataIn[63:0] I Barramento de dados do módulo USB para o DCC ROC. ROC_FIFO_Write I Activação da escrita na FIFO do módulo USB. ROC_FIFO_Full O Flag que indica que a FIFO do modulo USB está cheia Tabela 6-3 Sinais da interface do DCC ROC com o módulo USB. Na Figura 6-10 ilustra-se os diálogos entre o módulo de comunicação e o módulo DCC/ROC e o módulo de comunicação e o microcontrolador USB

89 ROC_DataOut[63:0] ROC_FIFO_Read USB_Data[15:0] ROC_FIFO_Empty USB_FIFOAdr0 DCC ROC Módulo Comunicação via USB USB_FIFOAdr1 USB_SLRD_L USB_SLWR_L USB_SLOE_L Microcontrolador USB USB_PktEnd ROC_DataIn[63:0] ROC_FIFO_Write ROC_FIFO_Full USB_FIFO_Full USB_FIFO_Empty Figura 6-10 Interface do módulo USB Memórias FIFOs do Módulo de Comunicação via USB A comunicação com o microcontrolador USB é feita por um barramento de 16 bits à frequência de 48 MHz. A comunicação com o DCC ROC é feita por um barramento de 64 bits à frequência de 50 MHz. Para garantir o sincronismo do sistema, utilizaram-se, como foi referido FIFOs assíncronas. São FIFOs com interfaces de escrita e de leitura distintas, utilizando barramentos de dados de diferentes dimensões e sinais de relógio de diferentes frequências. Essas FIFOs têm uma capacidade de 16 pacotes de 64 bits, ou 64 pacotes de 16 bits, dependo da interface que se está a avaliar. Os diagramas de blocos das FIFOs, com indicação dos sinais e dados envolvidos no seu funcionamento são representados na Figura (a) (b) Figura 6-11 Memórias FIFO (a) dados para o PC; (b) dados do PC A descrição dos sinais usados pelas duas FIFOs encontra-se na Tabela

90 Sinal Tipo Descrição din I Barramento de dados para escrita. dout O Barramento de dados para leitura. empty O Flag que indica que a FIFO está vazia. full O Flag que indica que a FIFO está cheia. wr_en I Activação da escrita na FIFO. rd_en I Activação da leitura na FIFO. wr_clk I Sinal de relógio para operações de escrita. rd_clk I Sinal de relógio para operações de leitura. Tabela 6-4 Sinais usados pelas FIFOs do módulo USB As FIFOs foram implementas usando o Core Generator disponível na ferramenta de desenvolvimento. Esta ferramenta permite criar diversos tipos de entidades que podem ser facilmente implementadas e que estão optimizadas para as diferentes FPGAs disponibilizadas pelo fabricante Controlador do Módulo de Comunicação via USB A função deste bloco é gerir o fluxo de dados entre as duas FIFOs e o microcontrolador USB. Para isso, as flags das FIFOs descritas na secção anterior e as flags das FIFOs do microcontrolador USB, as USB endpoints, são constantemente monitorizadas. Os sinais usados por esse bloco podem ser visualizados na Figura 6-12 e as suas descrições na Tabela 6-5. Figura 6-12 Sinais usados no controlador USB

91 Modo de Funcionamento O controlador do módulo de comunicação via USB, simplesmente designado, controlador USB, inicia a transferência de dados sentido DCC ROC USB, quando há dados na respectiva FIFO e o microcontrolador USB está disponível para os receber. Todos os dados provenientes da TGR/DCC têm a dimensão de 64 bits. Porém, a comunicação com o microcontrolador USB é realizada a 16 bits de cada vez. Isto obriga a que sejam necessárias 4 operações de escrita/leitura para transferir os 64 bits. Assim, é necessário enviar uma trama de 4 pacotes de 16 bits. Essa operação é realizada pelo controlador USB. O fim de envio de ma trama, é indicado ao microcontrolador, por meio do sinal PktEnd. Esse é necessário, pois só assim o microcontrolador dá indicação ao PC que tem dados disponíveis. A operação de transferência de dados no sentido USB DCC ROC inicia-se quando o microcontrolador indica que tem dados disponíveis e a respectiva FIFO do módulo USB tem espaço para armazená-los. À semelhança com o que acontece com os dados provenientes da TGR/DCC, os dados enviados pelo PC têm a dimensão de 64 bits. Uma vez mais são necessárias 4 operações de escrita/leitura para transferir os dados do microcontrolador para a respectiva FIFO do módulo USB. Os sinais e o protocolo usado na comunicação como o microcontrolador estão descritos na secção 6.4. Sinal Tipo Descrição FIFOtoROC_Full I Flag que indica se a FIFOtoROC está cheia FIFOtoROC_WR O Activa a escrita dos dados na FIFOtoROC FIFOfromROC_Empty I Flag que indica que a FIFOfromROC está vazia. FIFOfromROC_RD O Activa a escrita dos dados na FIFOfromROC USB_FlagA I Flag que indica se a USB Endpoint 2 10 está vazia. USB_FlagC I Flag que indica se a USB Endpoint 6 10 está cheia. USB_FIFOAdr0 USB_FIFOAdr1 O Selecção da FIFO do microcontrolador que se quer aceder USB_SLRD_L O Activa a leitura dos dados do USB Endpoint 2 10 USB_SLWR_L O Activa a escrita dos dados do USB Endpoint 6 10 USB_SLOE_L O Selecciona a direcção do barramento de dados USB_PktEnd O Indicação de fim de trama clk I Sinal de relógio reset I Sinal de reset Tabela 6-5 Descrição dos sinais usados pelo controlador USB. 10 Ver secção

92 6.7. Alterações ao DCC ROC Conforme já foi referido, o módulo de comunicação interage com o bloco DCC/ROC da FPGA TGR/DCC. Foi necessário efectuar algumas alterações no DCC/ROC, para implementar a comunicação com o módulo de comunicação USB e S-LINK. Foram efectuadas as seguintes as alterações: Foram adicionados os sinais necessários para o módulo de comunicação; As máquina de estados dos módulos de entrada e de saída do DCC/ROC, nomeadamente, os módulos RIC (Read-In Controller) e ROC (Read-Out Controller) foram modificados por forma a respeitar o novo protocolo de comunicação; O ROC passou a usar dois barramentos distintos, um para o USB e outro para o S- LINK, dependendo do tipo de dados Implementação Física do Módulo de Comunicação O firmware implementado na FPGA TGR/DCC contendo o módulo de comunicação foi desenvolvido com a ferramenta ISE i da XILINX [62]. Todas as interligações ao exterior são realizadas na placa TGR/DCC, nomeadamente, a que se refere à utilização da estrutura de configuração da FPGA TGR/DCC Simulação e Teste O funcionamento correcto do módulo de comunicação via USB implementado foi validado em primeiro lugar por simulação. O módulo de comunicação USB foi simulado e testado como um módulo isolado e inserido no sistema DAE, isto é, com o firmware desenvolvido para o módulo de comunicação e com as alterações ao DCC/ROC incluídos no firmware da FPGA TGR/DCC. Este último caso corresponde à simulação em condições de funcionamento real. Para a simulação, recorreu-se ao simulador ModelSim [62] v6.3g da Mentor Graphics [63] e desenvolveram-se testbenches adequados. Os sinais eram injectados nas entradas do módulo e as saídas eram observadas na interface do simulador. Na simulação foram utilizados no primeiro caso, dados genéricos, isto é, dados que não correspondiam aos dados provenientes de um exame PET, mas que permitiam testar um sistema de comunicação. No segundo caso, foram utilizados dados reais Simulação do Modulo de Comunicação via USB Para aferir se a funcionalidade implementada satisfazia os requisitos funcionais especificados, simularam-se os dois cenários de funcionamento: Envio de dados do DCC/ROC módulo USB; Envio de dados do PC módulo USB

93 Em ambos os casos, observaram-se os dados na saída do módulo USB e conclui-se que os dados tinham sido correctamente transmitidos. Verificou-se que os dados chegavam à saída no formato correcto, isto é, no 1º caso (sentido TGR/DCC - PC): Entrada - injectaram-se sequências de pacotes de 64 bit; Saída - observou-se a mesma sequência em pacotes de 16 bit. no 2º caso (sentido PC TGR/DCC): Entrada - injectaram-se sequências de pacotes de 16 bit; Saída - observou-se a mesma sequência em pacotes de 64 bit. Estes resultados permitem concluir que as FIFOs assíncronas funcionaram correctamente, na medida em que as operações de leitura e escrita foram correctamente executadas. Pode pois concluir-se, dos resultados da simulação, que o sistema executava correctamente a funcionalidade pretendida Teste Laboratorial do Módulo de Comunicação via USB Após implementação física, procedeu-se aos testes laboratoriais do sistema. A realização dos testes contou com a colaboração da equipa do INOV envolvida no projecto PEM. Estes testes foram realizados no laboratório do INOV, usando a placa TGR/DCC configurada com firmware dedicado desenvolvido para a realização deste teste. Este firmware reproduzia o testbench utilizado na simulação. A transmissão de dados do PC para a placa TGR/DCC e vice-versa foi conseguida com sucesso neste contexto de teste Simulação do Sistema DAE com o Módulo de Comunicação via USB Na segunda fase foi testado o módulo de comunicação inserido no firmware completo da TGR/DCC, isto é, foi testado o módulo de comunicação e as alterações introduzidas no DCC/ROC para compatibilizar este módulo com o módulo de comunicação. Simula-se deste modo, o comportamento de firmware de comunicação desenvolvido, em condições de funcionamento real. Foi desenvolvido para o efeito um testbench onde se implementou o envio de dados reais. O formato desses dados está descrito na secção desta Dissertação. Foram simulados os seguintes cenários:

94 Dados enviados do PC para o DAE: o Envio de constantes de calibração do sistema; o Pedido de erros; o Pedido de início de BIST (Built In Self Test); o Alteração do modo de funcionamento (Single e Normal/Aleatório); o Pedido de início/paragem de exame. Dados enviados do DAE para o PC: o Envio da resposta ao pedido de erros; o Envio do resultado do BIST; o Envio de dados provenientes de um exame. Resultados de simulação Embora a frequência de trabalho seja de 100 MHz, todas as simulações foram realizadas a uma frequência de 50 MHZ foram simulados todos os cenários com dados reais e os resultados da simulação mostraram que, do ponto de vista funcional, a transmissão de dados nos dois sentidos, estava correcta em todos os cenários Teste Laboratorial do Sistema DAE com o Módulo de Comunicação via USB Os testes foram realizados, nas instalações do TAGUSLIP, em colaboração com a equipa de investigação do LIP aí residente. Os testes foram realizados em conjunto com os testes do sistema de comunicação S-LINK 11 permitindo, deste modo, testar não só os módulos de comunicação mas também as alterações realizadas no firmware da FPGA - TGR/DCC para compatibilizá-lo com este sistema de comunicação. Os testes funcionais realizados foram os seguintes: Foram enviados pedidos pelo PC; Foi observado a dos pedidos chegada no barramento GBUS; As respostas aos pedidos de erros e resultado do auto-teste (BIST) foram recebidas pelo PC. Para realizar os testes desempenho, foram utilizadas placas desenvolvidas para emular o scanner e electrónica de Front End, as FE-EMU (Front End Emulator). Estas placas simulam o envio de dados provenientes de um exame. 11 Os membros da equipa do INESC-ID que participou na realização destes testes foram: Pedro Machado e Carlos Leong

95 Resultados do Teste Laboratorial Com os testes descritos na secção anterior foi possível tirar as seguintes conclusões relativamente ao funcionamento da arquitectura implementada: Foram enviados comandos pelo PC, via USB, com sucesso; Foram enviados respostas a comandos para o PC, via USB, com sucesso; Foram enviados dados, provenientes de um exame, para o PC, com sucesso; Foi comprovado o funcionamento correcto da arquitectura; Obteve-se uma taxa de transferência máxima de 85 MB/s. Esta taxa de transferência apesar inferior do que a especificada (150 MB/s), é suficiente para os testes clínicos iniciais. Esse valor está a ser limitado pelo GBUS. Espera-se que depois da modificação do GBUS se atinja a taxa de transferência requerida

96

97 7. Conclusões e Trabalho Futuro Na presente Dissertação apresentou-se o projecto, desenvolvimento, implementação física e validação de duas soluções para o sistema de transmissão de dados entre o sistema electrónico do sistema PET e o computador externo de reconstituição de imagem. O trabalho foi desenvolvido no âmbito de um projecto inovador onde se pretende desenvolver um sistema para detecção de cancro da mama baseado em tecnologia PET (Positron Emission Tomography). O sistema é designado genericamente por sistema PEM (Positron Emission Mammography). Os resultados dos exames realizados pelo sistema PEM, são imagens das células cancerígenas detectadas no interior do corpo humano. Estas imagens são reconstituídas a partir de dados obtidos em exames médicos com o sistema PEM. Esses dados são detectados por um scanner de cristais e processados pelo sistema electrónico, que recebe e processa essa informação. Uma das características do sistema PEM é a enorme quantidade de informação gerada durante um exame. Deste modo é crucial que o sistema de comunicação entre o sistema electrónico e o PC de reconstituição de imagem seja capaz de garantir uma taxa de transmissão e fiabilidade elevadas. Para implementar esse sistema de comunicação foram estudadas e desenvolvidas duas soluções distintas. A primeira baseada no protocolo PCI e a segunda nos protocolos USB e S-LINK, sendo esse ultimo um protocolo proprietário do CERN. A Solução PCI é baseada num dispositivo comercial, o circuito QL5064, constituído por um core PCI e uma FPGA, e num conjunto de placas comerciais que realizam uma ponte PCI-to-PCI. O trabalho que se descreve nesta dissertação refere-se à adaptação do QL5064 para esta aplicação específica. A arquitectura desenhada e simulada foi implementada no circuito físico e cumpriu os requisitos funcionais de especificação. Dois motivos levaram a que se abandonasse, de momento, esta solução, sendo o mais importante o facto de a produção do QL5064 ter sido descontinuada. O desenvolvimento do sistema baseado no protocolo S-LINK foi a solução escolhida. Dado que o S-LINK é um sistema unidireccional, foi necessário implementar um segundo sistema que garantisse a comunicação nos dois sentidos e que fosse utilizado para a comunicação dos dados que não requeriam grande largura de banda. Pela sua popularidade, versatilidade e simplicidade de uso escolheu-se o sistema USB. O desenvolvimento do sistema de comunicação baseado no protocolo USB foi a segunda solução realizada no âmbito deste trabalho. A arquitectura desenvolvida foi implementada na FPGA TGR/DCC. Os resultados de simulação e os testes laboratoriais mostram que o sistema desenvolvido cumpre os requisitos de especificação. De facto, testes laboratoriais revelaram que com a FPGA TGR/DDC a trabalhar a uma frequência de 50 MHZ é possível transmitir correctamente dados de e para o PC com uma taxa de transferência máxima de 85 MB/s. Este valor não cumpre as especificações, mas é limitado pelo TGR/DCC e não pelo USB. A solução implementada para a comunicação entre a DAE e o PC de reconstrução de imagem, usando simultaneamente os protocolos USB e o S-LINK, não deverá ser uma solução final,

98 na medida em que existem limitações físicas associadas ao protocolo USB, nomeadamente no que se refere a largura de banda e comprimento máximo dos cabos de ligação. Esta solução é suficiente para a realização dos testes clínicos iniciais. Contudo tem insuficiências óbvias. De facto, utilizar dois sistemas distintos, USB e S-LINK, para efectuar a mesma tarefa, ou seja, comunicar com o PC, não é uma solução muito elegante. Por outro lado, não é difícil de prever no futuro querendo desenvolver sistemas PEM mais sofisticados, os requisitos funcionais e de desempenho serão mais exigentes, nomeadamente, no que se refere à taxa de transferência e às dimensões dos cabos. Está já em desenvolvimento no INOV, uma solução que permite resolver os problemas apontados. Este sistema, tal como o S-LINK, é constituído por duas placas: a placa PCI-E, no interior do PC de reconstrução de imagem, e uma mezzanine, na placa TGR/DCC [64][65]. Essa ligação usa os conectores existentes na placa TGR/DCC (como a mezzanine S-LINK). Na Figura 7-1 apresentase uma arquitectura possível para este sistema. A ligação entre as placas é realizada por um cabo de fibra óptica. Esta solução garante a comunicação entre DAE e o PC nos dois sentidos, com taxas de transferência muito elevadas e com distâncias entre placas também superiores. Esse sistema, baseado em fibra óptica assegura também uma transmissão mais fiável. Placa PCI-E Modulo SFP A Cabo de Fibra Óptica Placa Mezzanine FPGA Modulo SFP B Modulo SFP FPGA Sinais de Dados Sinais de Controlo PCI-E PHY Interface PCI-E Figura Solução Óptica para a comunicação entre o DAE e o PC É necessário desenvolver firmware para cada uma das duas placas: para a placa PCI-E e para a mezzanie. O firmware da placa PCI-E faz a interface entre os links ópticos e o core PCI. Será necessário estudar o funcionamento desse core. O firmware da mezzanine faz a interface entre o link óptico e a FPGA TGR/DCC. Numa primeira versão, a comunicação com a FPGA TGR/DCC utiliza o protocolo S-LINK, o que permite tirar partido dos conhecimentos adquiridos, e evita que seja necessário alterar o firmware da FPGA TGR/SCC. Este sistema de comunicação é suficientemente versátil para que em futuros desenvolvimentos se possa utilizar qualquer protocolo de comunicação

99 8. Referências [1] American Cancer Society, [2] Greenlee RT, Hill-Harmon MB, Murray T, et al. Cancer Statistics, CA cancer J Clin. 2001; 51:1526. [3] Thomson CJ, et al., Positron Emission Mammography (PEM): a promising technique for detecting breast cancer. IEEE Trans Nucl Sci, : p [4] Noh D et al., Diagnostic value of positron emission tomography for detecting breast cancer. World J Surg. 1998; 22: [5] Bender H. E col. Breast imaging with positron emission tomography. In: Taillefer R, Khalkhali I, Waxman AD e col. Eds. Radionuclide imaging of the breast. New York: Marcel Dekker: , [6] Weinberg I., et al., Preliminary results for positron emission mammography: real-time functional breast imaging in a conventional mammography gantry. Eur J Nucl Med, (7): p [7] Varela, J. Clear-PEM, a dedicated PET camera for Mammography, in Workshop on Positron Emission Mammography, Lisbon, July, [8] A. Trindade et al., Clear-PEM: Monte Carlo Performance and Image Reconstruction Studies, poster at IEEE-Medical Imaging Conference, Portland, October [9] L. Peralta et al., Clear-PEM: A dedicated PET camera for improved breast cancer detection, ICRS10-RPS2004, Madeira, Maio 2004 [10] N. Matela et al, System matrix for Clear-PEM using ART and linograms, MIC/IEEE 2004, Rome, Italy (Proceedings to be published), [11] M. Martins et al., Clear-PEM Data Reconstruction Using STIR, Annual Congress of the European Association in Nuclear Medicine, Istanbul, October [12] H. Cordeiro et al, Avaliação de um Algoritmo Exacto de Rearranjo de Dados para Clear-PEM, X Congresso Nacional de Medicina Nuclear, Novembro 2005, Lisboa, Portugal. [13] N. Oliveira et al., Visualização e Análise de Imagens para Clear PEM, X Congresso Nacional de Medicina Nuclear, Novembro 2005, Lisboa, Portugal. [14] Weinberg I., et al., Preliminary results for positron emission mammography: real-time functional breast imaging in a conventional mammography gantry. Eur J Nucl Med, (7): p [15] Raylman RR, et al., The potential role of positron emission mammography for detection of breast cancer. A phantom study. Med Phys, (8): p [16] P.M. Lousã, A.I. Santos et al., Diagnóstico do Cancro da Mama Vantagens de um Novo Sistema Dedicado, II Fórum Ibérico de Telemedicina, Viseu, Outubro de [17] A. I. Santos et al., Design and evaluation of the Clear-PEM detector for positron emission mammography, MIC/IEEE 2004, Rome, Italy [18] S. Agostinelli et al., 1995, GEANT4 A simulation toolkit, Nucl. Instrum. Meth. A. vol A 506, 2003, pp

100 [19] Bender H. E col. Breast imaging with positron emission tomography. In: Taillefer R, Khalkhali I, Waxman AD e col. Eds. Radionuclide imaging of the breast. New York: Marcel Dekker, 1998, pp [20] P. Rodrigues et al., Geant4 applications and developments for medical physics experiments, IEEE Trans. Nucl. Sci. vol 51, 2004, pp [21] S. Agostinelli et al., 1995, GEANT4 A simulation toolkit, Nucl. Instrum. Meth. A. vol A 506, 2003, pp [22] P. Lecoq and J. Varela, 2002 Clear-PEM, A dedicated PET camera for mammography, Nucl. Instrum. Meth. vol. A 486, 2002, pp [23] R. Moura, C. Ortigão et al., Experimental characterization of the ClearPEM Detector Module, European Physical Society, 19th Nuclear Physics Divisional Conference, New Trends in Nuclear Physics Applications and Technology, Pavia (Italy) September 5-9, [24] B. Carriço et al., Quality control for Clear-PEM detector modules, Institute of Physics and Engineering in Medicine, Annual Scientific Meeting, Glasgow, UK, September [25] E. Albuquerque, P. Bento, F. Goncalves, C. Leong, P. Lousã, J. Nobre, J. C. Silva, L. Silva, M. M. Silva, J. Rego, P. Relvas, P. Rodrigues, I. C. Teixeira, J. P. Teixeira, A. Trindade, J. Varela, Performance Simulation Studies of the Clear-PEM DAQ/Trigger System, Proc. of the 14th. IEEE NPSS Real Time Conference, Stockholm, Sweden, June, [26] C. Leong, P. Machado, V. Bexiga, et al. Memory Management and Synchronism Issues in a Complex System Implemented in FPGA Technology, Proc. of the 23rd. Conf. On Design of Circuits and Integrated Systems (DCIS), (full paper in CD-ROM format, ISBN-), November, [27] V. Bexiga,, P. Machado,, et. al. Experimental Validation and Performance Analysis of the Clear-PEM Data Acquisition Electronics, Proc. Nuclear Science Symposium / Medical Imaging Conf. (NSS/MIC), Dresden, October, [28] E. Albuquerque,, V. Bexiga,, P. Machado, et. al. An Oveview of the Clear-PEM Breast Imaging Scanner, Proc. 4th. Int. Workshop on the Molecular Radiology of Breast Cancer (MRBC), fringe to the Nuclear Science Symposium / Medical Imaging Conf. (NSS/MIC), Dresden, October, [29] Pedro Machado, Vasco Bexiga, Carlos Leong, Pedro Bento, J. Paulo Teixeira, Pedro Lousã, Joel Rego, Pedro Rodrigues, Andreia Trindade, José C. Silva, João Varela, Isabel C. Teixeira, "Using a Commercial Core to Customise the PCI Protocol to a Specific Environment", Reconfigurable System Conference, February [30] C. Leong, P. Machado, V. Bexiga, et al., FPGA Based Implementation, Test and Validation of a Very Complex Hw/Sw System for Medical Imaging, Reconfigurable System Conference, February [31] Edgar Albuquerque, Pedro Bento, Carlos Leong, Fernando Gonçalves, João Nobre, Joel Rego, Paulo Relvas, Pedro Lousã, Pedro Rodrigues, Isabel C. Teixeira, João P. Teixeira, Luís Silva, M. Medeiros Silva, Andreia Trindade and João Varela, The Clear-PEM Electronics System, IEEE Transactions on Nuclear Science, vol. 53, nº. 5, pp ,

101 [32] A. Trindade et al., Design and Evaluation of the Clear-PEM Detector for Positron Emission Mammography, IEEE-Medical Imaging Conference, Rome, Oct [33] C. Leong, Sistema Electrónico de Qualificação e Filtragem de Dados para Detecção de Cancro da Mama em Tecnologia PET (Electronic System for Qualification and Filtering Data for the Detection of Breast Cancer using PET Technology), MSc degree in Electrical and Computer Engineering from IST-UTL, [34] P. Bento, Sistema Electrónico Para Organização e Encaminhamento de Dados de um Sistema de Detecção de Cancro da Mama em Tecnologia PET (Electronic System to Data Routing and Organization for Breast Cancer System Detection using PET Technology), MSc degree in Electrical and Computer Engineering from IST-UTL, [35] Pedro Rodrigues et al., Performance Simulation Studies of the Clear-PEM DAQ/Trigger System, 14th IEEE-NPSS Real Time Conference 2005, Stockholm, June 4-10, [36] Andreia Trindade et al., Breast Cancer Imaging Studies by Monte Carlo Simulation with Clear PEM, IEEE-Medical Imaging Conference, Puerto Rico, USA, October [37] Electronic Industries Alliance, [38] Institute of Electrical and Electronics Engineers, Inc., [39] USB Implementers Forum, Inc, [40] PCI-SIG, [41] StarFabric PCI Interface Card, Carlo Gavazzi Computing Solutions, [42] StarFabric PCI Mezzanine Card, Carlo Gavazzi Computing Solutions, [43] Carlo Gavazzi Computing Solutions, [44] The StarFabric Trade Association,, [45] Stargen, Inc., [46] Telecommunications Industry Association, [47] PCI Local Bus Specification, Revision 2.2. s.l. : PCI Special Interest Group, December 18, [48] Xilinx, Inc., [49] QuickLogic Corporation, [50] QL5064 QuickPCI Data Sheet, Quicklogic Corporation, [51] QuickPCI QL5064 User's Manual, Rev. E, Quicklogic Corporation, August [52] QuickWorks with SpDE Reference, [53] QuickWorks User Manual with SpDE Reference, QuickLogic Corporation, 2005 [54] Active-HDL Expert Edition, [55] Aldec, Inc., [56] P. Machado, High Performance Communication for the PET Mammography System, based on the PCI and S-LINK Protocols, documento provisório para obtenção do Grau de Mestre, Instituto Superior Técnico,

102 [57] PCI-to-PCI Bridge Architecture Specification. Revision 1.1. s.l. : PCI Special Interest Group, December 18, [58] CERN S-LINK, [59] FX2LP Datasheet (Cypress: [60] FX2LP Technical Reference Manual (Cypress: [61] J. Rego, Methodology and Environment for Validation High Complexity Hardware/Software Systems, Documento provisório para obtenção do Grau de Mestre, Instituto Superior Técnico, [62] Xilinx, [Online] [63] Mentor Graphics, [Online] [64] F. Piedade, DAE Link Specification Document, 2007 [65] F. Piedade, DAE Link Design Document,

103 Anexo 1 Ferramenta de Desenvolvimento - QuickWorks Descrição da Ferramenta Para desenvolver as aplicações para o QL5064, a Quicklogic fornece um pacote de ferramentas de desenvolvimento, proprietário. O pacote em questão é o QuickWorks v [52] [53]. Esse pacote fornece uma solução completa, que permite ao projectista executar todos os passos necessários ao desenvolvimento dos seus projectos, desde o desenho, passando pela síntese lógica, place and route, até à simulação, essa ultima usando o Active-HDL da Aldec, Inc, que está descrito em pormenor na secção seguinte. No QuickWorks é possível descrever as arquitecturas em VHDL, Verilog, em esquemático ou numa mistura de VHDL/Verilog e esquemático. A programação dos dispositivos utiliza um programador específico, que pode ser adquirido juntamente com os dispositivos. No entanto, e tendo em conta que se pretendia desenvolver uma aplicação para um protótipo, esse programador não foi adquirido, pelo que a programação do dispositivo QL5064 foi realizada pela própria QuickLogic. Na figura A2.1 ilustra-se a interface inicial que dá acesso as diversas ferramentas fornecidas no pacote. Figura A1 - Interface do QuickWorks Simulador Active-HDL Para a simulação da arquitectura, é fornecido no pacote de ferramentas QuickWorks, uma ferramenta de terceiros, a Active-HDL Expert Edition v.6.3 [54] da empresa Aldec, Inc. [55]. Esse - A -

104 software permite o desenho e verificação de arquitecturas implementadas em FPGA através do uso das bibliotecas fornecidas pelos diversos fabricantes, incluído a QuickLogic, Inc.. Na figura A2.2 pode-se observar-se a interface através de exemplos de alguns sinais simulados. Figura A2 Interface do Active-HDL - B -