Sistema de Comunicação para o Sistema PET Mamografia ... · O sistema que constitui o principal...

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

2

I

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.

III

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.

V

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.

VII

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.

IX

Índice

NOTA ........................................................................................................................................................ I

Agradecimentos ...................................................................................................................................... III

Resumo ................................................................................................................................................... V

Abstract.................................................................................................................................................. VII

Índice ...................................................................................................................................................... IX

Lista de Figuras ..................................................................................................................................... xiii

Lista de Tabelas ..................................................................................................................................... xv

Lista de Acrónimos ................................................................................................................................ 17

1. Introdução ............................................................................................................................................ 1

1.1. Contexto e Motivação ................................................................................................................... 1

1.2. Enquadramento do Sistema de Comunicação ............................................................................. 2

1.3. Objectivos do Trabalho ................................................................................................................. 3

1.4. Contribuições Relevantes ............................................................................................................. 4

1.5. Organização da Dissertação ........................................................................................................ 5

2. Sistema PEM ....................................................................................................................................... 7

2.1. Princípio de Funcionamento do Sistema PEM ............................................................................. 7

2.2. Arquitectura do Sistema PEM ....................................................................................................... 9

2.3. Organização dos Planos de Cristais ........................................................................................... 10

2.4. Electrónica de Front-End ............................................................................................................ 11

2.4.1 Caracterização dos Sinais .................................................................................................... 11

2.4.2 Tipos de Eventos................................................................................................................... 13

3. Electrónica de Aquisição de Dados ................................................................................................... 15

3.1. Requisitos do sistema DAE ........................................................................................................ 15

3.2. Cenários de Funcionamento do DAE ......................................................................................... 15

3.3. Arquitectura do sistema DAE ...................................................................................................... 16

3.4. Subsistema de Qualificação e Filtragem de Dados .................................................................... 17

3.4.1 Módulo de Aquisição de Dados ............................................................................................ 18

3.4.2 Módulo de Filtragem ............................................................................................................. 19

3.4.3 Módulo Trigger ...................................................................................................................... 19

3.5. Subsistema de Organização e Encaminhamentos de Dados .................................................... 19

X

3.5.1 Unidade de Memória ............................................................................................................. 20

3.5.2 Concentrator de Dados ......................................................................................................... 20

4. Interface de Comunicação DAE PC ............................................................................................. 21

4.1. Requisitos da Interface de Comunicação ................................................................................... 22

4.1.1 Requisitos de Desempenho .................................................................................................. 22

4.1.2 Requisitos Funcionais ........................................................................................................... 22

4.1.2.1 Formato dos Comandos .................................................................................... 23

4.1.2.2 Dados de Calibração do Sistema ...................................................................... 25

4.1.2.3 Dados Relevantes (amostras associadas a fotoeventos) ................................. 25

4.2. Protocolos de Comunicação ....................................................................................................... 26

5. Solução PCI ....................................................................................................................................... 29

5.1. Ponte PCI-to-PCI ........................................................................................................................ 30

5.2. Dispositivo QL5064 ..................................................................................................................... 31

5.2.1 Arquitectura do Dispositivo QL5064 ..................................................................................... 32

5.3. Arquitectura da Interface PCI / TGR ........................................................................................... 33

5.4. Arquitectura da FPGA do QL5064 .............................................................................................. 36

5.4.1 Controlador Blast Mode ........................................................................................................ 37

5.4.2 FIFO Blast Mode ................................................................................................................... 39

5.4.3 Controlador das FIFOs .......................................................................................................... 41

5.4.4 Protocolo de Comunicação ................................................................................................... 42

5.4.5 Registos de Configuração ..................................................................................................... 43

5.5. Simulação da Interface de Comunicação ................................................................................... 45

5.5.1 Ambiente de Simulação ........................................................................................................ 45

5.5.2 Validação Funcional e de Desempenho ............................................................................... 46

5.5.3 Resultados de Simulação ..................................................................................................... 46

5.6. Implementação Física e Teste .................................................................................................... 47

5.6.1 Testes de Laboratório ........................................................................................................... 47

5.6.2 Emulação de um Barramento PCI Secundário ..................................................................... 49

5.6.2.1 Árbitro ................................................................................................................ 50

5.6.2.2 Gestão RST/REQ64 .......................................................................................... 50

5.6.3 Modelo (firmware) da TGR/DCC ........................................................................................... 52

XI

5.6.3.1 Módulo de Entrada ............................................................................................ 53

5.6.3.2 FIFO de Resposta a Comandos ........................................................................ 54

5.6.3.3 Módulo de simulação de exame ........................................................................ 54

5.6.3.4 FIFO de simulação de exame............................................................................ 55

5.6.3.5 Módulo de Saída ................................................................................................ 56

5.7. Resultados da Solução PCI ........................................................................................................ 58

5.8. Solução USB/S-LINK .................................................................................................................. 59

6. Interface USB .................................................................................................................................... 61

6.1. Cenários de Comunicação USB ................................................................................................. 61

6.2. Arquitectura do Módulo de Comunicação................................................................................... 61

6.3. Microcontrolador Cypress FX2LP ............................................................................................... 62

6.4. Comunicação FX2LP-TGR/DCC ................................................................................................ 64

6.4.1 Operação de Leitura ............................................................................................................. 65

6.4.1 Operação de Escrita ............................................................................................................. 66

6.5. Módulo de Comunicação ............................................................................................................ 67

6.6. Módulo de Comunicação via USB .............................................................................................. 68

6.6.1 Memórias FIFOs do Módulo de Comunicação via USB ....................................................... 69

6.6.2 Controlador do Módulo de Comunicação via USB ............................................................... 70

6.7. Alterações ao DCC ROC ............................................................................................................ 72

6.8. Implementação Física do Módulo de Comunicação ................................................................... 72

6.9. Simulação e Teste ...................................................................................................................... 72

6.9.1 Simulação do Modulo de Comunicação via USB ................................................................. 72

6.9.2 Teste Laboratorial do Módulo de Comunicação via USB ..................................................... 73

6.9.3 Simulação do Sistema DAE com o Módulo de Comunicação via USB ................................ 73

6.9.4 Teste Laboratorial do Sistema DAE com o Módulo de Comunicação via USB .................... 74

Resultados do Teste Laboratorial ...................................................................................................... 75

7. Conclusões e Trabalho Futuro .......................................................................................................... 77

8. Referências ....................................................................................................................................... 79

XIII

Lista de Figuras

Figura 1-1 - Mamografia obtida: com Raios-X (a) e com PET (b) .............................................. 1

Figura 1-2 - 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 2-4 - Arquitectura do sistema PEM ................................................................................. 9

Figura 2-5 – Módulo de 32 cristais ........................................................................................... 10

Figura 2-6 – Cristal associado a dois APD’s ............................................................................ 10

Figura 2-7 – Matriz de 32 células fotossensíveis ..................................................................... 10

Figura 2-8 – Formato do sinal produzido pelo ASIC ................................................................ 11

Figura 2-9 – Efeito de Compton ............................................................................................... 12

Figura 3-1 – Arquitectura de alto-nível do sistema DAE .......................................................... 16

Figura 3-2 – Subsistemas e blocos constituintes do sistema DAE .......................................... 17

Figura 3-3 – Exemplo de um sinal de entrada e uso do parâmetro Delta ................................ 19

Figura 4-1 – Arquitectura detalhada do Sistema DAE ............................................................. 21

Figura 4-2 – Arquitectura da Interface entre DCC e PC ........................................................... 21

Figura 5-1 – Arquitectura da solução PCI implementada na TGR/DCC .................................. 29

Figura 5-2 – Arquitectura da solução PCI ................................................................................ 30

Figura 5-3 – Placa PCI-SB (a) Placa PMC-SB (b) ................................................................... 30

Figura 5-4 – Diagrama de blocos do QL5064 .......................................................................... 32

Figura 5-5 – Sinais das interfaces entre o core PCI e a FPGA e PCI ...................................... 34

Figura 5-6 – Sinais das interfaces entre a FPGA do QL5064 e o módulo TGR/DCC ............. 35

Figura 5-7 – Arquitectura da FPGA do QL5064 ....................................................................... 36

Figura 5-8 – Controlador Blast Mode ....................................................................................... 37

Figura 5-9 – Máquina de estados do controlador Blast Mode .................................................. 39

Figura 5-10 – FIFO Blast mode ................................................................................................ 40

Figura 5-11 – Controlador das FIFOs. ...................................................................................... 41

Figura 5-12 – Protocolo de comunicação TGR/DCC – QL5064 .............................................. 42

Figura 5-13 – Ambiente de simulação ...................................................................................... 45

Figura 5-14 – Placa TGR com o QL5064 (a) e com a PMC-SB (b). ........................................ 47

Figura 5-15 – Bancada de teste ............................................................................................... 47

Figura 5-16 – Medição dos sinais da FIFO Single Mode ......................................................... 48

Figura 5-17 – Medição dos sinais da FIFO Blast Mode ........................................................... 48

Figura 5-18 - Diagrama temporal do uso dos sinais RST# e REQ64# na inicialização. .......... 51

Figura 5-19 – Esquema do módulo REQ64# ........................................................................... 51

Figura 5-20 – Arquitectura do emulador da TGR/DCC. ........................................................... 52

Figura 5-21 – Módulo de entrada ............................................................................................. 53

Figura 5-22 – FIFO de resposta a comandos .......................................................................... 54

XIV

Figura 5-23 – Módulo de simulação de exame ........................................................................ 55

Figura 5-24 – FIFO de simulação de exame ............................................................................ 56

Figura 5-25 – Módulo de saída. ................................................................................................ 57

Figura 5-26 – Detecção do sistema pelo Sistema Operativo ................................................... 58

Figura 5-27 – Diagrama de blocos da solução USB & S-LINK ................................................ 60

Figura 6-1 – Arquitectura TGR/DCC com o módulo de comunicação ..................................... 62

Figura 6-2 – Diagrama de blocos do microcontrolador Cypress FX2LP .................................. 63

Figura 6-3 – Diagrama de blocos da interface de comunicação com o Cypress FX2LP. ........ 63

Figura 6-4 - Interface das FIFOs do FX2LP ............................................................................. 64

Figura 6-5 – Interface de leitura entre a FPGA TGR/DCC e o FX2LP ..................................... 65

Figura 6-6 – Diagrama temporal da operação de leitura na FIFO do FX2LP .......................... 65

Figura 6-7 - Interface de escrita entre a FPGA TGR/DCC e o FX2LP ..................................... 66

Figura 6-8 - Diagrama temporal da operação de escrita na FIFO do FX2LP .......................... 67

Figura 6-9 – Diagrama de blocos do módulo de comunicação na FPGA TGR/DCC. ............. 67

Figura 6-10 – Interface do módulo USB ................................................................................... 69

Figura 6-11 – Memórias FIFO – (a) dados para o PC; (b) dados do PC ................................. 69

Figura 6-12 – Sinais usados no controlador USB .................................................................... 70

Figura 7-1 - Solução Óptica para a comunicação entre o DAE e o PC ................................... 78

XV

Lista de Tabelas

Tabela 4-1 – Protocolos de comunicação mais usuais em PCs comerciais ............................ 27

Tabela 5-1 – Configuração dos DIP Switch das placas Starfabric ........................................... 31

Tabela 5-2 – Modos de funcionamento dos blocos de memória RAM .................................... 33

Tabela 5-3 - Descrição dos sinais do controlador Blast mode ................................................. 38

Tabela 5-4 – Descrição dos sinais da FIFO Blast Mode .......................................................... 40

Tabela 5-5 – Descrição dos sinais do controlador das FIFOs. ................................................ 42

Tabela 5-6 – Registos de configuração do QL5064. ................................................................ 45

Tabela 5-7 – Medições dos sinais das FIFOs .......................................................................... 49

Tabela 5-8 – Requisitos de tempo dos sinais RST# e REQ64# .............................................. 51

Tabela 5-9 – Sinais do módulo de entrada da TGR/DCC ........................................................ 53

Tabela 5-10 – Sinais da FIFO de resposta a comandos .......................................................... 54

Tabela 5-11 – Sinais do módulo de exame .............................................................................. 55

Tabela 5-12 – Sinais da FIFO de simulação de exame. .......................................................... 56

Tabela 5-13 – Sinais do módulo de saída da TGR/DCC ......................................................... 57

Tabela 6-1 – Parâmetros da operação de leitura da FIFO do FX2LP ..................................... 66

Tabela 6-2 - Parâmetros da operação de escrita da FIFO do FX2LP ..................................... 67

Tabela 6-3 – Sinais da interface do DCC ROC com o módulo USB. ....................................... 68

Tabela 6-4 – Sinais usados pelas FIFOs do módulo USB ....................................................... 70

Tabela 6-5 – Descrição dos sinais usados pelo ‘controlador USB’. ......................................... 71

XVII

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

- 1 -

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 1-1 - Mamografia obtida: com Raios-X (a) e com PET (b)

- 2 -

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 mama1. Para este efeito, foi criado o consórcio

PEM2 [8], com o objectivo de desenvolver o sistema PEM (Positron Emission Mammography) [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.

1.2. 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.

- 3 -

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 1-2 - 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.

1.3. 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:

- 4 -

• 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.

1.4. 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.

- 5 -

• Estudo da viabilidade da implementação de um sistema de comunicação baseado no

protocolo PCI. Este estudo envolveu:

o Procura de soluções tecnológicas para a implementação do protocolo PCI;

o Estudo do dispositivo QL5064;

o Desenvolvimento (desenho e simulação) do sistema de comunicação PC DAE;

o 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 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;

o Desenvolvimento do ambiente de simulação e teste laboratorial deste sistema como

elemento genérico;

o Inserção do sistema de comunicação no sistema DAE;

o Desenvolvimento do ambiente de simulação deste sistema com dados reais.

1.5. 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 sub-

sistema 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.

- 7 -

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ído3 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) (18F-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.

- 8 -

solução. A emissão de fotões pelas células cancerígenas é pois consideravelmente superior à

originada em células normais.

Quando a 18F-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

- 9 -

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.

2.2. 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 2-4 - 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.

- 10 -

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).

LYSOAPD APD

Sinaleléctrico

Sinalelé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

- 11 -

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.

2.4. 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.

2.4.1 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

- 12 -

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.

- 13 -

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.

- 14 -

- 15 -

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.

3.1. 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.

3.2. 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

- 16 -

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 12288 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.

3.3. 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].

Plano de CristaisA

Face A

Face B

Plano de CristaisB

Face C

Face D

ElectrónicaFront 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].

- 17 -

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).

- 18 -

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.

3.4.1 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.

- 19 -

Figura 3-3 – Exemplo de um sinal de entrada e uso do parâmetro Delta

3.4.2 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.

3.4.3 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.

3.5. 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).

- 20 -

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.

3.5.2 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.

- 21 -

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.

LVDS FE

B U F F E R S

LVDS FE

G B U S

D B U S

DAQ Board

TGR/ DCC ROC

B U F F E R S

TGR

DCC

DCC ROC

PCI Controller

TGR/DCC FPGA

PCI FPGA

PCI BUS PC

TGR/ DCC

Board

DAQ DAQ ROC

Filter

DAQ FPGA

Test Module

DAQ DAQ ROC

Filter

DAQ FPGA

Test Module

Test Module

DB Arb.

C O N

C O N

C O N

LVDS FE

B U F F E R S

LVDS FE

G B U S

D B U S

Placa DAQ

TGR/ DCC ROC

B U F F E R S

TGR

DCC

DCC ROC

PCI Controller

TGR/DCC FPGA

PCI FPGA

PCI BUS PC

Placa TGR/

DCC

DAQ DAQ ROC

Filtro

DAQ FPGA

DAQ DAQ ROC

Filter

DAQ FPGA

Módulo de Teste

Módulo de Teste

DB Arb.

C O N

C O N

C O N

Interface De

Comunicação Módulo de Teste

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

- 22 -

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.

4.1. Requisitos da Interface de Comunicação

4.1.1 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.

4.1.2 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.

- 23 -

4.1.2.1 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:

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:

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:

Formato do pacote (resposta ao pedido de erros) DAE-> PC (CNT=001)

CNT=110 X X X S.M. S.M. S.M.63 61 60 3 2 1 0

CNT=11110 X X X OnOff OnOff OnOff63 59 58 3 2 1 0

CNT=1110 X X X63 60 59 0

CNT=001 XXX Err CTE Err Flag Err GBUS Err Sat Err FE Par.63 61 60 59 58 57 56 45 44 33 32 1 0

- 24 -

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:

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=111110 X X X63 58 57 0

CNT=0001 X X X TBUS_Error DBUS GBUS TD DAQ63 60 59 36 35 34 25 24 9 8 7 0

- 25 -

4.1.2.2 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.

• 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.

4.1.2.3 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.

CNT=0 X Crystal ID KA Sup KB Sup K Sup KA Inf KB Inf K Inf Par63 62 61 49 48 41 40 33 32 25 24 17 16 9 8 1 0

CNT=10 X X X FETh CmpTh CmpWin AcpWin RejWin DelayLng Par63 62 61 48 47 40 39 32 31 24 23 16 15 8 7 1 0

- 26 -

Formato dos pacotes:

• Inicio da trama (CNT= 01)

• Inicio de um conjunto de 4 pacotes (se pertencer ao primeiro hit) (CNT= 10)

• Inicio de um conjunto de 4 pacotes (se pertencer aos restantes hits) (CNT= 10)

• Pacotes seguintes (CNT= 10)

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.

4.2. 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.

CNT=01 EventNumber EventTime1/263 62 61 30 29 0

CNT=10 EventTime 2/2 00 # Hit Tgr Type ∆ Comp TimeTag ∆ Orig ID Sample 1/463 62 61 60 59 58 57 54 53 52 51 44 43 35 34 27 26 14 13 0

CNT=10 X X 00 # Hit Tgr Type ∆ Comp TimeTag ∆ Orig ID Sample 1/463 62 61 60 59 58 57 54 53 52 51 44 43 35 34 27 26 14 13 0

CNT=10 Sample 2/463 62 61 0

CNT=10 Sample 3/463 62 61 0

CNT Sample 4/463 62 61 0

- 27 -

Número de bits Freq. de trabalho Taxa de transferência máxima Interface

RS-232 1 -- 115,2 Kb/s Serie

Paralelo 8 2 MHz 2,5 MB/s Paralelo

USB v2.0 1 48 MHz 60 MB/s Serie

Firewire 1 -- 100 MB/s Serie

PCI v2.2 32/64 33,33 e 66,66 MHz 533 MB/s Paralelo

PCI-X 1.0 64 100 e 133 MHz 1024 MB/s Paralelo

PCI-X 2.0 64 266 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)

Serie

Tabela 4-1 – Protocolos de comunicação mais usuais em PCs comerciais

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 6.

- 28 -

- 29 -

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.

TGR/DCC ROC

BUFFERS

TGR

DCC

DCC ROC

QL5064

FPGA TGR/DCC

PlacaTGR/DCC

PC

Figura 5-1 – Arquitectura da solução PCI implementada na TGR/DCC

- 30 -

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)

- 31 -

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 Modo Teste4 -- --

4

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 significativa5

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

, pelo que os responsáveis pelo projecto decidiram pela aquisição do

QL5064.

4 Para uso interno do pessoal da Aurora Technologies. 5 O preço do core PCI da XIlinx rondava os €10.000,00, enquanto que o preço da aquisição de cada QL5064 era de aproximadamente €100,00

- 32 -

QuickWorks v.9.7.1 [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 1.

5.2.1 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

- 33 -

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 back-

end 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 12.672 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.

5.3. 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.

- 34 -

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

- 35 -

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).

FP

GA

QL5

064

FiFO_Full

FIFO_AlmostFull

Write

Data_In[63:0]

Data_Out[63:0]

data_out_valid

tgr_fifo_full

FPG

A T

GR

/DC

C

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 5.4.5.

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.

- 36 -

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 4.

5.4. 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.

ControladorSingle Mode

Core PCIFPGA

TGR/DCCDados de StatusFIFO

Pedidos

Watch Dog

ControladorBlast Mode

FIFO

Watch Dog

Dados de Exame

Módulode 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

- 37 -

conjunto de sinais de informação do estado e controle das FIFOS. A descrição detalhada desses

sinais pode ser encontrada na 5.4.4.

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.

5.4.1 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

- 38 -

é 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.

xmt1_fifo_full I

Estado da FIFO do core que recebe os dados provenientes de um exame.

0 – tem espaço.

1 – está cheia.

cntl_addr[7:3] O

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.

cntl_wrt_nrd O

Ciclo de escrita ou leitura.

0 – Escrita

1 – Leitura

mux_sel O

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 5-3 - 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

- 39 -

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.

Flag_configuration

Data_wait

Clock_wait

Chegada de dados e FIFO do core com espaço

Configuração da flagalmost-full do core PCI

Reset ao WatchdogEnvio de dados para o core PCI

Estado de espera

Espera chegada de dados

Sem dados ou FIFOdo core PCI cheia

Inicio

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.

5.4.2 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 5-4.

- 40 -

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.



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

- 41 -

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.

5.4.3 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.

- 42 -



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.

5.4.4 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 – QL5064

- 43 -

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 𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏 𝑥𝑥 100 𝑀𝑀𝑀𝑀𝑀𝑀

2= 3200 𝑀𝑀𝑏𝑏𝑏𝑏𝑏𝑏/𝑏𝑏 = 400 𝑀𝑀𝑀𝑀𝑀𝑀𝑏𝑏𝑀𝑀/𝑏𝑏

5.4.5 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] 1111111111111111 Identificação do dispositivo

AF_VENDOR_ID [15:0] 0001000111100011 Identificação do vendedor (foi usado o ID da QuickLogic, Inc)

AF_STATUS_IN [7:0] 10100000 Registos de estado (ver Anexo 2).

AF_COMMAND_IN [15:0] 0000000101000111 Registos de commando (ver Anexo 1).

Tabela 5-6 - Registos de configuração do QL5064 (continua)

- 44 -


AF_CLASS_CODE [23:0] 000100011000000000000000

Classe do dispositivo. Apresente configuração pertence à classe “Other data acquisition/signal processing controllers” (consultar regras em [47])

AF_REVISION_ID [7:0] 00000001 Identificação da revisão

AF_HEADER_TYPE [7:0] 00000000 Como o QL5064 funciona em modo “Target” deve estar tudo a zeros

AF_BASE0_IN [31:0] 11111111111111111111000000000000

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_BASE1_IN [31:0] 11111111111111110000000000000000

AF_BASE2_IN [31:0] 11111111000000000000000000000000

AF_BASE3_IN [31:0] 00000000000000000000000000000000

AF_BASE4_IN [31:0] 00000000000000000000000000000000

AF_BASE5_IN [31:0] 00000000000000000000000000000000

AF_CIS_PNTR [31:0] 00000000000000000000000000000000 Apontador para “Cardbus CIS” (N/A)

AF_SUBSYSTEM_ID [15:0] 0000000000000001 Identificação do subsistema

AF_SUBSYSTEM_VID [15:0] 0000000000000001 Identificação do subsistema do vendedor

AF_ROMBADDR_IN [31:11] 000000000000000000000 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] 00000000000000000000000000000000 Funções de capacidade estendidas (N/A)

AF_CFIG_RESERVED1_IN [31:0] 00000000000000000000000000000000 Reservado

AF_MAX_LAT [7:0] 00000000 Frequência com que o dispositivo acede ao barramento (N/A)

AF_MIN_GNT [7:0] 00010001 Período mínimo de uma transmissão em rajada, em incrementos de 250ns (valor aconselhado).

AF_INT_PIN [7:0] 00000000 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] 000111 Selecciona os BARs usados.

AF_USER_REV_ID [7:0] 00000001 Identificação da revisão do utilizador

AF_TARGET_ENA_MASTER_FIFO 1

Atribui a Transmit FIFO 1 e a Received_FIFO_1 ao modo Target Blast Mode

AF_WAIT_TIMEOUT_WRITE 1 Espera por um período de 16/8 ciclos até que aja espaço na FIFO

AF_WAIT_TIMEOUT_READ 1 Espera por um período de 16/8 ciclos até que aja dados na FIFO

AF_ENABLE_16_8_TIMEOUT 1

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

AF_MASTER_ALWAYS_ENABLE 0 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_TIMEOUT [1:0] 00 Configura o tempo de repetição de uma

leitura falhada em 215 ciclos de relógios

Tabela 5-6 - Registos de configuração do QL5064 (continua)

- 45 -


AF_PCI_FORCE_64_BIT 0 O dispositivo comuta automaticamente entre 32 e 64 bits de comunicação

AF_32PCIBUS_HOLDUPPER 1 Activa ou desactiva os AD[63:32] e C/BE[7:4]# quando inseridos numa slot de 32 bits

AF_PASS_HIGH_CONFIG 0 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 QL5064.

5.5. 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.

5.5.1 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.

Dispositivo“Master”

ÁrbitroQL5064(“Target”)TGR/DCC

Módulode

teste

Barramento PCI

Figura 5-13 – Ambiente de simulação

- 46 -

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 5.4.4 e o formato dos dados

descrito na secção 4.1.2.

5.5.2 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 4.1.2.

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.

5.5.3 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.

- 47 -

5.6. Implementação Física e Teste Após a programação do QL50646 Figura 5-14, este foi montado na placa TGR/DCC. Na

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).

5.6.1 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 teste7

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.

- 48 -

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

teste8

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

. 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,

Figura 5-16. 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 5-17.

Figura 5-17 – Medição dos sinais da FIFO Blast Mode

8 A placa de teste foi desenvolvida pelo INOV, a nosso pedido.

- 49 -

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 2440 2460

Core FIFO Full 2680 2560

FIFO Almost Full 4080 3980

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.

5.6.2 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.

- 50 -

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.

5.6.2.1 Á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.

5.6.2.2 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 5-18.

- 51 -

Figura 5-18 - 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

TRST 1 -- ms Tempo de reset activo depois de a alimentação estabilizar

TRST-CLK 100 -- µs Tempo de reset activo depois do sinal de relógio estabilizar

TRRH 0 50 ns Tempo de espera desde a activação de RST# até ao REQ64#

TRRSU 10xTciclo -- ns Tempo de permanência do REQ64# até à desactivação do RST#

TRST-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 TRRH e TRRSU. 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:

- 52 -

• TRRH = 0 ns;

• TRRSU = 20 ciclos de relógio (de 50MHz).

5.6.3 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.

Módulo de Saída

FIFO de Resposta

Módulo de Entrada

FIFO de Exame Módulo de Exame

FPGA TGR/DCC

QL5064

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.

- 53 -

5.6.3.1 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.


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”01234567” ou ”0123456789ABCDEF”

Tabela 5-9 – Sinais do módulo de entrada da TGR/DCC

- 54 -

5.6.3.2 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 5-10.


Din(63:0) I Dados de entrada.

Wr_en I Activa a escrita na FIFO.

Rd_en I Activa a leitura na FIFO.



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

5.6.3.3 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.

- 55 -

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

5-11.


FIFO_Full I Indicação do estado da FIFO de saída.

Exame_ON_OFF I Activa/Desactiva envio de dados.



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

5.6.3.4 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 QL5064.

- 56 -

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 5-12.


Din(63:0) I Dados de entrada.

Wr_en I Activa a escrita na FIFO.

Rd_en I Activa a leitura na FIFO.



Dout(63:0) O Dados de saída.



prog_full O Flag que indica que há pelo menos um evento armazenado.

Tabela 5-12 – Sinais da FIFO de simulação de exame.

5.6.3.5 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.

- 57 -

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.




QL_fifo_full I Flag que indica que a FIFO de respostas do QL5064 está cheia.

QL_fifo_almost_full I 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 I Indica que existe pelo menos um evento na FIFO de exame.

Ql_write O 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

- 58 -

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

- 59 -

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.

5.8. 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 decidiu-

se 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 PC9

[59]

, e é amplamente usado nos PCs comerciais actuais. Adicionalmente, na placa

TGR/DCC já existia um microcontrolador, o Cypress FX2LP [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.

- 60 -

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

5-27.

FPGATGR/DCC

MicrocontroladorUSB

Placa S-LINK(mezannine)

16

64

Placa TGR/DCC

Protocolo S-LINK

Protocolo proprietário

PCControlador

USB

Placa S-LINK(PCI)

Protocolo USB

Protocolo proprietário

Figura 5-27 – Diagrama de blocos da solução USB & S-LINK

- 61 -

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.

6.1. Cenários de Comunicação USB A interface USB é responsável pelo envio de dados nos seguintes cenários:


• 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.



o Envio do resultado do BIST.

6.2. 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.

- 62 -

TGR/DCC ROC

TGR

DCC

DCC ROC

FPGA TGR/DCC

PlacaTGR/DCC

Microcontrolador USB

PC

Placa S-LINK

Módulo de Comunicação

Buffe

rs

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.

6.3. 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.

- 63 -

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 8051. 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.

- 64 -

Na Figura 6-4 representam-se os sinais usados na interface das FIFOs do FX2LP.

Figura 6-4 - 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.

6.4. 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].

- 65 -

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

- 66 -

Símbolo Min. Max. Unidades Descrição

TIFCLK 20,83 -- ns Período do sinal de relógio

TSRD 18,7 -- ns Tempo de setup do SLRD -> IFCLK

TRDH 0 -- ns Tempo de permanência do IFCLK -> SLRD

TOEon -- 10,5 ns Tempo desde a activação do SLOE até haver dados validos

TOEoff -- 10,5 ns Tempo de permanência dos dados desde a desactivação do SLOE

TXFLG -- 9,5 ns Atraso da propagação das flags

TXFD -- 11 ns Atraso de propagação dos dados

Tabela 6-1 – Parâmetros da operação de leitura da FIFO do FX2LP

6.4.1 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 6-7 - 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 6-2.

- 67 -

Figura 6-8 - Diagrama temporal da operação de escrita na FIFO do FX2LP

Símbolo Min. Max. Unidades Descrição

TIFCLK 20,83 -- ns Período do sinal de relógio

TSWR 18,1 -- ns Tempo de setup do SLWR -> IFCLK

TWRH 0 -- ns Tempo de permanência do IFCLK -> SLRD

TSFD 9,2 -- ns Tempo de setup dos Dados -> IFCLK

TFDH 0 -- ns Tempo de permanência IFCLK -> Dados

TXFLG -- 9,5 ns Atraso da propagação das flags

Tabela 6-2 - 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.

ControladorUSB

Mód

ulo

Com

unic

ação

ControladorS-LINK

FIFOSíncrona

MicrocontroladorUSB

PlacaS-LINK

FIFO

Assín

cron

a

FIFO

Assín

cron

a

64 64 64

16

64

Módulo USBMóduloS-LINK

Figura 6-9 – Diagrama de blocos do módulo de comunicação na FPGA TGR/DCC.

- 68 -

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.

6.6. 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.


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.

- 69 -

DCCROC

ROC_DataOut[63:0]

MóduloComunicação

via USB

ROC_FIFO_Read

ROC_FIFO_Empty

ROC_DataIn[63:0]

ROC_FIFO_Write

ROC_FIFO_Full

USB_Data[15:0]

USB_FIFOAdr0

USB_FIFOAdr1

USB_SLRD_L

USB_SLWR_L

USB_SLOE_L

USB_PktEnd

USB_FIFO_Full

USB_FIFO_Empty

MicrocontroladorUSB

Figura 6-10 – Interface do módulo USB

6.6.1 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 6-11.

(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 6-4.

- 70 -


din I Barramento de dados para escrita.

dout O Barramento de dados para leitura.



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.

6.6.2 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

- 71 -

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.


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 210 está vazia.

USB_FlagC I Flag que indica se a USB Endpoint 610 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 210

USB_SLWR_L O Activa a escrita dos dados do USB Endpoint 610

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 6.3

- 72 -

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.

6.8. 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 9.2.04i 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.

6.9. 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

6.9.1 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.

- 73 -

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.

6.9.2 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.

6.9.3 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 4.1.2 desta Dissertação.

Foram simulados os seguintes cenários:

- 74 -


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.



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.

6.9.4 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-LINK11

• Foram enviados pedidos pelo PC;

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:

• 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.

- 75 -

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.

- 77 -

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,

- 78 -

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 apresenta-

se 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.

Modulo SFP FPGA

Placa Mezzanine

Sinais de Dados

Sinais de Controlo

Modulo SFP A

Modulo SFP B

PCI-EPHY

FPGA

Placa PCI-E

Interface PCI-E

Cabo de Fibra Óptica

Figura 7-1 - 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.

- 79 -

8. Referências [1] American Cancer Society, http://www.cancer.org/

[2] Greenlee RT, Hill-Harmon MB, Murray T, et al. “Cancer Statistics”, 2001. 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, 1994. 41: p. 1012--1017.

[4] Noh D et al., “Diagnostic value of positron emission tomography for detecting breast cancer”.

World J Surg. 1998; 22: 223-228.

[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: 147-

75, 1998.

[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, 1996.

23(7): p. 804-6.

[7] Varela, J. “Clear-PEM, a dedicated PET camera for Mammography”, in Workshop on Positron

Emission Mammography, Lisbon, July, 2002.

[8] A. Trindade et al., “Clear-PEM: Monte Carlo Performance and Image Reconstruction Studies”,

poster at IEEE-Medical Imaging Conference, Portland, October 2003.

[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), 2004.

[11] M. Martins et al., “Clear-PEM Data Reconstruction Using STIR”, Annual Congress of the

European Association in Nuclear Medicine, Istanbul, October 2005.

[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, 1996.

23(7): p. 804-6.

[15] Raylman RR, et al., “The potential role of positron emission mammography for detection of

breast cancer. A phantom study”. Med Phys, 2000. 27(8): p. 1943-54.

[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 2005.

[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. 250-303.

http://www.cancer.org/�

- 80 -

[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. 147-175.

[20] P. Rodrigues et al., “Geant4 applications and developments for medical physics experiments”,

IEEE Trans. Nucl. Sci. vol 51, 2004, pp. 1412-1419.

[21] S. Agostinelli et al., 1995, “GEANT4 – A simulation toolkit”, Nucl. Instrum. Meth. A. vol A 506,

2003, pp. 250-303.

[22] P. Lecoq and J. Varela, 2002 “Clear-PEM, A dedicated PET camera for mammography”, Nucl.

Instrum. Meth. vol. A 486, 2002, pp. 1-6.

[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, 2005.

[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 2005.

[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, 2005.

[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,

2008.

[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, 2008.

[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, 2008.

[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 2007.

[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 2008.

[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. 2704-2711, 2006.

https://www.fct.mctes.pt/fctsig/contents/index.asp?area=3&object=42&formCommand=edit&formName=CVO_publicacoes&key=140306�

- 81 -

[32] A. Trindade et al., “Design and Evaluation of the Clear-PEM Detector for Positron Emission

Mammography”, IEEE-Medical Imaging Conference, Rome, Oct 2004.

[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, 2006.

[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, 2006.

[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, 2005.

[36] Andreia Trindade et al., “Breast Cancer Imaging Studies by Monte Carlo Simulation with

Clear–PEM”, IEEE-Medical Imaging Conference, Puerto Rico, USA, October 2005.

[37] Electronic Industries Alliance, http://www.eia.org/

[38] Institute of Electrical and Electronics Engineers, Inc., www.ieee.org

[39] USB Implementers Forum, Inc, http://www.usb.org/

[40] PCI-SIG, http://www.pcisig.com

[41] StarFabric PCI Interface Card, Carlo Gavazzi Computing Solutions,

http://www.gavazzi-computing.com/products/details.php?Product=59

[42] StarFabric PCI Mezzanine Card, Carlo Gavazzi Computing Solutions,

http://www.gavazzi-computing.com/products/details.php?Product=65

[43] Carlo Gavazzi Computing Solutions, http://www.carlogavazzi.com/

[44] The StarFabric Trade Association, , http://www.starfabric.org/

[45] Stargen, Inc., http://www.stargen.com

[46] Telecommunications Industry Association, http://www.tiaonline.org/

[47] PCI Local Bus Specification, Revision 2.2. s.l. : PCI Special Interest Group, December 18,

1998.

[48] Xilinx, Inc., http://www.xilinx.com/ [49] QuickLogic Corporation, http://www.quicklogic.com/.

[50] QL5064 QuickPCI Data Sheet, Quicklogic Corporation, 2003.

[51] QuickPCI QL5064 User's Manual, Rev. E, Quicklogic Corporation, August 2003.

[52] QuickWorks with SpDE Reference, http://www.quicklogic.com/home.asp?PageID=742

[53] QuickWorks User Manual with SpDE Reference, QuickLogic Corporation, 2005

[54] Active-HDL Expert Edition, http://www.aldec.com/ActiveHDL/

[55] Aldec, Inc., http://www.aldec.com

[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, 2008.

http://www.eia.org/�

http://www.ieee.org/�

http://www.usb.org/�

http://www.pcisig.com/�

http://www.gavazzi-computing.com/products/details.php?Product=59�

http://www.gavazzi-computing.com/products/details.php?Product=65�

http://www.carlogavazzi.com/�

http://www.starfabric.org/�

http://www.stargen.com/�

http://www.tiaonline.org/�

http://www.tiaonline.org/�

http://www.xilinx.com/�

http://www.quicklogic.com/�

http://www.quicklogic.com/home.asp?PageID=742�

http://www.aldec.com/ActiveHDL/�

http://www.aldec.com/�

- 82 -

[57] PCI-to-PCI Bridge Architecture Specification. Revision 1.1. s.l. : PCI Special Interest Group,

December 18, 1998.

[58] CERN S-LINK, http://hsi.web.cern.ch/hsi/s-link/

[59] FX2LP Datasheet (Cypress: www.cypress.com)

[60] FX2LP Technical Reference Manual (Cypress: www.cypress.com)

[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,

2008.

[62] Xilinx, http://www.xilinx.com/ [Online]

[63] Mentor Graphics, http://www.mentor.com/ [Online]

[64] F. Piedade, “DAE Link Specification Document”, 2007

[65] F. Piedade, “DAE Link Design Document”, 2007

http://hsi.web.cern.ch/hsi/s-link/�

http://www.cypress.com/�

http://www.cypress.com/�

http://www.xilinx.com/�

http://www.mentor.com/�

- A -

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.9.7.1 [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

- B -

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

- C -

Anexo 2 - Registos de configuração do QL5064

Nesta secção encontra-se os registos de configuração usados por dispositivos PCI. Na figura

seguinte ilustra-se o endereço de cada registo, e na tabela A1 uma pequena descrição de cada um.

Figura A3 – Distribuição dos registos de configuração dos dispositivos PCI

- D -

Offset Name Type Function

00h Device ID[15:0] Read only Identifies the particular device.

Vendor ID[15:0] Read only Identifies the manufacturer of the device.

04h

Status[15:0] Read/Write

Bit #

15- Detected Parity Error

14- Signaled System Error

13- Received Master Abort

12- Received Target Abort

11- Signaled Target Abort

10:9 – Device Selecting Timing

8 – Data Parity Reported

7 – Fast Back-to-Back Capable For Target

6 – User Defined Feature

5 – Bit 5

4 – Bit 4

3:0 – Reserved

Command [15:0] Read/Write

Bit #

15:10 – Reserved

9 – Fast Back-to-Back Enable For Master

8 – System Error Enable

7 – Wait Cycle Enable

6 – Parity Error Enable

5 – Palette Snoop Enable

4 – Memory Write & Invalidate Enable

3- Special Cycle Enable

2- Bus Master Enable

1 – Memory Space Enable

0 – I/O Space Enable

08h

Class Code[23:0] Read only

Bit #

23:16 – Base Class

15:8 – Sub-Class

7:0 – Programming Interface

Revision ID[7:0] Read only Revision identification selected by

the user

0Ch

BIST[7:0] Read/Write

Bit #

7- BIST Capable

6- Built-In Self-Test

5:4- Reserved

3:0- Result Code

Header Type[7:0] Read only

Bit #

7- Single/Multi-Function Device

6:0- Format Field

Latency Timer[7:0] Read/Write Latency Timer

Cache Line Size[7:0] Read/Write Cache Line Size.s

10h

14h

18h

1Ch

BAR0 Base Address[31:0]




Read/Write

Bit #

31:4 - Base Address size

3– Prefetchable

2 – 32bit/64bits address location

- E -

20h

24h



1 – Memory vs. I/O Space Configuration

28h Cardbus CIS

Pointer[31:0] Read only Cardbus CIS Pointer

2Ch

Subsystem

ID[15:0] Read only Subsistem identification (optional)

Subsystem

Vendor ID[15:0] Read only Subsistem Vendor (optional)

30h

Expansion

ROM Base

Address[31:0

Read only

Bit #

31:11 - Base Address

10:1 – Reserved

0 - Address Decode Enable

34h Reserved[23:0] Reserved

Cap_Ptr[7:0] Pointer to linked list of new capabilities

38h Reserved[31:0] Read only Reserved

3Ch

Max_Lat[7:0] Read only Maximum Latency

Min_Gnt[7:0] Read only Minimum Grant

Interrupt Pin[7:0] Read only PCI interrupt request pins used.

Interrupt Line [7:0] Read/Write Interrupt line routing information

Tabela A1 – Descrição dos registos de configuração dos dispositivos PCI

- G -

Anexo 3 – Sinais da interface PCI

Na seguinte tabela descreve-se resumidamente os sinais da interface PCI. Esses sinais

pertencem ao protocolo PCI e por tal estão descritos em pormenor na especificação PCI 2.2.

Signal Type Function name

AD[63:0] t/s Address/Data

C/BE[7:0]# t/s Command/Byte Enable

PAR t/s Parity

CLK in PCI Clock

RST# in Reset

FRAME# s/t/s Frame

IRDY# s/t/s Initiator Ready

TRDY# s/t/s Target Ready

STOP# s/t/s Stop

IDSEL in Initialization Device Select

DEVSEL# s/t/s Device Select

INTA# o/d Interrupt A

PERR# s/t/s Parity Error

SERR# o/d System Error

REQ64# s/t/s Request 64-bit Transfer

ACK64# s/t/s Acknowledge 64-bit Transfer

PAR64 t/s Parity Upper

REQ# o/t/s Request

GNT# in Grant

Figura A4 – Sinais usados no protocolo PCI

- I -

Anexo 4 – Arquitectura implementada

- K -

Anexo 5 – Arquitectura da Blast Controller FIFO

- M -

Anexo 6 – Arquitectura do controlador das FIFOs

- O -

Anexo 7 - Ambiente de Simulação

- Q -

Anexo 8 – Arquitectura de Teste da TGR/DCC

- S -

Anexo 9 – Arquitectura do Módulo de Comunicação

- U -

Anexo 10 – Arquitectura do Módulo de Comunicação USB

Sistema de Comunicação para o Sistema PET Mamografia ... · O sistema que constitui o principal...

Documents

Transcript of Sistema de Comunicação para o Sistema PET Mamografia ... · O sistema que constitui o principal...