“UUM CLUSTACEL

TER DE PLERADOR

RODR

UNIV

PÓS‐G

PCs USANRES DE H

PROC

RIGO WAN

Dissert

VERSIDADE CIN ‐ CEN

GRADUAÇÃOposgrad

www.cin.

RECIF

 

 

 

 

 

NDO NÓSHARDWACESSADO

Por 

NDERLEY PIM

tação de Me

 

 

 

FEDERAL DNTRO DE INFOEM CIÊNCIAduacao@cinufpe.br/~pos

 

 

 

FE, AGOSTO/

S BASEARE (FPGAORES” 

MENTEL ARA

estrado 

 

E PERNAMORMÁTICA A DA COMPUn.ufpe.br sgraducao 

/2010 

 

DOS EM A) COMO

AUJO 

BUCO 

TAÇÃO 

MÓDULO CO‐

LOS 

 

 

“U

 

 

 

                                                

UM CLUSACEL

                                                                                                    

RODRIG

STER DE PLERADOR

                ES                CI                U                PA                DA

GO WAND

PCs USANRES DE H

PROC

STE TRABALIÊNCIA DA CNIVERSIDADARCIAL PARA COMPUTA

RECIF

 

 

 

 

 

 

 

DERLEY PI

 

 

NDO NÓSHARDWACESSADO

LHO FOI APRCOMPUTAÇDE FEDERARA OBTENÇÃAÇÃO. 

ORIENT

 

 

FE, AGOSTO/

MENTEL A

S BASEADRE (FPGAORES” 

RESENTADOÇÃO DO CENL DE PERNAÃO DO GRA

TADOR (A): 

/2010  

ARAUJO 

DOS EM A) COMO

O À PÓS‐GRNTRO DE INFAMBUCO COAU DE MEST

MANOEL E

MÓDULOO CO‐

RADUAÇÃO FORMÁTICAOMO REQUTRE EM CIÊN

USÉBIO DE 

2 

 

OS 

EM A DA ISITO NCIA 

LIMA 

Araujo, Rodrigo Wanderley Pimentel Um cluster de PCs usando nós baseados em módulos aceleradores de hardware (FPGA) como co-processadores / Rodrigo Wanderley Pimentel Araujo - Recife: O Autor, 2010. 83 folhas : il., fig., tab. Dissertação (mestrado) Universidade Federal de Pernambuco. CIn. Ciência da computação, 2010. Inclui bibliografia, glossário e apêndice. 1. Engenharia da computação. 2. Computação de alto desempenho. 3. Cluster de PCs. 4. FPGAs como co-processadores. I. Título. 621.39 CDD (22. ed.) MEI2010 – 0185

 

3  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

À minha família e aos meus amigos.

 

4  

Agradecimentos Agradeço  aos meus  pais  e minha  irmã,  pois  sem  eles  eu  nada  seria,  que me 

prepararam para a vida e sempre acreditaram em mim. 

Agradeço aos meus poucos e verdadeiros amigos do colégio, pelos ensinamentos 

e momentos de descontração, e que me acompanharam por toda minha vida escolar e 

acadêmica. 

Agradeço aos companheiros do HPCIn, principalmente Bruno Holanda, Fábio Leite 

e Bruno Corrêa que me deram suporte para o desenvolvimento desse trabalho. 

Agradeço ao meu orientador, professor Manoel Eusébio, que com sua formação e 

experiência guiou meus passos nesta tarefa. 

 

   

 

5  

Resumo A  criação  de  novas  soluções  para  aumentar  o  desempenho  de  aplicações  está 

crescendo de  importância, pois os processamentos  convencionais estão  se  tornando 

obsoletos.  Diferentes  abordagens  têm  sido  estudadas  e  usadas,  porém  vários 

problemas foram encontrados. Um exemplo é dos processadores com vários núcleos, 

que, apesar de dissipar pouca potência, apresentam velocidade de transmissão baixa e 

pequena  largura  de  banda.  Circuitos  ASICs  apresentam  alto  desempenho,  baixa 

dissipação de potência, mas possuem um alto custo de engenharia. 

Na  tentativa  de  conseguir  mais  altos  níveis  de  aceleração,  plataformas  que 

associam  o  uso  de  cluster  de  computadores  convencionais  com  FPGAs  têm  sido 

estudadas. Este tipo de plataforma requer o uso de barramentos de alto desempenho 

para  minimizar  o  gargalo  de  comunicação  entre  PC  e  FPGA,  e  um  comunicador 

eficiente entre os nós do sistema. 

Neste trabalho, são vistas as principais características de algumas arquiteturas que 

utilizam cluster de PCs. Com  isto, é proposta uma arquitetura que utiliza FPGA como 

co‐processador em cada nó do sistema, utilizando a  interface MPI para comunicação 

entre os nós e um device driver, para Linux, que permite transferência em rajada dos 

dados, através do barramento PCIe. 

Como estudo de caso, usado para a validação da arquitetura, é  implementado a 

multiplicação  de  matrizes  densas,  esta  funcionalidade  é  baseada  no  nível  três  da 

biblioteca BLAS. 

Palavras  chaves:  Cluster,  Computação  de  alto  desempenho,  FPGA, MPI,  Device 

Driver, PCIe.   

 

6  

Abstract The creation of new solutions to  increase performance of applications  is growing 

in  importance  since  conventional  processors  are  becoming  obsolete.  Different 

approaches have been studied and used, but several problems were encountered. One 

example  is  the  multi‐core  processors,  which,  despite  consuming  low  power,  have 

lower transmission speed and low bandwidth. ASICs circuits present high performance 

and low power dissipation, but have a high cost of engineering. 

In order to achieve higher  levels on acceleration, platforms that combine the use 

of cluster computers with conventional FPGAs have been studied. This kind of platform 

requires  the  use  of  high‐performance  buses  to  minimize  the  bottleneck  of 

communication between PC and FPGA, and an effective communicator between  the 

nodes of the system. 

This work  considers  the main  characteristics of  some  cluster architectures using 

PCs. With this, an architecture that utilizes FPGA as a co‐processor on each node of the 

system  is  proposed.  It  uses  the MPI  interface  for  internode  communication  and  a 

device driver to Linux, which allows burst transfer of data via the PCIe bus. 

As a study case, used  to validate  the architecture, dense matrix multiplication  is 

implemented. This feature is based on the level three of the BLAS library. 

Keywords: Cluster, High Performance Computing, FPGA, MPI, Device Driver, PCIe. 

   

 

7  

Sumário 1.  Introdução ........................................................................................................................... 14 

2.  Trabalhos Relacionados ...................................................................................................... 19 

2.1 Conclusões ......................................................................................................................... 24 

3.  Fundamentação Teórica ...................................................................................................... 26 

3.1 Message Passing Interface ................................................................................................ 26 

3.1.1 Convenções e Termos do MPI .................................................................................... 27 

3.1.2 Comandos de Comunicação Ponto a Ponto ............................................................... 29 

3.1.3 Gerenciamento dos Comunicadores .......................................................................... 31 

3.2 Linux e Device Drivers ........................................................................................................ 32 

3.2.1 Classes de Dispositivos e Módulos ............................................................................. 34 

3.2.2 Char Drivers ................................................................................................................ 35 

3.3 Barramento PCI e seus Drivers .......................................................................................... 40 

3.3.1 Barramento PCI Express ............................................................................................. 41 

3.3.2 A Estrutura do PCI Express ......................................................................................... 43 

3.3.3 Visão Geral das camadas do PCI Express ................................................................... 44 

3.3.3.1 Transaction Layer .................................................................................................... 45 

3.3.3.2 Data Link Layer ........................................................................................................ 46 

3.3.3.3 Physical Layer .......................................................................................................... 46 

3.3.4 Configuração plug‐and‐play ....................................................................................... 47 

3.3.5 Device Driver para acesso ao Barramento PCIe ......................................................... 52 

3.4 Dispositivos Lógicos Reconfiguráveis ................................................................................ 55 

3.5 Conclusões ......................................................................................................................... 58 

4.  Arquitetura Proposta .......................................................................................................... 59 

4.1 Interface de Aplicação ....................................................................................................... 59 

4.2 Nós do Sistema .................................................................................................................. 61 

4.2.1 Core PCIe .................................................................................................................... 63 

4.3 Device Driver ..................................................................................................................... 65 

4.3.1 Estrutura Char Driver .................................................................................................. 66 

4.3.2 Estrutura PCI Driver .................................................................................................... 69 

4.4 Conclusões ......................................................................................................................... 71 

5.  Estudo de Caso .................................................................................................................... 73 

5.1 Algoritmo de Particionamento de Matrizes ...................................................................... 73 

5.2 Implementação da Aplicação ............................................................................................ 74 

 

8  

5.2.1 Aplicação no Nó Mestre ............................................................................................. 75 

5.2.2 Aplicação nos Nós Escravos ........................................................................................ 77 

5.3 Core de Multiplicação de Matrizes ................................................................................... 79 

5.4 Conclusões ......................................................................................................................... 81 

6.  Resultados ........................................................................................................................... 82 

6.1 Análise Quantitativa dos Códigos ...................................................................................... 82 

6.2 Uso da Arquitetura ............................................................................................................ 82 

6.3 Estimativa de desempenho da plataforma ....................................................................... 83 

6.4 Atrasos gerados pelo barramento PCIe ............................................................................ 83 

6.5 Comparação de desempenho hardware x software ......................................................... 84 

7.  Conclusões e Trabalhos Futuros ......................................................................................... 86 

8. Referências Bibliográficas ....................................................................................................... 88 

 

   

 

9  

Lista de Figuras 

Figura 1 ‐ Classificação dos circuitos integrados [1]. ...................................................... 14 

Figura 2 ‐ Implementações de máquinas de HPC da classe 2. ....................................... 19 

Figura 3 ‐ MPI‐HMMER com FPGAs. ............................................................................... 22 

Figura 4 ‐ Tempo de comparação do MPI otimizado e implementaçao MPI+FPGA para 

dois processadores. ........................................................................................................ 23 

Figura 5 ‐ A arquitetura do cluster de GPU mostrando apenas um nó. ......................... 24 

Figura 6 ‐ Valores para o DataType ................................................................................ 30 

Figura 7 ‐ As diferentes tarefas do kernel. ..................................................................... 34 

Figura 8 ‐ Representação do sistema de arquivo. .......................................................... 36 

Figura 9 ‐ Estrutura do file operations ............................................................................ 38 

Figura 10 ‐ Link PCI Express ............................................................................................. 42 

Figura 11 ‐ Exemplo da topologia da estrutura do PCI Express ...................................... 43 

Figura 12 – Diagrama das camadas do PCIe ................................................................... 45 

Figura 13 – Formato genérico do TLP ............................................................................. 46 

Figura 14 – Espaço de configuração, tipo 0, do barramento PCIe ................................. 48 

Figura 15 – Command Register ....................................................................................... 49 

Figura 16 – Status Register ............................................................................................. 50 

Figura 17 – Estrutura do Base Address Register (BAR) ................................................... 51 

Figura 18 – Estrutura do pci_driver ................................................................................ 54 

Figura 19 – Estrutura básica de um FPGA ...................................................................... 56 

Figura 20 – (a) Bloco lógico Altera Stratix II (b) LUT de duas entradas e uma saída ...... 57 

Figura 21 – (a) Estrutura geral da FPGA (b) bloco de switch (c) bloco de conexão ....... 57 

Figura 22 ‐ Função de inicialização do MPI. ................................................................... 59 

Figura 23 ‐ Figura que mostra o uso das funções de escrita e leitura do MPI ............... 60 

Figura 24 ‐ Uso dos comunicadores. .............................................................................. 60 

Figura 25 ‐ Uso da função MPI_Finalize. ........................................................................ 61 

Figura 26 ‐ Placa ML555 com FPGA Virtex 5 da Xilinx. ................................................... 62 

Figura 27 ‐ Nó escravo do cluster com um FPGA como co‐processador. ...................... 62 

Figura 28 ‐ vendorID da Xilinx e deviceID. ...................................................................... 66 

Figura 29 ‐ Estrutura pci_device_id. ............................................................................... 66 

 

10  

Figura 30 ‐ Estrutura contendo char driver e pci driver. ................................................ 66 

Figura 31 ‐ Função que registra o char driver. ................................................................ 67 

Figura 32 ‐ Função que remove o char driver do kernel. ............................................... 67 

Figura 33 ‐ Estrutura file operations. .............................................................................. 67 

Figura 34 ‐ Função write. ................................................................................................ 68 

Figura 35 ‐ Função read. ................................................................................................. 68 

Figura 36 ‐ Estrutura dos registradores de controle e status do DMA. ......................... 69 

Figura 37 ‐ Estrutura pci_driver. ..................................................................................... 69 

Figura 38 ‐ Função scan_bars. ........................................................................................ 70 

Figura 39 ‐ Função map_bars. ........................................................................................ 70 

Figura 40 ‐ Função free_bars. ......................................................................................... 70 

Figura 41 ‐ Função probe. ............................................................................................... 71 

Figura 42 ‐ Função remove. ............................................................................................ 71 

Figura 43 ‐ Diagrama no nó mestre. ............................................................................... 75 

Figura 44 ‐ Disposição dos números do arquivo de entrada .......................................... 75 

Figura 45 ‐ Alocação das matrizes. ................................................................................. 76 

Figura 46 ‐ Leitura dos elementos das matrizes. ............................................................ 76 

Figura 47 ‐ Algoritmo de particionamento da matriz A. ................................................ 76 

Figura 48 ‐ Envio dos dados para os nós escravos. ........................................................ 77 

Figura 49 ‐ Recebimento dos dados dos nós escravos. .................................................. 77 

Figura 50 ‐ Diagrama no nó escravo. .............................................................................. 78 

Figura 51 ‐ Abertura do arquivo para o char_driver. ..................................................... 78 

Figura 52 ‐ Funções do device driver para trocar dados com o FPGA. .......................... 79 

Figura 53 ‐ Decomposição das matrizes no produto da multiplicação de vetores. ....... 80 

Figura 54 ‐ Fluxo de dados no nó mestre. ...................................................................... 80 

Figura 55 ‐ Execução do algoritmo de multiplicação de matrizes considerando apenas 

um FPGA. ........................................................................................................................ 84 

Figura 56 ‐ Tempo de execução em usec considerando uma implementação em 

software, um FPGA e o cluster com dois nós. ................................................................ 85 

   

 

11  

Lista de Tabelas 

Tabela 1 – Descrição dos bits do command register. ..................................................... 49 

Tabela 2 – Descrição dos bits do status register. ........................................................... 51 

Tabela 3 – Resumo das famílias e características dos FPGA da Altera. ......................... 58 

Tabela 4 – Resumo das famílias e características dos FPGA da Xilinx ............................ 58 

Tabela 5 ‐ Registradores de controle e status do DMA. ................................................. 63 

Tabela 6 ‐ Definições dos bits do registrador DMACS. ................................................... 64 

Tabela 7 ‐ Número de linhas de código .......................................................................... 82 

   

 

12  

Glossário 

Esta seção descreve o significado de alguns termos freqüentemente utilizados no 

texto e tem como objetivo familiarizar o leitor com tais termos. 

FPGA (Field Programmable Gate Array) 

Circuito integrado que pode ser programado em campo. É formado por uma matriz de 

blocos lógicos configuráveis com interconexões internas e externas a esses blocos, que 

permitem que o projetista  construa  sistemas baseados em  lógicas  combinacionais e 

seqüenciais. 

ASIC (Application Specific Integrated Circuit) 

Circuito  integrado  de  aplicação  específica.  Apresenta  uma  funcionalidade  específica 

que não pode ser modificada em campo. 

BRAM Block 

Bloco de memória RAM interno ao FPGA e que pode ter seu comportamento, largura e 

número de palavras configuráveis de acordo com as necessidades do projetista. 

BLAS (Basic Linear Algebra Subprograms) 

Conjunto  de  rotinas  eficientes  que  provêem  blocos  básicos  para  execução  de 

operações  entre matrizes  e  vetores.  É  dividido  em  três  níveis:  BLAS  1  que  contém 

rotinas  para  operações  entre  vetores,  BLAS  2  com  rotinas  para  operações  entre 

matrizes e vetores e BLAS 3 que contém rotinas para operações entre matrizes. 

DRAM (Dynamic Random Access Memory) 

Memória volatil dinâmica baseada em capacitores e utilizada como memória principal 

dos processadores. Apresenta maior capacidade de armazenamento e menor  largura 

de banda quando comparada a memória SRAM. 

SRAM (Static Random Access Memory) 

Memória  volatil  estática  baseada  em  flip‐flops.  Apresenta  menor  capacidade  de 

armazenamento e maior largura de banda quando comparada à memória DRAM. 

Conexão RapidArray 

Rede de  interconexão de alta velocidade  (2GB/s) proprietária da Cray que permite a 

interconexão de vários compute blades do sistema Cray XD1. 

 

 

 

13  

NUMAlink 

Sistema  de  interconexão  desenvolvido  pela  SGI  para  utilização  nos  seus  sistemas 

computacionais de memória distribuída. O NUMAlink 4 possui uma  largura de banda 

de 6,4 GB/s. 

DMA (Direct memory access) 

Técnica que permite que certos dispositivos de hardware num sistema computacional 

acessem o sistema de memória para leitura e escrita independentemente da CPU (sem 

sobrecarregar a CPU). 

Verilog 

Linguagem  de  descrição  de  hardware  usada  para  descrever  circuitos  eletrônicos  e 

sistemas. É uma linguagem destinada a verificação, testes e síntese lógica. 

VHDL (Very High Speed Integrated Circuit Hardware Description Language) 

Linguagem  de  descrição  de  hardware  utilizada  para  descrever  sistemas  digitais. 

Permite descrições comportamentais, estruturais e temporais da lógica de circuitos. 

Cluster 

Conjunto de computadores ligados em rede e que trabalham de forma cooperativa na 

execução de uma tarefa , como se fossem uma única máquina de grande porte. 

MPI 

Biblioteca destinada à comunicação de dados em computação paralela. 

Linux 

Núcleo de sistema operacional para  família GNU/Linux de sistemas operacionais  tipo 

unix. Ele é um dos exemplos mais proeminentes de software livre. 

Device Driver 

É o comando de um dispositivo ou programa. É a forma a partir da qual uma unidade 

periférica  cria  uma  interface  com  o  sistema  operacional  para  se  conectar  com  o 

dispositivo do hardware. 

   

 

 

1D

do a

micro

treze

duze

segu

desd

tecno

por  c

mane

class

E

térm

da fa

Oxide

(VLSI

físico

oper

conh

volta

1. IntroDesde a intr

no 1971, o

oprocessad

entos  trans

entos  dólar

ndo o núm

de  o  lançam

ologia os ci

cm3,  poden

eira geral e

sificados con

Estes  dispo

mica, tamanh

abricação. D

e Silicon) é 

I‐Very  Larg

o  quanto  a

ração, princ

hecidos des

adas para pr

dução rodução do 

s sistemas 

dor,  introdu

sistores  em

res  americ

mero de  tra

mento  do m

rcuitos inte

ndo‐se  atin

stes circuito

nforme a Fi

Figur

sitivos  pod

ho, velocida

Dentre as te

a mais utili

ge  Scale  Int

ao  desempe

cipalmente 

ta  tecnolog

rocessamen

primeiro m

digitais têm

uzido  pela  I

m  uma  únic

anos.  A  co

nsistores d

microproces

egrados, con

gir  cem mi

os, que per

gura 1. 

a 1 ‐ Classifica

dem  ter  ca

ade dos tra

ecnologias d

zada na con

tegration). 

enho  desta

quando se 

gia e que  fa

nto de dado

microproces

m evoluído 

Intel  Corpo

ca  pastilha 

omplexidad

dentro do  c

sador  4004 

nsegue‐se i

ilhões  até 

mitem a im

ação dos circu

aracterística

ansistores, e

de semicond

nfecção de 

Acredita‐se

a  tecnologi

trata de m

azem parte

os digitais.

ssador come

de  forma c

oration,  inte

de  silício 

de  dos  mi

chip, é dobr

[1]. Atualm

integrar vár

2012  [2]  em

mplementaç

uitos integrado

as  bem  dif

entre outra

dutores, CM

circuitos in

e,  ainda,  te

a,  em  fun

icroprocess

e de pratica

ercial, o Int

consideráve

egrava  cerc

a  um  cust

croprocessa

rada a  cada

mente,  com

rios milhões

m  um  únic

ão lógica di

os [1]. 

ferentes,  c

s, em funçã

MOS (Compl

tegrados de

er‐se  chega

ção  da  sua

sadores com

amente  tod

tel 4004, no

el. Este peq

ca  de  dois 

to  estimad

adores,  m

a dezoito m

m  a  evoluçã

s de transis

co  chip. De

igital, pode

como  dissip

ão da tecno

lementary M

e alta integ

ado  a  um  l

a  freqüênc

merciais, os

das  as máq

14 

o final 

queno 

mil  e 

do  de 

edida 

meses 

ão  da 

stores 

  uma 

m ser 

 

pação 

ologia 

Metal 

ração 

limite 

ia  de 

 mais 

uinas 

 

15  

  Voltadas para o processamento de alto desempenho, como foco deste trabalho, 

observa‐se a  inviabilidade  técnica de  se explorar de  forma  ilimitada a  freqüência de 

operação destes dispositivos, contida hoje a níveis de ordem de 3GHz por core, e por 

conseguinte um aumento substancial de desempenho por unidade de processamento. 

Esta  limitação  tecnológica  levou  à  busca  de  novas  soluções,  como  a  integração  de 

vários  processadores  em  um  único  chip  [3][4][5][6],  a  uma  freqüência  de  operação 

mais  baixa,  promovendo  um  menor  aquecimento  do  sistema  e  um  melhor 

desempenho, com processamento paralelo [7]. 

Mais  recentemente,  outras  arquiteturas,  fora  aquelas  exploradas  pela  Intel[8]  e 

AMD[9],  têm  considerado  fortemente  o  fator  paralelismo  em  seus  projetos, 

integrando  não  só  núcleos  de  processamento  (cores),  mas  também  memórias  e 

barramentos rápidos. Entre estas arquiteturas especiais, destaca‐se as GPUs (Graphics 

Processing  Unit)[39],  processadores  especializados  em  processamento  gráfico  ou 

visual.  Na  maioria  dos  casos,  utilizadas  para  processar  as  imagens  com  maior 

velocidade  e  qualidade,  estes  dispositivo  têm  sido  também  largamente  usadas  em 

máquinas  de  última  geração  [39],  no  processamento  de  cálculos  matemáticos  e 

geométricos  complexos.  O  poder  computacional  das  atuais  GPUs  tem  excedido  as 

CPUs de propósito geral. Por exemplo,  a nVidia GeForce 6800 Ultra pode  atingir 40 

GFlops [18]. Em comparação, o pico teórico de performance do Intel 3 GHz Pentium 4 é 

de 6 GFlops. 

Dirigidas pela  indústria de  jogos, o desempenho das GPU tem, aproximadamente, 

dobrado a cada 6 meses desde meados dos anos 90 [17], o que é bem mais rápido que 

os  18 meses  de  uma  CPU,  e  essa  tendência  parece  continuar.  Isto  é  possível  pelo 

paralelismo explícito exposto em sua arquitetura. Como a tecnologia de fabricação de 

semicondutores  está  avançando,  GPUs  podem  usar  transistores  adicionais  mais 

eficientemente para computação do que CPUs, aumentando o número de pipelines. 

Observamos, porém, que mesmo com todo o ajuste arquitetônico, visando maior 

paralelismo, paradigmas de processamento baseados no modelo de von Neumann [10] 

ainda permanecem. CPUs precisam acessar memórias, decodificar instruções, apanhar 

dados  da  memória  e  executá‐las.  Ainda,  para  aplicações  que  requerem  um 

processamento  massivo  de  dados,  o  desempenho  de  tais  arquiteturas  ainda  fica 

 

16  

comprometido devido ao tempo de acesso aos dados, através de barramentos lentos e 

uma pequena largura de banda, quando do acesso aos dados na memória do sistema. 

Novas arquiteturas têm surgido no sentido de reduzir alguns gaps importantes no 

processamento paralelo de dados, com redução de energia e com desempenho similar 

e  muitas  vezes  melhor  que  as  tecnologias  expostas  acima.  Circuitos  dedicados  a 

execução em hardware de um determinado algoritmo, como ASIC (Application Specific 

Integrated Circuits)  são evidentemente os de melhor desempenho, em  freqüência e 

potência, no entanto,  requerem projetos de  alto  custo para  seu desenvolvimento e 

possuem lógica fixa.  

Uma solução interessante, que embora não seja nova no mercado de prototipação 

de circuitos  integrados de média e  larga escala, mas que começam também a serem 

explorados fortemente como uma possível solução na área de processamento de alto 

desempenho  são  os  circuitos  baseados  em  lógica  programável,  tais  como:  PLD 

(Programmable  Logic  Device),  CPLD  (Complex  Programmable  Logic  Device)  e  FPGA 

(Field Programmable Gate Array)  [11]. Estes dispositivos possuem a  flexibilidade em 

sua reconfiguração  interna, permitindo sua customização, de acordo com o algoritmo 

do cliente. Com  isto, a  implementação do algoritmo é  transformada em um modelo 

em hardware, pura  lógica digital, sem a necessidade de sequencialidade na execução 

de  instruções, como em CPUs convencionais. Atrelados à evolução das metodologias 

de  projeto  de  hardware,  apoiadas  em  poderosas  ferramentas  de  software,  esses 

circuitos abriram novas perspectivas, que  tornam possível o desenvolvimento  rápido 

de um projeto de sistema digital com um alto desempenho computacional. 

De  fato,  cada  arquitetura  possui  suas  vantagens  e  desvantagens  associada  à 

relação custo/benefício, na implementação, manutenção, programação e desempenho 

dos sistemas. Uma solução interessante é tirar o melhor destes mundos e desenvolver 

uma arquitetura híbrida que satisfaça as necessidades do cliente, permita flexibilidade 

para ajustar seu problema ao  longo da produção e um custo acessível de aquisição e 

manutenção.    

Neste  contexto,  este  trabalho  visa  o  estudo  e  desenvolvimento  de  um  sistema 

computacional de alto desempenho, baseado em um cluster de nós baseados em CPUs 

convencionais  e  co‐processadores  reconfiguráveis,  utilizando  um modelo  hw/sw  co‐

design,  tirando  o  melhor  das  duas  tecnologias.  O  uso  de  dispositivos  lógicos 

 

17  

programáveis  FPGAs,  como  co‐processadores,  permite  um  maior  desempenho  na 

execução de algoritmos aritméticos/lógicos que em software, mantendo também um 

alto grau de  flexibilidade quanto a customização do algoritmo. As CPUs, por sua vez, 

permitem  um  acesso  mais  transparente  ao  usuário  quanto  à  comunicação  e 

tratamento/controle prévio de dado. 

 O modelo, que analisa mais de perto o uso de dispositivos FPGAs, observa como o 

ganho em desempenho pode ser avaliado em função do paralelismo  intrínseco desta 

arquitetura,  possibilidade  de  técnicas  de  reuso  de  dados  e  flexibilidade  na 

implementação  de  diferentes  núcleos  de  hardware  em  um  único  dispositivo.  O 

desempenho  alcançado  por  esses  dispositivos  reconfiguráveis  tem  permitido  o 

desenvolvimento de  soluções em várias áreas do conhecimento humano,  tais como: 

medicina,  geofísica,  biotecnologia,  engenharias,  financeira,  etc.,  em  aplicações  que 

requerem processamento aritmético inteiro, ponto fixo, binário ou ainda com notação 

aritmética ponto flutuante, com simples ou dupla precisão, etc [12]. 

O desempenho de um cluster de computadores formado por uma interconexão de 

vários  nós,  são  em  geral  baratos  e  possuem  uma  capacidade  computacional 

comparável  aos  de  supercomputadores  [13].  Esta  abordagem  exige,  no  entanto, 

interconexões entre os nós com barramentos rápidos, tais como Gigabit Ethernet [40] 

e  InfiniBand[41],  linguagens  de  programação  padrões,  como  C,  protocolos  especiais 

como o MPI [14], device drivers, etc. 

Quanto ao custo de implementação de um cluster híbrido, como o sugerido neste 

trabalho, observa‐se que o custo de se utilizar FPGAs em nós, geralmente é o mesmo 

de se adicionar um novo nó ao sistema. Este projeto visa, portanto, o desenvolvimento 

de  um  cluster  experimental  com  nós  híbridos  (CPU+FPGA),  voltado  para  aplicações 

científicas.   

Este  cluster  está  associado  à  Rede  de  Modelagem  Computacional 

RPCMOD/CENPES/FINEP  da  Petrobrás  [15],  em  desenvolvimento  no  Centro  de 

Informática, da Universidade Federal de Pernambuco, através do grupo HPCIn. 

Uma  arquitetura mínima,  assim  como  um  estudo  de  caso,  foi  desenvolvida  no 

sentido de validar este trabalho. O estudo de caso corresponde a  implementação de 

subset da biblioteca do BLAS  (Basic  Linear Algebra Subprogram)  [16],  implementada 

em hardware, nos FPGAs do cluster, a saber multiplicação de matrizes densas. Toda a 

 

18  

estrutura de desenvolvimento dos devices drivers,  rotinas para acesso as  funções de 

hardware, comunicação, etc. serão apresentadas em detalhes no texto.  

A  organização  deste  trabalho  é  feita  da  seguinte  forma:  no  capítulo  2  são 

apresentados  trabalhos  científicos  relacionados,  que  foram  usados  com  objetivos 

semelhantes;  o  capítulo  3  faz  uma  fundamentação  teórica  das  tecnologias  usadas 

nesse  projeto, mostrando  o  que  é  necessário  para  o  entendimento  do mesmo;  no 

capítulo 4, é apresentado  todo o  fluxo para a elaboração do ambiente; o  capítulo 5 

mostra um estudo de caso desenvolvido; no capítulo 6 são apresentados os resultados 

conseguidos  com  esse  trabalho;  e,  para  finalizar,  no  capítulo  7,  é  apresentada  a 

conclusão e os trabalhos futuros.   

 

 

2E

clust

anali

O 

escal

poss

dispo

FPGA

nívei

Ne

três 

clust

nós d

como

Esta 

técni

instâ

comb

A 

A 

As

entre

2. TrabaEste  capítul

ters que uti

isados bem 

trabalho de

lar  sistema

ibilita  a  im

ositivos ace

As, todos in

is foi explor

este trabalh

categorias.

ter de CPUs

de CPUs. A 

o  co‐proces

aceleração

icas  como 

âncias  de  u

binam algum

terceira cla

Figura 2 mo

s  três  clas

egam soluçõ

alhos Ro  tem  por

lizam FPGA

como com

escrito em 

as  compost

plementaçã

eleradores e

nterconecta

rado para ob

ho, o autor 

  A  primeir

.  Nesta cat

segunda c

ssadores,  c

o é  feita em

pipeline  e 

unidades  fu

ma forma d

asse compre

ostra arquit

Figura 2 ‐ Im

ses  acima 

ões de com

Relacion  finalidade

s como co‐

parações se

[19] propõe

os  desde  a

ão de  aplic

em hardwar

dos por um

bter o máxi

classifica m

a  categoria

tegoria, tare

lasse comp

com  o  prop

m geral atrav

paralelism

uncionais.  E

de hardware

eende aque

teturas bási

mplementaçõe

são  dispo

mputação de

nados  apresenta

‐processado

erão feitas e

e uma arqu

alguns  até 

ações usan

re e microp

ma comunic

imo de thro

máquinas de

a  consiste  e

efas são pa

reende clus

pósito  de  a

vés da exp

o  de  dado

Esta  catego

e reconfigur

elas máquin

icas de máq

es de máquin

onibilizadas 

e alto desem

ar  e  discuti

ores. Três im

em relação 

itetura e um

milhares  d

ndo uma  co

processador

cação flexíve

oughput. 

e computaç

em  superco

rticionadas 

sters de CP

acelerar  cer

loração do 

os  através  d

oria  abrang

rável com, n

as que usam

quinas da cl

as de HPC da 

como  pro

mpenho, co

r  trabalhos

mportantes

à proposta 

m fluxo de p

de  FPGAs.  E

ombinação 

res espalha

el. O parale

ão de alto d

omputadore

e executad

PUs que  inc

rtas  partes 

paralelismo

da  replicaçã

ge  todas  as

no mínimo, 

m apenas FP

asse 2. 

classe 2[19]. 

odutos  por

m diferente

s  relacionad

s trabalhos 

deste traba

projeto cap

Esta  abord

heterogêne

dos entre v

elismo em v

desempenh

es  baseado

das em múl

orporam FP

dos  algorit

o de algorit

ão  de múl

s  máquinas

 uma CPU. 

PGA como 

r  empresas

es arquitetu

19 

dos  à 

serão 

alho. 

paz de 

agem 

ea de 

vários 

vários 

ho em 

os  em 

tiplos 

PGAs, 

tmos. 

tmos, 

tiplas 

s  que 

nós. 

 

s  que 

uras e 

 

20  

solução  de  gargalo  nos  problemas  críticos  de  transferência  de  dados  entre  CPU  e 

FPGA. 

A plataforma Cray XD1 representa aqueles computadores da segunda classe. Nesta 

arquitetura as FPGAs são diretamente conectadas às CPUs através de seu mecanismo 

de  interconexão  proprietário,  o  RapidArray.  Este mecanismo  possui  uma  largura  de 

banda de 2x2.0GB/s [20]. 

Neste modelo, cada FPGA pode ser configurado para mapear uma memória SRAM 

externa  dentro  do  espaço  de  memória  do  usuário  no  processador,  permitindo  a 

aplicação  em  software  transferir  dados  diretamente  para  o  FPGA.  Sob  condições 

ideais, o FPGA pode processar dados em uma região da SRAM, enquanto que a CPU, 

concorrentemente,  preenche  e  drena  os  buffers  em  outra  região.  A  biblioteca  do 

software é provida para usuários finais do sistema para acelerar a aplicação. 

A SGI implementa a sua classe. Nesta arquitetura, o FPGA é conectado ao resto do 

sistema através de um barramento de  interconexão proprietária, o NUMALink™[21]. 

Este  criada  pela  própria  SGI  e  está,  atualmente,  na  quinta  geração  e  é  capaz  de 

alcançar pico de largura de banda de 15 GB/s Diferente da configuração Cray, que usa 

uma SRAM externa  como  cache, esta arquitetura permite ao FPGA acesso direto ao 

domínio da memória usado pelos processadores. A SRAM externa é usada pelo FPGA 

somente  para  armazenamento  intermediário  de  dados.  O  acesso  ao  FPGA  pelo 

software  é  feito  alcançado  através  de  um  conjunto  de  rotinas  contidas  em  uma 

biblioteca especial. 

Ao contrário das abordagens usadas pela Cray e SGI, o sistema da SRC Computers 

não  acopla  FPGAs  diretamente  ao  barramento  [22].  Um  FPGA  intermediário  é, 

primeiramente, usado como uma ponte entre o barramento do sistema e a RAM dual 

port. A  segunda  porta da RAM  conecta  os múltiplos  chips  FPGAs  contendo  a  lógica 

definida  pelo  usuário. A  RAM  intermediária  é  usada  para  implementar  buffers  para 

permitir  a  troca de dados entre o barramento do  sistema e o  FPGA. A  SRC usa um 

compilador customizado para extrair automaticamente algoritmos, escritos em C, que 

sejam apropriados para serem implementados em hardware. 

A última máquina considerada pelos autores é considerada a mais relevante para a 

aplicação proposta no trabalho, mesmo que não seja considerada uma plataforma de 

super  computação.  O  hardware  denominado  PROGRAPE  (PROgrammable  GRavity 

 

21  

Pipe) é baseado em uma implementação de FPGA da GRAPE [23], que foi desenvolvida 

para simulações de corpos estrelares e depois estendida para dinâmica molecular. O 

FPGA da PROGRAPE é conectado ao host através do barramento PCI. O software, na 

CPU,  executa  a  computação  com  complexidade O(n) e usa o  FPGA para  acelerar os 

cálculos O(n2). 

Este trabalho propõe então um modelo de plataforma voltada para computação de 

alto  desempenho,  denominada  TMD,  como  Abreviação  de  Toronto  Molecular 

Dynamics. 

A  arquitetura  TMD,  não  utiliza  memória  compartilhada  nem  barramento 

compartilhados.  No  entanto,  cada  unidade  de  computação  apresenta  sua  própria 

memória  local.  Um  modelo  de  programação  apropriado  para  memória  distribuída 

baseada  em  passagem  de  mensagem  também  foi  desenvolvida.  Neste  cluster,  foi 

utilizado  o  padrão MPI  [14]  como  base  para  o modelo  de  programação  do  TMD, 

provendo um ambiente familiar para o desenvolvimento de aplicações. O uso de MPI 

possibilitou  também  a  portabilidade  de  aplicações  paralelas  para  diferentes 

plataformas, padronizando a semântica e a sintaxe da interface de programação. 

Outro  trabalho,  descrito  em  [25],  apresenta  a  implementação  de  um  cluster  da 

ferramenta  de  busca  HMMER,  o  hmmsearch.  Nesta  arquitetura  é  explorada  a 

combinação de duas técnicas de aceleração: o BioBoost hardware accelerator baseado 

em um FPGA; e a  implementação de  cluster baseado no MPI,  conhecida  como MPI‐

HMMER.  Estas  duas  técnicas  foram  usadas  em  conjunto,  utilizando  o  MPI,  para 

escalonar mais de um acelerador em hardware. Como resultado deste modelo híbrido 

foi criado o MPI‐HMMER‐Boost, cuja arquitetura pode ser vista na Figura 3. 

 

 

Ne

respo

a  ou

simp

ao  se

sem 

seja 

tenta

infor

acord

nós 

oper

proce

ether

mem

FPGA

atrav

esta arquite

onsável por

utra  é  resp

plificar a co

e  inicializar

os acelerad

encontrado

ando  inicia

rmação, ele

do a existê

em  softwa

racional Red

essador Du

rnet entre e

mória  RAM. 

As usados  f

vés de uma 

etura, o nó

r coletar e p

ponsável  po

municação 

r  a bibliotec

dores em ha

o,  este  ser

alizar  é  po

es são divid

ncia ou não

are  foram 

d Hat Enter

ual‐Core AM

eles. Cada e

A  versão 

foram os Xi

interface U

Figura 3 ‐ MP

 mestre é c

processar o

or  coletar 

entre os g

ca MPI. Est

ardware. Ca

rá  usado  p

ossível  sab

idos em do

o de um FP

baseadas 

rprise Linux 

MD Opteron

escravo tem

7.1.2  do  LA

ilinx Sparta

USB 2.0. Doi

PI‐HMMER co

controlada 

s dados ori

e  pós‐proc

rupos, dois

tes dois  co

ada nó tenta

para  acelera

ber  quais 

ois grupos, 

PGA.   A plat

no  cluster 

x 4. O cluste

n 275, e de

m um proce

AM/MPI  fo

an‐3 XC3S15

s nós escra

m FPGAs[25].

por duas th

undos dos n

cessar  os 

s comunicad

municadore

a inicializar 

ar  a  comp

nós  possu

e responde

taforma de 

SunFire  x2

er consiste 

ez nós escra

ssador AMD

i  usada  pa

500. Essa p

vos foram u

. 

hreads nos 

nós em soft

resultados 

dores MPI  f

es  represen

um FPGA, c

utação.  Ap

uem  FPGAs

erão aos co

hardware u

2100  utiliza

de um nó m

avos  com  c

D Opteron 1

ra  a  comun

placa  foi  con

usados com

 

servidores;

tware, enqu

do  FPGA. 

foram  form

ntam nós  c

caso o hard

pós  cada  n

s.  Usando 

omunicador

utilizada pa

ando  o  sis

mestre, com

conexões gi

175 com 2G

nicação MP

nectada ao

m os FPGAs. 

22 

; uma 

uanto 

Para 

mados 

om e 

dware 

ó  ter 

esta 

es de 

ara os 

stema 

m um 

ibabit 

GB de 

PI. Os 

o host 

 

 

Os

aume

Adici

análi

Os

HMM

Em

tamb

utiliz

Nest

teóri

GPU,

de 4 

2.4 G

mem

Ne

discu

geral

poss

potê

s  resultado

ento de des

ionando‐se 

ise pode ser

Figura 4 ‐ Te

s  resultado

MER‐Boost c

mbora não 

bém  interes

za GPUs com

e exemplo,

ico de perfo

, a mesma a

vezes da p

GHz e 2.5 G

mória.  

este  trabal

ute process

l,  aplicaçõe

uem melho

ncia por GF

os mostram

sempenho 

um segund

r visto na Fi

empo de com

os  conseguid

conseguiu u

seja um tra

ssante  de  s

mo co‐proc

 adicionand

ormance de

aplicação fo

performance

GHz de mem

ho, porém 

amento de

es  não  cu

or desempe

FLOPs é extr

m  que,  com

de oito a q

do FPGA o a

gura 4. 

paração do M

pro

dos pelos a

um bom aum

abalho diret

ser  analisad

essadores, 

do 32 GPUs

e 512 GFlop

oi usada em

e. Cada um 

mória e um

é discutido

 alto desem

stomizadas

enho em G

remamente

  a  utilizaçã

quinze vezes

aumento pa

MPI otimizado

ocessadores[2

autores mo

mento de d

tamente re

do  é  o  [27]

para comp

 em um clu

ps. Para dem

m um cluste

 dos 32 nós

a GPU, a G

o um ponto

mpenho com

s,  em  unid

GPUs que em

e inferior no

ão  de  um  ú

s em relaçã

assa a ser d

e implement

25]. 

ostram que 

esempenho

lacionado à

],  que mos

utação cien

uster de PC é

monstrar a 

r de CPU, e

s foi equipa

GeForce FX 5

o extremam

m GPUs e F

dades  de  p

m  FPGAs. N

os FPGAs [2

único  FPGA

ão ao MPI‐H

e mais de t

açao MPI+FPG

a  impleme

o. 

à FPGAs, um

tra  um  clus

ntífica de alt

é possível c

performan

 conseguiu‐

ado com do

5800 Ultra 

mente  relev

FPGAs. Obs

processame

No entanto

7]. 

A,  é  possíve

HMMER soz

trinta vezes

 

GA para dois 

entação do 

m outro tra

ster  de  PCs

to desempe

chegar a um

nce do clust

‐se um aum

ois Pentium 

com 128 M

vante quand

erva‐se que

ento  aritm

o, o  consum

23 

el  um 

zinho. 

. Esta 

MPI‐

balho 

s  que 

enho.   

m pico 

ter de 

mento 

Xeon 

MB de 

do  se 

e, em 

ético, 

mo de 

 

 

A 

N

exec

barra

pico 

2.1 C

Ap

ser d

O 

foram

clust

comu

difer

Em

difer

nós e

Expre

USB 

PCIe 

arquitetura

Fig

este cluster

ução  dos 

amento AG

para downs

Conclusõ

pesar das se

destacadas c

foco em [1

m mostrad

ters  estão  d

unicação e 

rente do ass

m  [25], é p

rente do pro

e o FPGA é 

ess 8x. Com

2.0 alcança

8x pode ch

a deste trab

gura 5 ‐ A arqu

r a interface

algoritmos

GP x8, que s

stream e de

es

emelhanças

como forma

19] é desen

os  usando 

difundidos 

interconexã

sociado a es

possível per

oposto ness

feita atravé

m  isto, é po

a uma veloc

egar a 2000

balho é mos

uitetura do clu

e MPI foi us

.    A  comu

só consegue

e 133 MB/s

s com os tra

a de entend

volver um 

cluster  de 

no mercad

ão próprias

ste trabalho

ceber que 

se trabalho.

és de uma U

ossível  tent

cidade de tr

0 Mbps [29]

strada na Fig

uster de GPU 

sada para tr

unicação  e

e uma velo

para upstre

abalhos apr

der o objetiv

cluster ape

PCs  com 

o,  porém  u

s, fazendo c

o. 

existem nó

. Outra dife

USB 2.0 e ne

tar um aum

ransmissão 

]. 

gura 5. 

mostrando ap

ransferir da

entre  PC  e

cidade de t

eam. 

resentados,

vo da elabo

nas de FPG

FPGAs  com

usam  barra

com que o s

ós no  cluste

erença é vist

esse projeto

mento de d

de até 480

 

penas um nó[2

ados entre a

GPU  é  fe

transmissão

algumas di

oração deste

GAs, porém 

mo  co‐proce

mentos  co

seu uso ger

er que não 

ta na comu

o é usado o

esempenho

0 Mbps [24]

27]. 

a rede dura

eita  atravé

o de 2.1 GB

iferenças po

e trabalho. 

vários trab

essadores, 

om  interface

re um custo

possuem F

nicação ent

o barrament

o  visto que

], enquanto

24 

ante a 

és  do 

B/s de 

odem 

balhos 

estes 

es  de 

o alto, 

FPGA, 

tre os 

to PCI 

 uma 

o uma 

 

25  

  O trabalho em [27], embora não utilize FPGAs como co‐processadores, mas GPUs é 

uma  das  soluções  em  destaque  em máquinas  de  alto  desempenho  computacional. 

Trabalhos  atuais  como  [28][26]  demonstram  que    GPUs  conseguem  melhor 

desempenho  que  os  FPGAs  em  várias  aplicações,  sem  customizações,  quando 

considera‐se  métricas  como  quantidade  de  operações  realizadas  por  segundo.  No 

entanto,  em  ambientes  customizados,  e  como novas métricas de desempenho, que 

levam  em  conta  também  fatores  como  espaço  e  dissipação  de  potência,  como 

GFlops/W, observa‐se os FPGAs conseguem um melhor desempenho que as GPUs em 

diversas  aplicações.  Os  trabalhos  [28][26] mostram  isso.  Apesar  de  ser  um  estudo 

importante, abordagem com GPUs não fará parte do escopo desta dissertação. 

   

 

26  

3. Fundamentação Teórica Este  capítulo  visa  conceituar  elementos  usados  nesse  projeto,  voltados  para  o 

desenvolvimento de um cluster híbrido, com o uso de FPGAs como co‐processadores. 

Neste contexto serão abordados os recursos que possibilitam a implementação de 

um  cluster  como  este,  tanto  no  que  tange  aos  recursos  de  software  como  os  de 

hardware, quais sejam: 

• o uso do MPI para paralelização das aplicações e o uso de um barramento de alto 

desempenho;  

• elaboração  de  device  drivers  para  sistemas  operacionais,  para  que  os  usuários 

tenham mais autonomia para controlar seus sistemas;  

• unidade  de  hardware  reconfigurável  (FPGA).  Uma  visão  geral  de  sua  estrutura 

interna, recursos e ambiente de desenvolvimento. 

3.1 Message Passing Interface

Message Passing é um paradigma muito usado em certas classes de máquinas que 

trabalham  paralelamente,  especialmente  aquelas  com memória  distribuída.  Embora 

existam muitas variações, o conceito básico de processadores se comunicando através 

de  mensagens  é  bem  conhecido.  No  passar  dos  últimos  dez  anos,  progressos 

substanciais vêm ocorrendo para  incluir aplicações significantes para este paradigma. 

Cada  fabricante  tem  desenvolvido  a  sua  própria  variação,  e  recentemente, muitos 

sistemas  têm  demonstrado  que  o  message  passing  pode  ser  bem  eficiente 

[25][26][27]. 

Na  direção  de  se  criar  um  padrão  para  comunicação  de  dados  em  computação 

paralela,  foi criada a  interface Message Passing  Interface ou MPI, através do esforço 

de  várias  pessoas  e  organizações  [14].  As  principais  vantagens  do  estabelecimento 

deste  padrão  são  a  portabilidade  e  a  facilidade  de  seu  uso.  Em  um  ambiente  de 

comunicação de memória distribuída, no qual o alto nível de  rotinas e abstrações é 

construído  através  de  rotinas  de  troca  de mensagens  de  baixo  nível,  os  benefícios 

desta  padronização  são  evidentes. O  objetivo  principal  desta  interface  é  permitir  o 

desenvolvimento  de  um  padrão,  de  uso  abrangente,  para  escrita  de  programas  de 

 

27  

trocas  de mensagens  entre  nós  em  uma  rede  de  computadores,  estabelecendo  um 

padrão prático, portável, eficiente e flexível para esta troca. 

Este padrão permite também: 

• projetar  interfaces  para  a  programação  de  aplicações  (não  necessariamente 

para compiladores ou bibliotecas); 

• estabelecer uma comunicação eficiente: evitar cópia memória‐para‐memória, e 

permitir overlap de computação e comunicação; 

• permitir que implementações possam ser usadas em ambientes heterogêneos; 

• definir  uma  interface  que  possa  ser  desenvolvida  em  várias  plataformas  de 

fabricantes  diferentes,  sem  mudanças  significativas  na  comunicação  e  no 

software do sistema. 

Este padrão tem a pretensão de ser usado por todos aqueles que queiram escrever 

programas escritos em Fortran, C ou C++.  

Programas que usam este padrão devem  ser executados em multiprocessadores 

com  memória  distribuída,  estações  de  trabalho  conectadas  em  uma  network  ou 

combinações  destes.  Neste  contexto,  é  possível  também  implementações  com 

memória  compartilhada.  O MPI  é  apropriado  para  ser  usado  em  estruturas MIMD 

(Multiple  Instructions Multiple Data)  [42], bem como, aqueles escritos no estilo mais 

limitado do SPMD (Simple Program Mutiple Data) [42]. 

 

3.1.1 Convenções e Termos do MPI

  Procedimentos  MPI  são  especificados  usando  uma  notação  de  linguagem 

independente. Os argumentos de chamada são marcados como IN, OUT ou INOUT. O 

significado disto  são que  a  chamada usa, mas não  atualiza um  argumento marcado 

como IN, que representa um dado de entrada; a chamada deve atualizar argumentos 

marcados  como  OUT,  que  são  argumentos  de  saída.  A  chamada  tanto  usa  quanto 

atualiza um argumento marcado como  INOUT, que representa parâmetros que tanto 

são de entrada quando de saída. 

  Quando se fala de procedimentos MPI os seguintes termos semânticos são usados: 

• Nonblocking  –  Uma  rotina  de  comunicação  é  dita  “não‐bloqueante”  se  a 

chamada  retorna,  sem  esperar,  qualquer  evento  que  indique  o  fim  ou  o 

 

28  

sucesso da rotina.  Isso caracteriza uma comunicação assíncrona. Desta forma, 

não se espera pela cópia de mensagens do “application buffer” para o “system 

buffer”,  ou  a  indicação  do  recebimento  de  uma  mensagem.  É  da  inteira 

responsabilidade do programador a certeza de que o “application buffer” esteja 

disponível  para  ser  reutilizado.  Este  tipo  de  comunicação  é  utilizado  para 

melhorar a relação entre computação e comunicação para efeitos de ganho de 

desempenho. 

• Blocking  –  Uma  rotina  é  dita  “bloqueante”  quando  a  finalização  de  uma 

chamada precisar de determinados eventos. Por exemplo, um dado precisa ser 

enviado com sucesso, ou ter sido armazenado no buffer do sistema informando 

que o endereço do buffer da aplicação pode ser utilizado novamente. Em uma 

rotina  de  recepção,  a mensagem  deve  ser  armazenada  no  “system  buffer”, 

indicando que pode ser utilizada. A comunicação “bloqueante” é considerada 

síncrona. 

• Local  –  Se  o  término  do  processo  depender  somente  do  processo  que  está 

sendo executado localmente. 

• Non‐local – Se o  término do processo requerer a execução de alguma  função 

MPI em outro processo. 

• Collective – Se todos os processos de um grupo de processo precisar invocar o 

procedimento. 

 

3.1.1.1 Tipos de Argumentos em MPI 

  O MPI gerencia a memória do  sistema que é usada para bufferizar mensagens e 

para  armazenar  representações  internas  de  vários  objetos  MPI,  como  grupos, 

comunicadores,  tipos  de  dados,  entre  outros.  Esta  memória  não  é  diretamente 

acessível  ao  usuário,  e  objetos  armazenados  nela  são  opacos;  seus  tamanhos  e 

formatos  não  são  visíveis  para  o  usuário.  Estes  objetos  são  acessados  através  de 

handles,  que  existem  no  espaço  do  usuário  e  são  alocados  e  desalocados  por 

chamadas  que  são  especificadas  para  cada  tipo  de  objeto.  Juntamente  com  seu 

handle,  eles  são  apenas  significantes  em  processos  onde  o  objeto  foi  criado,  e  não 

podem ser transferidos para outro processo. 

 

29  

    MPI provê handles constantes pré‐definidos, como MPI_COMM_WORLD, que é 

um  handle  para  um  objeto  que  representa  todos  os  processos  disponíveis  na 

inicialização do sistema e permite a comunicação entre eles. Objetos opacos acessados 

por handles constantes são definidos e não mudam de valores entre a inicialização do 

MPI (chamada do MPI_INIT) e o término do MPI (chamada do MPI_FINALIZE). 

     Procedimentos MPI atribuem também um significado especial a tipos básicos de 

argumentos, como tag, um argumento  inteiro de operações de comunicação ponto a 

ponto, com um valor especial denominado MPI_ANY_TAG. 

 

3.1.1.2 Processos 

  Um  programa  MPI  consiste  de  um  conjunto  de  processos  autônomos,  não 

necessariamente  idênticos, em um estilo MIMD. Estes processos, que podem  ser do 

tipo sequencial ou multi‐threaded, se comunicam através de chamadas para primitivas 

de  comunicação  MPI  e  tipicamente  são  executados  em  seu  próprio  espaço  de 

endereçamento, com ou  sem memória compartilhada. Além disso, os processos não 

possuem  uma  alocação  prévia  para  sua  execução,  o  que  deve  ser  feito  pelos 

fabricantes em  tempo de  compilação ou execução. Também, o MPI é um protocolo 

tipo  thread‐safe,  isto  é,  evita  o  uso  de  estados  implícitos  e  a  interface  funciona 

corretamente durante a execução simultânea por vários threads. 

  Tais  mecanismos  permitem  a  especificação  do  número  inicial  de  processos,  o 

código a ser executado por cada um deles e a alocação destes nos processadores do 

cluster.  Cada  um  destes  processos  é  também  identificado  de  acordo  com  seu  rank 

relativo, dentro de um grupo, ou seja, inteiros consecutivos que variam desde zero até 

(tamanho_do_grupo ‐ 1). 

 

3.1.2 Comandos de Comunicação Ponto a Ponto

Esses  comandos  são  usados  quando  dois  processos  precisam  se  comunicar 

diretamente, o que caracteriza uma comunicação ponto a ponto. Para cada envio de 

dados de um ponto a outro no cluster deve haver sempre o  respectivo comando de 

recepção, para que nenhuma mensagem seja perdida. 

 

 

A

proce

e

A

MPI 

pode

O

comu

recei

as do

A

N

coun

most

ident

que c

dent

garan

D

usad

Antes do us

esso de com

e a limpeza 

Após sua ch

poderá  ser

erão ser usa

O envio e o

unicação M

ive. Existem

o tipo block

A função sen

int M

Nesta  funçã

nt  é  o  núm

tra  para  qu

tificação e c

consegue e

ro  de  um  c

ntir uma co

Datatype  é 

os, em C, n

so de qualq

municação, 

de todos os

hamada, nen

r utilizada, 

adas após a 

o  recebimen

MPI. Para  iss

m, de fato, v

king, descrit

nd possui a 

MPI Send(v

ão, o parâm

ero  de  ele

ual  nó  será

comm é o c

nxergar um

comunicado

omunicação

o  tipo  de 

este argum

quer  rotina 

torna‐se ne

int MPI Init

s seus estad

int 

nhuma roti

ou  seja, as

chamada d

nto de men

so, são utili

ários tipos 

as em deta

seguinte si

void* buf, in

int tag

metro buf é

mentos  co

á  enviada  a

comunicado

m ao outro.  

or. O MPI 

confiável e

dado  com

mento são m

Figura 6 ‐ V

MPI, proce

ecessário a 

t(int *argc, 

dos através 

MPI Finaliz

na que util

s  funções d

da MPI Final

nsagens por

izadas as ro

de rotinas s

lhes a segu

ntaxe: 

nt count, MP

g, MPI Com

é o endereç

ntidos  no  b

a  informaçã

or, o qual c

No MPI as 

usa  essa  co

e segura de 

m  que  está

mostrados n

Valores para o

esso de  inic

chamada d

char ***ar

da função:

ze(void); 

iza as funçõ

e envio e  r

lize. 

r processos

otinas básic

send e recei

ir. 

PI Datatype

m comm);

ço  inicial do

buffer,  dest

ão,  tag  é  a

consiste em

mensagens

ombinação 

mensagens

  sendo  tra

a Figura 6.

o DataType 

cialização,  t

a função: 

rgv); 

ões definida

recebiment

s é o mecan

cas de com

ive, porém 

 datatype, i

o buffer qu

t  é  o  rank 

apenas  uma

um conjun

s só podem 

de  grupo  e

s entre os p

abalhado.  P

 

tais  como a

as pela inte

to de dados

nismo básic

unicação se

os principa

int dest, 

ue  será env

do  destino

a mensage

nto de proc

ser transm

e  contexto

rocessos. 

Possíveis  va

30 

as do 

erface 

s não 

co de 

end e 

is são 

viado, 

o  que 

m  de 

essos 

itidas 

para 

alores 

 

31  

Além da parte de dados, mensagens como essa carregam informações que podem 

ser  usadas  para  distinguir mensagens  e  recebê‐las  seletivamente.  Esta  informação 

consiste em um número  fixo de campos, conhecido como “envelope de mensagem”, 

quais sejam: source, destination, tag e communicator. Os campos source e destination 

determinam  implicitamente  a  identidade  de  quem  está  enviando  e  de  quem  deve 

receber a mensagem. Os demais campos são similares aqueles já mencionados acima. 

Um  outro  componente  denominado  de  comunicador,  o   MPI_COMM_WORLD  é 

também provido pelo MPI. Este componente permite a comunicação entre  todos os 

processos  que  são  acessíveis  após  a  inicialização  do  MPI  e  a  identificação  dos 

processos através do rank. 

A rotina responsável pelo recebimento de dados é denominada de blocking receive 

e possui a seguinte sintaxe: 

int MPI Recv(void* buf, int count, MPI Datatype datatype, int source, 

int tag, MPI Comm comm, MPI Status *status); 

Nesta  especificação  de  chamada,  o  campo  buffer  de  recebimento  consiste  dos 

count  elementos  consecutivos  do  tipo  especificado  pelo  datatype,  começando  no 

endereço buf. O tamanho da mensagem recebida deve ser menor ou igual ao tamanho 

do buffer de recebimento. 

O processo recebedor pode especificar o source com o valor MPI_ANY_SOURCE e 

MPI_ANY_TAG para tag, indicando que qualquer fonte e/ou tag são aceitáveis. Caso os 

valores  sejam  diferentes,  é  necessário  especificar  o  rank  do  grupo  de  processo 

associado com o mesmo comunicador. 

 

3.1.3 Gerenciamento dos Comunicadores 

Operações  que  acessam  os  comunicadores  são  locais  e  suas  execuções  não 

necessitam  de  comunicação  entre  os  processos.  No  entanto,  operações  que  criam 

comunicadores  são  coletivas  e  requerem  uma  comunicação  entre  processos.  Essas 

funções são as operações locais: 

int MPI Comm size(MPI Comm comm, int *size); 

int MPI Comm rank(MPI Comm comm, int *rank); 

int MPI Comm compare(MPI Comm comm1,MPI Comm comm2, int *result); 

 

32  

Na primeira função, o parâmetro *size representa o número de processos no grupo 

de  comm, que  é o handle do  comunicador. Na  segunda  função, o parâmetro *rank 

representa o rank do processo que está sendo chamado no grupo de comm.  Na última 

função, o parâmetro *result retorna MPI_IDENT caso comm1 e comm2 sejam handles 

para o mesmo objeto  (grupos  idênticos e mesmo contexto);   MPI_CONGRUENT, caso 

sejam  iguais  seus  constituintes  e  também  a  ordem  do  rank; MPI_SIMILAR,    se  os 

membros  do  grupo  forem  os  mesmos,  porém  com  rank  diferentes;  ou  ainda,  

MPI_UNEQUAL nos demais casos. 

 

3.2 Linux e Device Drivers

Linux é o  termo  geralmente usado para designar qualquer  sistema operativo ou 

sistema  operacional  que  utilize  o  núcleo  Linux.  Este  adota  a  GPL,  uma  licença  de 

software livre – o que significa, entre outras coisas, que todos os interessados podem 

usá‐lo e redistribuí‐lo, nos termos da licença. 

O  Linux  é  um  núcleo  monolítico:  as  funções  do  núcleo  (escalonamento  de 

processos, gerenciamento de memória, operações de entrada/saída, acesso ao sistema 

de arquivos) são executadas no espaço de núcleo. Uma característica do núcleo Linux é 

que algumas das funções (drivers de dispositivos, suporte à rede, sistema de arquivos, 

por exemplo) podem ser compiladas e executadas como módulos, que são bibliotecas 

compiladas separadamente da parte principal do núcleo e que podem ser carregadas e 

descarregadas após o núcleo estar em execução. 

Uma das principais vantagens de um sistema operacional como o Linux, é de que 

seus  módulos  internos  estão  disponíveis  a  todos  aqueles  que  desejam  vê‐los.  O 

conceito  de  open‐source  permite  que  estes  módulos,  para  uma  dada  instalação 

possam  ser  examinados,  entendidos  e  modificados.  O  Linux  tem  ajudado  na 

democratização  dos  sistemas  operacionais,  porém  possui  um  complexo  e  extenso 

conjunto  de  códigos,  na  sua  maioria,  escritos  utilizando  a  linguagem  C.  Por  isto, 

aqueles que desejam  inserir  funcionalidades  ao  seu  kernel,  sem  se  sentir oprimidos 

pela  complexidade  já  existente,  precisam  de  um  ponto  de  entrada  no  mesmo, 

fornecido pelos device drivers [30]. 

 

33  

Os device drivers são “caixas‐pretas” que fazem um hardware específico responder 

a uma bem definida  interface  interna de programação e escondem, completamente, 

detalhes  de  como  estes  dispositivos  funcionam. Atividades  e  aplicações  criadas  por 

usuários  são  executadas  através  de  um  conjunto  de  funções  padronizadas,  que  são 

independentes  de  um  driver  específico;  mapear  essas  funções  em  operações  que 

atuam em um dispositivo de hardware é o papel dos device drivers.  

A  interface  de  programação  é  feita  de  tal  forma  que,  os  drivers  possam  ser 

construídos separadamente do resto do kernel e, depois, serem inseridos, no mesmo, 

em tempo de execução, quando necessário; tornando o trabalho de desenvolvimento 

de device drivers mais fácil. 

A  inclusão  ou  atualização  de  um  novo  dispositivo  de  hardware  requer  o 

desenvolvimento  de  novos  device  drivers  para  dar  suporte  as  suas  características 

específicas  no  sistema  operacional  em  operação.  Como  quase  todos  os  sistemas 

operacionais,  eventualmente, mapeiam  dispositivos  físicos,  surgiu  a  necessidade  da 

criação  de  mecanismo  que  identifiquem  estes  dispositivos  e  tenham  informações 

precisas sobre suas interfaces, operações, controle, entre outras. Este mecanismo, em 

forma de código, é chamado de device driver, e podem ser vistos como uma camada 

de software entre a aplicação e os dispositivos de hardware.  

Em um sistema operacional, diversos processos, gerenciados pelo seu kernel, são 

responsáveis  por  diferentes  tarefas  e  requisitam  muitos  recursos  do  sistema,  tais 

como: poder computacional, memória, conectividade de rede, entre outros. As tarefas 

do kernel são distribuídas conforme mostra a Figura 7. Nesta, é possível perceber que 

os  devices  drivers  abstraem  para  o  usuário  toda  a  interface  do  hardware  e  kernel, 

facilitando a implementação de controle para dispositivos externos. 

 

 

D

habil

ofere

ou re

ao ke

mód

que 

desli

 

3.2.

O

deno

mód

mód

mod

M

defin

Dentro do c

lidade  de 

ecidas pelo 

emovidas e

ernel é deno

ulos, inclus

pode  ser d

gado atravé

1 Classes 

O Linux enx

ominados  c

ulos não é 

ulo que imp

ularidade, f

Mais  especi

nidos: 

contexto de

aumentar, 

seu kernel.

nquanto o 

ominado de

ive para de

dinamicame

és do rmmo

de Dispos

erga dispos

char  modu

rígida e os

plementa m

fazendo com

ificamente,

Figura 7 ‐ As d

este trabalh

em  tempo

. Entre outr

sistema est

e “módulo”

evice drivers

ente  conect

od [30]. 

sitivos e M

sitivos atrav

le,  block  m

s programa

mais de um 

m que as po

os  três  ti

diferentes tare

ho, a utilizaç

o  de  execu

ras, novas fu

tiver em op

. O Linux fo

s. Cada mód

tado ao ker

Módulos

vés dos mó

module  ou

adores pode

tipo. Este p

ossibilidade

pos  de  dis

efas do kerne

ção do Linu

ução,  o  co

uncionalida

peração. Ca

ornece supo

dulo é com

rnel, atravé

dulos que i

  network

em escolhe

procedimen

s de seu reu

spositivos  d

l. 

ux permite 

njunto  de 

des podem

da novo có

rte para dif

posto de u

s dos prog

mplementa

module.  E

er em  const

to pode, po

uso diminua

do  Linux  po

 

um aumen

funcionalid

m ser adicion

ódigo adicio

ferentes tip

m código o

gramas  insm

am um dos 

sta  divisão

truir um  gr

orém reduz

am. 

odem  ser  a

34 

to da  

dades 

nadas 

onado 

os de 

objeto 

mod e 

tipos 

o  dos 

rande 

ir sua 

assim 

 

35  

• Character  (Char)  Devices  –  são  dispositivos  que  podem  ser  acessados  como 

uma  stream  de  bytes  (como  um  arquivo);  neste  caso,  um  char  driver  é 

encarregado  de  implementar  esse  comportamento.  Este  driver  implementa, 

pelo menos, funções básicas como: open, close, read e write. As portas seriais 

são exemplos de  char devices,  já que  são  representadas pela a abstração de 

stream. 

• Block Devices  ‐  estes  são  dispositivos  que  podem  armazenar  um  sistema  de 

arquivos.  Na  maioria  dos  sistemas,  o  block  device  só  é  responsável  por 

operações de E/S que transferem um ou mais blocos, cada um possuindo 512 

bytes.  O  Linux,  no  entanto,  permite  a  aplicação  ler  ou  escrever  qualquer 

número de bytes. Como resultado, block e char devices diferem na maneira de 

como os dados são manipulados internamente pelo kernel, mas possuem uma 

interface completamente diferente uma da outro. 

• Network devices ‐ estes dispositivos consistem em interfaces de redes que são 

responsáveis por transmitirem e receberem pacotes de dados que estão sob o 

controle do subsistema de rede do kernel, sem ter conhecimento de como as 

transações de rede estão mapeadas nesses pacotes. Diferentemente dos char e 

block devices, os network devices não são acessados como se fossem arquivos. 

Existem  outras maneiras  de  classificar  os módulos  que  são  ortogonais  aos  tipos 

descritos  acima. Por exemplo, pode‐se  falar em módulos Universal  Serial Bus  (USB), 

seriais,  SCSI,  entre  outros.  Por  exemplo,  todo  dispositivo USB  é  controlado  por  um 

módulo USB que trabalha com um subsistema USB, porém o dispositivo se mostra no 

sistema  como  um  char  device  (uma  porta  USB),  ou  um  block  device  (um  leitor  de 

cartão de memória) ou um network device (uma interface USB Ethernet). 

 

3.2.2 Char Drivers

Como  dito  anteriormente,  os  char  drivers  são  responsáveis  por  controlar 

dispositivos como arquivos que são representados por stream de bytes. Abaixo, segue 

uma descrição mais detalhada sobre char drivers. 

 

36  

3.2.2.1 Os números Major e Minor 

Char Drivers são drivers acessados através de seus nomes no sistema de arquivo. 

Estes nomes são chamados de arquivos especiais, arquivo de dispositivos ou ainda nós 

da árvore do sistema de arquivos e estão localizados, convencionalmente, no diretório 

/dev do  sistema de arquivos do  Linux. Estes drivers  são  identificados por um  “c” na 

primeira coluna da saída da chamada da função ls ‐l, como mostrada na Figura 8. Block 

devices também aparecem no diretório /dev, porém são identificados por um “b”. 

Os números major e minor são representados por números, separados por vírgula, 

um par para cada dispositivo específico. O major  identifica o driver associado a cada 

dispositivo, podendo múltiplos drivers compartilhar o mesmo major. O minor é usado 

pelo kernel para determinar, exatamente, qual dispositivo está sendo referenciado. Na 

primeira linha da figura 8, por exemplo, o parâmetro major vale 1 e o minor 3. 

 Figura 8 ‐ Representação do sistema de arquivo. 

Dentro do kernel, o tipo dev_t (definido em <Linux/types.h>), de 32 bits, dos quais 

12 representam o major e os outros 20, o minor, é gerado a partir da função MKDEV 

(int major, int minor). 

Os valores major e minor são obtidos através da função: 

int register_chrdev_region(dev_t first, unsigned int count, char *name); 

Nesta  função,  first  representa  o  número  (o  major  e  o  minor)  do  primeiro 

dispositivo; geralmente, o minor do primeiro dispositivo é zero. O count é o número 

total de dispositivos que se deseja alocar. Por  fim, o parâmetro *name  representa o 

nome  que  será  associado  a  esses  números,  e  que  será  apresentado  no  diretório 

/proc/devices. 

Esta função funciona bem caso  já se saiba, previamente, os números que se quer 

alocar  para  o  dispositivo.  Caso  contrário,  quando  se  deseja  que  o  kernel  aloque  os 

números em tempo de execução, é necessário o uso da função: 

 

37  

int alloc_chrdev_region(dev_t *dev, unsigned int firstminor, unsigned int count, char 

*name); 

Neste caso, *dev é um parâmetro de saída que irá guardar os números do primeiro 

dispositivo,  firstminor é o minor do primeiro dispositivo,  count é o número  total de 

dispositivos que  se deseja  alocar e  *name é o nome que  será  associado  com  esses 

números. 

A grande vantagem de se utilizar a alocação dinâmica é que o driver desenvolvido 

se torna mais portável, podendo ser inserido em qualquer sistema, sem a preocupação 

de se utilizar um major já existente. 

Independente  da maneira  como  os  números  dos  dispositivos  foram  alocados,  é 

necessário  liberá‐los  quando  não  estão mais  sendo  usados.  Isto  é  feito  através  da 

chamada de função: 

void unregister_chrdev_region(dev_t first, unsigned int count); 

Nesta  função, parâmetros  são usados de  forma  igual às duas  funções mostradas 

anteriormente. 

 

3.2.2.1 Estruturas de Dados do Kernel Como  se  pode  imaginar,  a  associação  dos  números  major  e  minor  para  um 

dispositivo  é  apenas  uma  das muitas  tarefas  que  o  desenvolvimento  de  um  driver 

requer.  Muitas  das  operações  fundamentais  do  driver  dependem  ainda  de  três 

estruturas de dados existentes no kernel, chamadas de file operations, file e inode. 

 

3.2.2.2.1 File Operations Após  reservar os números do dispositivo, é necessário conectar as operações do 

driver a esses números. A estrutura  file operations, definida em <Linux/fs.h>, possui 

esta função e consiste em um conjunto de ponteiros para funções. As operações estão 

normalmente  encarregadas  de  implementar  as  chamadas  de  sistema,  como  read, 

write, open, entre outras. A Figura 9 representa um pequeno exemplo da estrutura file 

operations.  

 

 

A

a seg

Algumas das

guir: 

• struc

que c

retira

macr

inicia

• int  (

exec

inicia

pode

corre

• int (*

o  dr

aloca

• int  (*

funçã

drive

estar

• ssize_

Esta 

repre

serve

algum

trans

posiç

s principais

ct module *

contém a e

ado  do  ker

ro  THIS_M

alizar o cam

(*open)  (st

utada no d

adas as vari

em  ser  fe

etamente. 

*release) (st

river  é  fec

ados na fun

*ioctl)  (stru

ão  fornece

er.  Alguns 

rem na tabe

e_t  read(str

função  é 

esenta  a  e

e  como  um

m  na  comp

sferida  e  o

ção  a  estru

Figura 9 ‐ Es

 funções de

owner – Est

strutura. Es

rnel  enquan

ODULE,  de

mpo. 

truct  inode 

driver. Nela 

iáveis e  inic

itos  para 

truct inode 

hado  pela 

ção open e

uct  inode *, 

  um  canal 

comandos 

ela da estru

uct  file *fil

usada  pa

strutura  qu

ma  espécie 

pilação,  o  c

o  ponteiro 

utura  file  (u

strutura do fil

efinidas na 

te campo re

ste campo é

nto  as  ope

efinida  em 

*,  struct 

é alocada a

ciado o disp

garantir  q

*, struct file

aplicação.

 o dispositiv

 struct  file 

de  comun

como  ioct

utura file op

lp,  char  __u

ara  ler  dad

ue  contém

de  docum

count  repre

offp  repre

um  arquivo

le operations

estrutura f

epresenta  u

é usado par

erações  ain

<Linux/mo

file  *)  –

a memória 

positivo con

que  o  disp

e *) – Esta f

.  Nela  são

vo desativa

*, unsigned

nicação  ent

tl  são  reco

erations. 

user  *buff,s

dos  no  dis

  o  file_ope

entação  do

esenta  a  q

esenta  um 

o)  será  ace

file operatio

um ponteiro

ra prevenir 

da  estão  s

odule.h>  é 

Esta  é  a  p

para a estr

ntrolado pe

positivo  es

função é ex

desalocad

do. 

d  int, unsign

tre  a  aplica

nhecidos  p

size_t  coun

spositivo.  O

erations,  a 

o  código,  n

uantidade 

offset  indi

essada.  O  r

 

ons são des

o para o mó

o módulo d

sendo  usad

utilizada   

primeira  fu

rutura de d

elo driver. T

stá  funcion

xecutada qu

dos  os  rec

ned  long) –

ação  e  o  d

pelo  kernel

nt,  loff_t *o

O  ponteiro

diretiva  _

ão  tendo  e

de  dados 

icando  em 

retorno  ind

38 

critas 

ódulo 

de ser 

as.  A 

para 

unção 

ados, 

Testes 

nando 

uando 

ursos 

– Esta 

device 

l  sem 

offp)  ‐ 

o  filp 

_user 

efeito 

a  ser 

qual 

dica  a 

 

39  

quantidade de bytes lidos ou escritos. O ponteiro buff é um ponteiro criado 

na camada de aplicação, ou seja, no espaço do usuário fora do kernel. 

• ssize_t write(struct  file *filp,  char __user *buff,size_t  count,  loff_t *offp)  ‐ 

Esta função é usada para escrever dados no dispositivo. Os parâmetros são 

usados da mesma forma da função read, mostrada anteriormente. 

 

3.2.2.2.2 A Estrutura file 

Definida em <Linux/fs.h>, a estrutura  file é a  segunda estrutura mais  importante 

usada em device drivers. Esta estrutura não possui nenhuma relação com o ponteiro 

FILE  usado  em  aplicações  no  espaço  do  usuário.  Se  por  um  lado,  o  ponteiro  FILE, 

definida na biblioteca da linguagem C, nunca aparece no código do kernel; a estrutura 

file nunca aparece no código da camada de aplicação. 

A estrutura  file  representa um arquivo aberto. Este arquivo é  criado pelo  kernel 

após a chamada da  função open e passado para qualquer  função que manipula essa 

estrutura, até a chamada da função close.  

A estrutura file possui vários campos que não serão detalhados neste trabalho. O 

campo mais  importante  corresponde  a  uma  estrutura  file_operations  que  guarda  o 

mapeamento das funções desta estrutura, como explicado na seção anterior. 

 

3.2.2.2.3 A Estrutura inode Esta estrutura é usada internamente pelo kernel para representar arquivos, e pode 

conter  várias  estruturas  file  em  um  único  arquivo,  todas  apontando  para  o mesmo 

inode. 

Há  dois  campos  na  estrutura  inode  que  são  de  interesse  do  desenvolvedor  de 

device drivers: 

• dev_t i_rdev ‐ para inodes que representam arquivos de dispositivos (ou seja 

arquivos que representam o device driver do dispositivo), este campo guarda 

os números do dispositivo  (major e o minor). 

• struct cdev *i_cdev ‐ A estrutura cdev é uma estrutura interna do kernel que 

representa  os  char  devices.  Quando  o  inode  representa  um  arquivo  de 

dispositivo, esse campo possui um ponteiro para a estrutura cdev. 

 

40  

3.2.2.3 Registrando um char driver   Para que o kernel possa fazer uso das operações do dispositivo é preciso registrar 

o  char  device  no mesmo.  Para  que  isso  seja  possível  inclui‐se  as  seguintes  funções 

definidas em <Linux/cdev.h>: 

• void cdev_init(struct cdev *cdev, struct file_operations *fops) ‐ Esta função 

associa o char device à estrutura file_operations. 

• int cdev_add(struct cdev *dev, dev_t num, unsigned int count) ‐ Esta função 

informa  ao  kernel  a  que  números  de  dispositivo  (major  e  minor)  está 

associado o char device. 

• void cdev_del(struct cdev *dev)  ‐ Responsável por  remover o char device 

do kernel. 

 

3.3 Barramento PCI e seus Drivers

Usado para fazer a comunicação entre dois ou mais elementos de um computador, 

o barramento nada mais é do que um conjunto de sinais digitais, composto por vias de 

dados e controle, que possibilita a troca de  informações entre processador (CPU) e o 

mundo exterior. Ou seja, permite que a CPU possa se comunicar com diversas placas 

controladoras  de  dispositivos  periféricos,  memórias,  entre  outros.  Logo,  um 

barramento é um “caminho” através do qual os dados transitam entre componentes 

em um computador. 

Um barramento caracteriza‐se em termos do número de bits de endereço e dados, 

se estes trafegam de forma seqüencial ou paralela, etc. Em geral, em sistemas de alto 

desempenho, estes barramentos  são paralelos e possuem uma  largura de 32 ou 64 

bits, multiplexados ou não,  para envio e recebimento de endereço e/ou dados. Outro 

elemento  importante é a velocidade de  transferência destes dados,  fator primordial 

para  a  análise de desempenho do barramento Nos  sistemas  atuais o processador é 

mais rápido que o barramento, representando, assim, um gargalo no desempenho dos 

sistemas. 

O número máximo de dispositivos que podem ser conectados a um barramento é, 

da mesma maneira,  tão  importante quanto o desempenho do mesmo. Barramentos 

mais atuais podem tolerar um grande número de dispositivos ligados a eles. 

 

41  

Desde o aparecimento do primeiro PC, em 1981, e até ao tempo presente, vários 

tipos  de  barramentos  foram  desenvolvidos  para  permitir  uma melhor  comunicação 

entre o processador e os vários periféricos de I/O, tais como: 

• ISA – Industry Standard Architecture, definido pela IBM para o PC_AT e adotado 

por toda a indústria, tendo sido um dos mais difundidos e utilizados; 

• MCA – Micro Channel Architecture, definido pela IBM para sistemas PS‐2; 

• VLB – VESA Local Bus; 

• PCI – Peripheral Component Interconnect; 

• AGP – Accelerated Graphic Port; 

• USB – Universal Serial Bus; 

• PCI  e  PCI‐X  –  Peripheral  Component  InterConnect  e  Peripheral  Component 

InterConnect Extended; 

• PCIe – Peripheral Component InterConnect Express; 

Em 2004, a  Intel decidiu  introduzir no mercado outro padrão de slots para placas 

de  expansão  utilizadas  em  PCs,  para  substituir  os  padrões  AGP  e  PCI,  o  qual  foi 

denominado de PCIe (PCI Express). 

 

3.3.1 Barramento PCI Express

O padrão PCI surgiu no início da década de 1990 e, por mais de 10 anos [29], foi o 

barramento  mais  utilizado  para  a  conexão  de  dispositivos  ao  computador, 

principalmente placas de vídeo, placas de som, placas de rede e placas de modem. O 

barramento PCI trabalha com 32 bits por vez na transferência de dados (mas há alguns 

slots  PCI  que  funcionam  a  64  bits),  o  que  permite  ao  padrão  atingir  a  velocidade 

(teórica) de até 132 MB por segundo. 

Como as aplicações em 3D exigem, cada vez mais, taxas de transferências maiores, 

o barramento AGP  foi  inserido no mercado, oferecendo velocidades que vão de 266 

MB por  segundo  (no padrão AGP  1x)  a  2128 MB por  segundo  (no padrão AGP  8x). 

Praticamente todas as placas‐mãe com suporte a AGP só possuem um slot desse tipo, 

já que este padrão é usado exclusivamente por placas de vídeo. 

O problema é que, mesmo oferecendo velocidades acima de 2 GB/s, a  indústria 

percebeu  que  o  slot  AGP  8x  não  suportaria  os  avanços  seguintes  em  aplicações 

 

 

gráfi

uso 

apes

aplic

proce

por c

N

traba

de  u

comp

vídeo

O

recep

entre

O

cas, não só

de  recurso

ar  do  AGP

ações  de  v

essamento 

conseguinte

Na  busca  d

alhou (e tra

um  padrão

putador em

o 3D. 

O  link PCI  E

pção, como

e dois comp

Os atributos

• O  lin

unid

rece

para

• Sinal

em u

tecn

que 

ó por  limita

s  que  a  te

P  ter  vanta

vídeo.  Acon

de  imagen

e a demand

de  uma  so

abalha) no b

o  que  prop

m si e um d

Express bás

o mostrado 

ponentes. 

s do link são

nk  básico  –

irecionais 

pção. O  clo

 alcançar u

lização de t

um dos níve

ologia do P

provê 2.5 G

ções na  tax

cnologia  nã

gens  basta

ntece  que 

ns, etc.,  tam

a por mais 

olução  par

barramento

porciona  al

ispositivo ‐

sico  é  const

na Figura 1

Figura 

o: 

–  O  link  P

implement

ock  é  emba

ma alta taxa

taxa – Uma

eis de sinali

PCI Express,

Gigabits/seg

xa de  trans

ão  suporta.

ante  razoáv

aplicações 

mbém evolu

vazão de da

a  esses  pr

o PCI Expres

ltas  taxas 

por exemp

tituído por 

10. Um link

10 ‐ Link PCI 

PCI  Express

tados  com

arcado  usan

a de dados.

a vez  inicial

ização supo

, existe ape

gundo/lane/

sferência de

.  Ainda,  é 

veis,  seu  u

de  áudio  e

uíram ao  lo

ados por se

roblemas, 

ss, cujo nom

de  transfe

plo, entre a 

dois pares

representa

Express 

consiste  e

o  os  pare

ndo  um  es

. 

izado, cada

ortados. Par

enas uma ta

/direção de

e dados, ma

necessário 

so  é  destin

e  redes  de

ongo destes

gundo. 

a  indústria

me inicial er

erência  de 

placa‐mãe 

s: o de  tran

a um canal 

em  dois  pa

es  de  tran

quema  de 

a  link deve 

ra a primeir

axa de sina

e largura de 

as  também

considerar

nado  apen

e  computad

s últimos a

a  de  tecno

ra 3GIO. Tra

dados  ent

e e uma pla

nsmissão  e 

de comunic

 

ares  difere

nsmissão 

codificação

somente o

ra sinalizaçã

lização def

 banda. 

42 

m pelo 

  que, 

as  às 

dores, 

nos e 

ologia 

ata‐se 

tre  o 

ca de 

o de 

cação 

nciais 

e  de 

o  [31] 

perar 

ão da 

inida, 

 

 

3.3.2

É

comp

 

• Lane

perm

cham

dois 

paco

cont

32). 

MB/

• Inicia

dispo

entre

pass

proto

softw

• Sime

lanes

sinai

 

2 A Estrut

É  compost

ponentes, u

es – A  tecn

mite  o  uso 

mados de la

pares de fi

otes nas du

er desde um

No padrão 

s para cada

alização – Q

ositivos estã

e  os  dispo

ar e “negoc

ocolo  que 

ware nem d

etria  –  Cad

s em cada d

is em cada d

tura do PC

to  por  lin

um exemplo

Figura 11 ‐

ologia utiliz

de  uma  o

anes) para t

os, um para

as direções

m até trinta

1.0, conseg

a lane, prete

Quando um

ão conecta

sitivos,  cria

cia” a largu

o  PCI  usa, 

do sistema o

a  link  deve

direção, ou 

direção. 

CI Express

nks  ponto‐

o é mostrad

‐ Exemplo da 

zada no PC

ou  mais  co

ransferênci

a enviar e o

s  simultane

a e dois lane

gue‐se uma 

ende‐se che

m computad

dos à placa

ando  um  m

ra de cada 

por  isto,  n

operacional

e  suportar 

seja, um lin

s

‐a‐ponto  q

da na Figura

topologia da 

CI Express  c

onexões  ser

ia de dados

outro para r

eamente. Fi

es, em potê

taxa de tra

egar a 1 GB/

dor é  iniciad

a mãe. Ele, e

mapeament

ligação. Est

não  é  prec

. 

um  número

nk x8 indica

que  interc

a 11. 

estrutura do P

conta  com 

riais  ("cami

. Cada lane 

receber dad

sicamente, 

ências de do

nsferência 

/s na versão

do, o PCIe d

então, iden

to  por  ond

ta identifica

iso  nenhum

o  simétrico

a que existe

onecta  um

 

PCI Express 

um  recurso

inhos",  tam

e é compost

dos, e trans

 os  slots po

ois (1, 2, 4, 

de dados d

o 3.0 

determina 

tifica as liga

de  o  tráfeg

ação é o m

ma mudanç

o  do  númer

em oito par

m  conjunto

43 

o que 

mbém 

to por 

porta 

odem 

8, 16, 

e 250 

quais 

ações 

go  irá 

esmo 

ça  do 

ro  de 

res de 

o  de 

 

44  

3.3.2.1 Root Complex Um  Root  Complex  (RC)  denota  a  raiz  de  uma  hierarquia  de  E/S  que  conecta  a 

CPU/memória aos dispositivos de entrada e saída. Como mostrado na Figura 11, a RC 

deve  suportar  uma  ou mais  portas  PCI  Express.  Cada  interface  define  um  domínio 

separado de hierarquia. O RC deve suportar a geração de requisições de configuração 

e de E/S. 

 

3.3.2.2 Endpoints Endpoints referem‐se a tipos de dispositivos que podem ser os que requisitam ou 

que recebem transações PCI Express, por exemplo, um controlador USB‐PCI Express. 

 

3.3.2.3 Switch É  definido  para  ligar  os  Endpoints  ao  RC.  Não  é  permitido  separar  pacotes  em 

tamanhos menores, ou seja, um pacote de 256 bytes não pode ser dividido em pacotes 

com menos de 128 bytes. 

 

3.3.2.4 PCI Express‐PCI Bridge Provê  a  conexão  entre  a  estrutura  PCI  Express  e  a  hierarquia  PCI/PCI‐X  e  deve 

obedecer todos os requisitos da especificação PCIe. 

 

3.3.3 Visão Geral das camadas do PCI Express Existem  três  camadas  lógicas  que  pode  ser  separada  para  um  melhor 

entendimento da especificação do PCI Express, são elas: Transaction Layer, Data Link 

Layer e Physical Layer, isto é mostrado na Figura 12. 

 

 

O

form

comp

nece

proce

cheg

 

3.3.3E

mont

comu

even

T

trans

respo

difer

(Mem

A

de e

Esta 

O PCI Expre

mados  na  T

ponentes  p

essárias info

esso revers

gar à Transa

3.1 TransEsta é a cam

tar  e  desm

unicar  tran

ntos. 

Todo pacote

sação de qu

osta  para  i

rentes  tipos

mória, E/S, 

A Transactio

ndereços P

é usada pa

F

ess usa paco

Transaction 

para  compo

ormações ad

so ocorre ao

action Layer

saction Lamada mais 

montar  os 

sações,  tan

e de requisi

uebra. Cada

r  diretame

s  de  forma

Configuraçã

on Layer su

CI (memóri

ra gerencia

Figura 12 – Dia

otes para tr

Layer;  e 

onentes.    C

dicionais pa

onde prime

r. 

ayer

superficial 

Transaction

nto  de  escr

ição que re

 pacote tem

nte  para  a

as  de  ende

ão e Mensa

porta quat

ia, E/S e co

r interrupçõ

agrama das ca

rocar  inform

no  Data  L

Como  os  p

ara tratá‐los

eiramente o

da arquite

n  Layer  Pa

rita  como  d

quer um de

m uma iden

a  origem  co

ereçamento

agem). Um e

ro espaços 

nfiguração)

ões e requis

amadas do PC

mações ent

Link  as  inf

acotes  vão

s corretame

os pacotes c

tura. Sua p

ackets  (TLP

de  leitura, 

e resposta é

tificação ún

orreta.  O  fo

o  dependen

exemplo é m

de endereç

) e adiciona

sições de ge

 

CIe 

re compon

ormações 

o  através  d

ente. No lad

chegam à Ph

primeira  res

s).  Estes  sã

e  também 

é implemen

nica que ha

ormato  do 

ndo  do  tip

mostrado n

ços:  isto  inc

a um espaço

erenciamen

nentes. Este

são  levada

de  camadas

do do recep

hysical Laye

sponsabilida

ão  usados 

certos  tipo

ntado como

bilita pacot

pacote  su

po  de  trans

a Figura 13

clui três esp

o de mensa

nto de energ

45 

es são 

as  de 

s,  são 

tor, o 

er até 

ade é 

para 

os  de 

o uma 

tes de 

porta 

sação 

. 

paços 

agem. 

gia. 

 

 

3.3.3E

e  a 

gere

erros

O

mont

núm

conti

chec

proce

retra

A

de ge

 

3.3.3E

drive

Locke

man

com 

3.2 Data LEsta é a cam

Physical 

nciamento 

s. 

O  lado da  t

tados pelo 

ero  de  seq

inuidade a 

ar  a  integr

essamento.

ansmissão d

A Data Link 

erenciamen

3.3 PhysicEssa  camad

er e buffers

ed  Loop). 

utenção da

um  forma

Link Laymada interm

Layer.  A 

do  link  e 

transmissão

Transaction

quência  TL

transmissão

ridade  dos 

.  Na  detec

do TLP até a

Layer tamb

nto do link.  

cal Layerda  inclui  to

s de entrad

Isto  inclui 

a  interface. 

to  especific

Figura 13 –

er

mediária, e s

primeira 

integridade

o da Data  L

n Layer, cal

P,  e  subm

o. O lado d

TLPs  e  de

cção  de  er

 informação

bém gera e

r

do  o  esque

da,  conversõ

também 

A Physical 

co,  esta  ca

Formato gen

serve como

responsab

e  dos  dado

Link  Layer a

lcula e aplic

mete  o  pac

e recepção

e  submetê‐

rros,  esse 

o se recebid

e consome p

emático  pa

ões paralel

funções  ló

Layer  troc

mada  é  re

érico do TLP

o um estágio

ilidade  da 

os,  incluind

aceita TLPs,

ca o código

cote  para  a

o da Data Li

los  para  a 

link  é  res

da corretam

pacotes que

ara  operaçõ

a‐serial e  s

ógicas  relac

a  informaç

sponsável 

o entre a Tr

Data  Lin

o  detecção

, explicados

o de proteçã

a  Physical 

ink Layer é 

Transactio

ponsável  p

mente. 

e são usado

ões  de  inte

serial‐parale

cionadas  à

ões com a 

por  conver

Transaction 

nk  Layer 

o  e  correçã

s anteriorm

ão de dado

Layer  para

responsáve

on  Layer  pa

por  requisi

os pelas fun

erface,  inclu

ela e PLLs(P

à  inicializaç

Data Link 

rter  informa

46 

 

Layer 

inclui 

ão  de 

mente 

os e o 

a  dar 

el por 

ara  o 

tar  a 

nções 

uindo 

Phase 

ção  e 

Layer 

ações 

 

47  

recebidas  da  Data  Link  em  um  formato  apropriado  e  transmite‐as  através  da  PCI 

Express  Link  com a  freqüência e  largura  compatível  com o dispositivo  conectado no 

outro lado do link. 

A  arquitetura  PCI  Express  possui  estruturas  para  suportar  futuras melhorias  de 

desempenho através de melhoras de velocidade e avançadas técnicas de codificação. 

Isto tudo só afetaria a definição da Physical Layer. 

 

3.3.4 Configuração plug-and-play Uma das características principais do PCIe que o diferencia dos outros barramentos 

é a habilidade de configurar um sistema dinamicamente a fim de evitar conflitos. Essa 

habilidade é conhecida como configuração plug‐and‐play. 

 

3.3.4.1 Espaço de Configuração O  espaço  de  configuração  plug‐and‐play    é,  eventualmente,  a  diferença  mais 

significativa  relativamente  aos  barramentos  anteriores  ao  PCIe.  É  no  espaço  de 

configuração que se localiza informação crítica para o correto funcionamento, tanto do 

agente,  como  do  protocolo  PCIe.  Contudo,  os  agentes  necessitam  de  implementar 

somente os registros de configuração necessários para o seu funcionamento. O espaço 

de  configuração  deve poder  ser  aceito  em  qualquer  altura,  não  somente  durante  a 

inicialização do sistema. 

Os  primeiros  64  bytes  dos  256  do  espaço  de  configuração  são  chamados  de 

cabeçalho de configuração. Existem três diferentes tipos de cabeçalhos. O tipo 0 é para 

a maioria dos dispositivos. O tipo 1 descreve um dispositivo bridge e o tipo 2 descreve 

PC  Card.  Os  192  bytes  restantes  estão  disponíveis  para  configuração  de  funções 

específicas do dispositivo. A Figura 14 mostra o cabeçalho do espaço de configuração. 

Existem campos que são de implementação total e obrigatória, são eles: Device ID, 

Vendor  ID,  Class  Code,  Revision  ID  e Header  Type.  São  de  implementação  parcial  e 

obrigatória  os  campos  Status  e  Command.  Os  campos  restantes,  são  de 

implementação  opcional.  Os  campos  que  não  forem  implementados  devem  ser 

permanentemente ligados a zero; de tal forma que, a leitura destes retorna sempre 0 e 

a escrita é aceita como comando, mas é ignorada. 

 

 

 

Vend

 

pela 

Devic

 

Revis

 

dispo

Head

 

Comm

         

most

Abaixo, s

dor ID 

Identifica

PCI SIG. 

ce ID 

Identifica

sion ID 

Atribuído

ositivo. 

der Type 

O bit ma

mand Regis

    Registrad

tra o layout

Figura 14 – 

segue uma 

a o  fabrica

a o disposit

o pelo  fabr

ais significat

ster 

dor de 15 b

t do mesmo

Espaço de co

explicação 

nte do disp

tivo. O valor

ricante do d

tivo é 1 se o

bits que con

o. 

nfiguração, ti

dos campo

positivo. Os

r é atribuído

dispositivo 

o dispositivo

ntrola as tr

po 0, do barra

s de mais im

s códigos do

o pelo fabri

para  identi

o multi‐func

ransações d

amento PCIe 

mportantes

o Vendor  ID

cante. 

ificar o níve

ction. 

do barrame

 

: 

D  são atrib

el de  revisã

nto. A Figu

48 

uídos 

ão do 

ra 15 

 

 

A Tab

Bit 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

 

 

 

bela 1 abaix

Descrição

Controla

zero, o d

Controla

estiver ze

Controla

zero, o d

Um valor

tipo “Spe

Quando 

Write an

Este bit é

Se o bit e

o disposi

Indica se

Este bit p

Controla

xo descreve

Tabelo 

 a resposta

ispositivo n

 a  resposta

ero, o dispo

  a  possibili

ispositivo n

r de zero ne

ecial Cycle”.

o bit está 

d Invalidate

é implemen

estiver em 0

itivo tem de

e o dispositiv

permite a q

 se o dispos

Figura 15

e em detalh

la 1 – Descriç

a do disposi

não respond

a do dispos

ositivo não r

dade  de  o 

não pode da

este bit sign

. 

a 1, o disp

e”. 

ntado em pl

0, o disposit

e reagir a er

vo impleme

ue o driver 

sitivo (49ach

5 – Command

es os bits d

ção dos bits do

itivo a trans

de a transaç

sitivo a  tran

responde a 

dispositivo

ar inicio a tr

nifica que o

ositivo pod

acas gráfica

tivo ignora 

rros de pari

enta Steppin

do pino SER

hê49) pode

d Register 

o command

o command reg

sações no e

ções de I/O

nsações no 

transações

o  ser Maste

ransações P

o dispositivo

de gerar  tra

as 

erros de pa

dade. 

ng. 

RR# seja ati

e fazer trans

d register. 

gister.

espaço I/O. 

espaço me

s MEM. 

er. No  caso

PCIe. 

o irá ignora

ansações do

aridade. Se o

ivado 

sações fast 

 

 Se o bit es

emória. Se 

o  de  o  bit 

ar transaçõe

o  tipo  “Me

o bit estive

back‐to‐bac

49 

stiver 

o bit 

estar 

es do 

mory 

r a 1, 

ck. 

 

 

Statu

 

Figur

A Tab

Bits 

5 

7 

8 

9 – 1

11 

12 

13 

us Register 

Registrad

ra 16 mostr

bela 2 desc

Desc

Indic

Este 

back 

Bit ha

três c

‐ qua

‐ qua

‐ qua

10  Estes

Bit  h

com 

Bit ha

com 

Bit ha

dor de 15 b

ra o layout d

reve em de

Tabrição 

a se o dispo

bit  indica s

quando a t

abilitado po

condições: 

ndo PERR#

ndo ocorre

ndo é habil

s bits indica

abilitado  p

target‐abor

abilitado po

target‐abor

abilitado po

bits que con

do mesmo.

Figura 

talhes os bi

bela 2 – Descri

ositivo é cap

se o disposi

ransação nã

or um dispo

# é habilitad

u um erro n

litado o bit 

m a tempor

por  um  disp

rt. 

or um dispo

rt. 

or um dispo

ntém as inf

 16 – Status R

its do status

ição dos bits d

paz de oper

itivo é capa

ão é para o

ositivo que s

do. 

no qual o di

“Parity Erro

rização mai

positivo  tar

ositivo 50ac

ositivo 50ac

ormações d

Register 

s register.

do status regis

rar em 66 M

az de aceita

 mesmo dis

seja 50achê

ispositivo e

or Response

s lenta do p

rget,  quand

chê50, quan

chê50, quan

de status do

ster.

MHz. 

ar  transaçõ

spositivo. 

50 quando 

steve envol

e” do campo

pino DEVSE

do  termina 

ndo termina

ndo termina

o barramen

 

ões  fast bac

detecta um

lvido. 

o Command

L#. 

uma  trans

a uma trans

a uma trans

50 

nto. A 

ck‐to‐

ma de 

d. 

sação 

sação 

sação 

 

 

14 

15 

 

Base

 

confi

cabe

dispo

 

0 det

 

ser m

espa

respe

 

O

quan

com 5

Bit ha

Este b

e Address Re

O Base A

iguração  de

eçalho de co

ositivo ter a

Existem 

termina se 

Para esp

mapeado o 

ços e ende

ectivament

O dispositiv

ntidade de e

51achê51‐a

abilitado pe

bit é coloca

Tab

egister (BA

Address Re

eterminar  o

onfiguração

até seis inde

dois format

o Base Add

paço de me

tamanho d

ereços de 3

e. 

Figura

o para func

endereços p

abort; excet

elo dispositi

ado em 1 qu

bela 2 – Descri

R) 

gisters prov

os  recursos

 tipo 0 supo

ependentes

tos para o B

ress Registe

mória, os b

do Base Add

2 ou 64 bit

a 17 – Estrutur

cionar nece

para si; seja

to para a tra

ivo, quando

uando o disp

ição dos bits d

ve um mec

s  de memó

orta até seis

s endereços

Base Regist

er represen

bits 1 e 2 in

dress Regist

ts,  implican

ra do Base Ad

essita, norm

 no espaço 

ansação “Sp

o atua em S

positivo det

do status regis

canismo qu

ria  e  I/O  q

s Base Addr

s. 

ter como m

ta espaço d

dica como 

ter. A mem

do em regi

ddress Registe

malmente, d

de memóri

pecial Cycle

ERR#. 

tecta um er

ster. 

e possibilit

ue  o  dispo

ress Registe

mostrado na

de memória

o espaço de

ória pode s

istradores d

 

r (BAR) 

de alocar um

ia ou no esp

e”. 

rro de parid

ta o  softwa

ositivo  requ

ers, permitin

 Figura 17. 

a ou I/O. 

e memória 

ser mapead

de 32 ou 64

ma determ

paço de I/O

51 

dade. 

re de 

er. O 

ndo o 

O bit 

deve 

da em 

4 bits 

inada 

. 

 

52  

Na  seção  seguinte,  serão  mostrados  os  conceitos  básicos  necessários  para  o 

desenvolvimento de device driver que tem como característica acessar um dispositivo 

que esteja conectado ao barramento PCIe. 

 

3.3.5 Device Driver para acesso ao Barramento PCIe Cada dispositivo PCIe é identificado por um número de barramento, um número de 

dispositivo e um número de função. O Linux possui uma estrutura específica de dados 

conhecida  como  struct  pci_dev  que  abstrai,  para  o  desenvolvedor,  o  uso  destes 

números, facilitando a escrita de device drivers. 

Todos os periféricos ligados ao barramento PCIe podem responder a transações em 

três diferentes espaços de endereçamento: memória, portas de I/O e registradores de 

configuração.  As  regiões  de memória  e  portas  de  I/O  são  acessadas  com  funções 

conhecidas de C, como inb, readb, entre outras. 

Os  dois  primeiros  espaços  de  endereçamento  são  compartilhados  por  todos  os 

dispositivos no mesmo barramento PCIe  (ou seja, quando uma  região de memória é 

acessada, todos os dispositivos ligados ao um mesmo barramento enxergam o ciclo no 

barramento  ao  mesmo  tempo).  O  espaço  de  configuração  é  específico  para  cada 

dispositivo e as transações de configuração são realizadas para um dispositivo por vez 

de forma que não há colisão entre as transações. 

As transações de configuração são realizadas por funções específicas, definidas no 

kernel, que acessam os registradores de configuração. 

 

3.3.5.1 A Estrutura pci_device_id Esta estrutura é usada para definir uma  lista dos diferentes  tipos de dispositivos 

PCIe que o driver suporta e possui os principais campos: 

• vendorID  –  é  um  registrador  de  16  bits  que  identifica  o  vendedor  do 

dispositivo  controlado  pelo  driver.  Se  o  driver  puder  controlar  qualquer 

dispositivo pode‐se usar o valor PCI_ANY_ID para esse campo. 

• deviceID – é um registrador de 16 bits que guarda a  identificação para um 

dispositivo  específico  do  fabricante.  O  deviceID  não  possui  um  registro 

oficial,  logo  o  fabricante  é  livre  para  atribuir  qualquer  valor  a  este 

 

53  

registrador; é concatenado com o vendorID para formar uma  identificação 

única  de  32  bits  para  o  dispositivo,  esta  identificação  é  chamada  de 

assinatura.  O  device  driver  lê  os  registradores  vendorID  e  deviceID  para 

identificar  o  dispositivo  que  irá  controlar.  Se  o  driver  puder  controlar 

qualquer dispositivo pode‐se usar o valor PCI_ANY_ID para esse campo. 

Para  inicializar a estrutura pci_device_id, existem duas macros que auxiliam esse 

processo, são elas:  

• PCI_DEVICE(vendor,device)  –  Cria  a  estrutura  pci_device_id  que  utiliza  o 

vendor e o device passados como parâmetro. 

• PCI_DEVICE_CLASS(device_class,  device_class_maks)  –  Cria  a  estrutura 

pci_device_id que utiliza a classe especificada nos parâmetros. 

 

3.3.5.2 Registrando o PCIe driver Para que o PCIe driver  seja  registrado  corretamente no  kernel, este deve  conter 

uma  estrutura  conhecida  como  struct  pci_drive,  a  qual  consiste  de  um  número  de 

chamada  de  funções  e  variáveis  que  descrevem  o  driver  PCIe  para  o  core  PCIe. Os 

principais campos da estrutura são: 

• const char *name – este é o nome do driver e, geralmente, possui o mesmo 

nome do módulo do driver. Este nome deve ser único em relação a todos os 

drivers existentes no sistema. 

• const  struct  pci_device_id  *id_table  –  ponteiro  para  a  estrutura 

pci_device_id. 

• int  (*probe)  (struct  pci_dev  *dev,  const  struct  pci_device_id  *id)  –  é  um 

ponteiro  para  a  função  probe  que  é  chamada  pelo  core  PCIe  quando  o 

driver  é  registrado. O  ponteiro  *dev  guarda  o  dispositivo  retornado  pelo 

core  PCIe,  podendo  ser  feitas  consultas  para  saber  qualquer  tipo  de 

configuração  do  dispositivo.  É  nesta  função  que  se  habilita  o  dispositivo, 

para que se possam usar seus recursos, através da função: 

int pci_enable_device(struct pci_dev *dev); 

• void (*remove) (struct pci_dev *dev) – É um ponteiro para a função remove 

que  é  chamada  pelo  core  PCIe  quando  o  driver  está  sendo  removido  do 

 

 

A

P

respe

3.3.5A

nos t

sabe

está 

C

diret

escre

próp

acess

funçõ

siste

funçã

A Figura 18 

Para  registr

ectivament

5.3 AcessaApós o drive

três espaço

r se o dispo

mapeado, o

Como o pro

tamente, o 

ever  e  ler  o

pria de  cada

so  ao  espa

ões são as l

int pc

    int pc

       int pc

int p

  int pc

    int pc

ma. Todos 

ão. 

mostra um

rar  e  remo

e: 

p

ando o Eser detectar 

s de endere

ositivo é ma

o acesso ao

cessador nã

fabricante 

os  registrad

a  fabricante

ço de  conf

istadas aba

i_read_conf

ci_read_conf

ci_read_con

pci_write_co

ci_write_co

ci_write_co

os recursos

m exemplo d

Figura 18 –

ver  um  dri

pci_registe

pci_unregist

spaço de Co dispositi

eçamento: o

apeado em 

o espaço de 

ão possui a 

deve prove

dores  no  c

e. No  entan

figuração,  c

ixo: 

fig_byte(str

nfig_word(st

nfig_dword(

onfig_byte(s

onfig_word(

nfig_dword

s alocados n

da estrutura

– Estrutura do

iver  PCIe  d

er_driver(&p

ter_driver(&

 

Configuraçvo, ele pre

o de memó

portas de I

configuraçã

 capacidade

er um meio

ontrolador 

nto, o  Linu

conhecida  c

ruct pci_dev

truct pci_de

(struct pci_d

struct pci_d

(struct pci_d

d(struct pci_

na função p

a pci_driver

o pci_driver 

do  sistema 

pci_driver);

&pci_driver)

ção cisa estar p

ória, o de I/O

I/O ou mem

ão é necess

e de acessa

o para que 

PCIe.  Poré

x oferece u

como  <54ac

v *dev, int w

ev *dev, int 

dev *dev, in

dev *dev, in

dev *dev, in

_dev *dev, i

robe são de

. 

usa‐se  as 

 

); 

pronto para

O e o de co

mória e em 

sário. 

ar o espaço 

isto seja  fe

ém,  cada  im

uma  interfa

chê/pci.h>, 

where, u8 *

where, u16

nt where, u3

t where, u8

nt where, u1

int where, u

esalocados 

funções  ab

a  ler ou esc

onfiguração.

quais ende

de configu

eito. A CPU 

mplementaç

ace padrão

cujas princ

*54ac); 

6 *54ac); 

32 *54ac); 

8 val); 

16 val); 

u32 val); 

54 

nesta 

baixo, 

crever 

. Para 

reços 

ração 

deve 

ção  é 

 para 

cipais 

 

55  

As  três  primeiras  funções  são  responsáveis  por  leituras  de  8,  16  e  32  bits, 

respectivamente; e as três últimas por escritas. O ponteiro *dev é um ponteiro para o 

dispositivo,  o  inteiro where  indica  o  início  do  espaço  de  configuração  e  o  ponteiro 

*55ac guarda o resultado da leitura. 

 

3.3.5.4 Acessando os Espaços de I/O e Memória Possuindo até seis regiões de entrada e saída de dados, os dispositivos PCIe podem 

ter essas regiões sendo mapeadas em portas de  I/O ou em memória. Os dispositivos 

mapeados  em memória  devem  colocar  o  valor  de  um  registrador  de  configuração 

como “nonprefetchable”, para indicar que área de memória foi mapeada para não ser 

colocada na 55achê, evitando que otimizações sejam feitas e assim afetando os dados 

quando os mesmos forem acessados. 

As principais funções do kernel para acessar esses espaços são: 

• unsigned long pci_resource_start(struct pci_dev *dev, int bar) – Esta função 

retorna o primeiro endereço associado a umas das seis regiões de entrada e 

saída  de  dados.  A  região  é  selecionada  pelo  inteiro  bar  (base  address 

register). 

• unsigned  long pci_resource_end(struct pci_dev *dev,  int bar) – Esta função 

retorna o último endereço que  faz parte da  região de entrada e  saída de 

dados. 

• unsigned long pci_resource_flags(struct pci_dev *dev, int bar) – Esta função 

indica se o bar está mapeado em memória ou em portas de I/O e se estão 

selecionados como “nonprefetchable” ou “prefetchable”. 

 

3.4 Dispositivos Lógicos Reconfiguráveis

Dispositivos  lógicos  reconfiguráveis  [43]  são  dispositivos  que  possuem 

características  intermediárias  entre  os  processadores  de  propósito  geral  e  os ASICs. 

Eles combinam a flexibilidade dos processadores com o alto desempenho dos ASICs. 

Como  o  hardware  reconfigurável  é  programado  para  resolver  um  problema 

específico,  ele  pode  alcançar  um  melhor  desempenho  e  maior  eficiência  que  os 

 

 

proce

depo

flexib

D

arqu

bloco

redo

pinos

lógic

e ho

Esta 

O

mult

look‐

lógic

de  e

possí

U

repre

essadores 

ois  de  sua 

bilidade que

Dispositivos 

itetura  é  c

os de  I/O (I

r do dispos

s  de  I/O  de

os ou CLBs 

rizontais de

estrutura b

Os  blocos 

iplexadores

‐up  tables 

a combinac

endereçame

íveis são ar

Um exemplo

esenta um b

de  propósi

fabricação

e os ASICs. 

  reconfigu

composta  p

Input/Outpu

sitivo; cada 

e  uso  geral

(configurab

e chaves de

básica por se

lógicos  s

s  e  conexõ

e  multiple

cional com u

ento.  As  en

mazenadas

o de uma e

bloco lógico

ito  geral;  e

o,  ele  apre

ráveis,  com

por  três  est

ut, Entrada

um destes 

l,  disponíve

ble logic blo

e  interconex

er vista na F

Figura 19 – Es

são  compo

es  internas

xadores.  A

um número

ntradas  são

 durante a c

estrutura de

o da FPGA S

e  como  po

esenta  men

mo  os  FPG

truturas  bá

/Saída). Os

provê entr

eis  na  parte

ock) são con

xão (switch

Figura 19. 

strutura básic

ostos  por 

s.  A  lógica 

As  look‐up 

o de entrad

o  associada

configuraçã

e um bloco

Stratix II da A

ode  ser  pro

nor  custo 

GAs,  são  b

ásicas:  bloc

 blocos de 

rada, saída 

e  exterior  d

nectados at

h matrix), qu

ca de um FPGA

lógicas  c

combinacio

tables  pod

as correspo

as  às  linhas

ão do FPGA

o  lógico é m

Altera [8].

ogramado  e

de  projeto

aseados  em

os  lógicos, 

I/O formam

ou acesso b

do  compon

ravés de tri

ue também

 

A 

combinacio

onal  é  imp

em  implem

ondentes ao

s  de  ender

. 

mostrado na

e  reprogram

o  e  uma  m

m  SRAM  e

interconex

m uma bord

bi‐direciona

nente. Os  b

ilhas de ver

m é program

onais,  flip‐f

plementada

mentar  qua

o número d

reço  e  as  s

a Figura 20

56 

mado 

maior 

e  sua 

xão  e 

da ao 

al aos 

blocos 

rticais 

mável. 

flops, 

  com 

alquer 

e bits 

saídas 

0, que 

 

 

A

de  c

vizin

com 

U

confi

de p

exec

espe

O

digita

Figura 

A Figura 21 

chaveament

ho. A  Figur

elementos 

Figura

Uma  das  g

igurados pa

permitir  a  re

ução, em u

ctro de apli

O  campo  de

ais,  aplicaç

20 – (a) Bloco

mostra uma

to  (switch 

ra  21(c) mo

lógicos vizi

a 21 – (a) Estru

grandes  van

ara permitir

econfiguraç

uma única p

icações dos

e  aplicaçõe

ções  em 

o lógico Altera

a estrutura 

matrix)  sã

ostra  a  estr

nhos. 

utura geral da

ntagens  do

r o fluxo de

ção dos me

pastilha, de 

s FPGAs. 

es  dos  FPGA

indústria  a

a Stratix II (b) 

mais detal

ão  utilizado

rutura  de C

a FPGA (b) blo

os  FPGAs  é

e dados de 

esmos em  t

 diferentes 

As  é  divers

automotiva

LUT de duas e

hada de um

os  para  co

CLBs,  que  s

co de switch (

é  que  os 

forma  inde

tempo de e

processos 

so,  incluindo

  e  aeroes

entradas e um

m FPGA. Na 

nectar  bloc

se  comunica

(c) bloco de co

blocos  lógi

ependente 

execução.  I

concorrent

o  processam

spacial,  tel

 

ma saída 

figura, os b

cos  lógicos

am  diretam

onexão 

icos  podem

e paralela, 

Isto possibi

tes, amplian

mento  de 

lecomunica

57 

blocos 

s  não 

mente 

m  ser 

além 

ilita  a 

ndo o 

sinais 

ações, 

 

 

 

proce

de co

E

dom

exist

E

proje

cores

dispo

Alter

3.5 C

 

teóri

 

sepa

hard

 

essamento 

onsumo [32

Existem,  pe

inam no m

am outros f

Empresas  co

etos usando

s  (Intelectu

ositivos FPG

ra. 

T

Conclusõ

Este cap

ica para que

As  vária

radamente

wares reco

de  imagen

2]. 

elo  menos, 

ercado são 

fabricantes 

omo  a Xilin

o  seus  FPG

al Property

GAs, bem co

Tabela 3 – Res

Tabela 4 – Re

es

pítulo teve c

e a arquitet

as  partes, 

, desde os c

nfiguráveis

ns, criptogra

cinco  emp

a Altera Co

como Acte

nx e Altera

GAs, que  va

y  cores). Na

omo alguma

sumo das fam

esumo das fam

como princi

tura possa s

nas  quais

conceitos b

. 

 

afia, dispos

presas  que 

orporation

el [35], Latti

oferecem 

i desde  fer

a  Tabela 3

as de suas c

mílias e caracte

 mílias e caract

ipal finalida

ser entendid

s  esse  pro

básicos de d

itivos médi

fabricam 

[33] e Xilinx

ce [36] e Qu

todo o  sup

rramentas a

e na  Tabel

característic

erísticas dos F

terísticas dos F

ade apresen

da. 

ojeto  foi  d

device drive

cos, entre 

FPGAs  no 

x Corporati

uicklogic [37

porte para  a

até o  forne

a 4,  são m

cas, fabrica

FPGA da Altera

FPGA da Xilinx

ntar toda a 

dividido,  fo

r, do barram

outros prod

mundo,  as

ion [34], em

7].  

a elaboraçã

ecimento de

mostrados  a

ados pela Xi

a.

x 

fundamen

oram  explic

mento PCIe

58 

dutos 

s  que 

mbora 

ão de 

e  Ips‐

lguns 

ilinx e 

 

 

tação 

cadas 

e e de 

 

59  

4. Arquitetura Proposta Este capítulo tem para finalidade descrever em detalhes a arquitetura de um cluster 

experimental  desenvolvido  a  partir  de  nós  híbridos  compostos  por  uma  cpu  de 

propósito geral e um co‐processador reconfigurável. Nesta estrutura, algoritmos com 

processamento  massivo  de  dados  podem  ser  particionados  em  diferentes  nós  do 

cluster utilizando o protocolo MPI.   Sua operação deve ser compatível com os modelos 

de cluster baseados em CPUs. Para alcançarmos esta transparência para o usuário final, 

alguns módulos especiais e todo o ambiente de comunicação foram desenvolvidos, e 

representam a contribuição principal desta dissertação, são eles: (i) uma  interface de 

aplicação do usuário utilizando a biblioteca do MPI, (ii) nós que usam FPGAs como co‐

processadores e (iii) desenvolvimento de um  device driver para barramento PCI‐e. 

  

4.1 Interface de Aplicação

Para  que  fosse  possível  a manutenção  de  uma  estrutura  simples,  utilizada  por 

outros clusters comerciais, a conexão entre servidor e nós do sistema é feita através do 

protocolo  MPI.  Como  dito  no  capítulo  3,  esta  abordagem  é  usada  em  classes  de 

máquinas  que  trabalham  em  paralelo,  especialmente  aquelas  com  memória  e 

processamento  paralelos.  A  principal  vantagem  do  uso  desta  interface  é  a  sua 

portabilidade e seu fácil uso.  Neste projeto, o uso da interface MPI possibilita a troca 

de  dados  entre  o  nó mestre  e  os  nós  escravos.  A  implementação,  desta  interface, 

usada foi a MPICH2. 

Para  que  se  possa  iniciar  qualquer  rotina MPI  é  necessária  a  utilização  de  uma 

função de  inicialização, apresentada na Figura 22. Nesta  função, o argumento argc é 

um ponteiro para o número de argumentos e argv é um ponteiro para o vetor passado 

como parâmetro na função main. 

Figura 22 ‐ Função de inicialização do MPI. 

 

60  

As principais  funções no MPI  são  as que possibilitam o envio e  recebimento de 

mensagens, MPI_Send e MPI_Recv  respectivamente.   Os parâmetros destas  funções 

são explicados no capítulo 3 e a Figura 23 mostra seu uso neste projeto: 

Figura 23 ‐ Figura que mostra o uso das funções de escrita e leitura do MPI 

Como citado anteriormente, o uso dos comunicadores é de essencial importância 

dentro da estrutura MPI. Com eles, é possível saber a quantidade de processos em um 

mesmo  grupo  e  representar  o  processo  que  está  sendo  chamado  no momento.  A 

Figura 24 mostra o uso destes comunicadores. 

 Figura 24 ‐ Uso dos comunicadores. 

A distribuição da  carga  realizada pelo MPI  foi  feita de  forma bem  simples,  toda 

matriz  de  entrada  é  dividida  em  número  par  de  blocos,  de  forma  que  a  primeira 

metade é enviada e processada por um nó, e a segunda metade pelo segundo nó. 

Finalmente,  a  função  responsável por  limpar  todos os estados do MPI deve  ser 

usada no fim do programa, de tal forma que, após sua chamada, nenhuma outra rotina 

possa ser utilizada. Sua utilização é mostrada na Figura 25. 

 

61  

Figura 25 ‐ Uso da função MPI_Finalize.

4.2 Nós do Sistema 

Com o intuito de acelerar o processamento dos algoritmos nos nós do sistema, foi 

introduzido, em cada nó, um FPGA, como um co‐processador. Neste projeto usou‐se a 

plataforma ML555 da Xilinx [44], esta possui as seguintes principais características: 

• um FPGA Virtex 5 XC5VLX50T da Xilinx; 

• conectores  para  o  barramentos  PCI,  PCI‐X  e  PCI‐Express  8x,  que  foi  o  barramento 

utilizado neste trabalho; 

• socket SODIMM de 200 pinos com uma memória DDR2 SDRAM 256MB; 

• três  fontes  de  clock  na  placa,  duas  entradas  diferenciais  SMA  de  clock  e  dois 

sintetizadores de clock programáveis; 

• possibilidade  de  programar  o  FPGA  através  de  uma  Plataforma  Flash  na  placa  ou 

através de um cabo USB; 

• switches e LEDs disponíveis para o usuário. 

Com  estas  características  é possível  fazer  transmissão  em burst de uma  grande 

quantidade de dados. A Figura 26 abaixo mostra a plataforma usada. 

 

 

 

P

Core 

ferra

  C

 

Para que a 

PCIe  para

amenta COR

Chegou‐se 

Fi

Figura

conexão po

a  fazer  uso

RE Generato

na arquitet

igura 27 ‐ Nó 

a 26 ‐ Placa M

ossa ser feit

o  do  barra

or da Xilinx 

ura mostrad

escravo do clu

L555 com FPG

ta entre a C

amento  PCI

[38]. 

da na Figur

uster com um

GA Virtex 5 da

CPU e a FPGA

I‐e.  Este  co

a 27. 

m FPGA como c

a Xilinx. 

A é necessá

ore  foi  ger

co‐processado

ário o uso d

rado  atravé

 

or. 

62 

 

de um 

és  da 

 

63  

4.2.1 Core PCIe

A  implementação de todo o protocolo do barramento PCI‐e  foi gerado com suas 

características de rápida transmissão de dados através de canais de DMA, fundamental 

para o deslocamento rápido de dados entre a CPU e o co‐processador (FPGA). 

No controlador de DMA, os  registradores de controle e status são mapeados no 

espaço de memória do PCIe e conectados à lógica de aplicação do usuário. O processo 

do  host  acessa  o  arquivo  de  registro  através  de  ciclos  de  leituras  e  escritas  na 

memória. As operações de DMA são definidas nos registradores de controle e status 

do  DMA.  O  processador  inicia  as  transferências  inicializando  os  registradores  de 

controle. O  término é visto através dos  registradores de status. A Tabela 5 mostra a 

descrição de todos os registradores. 

Tabela 5 ‐ Registradores de controle e status do DMA.

Registrador  Descrição 

DMAWAS  Endereço da memória DDR2 para a operação de escrita. 

DMAWAD_L  32 bits menos significativos do buffer da memória do sistema para 

operação de escrita. 

DMAWAD_U  32  bits mais  significativos  do  buffer  da memória  do  sistema  para 

operação de escrita. 

DMARAS_L  32 bits menos significativos do buffer da memória do sistema para 

operação de leitura. 

DMARAS_U  32  bits mais  significativos  do  buffer  da memória  do  sistema  para 

operação de leitura. 

DMARAD  Endereço da memória DDR2 para a operação de leitura. 

DMAWXS  Números de bytes para  transferir da memória do  Endpoint para  a 

memória do sistema. 

DMARXS  Números  de  bytes  para  transferir  da memória  do  sistema  para  a 

memória do Endpoint. 

DMACST  Registrador de controle e status. A tabela 4.2 mostra uma descrição 

deste. 

DMAWRP  Registrador que provê um mecanismo para calcular o desempenho 

da operação de escrita. O contador inicia quando o DMA Write Start 

 

64  

bit é setado para um, e termina quando o end of frame é acionado 

no último pacote de escrita. 

DMARDP  Registrador que provê um mecanismo para calcular o desempenho 

da  operação  de  leitura.  Seu  funcionamento  é  semelhante  ao 

DMAWRP. 

A  leitura  representa  entrada  na  memória  do  DMA,  enquanto  que  a  escrita 

representa  saída. O  registrador de  controle e  status, DMACST, provê o  controle das 

operações requisitadas, este é detalhado na Tabela 6. 

Tabela 6 ‐ Definições dos bits do registrador DMACST.

Campo  Posição  Descrição 

Write DMA Start  0  Inicia uma operação de escrita quando é setado para 

1. 

Write DMA Done  1  Indica o término da operação de escrita. 

Read DMA Start  2  Inicia uma operação de  leitura quando é setado para 

1. 

Read DMA Done  3  Indica o término da operação de leitura. 

Reservado  31:5  Posições reservadas. 

Inicialização  da 

Memória PHY 

4  Quando  1,  indica  a  correta  inicialização  da  interface 

da memória DDR2. 

O firmware do processador do PC executa os seguintes acessos aos registradores 

para executar uma operação de escrita DMA. 

• Verifica se o start bit do registrador DMACST [0] é zero. 

• Grava  os  valores  adequados  nos  registradores  DMAWAS,  DMAWAD_L, 

DMAWAD_U e DMAWXS. 

• Grava 1 em DMACST [0] para iniciar a operação de gravação de DMA. 

• Faz  polling  no DMA Write Done  bit  para  determinar  quando  a  operação  de 

DMA está completa. 

• Calcula  o  desempenho  da  escrita  baseada  no  tamanho  da  transferência 

solicitada pelo usuário e no valor do contador de leituras. 

O  firmware do processador do PC executa os seguintes acessos aos registradores 

para executar uma operação de leitura DMA. 

 

65  

• Verifica se o bit do DMA Read em DMACST [2] é zero. 

• Grava  os  valores  adequados  nos  registradores  DMARAS_L,  DMARAS_U, 

DMARAD e DMARXS. 

• Grava um 1 em DMACST [2] para iniciar a operação de leitura DMA. 

• Faz polling no DMA Read Done bit para determinar quando a operação de DMA 

está completa. 

• Calcula  o  desempenho  da  leitura  baseada  no  tamanho  da  transferência 

solicitada pelo usuário e no valor do contador de leituras. 

• Calcula  o  desempenho  de  leitura  com  base  no  tamanho  de  transferência 

solicitada pelo usuário e somente leitura aos valores do arquivo de registro. 

Usar o processador do PC para fazer polling nos registradores para saber o status, 

indicando o  término das escritas ou  leituras DMA  ler ou escrever a  conclusão, pode 

afetar  o  throughput  do  projeto.  Depois  de  iniciar  uma  operação  de  DMA,  o 

processador do PC host espera por um tempo de retardo programado antes começar o 

polling no registrador de status para determinar se a transferência DMA foi concluída. 

Diversas máquinas de  estados  estão  localizadas no  arquivo dos  registradores de 

controle e status do DMA e trabalham em conjunto para alimentar o bloco de controle 

interno  com  pequenas  transferências.  Estas  máquinas  de  estados  são  capazes  de 

quebrar grandes transferências nos seguintes limites: 4 KB, 2 KB, 1 KB, 512 bytes, 256 

bytes  e  128  bytes.  Por  exemplo,  uma  transferência  de  9600  bytes  é  quebrada  nos 

seguintes pedaços: 2 x 4 KB, 1 x 1 KB, 1 x 256 bytes e 1 x 128 bytes. 

 

4.3 Device Driver

Com  o  uso  da  plataforma  baseada  em  um  FPGA  Xilinx  (Virtex5  VLX50T),  foi 

desenvolvido um device driver para Linux que permitisse a troca de dados entre PC e 

FPGA através do barramento PCIe. Esta transferência de dados é feita em modo burst. 

A Figura 28 mostra a definição do  vendorID da Xilinx e o deviceID que  representará 

está placa.  

 

66  

Figura 28 ‐ vendorID da Xilinx e deviceID. 

Estes são usados na estrutura pci_device_id, explicada no capítulo 3 e é mostrada 

na Figura 29Figura 29. 

 

Figura 29 ‐ Estrutura pci_device_id. 

Para este desenvolvimento, duas estruturas bem conhecidas no Linux e explicadas 

no capítulo 3  foram usadas: o “char driver” e o “pci driver”. Para  isto  foi criada uma 

outra  estrutura  que  contivesse  as  duas,  como mostrado  na  Figura  30.  Isto  se  faz 

necessário, pois apenas utilizando a pci driver, não seria possível a leitura e escritas, de 

dados,  a  partir  da  aplicação  devido  à  falta  de  funções  que  proporcionassem  estas 

funcionalidades. 

Figura 30 ‐ Estrutura contendo char driver e pci driver. 

 

4.3.1 Estrutura Char Driver

  Para que fosse possível registrar um char driver e o kernel pudesse fazer uso das 

operações do dispositivo, a  função  static  int _init dmaX5_init(void), mostrada abaixo 

na Figura 3131, foi criada, esta utiliza funções definidas pela biblioteca <Linux/cdev.h>.  

 

 

67  

 Figura 31 ‐ Função que registra o char driver. 

  Esta  função também é responsável por definir os números major e minor para o 

dispositivo usado. 

  Com o objetivo contrário da função de registro, a static void _init dmaX5_exit() foi 

desenvolvida para que o char driver possa ser removido do kernel, esta também usa a 

biblioteca citada acima. Esta função é mostrada na Figura 32. 

 Figura 32 ‐ Função que remove o char driver do kernel. 

  Antes de  implementar as funções para troca de dados entre PC e FPGA é preciso 

conectar as operações do driver com o dispositivo que foi mapeado usando os número 

major e minor. Isto é feito com a ajuda da estrutura file operations, como mostrado na 

Figura 33. 

 Figura 33 ‐ Estrutura file operations. 

  As funções write e read são as responsáveis por fazerem a transferência dos dados 

da camada da aplicação para a do kernel e de  setar os valores dos  registradores no 

core PCIe. Estes registradores vão dar as informações necessárias para a transferência 

como: endereço físico do buffer onde estão os dados, quantidade de dados que serão 

transferidos,  quantidade  de  pacotes  TLP  e  uma  flag  para  indicar  quando  se  deve 

 

68  

começar  a  transferência.  A  Figura  34  e  Figura  35  mostram,  respectivamente,  a 

implementação das funções write e read.  

Figura 34 ‐ Função write. 

 Figura 35 ‐ Função read. 

  Estes registradores estão definidos em uma estrutura descrita no próprio código e 

mostrada na Figura 36. 

 

69  

 Figura 36 ‐ Estrutura dos registradores de controle e status do DMA. 

 

4.3.2 Estrutura PCI Driver

  Como  explicado  anteriormente,  é necessária  a definição da  estrutura pci_driver 

para  que  o  PCIe  driver  seja  registrado  corretamente  no  kernel,  isto  devido  a 

necessidade de associar o driver PCIe com o core PCIe. A Figura 37Figura 37 mostra essa 

estrutura no código. 

Figura 37 ‐ Estrutura pci_driver.  

A  principal  função  desta  estrutura  é  a  probe,  mostrada  na  Figura  41,  esta  é 

chamada logo após o driver PCIe ter sido registrado. Nesta função, o dispositivo PCIe é 

habilitado,  com  isto, o dispositivo  acessa o espaço de  configuração para  guardar os 

endereços dos Base Address Register (BARs), funções auxiliares foram criadas para que 

isto  fosse  feito,  são  elas:  scan_bars, map_bars  e  free_bars.  A  primeira mapeia  as 

regiões de memória do dispositivo, estas regiões são mapeadas em endereços virtuais 

pela segunda  função. A  terceira  libera as regiões de memórias ocupadas pelos BARs. 

Estas funções são mostradas nas Figura 38, Figura 39 e Figura 40 

O endereço retornado pelas funções de acesso aos registradores de configuração 

retorna o endereço  físico de cada BAR que não pode ser acessado diretamente pelo 

 

70  

driver. Por isto a necessidade da utilização da função ioremap que mapeia o endereço 

físico de cada BAR em um endereço virtual que pode ser acessado pelo kernel. 

 Figura 38 ‐ Função scan_bars. 

 

 Figura 39 ‐ Função map_bars. 

 

 

Figura 40 ‐ Função free_bars.  

   

 

71  

 

Figura 41 ‐ Função probe.    

  Para  que  todos  os  recursos  alocados  pelas  funções  scan_bars  e  free_bars  na 

função probe pudesse ser desalocados, a função remove foi definida. Esta é chamada 

quando  o  driver  está  sendo  removido  do  sistema. AFigura  42  Figura  42 mostra  esta 

nova função. 

 Figura 42 ‐ Função remove. 

4.4 Conclusões

  Este  capítulo apresentou  todos os módulos desenvolvidos para a  construção do 

cluster. Foi apresentado como foi feita a utilização da interface MPI, como se deu o uso 

do core PCIe, e qual a plataforma usada para prototipação do algoritmo em hardware. 

 

72  

Os  módulos  de  software,  dado  pelo  device  driver  foi  explicado  através  do 

detalhamento de suas funções. 

   

 

73  

5. Experimento Com o intuito de validar a arquitetura proposta desta dissertação, um experimento 

foi desenvolvido neste trabalho, voltado para a implementação de uma das rotinas da 

biblioteca  BLAS  (Basic  Linear  Algebra  Subprograms),  nível  3.  Esta  implementação, 

especificamente diz respeito à multiplicação de matrizes densas, bastante utilizada em 

aplicações de computação científica. 

Este experimento foi desenvolvido considerando a implementação do algoritmo de 

multiplicação  de  grandes  matrizes,  as  quais  precisariam  ser  particionadas  e 

processadas em mais de um nó do cluster.   A arquitetura para teste é composta por 

dois  PCs,  cada  um  contendo  uma  placa  aceleradora,  composta  de  um  FPGA  (co‐

processador)  cada  já  citado no  capítulo 4. Um dos PCs  funciona  tanto  como mestre 

quanto  escravo  e  o  outro  apenas  como  escravo.  Tanto  o mestre  quando  o  escravo 

contém um processador Intel Core2 Quad 2.66 GHz com 4 GB de memória RAM. 

Ao  longo  deste  capítulo  serão  descritos  o  algoritmo  de  particionamento  das 

matrizes, a  implementação baseada no capítulo anterior e o core utilizado nos FPGAs 

para a multiplicação das matrizes. 

 

5.1 Algoritmo de Particionamento de Matrizes

Para que fosse possível dividir a matriz entre os dois nós do sistema foi utilizado o 

algoritmo SUMMA (Scalable Universal Matrix Multiplication Algorithm) [45]. 

Este algoritmo opera com diferentes estilos de produtos de matrizes, quais sejam: 

C = αAB + βC 

C = αABT + βC 

C = αATB + βC 

C = αATBT + βC 

  Estes são os casos especiais implementados como parte da biblioteca BLAS. 

 Neste contexto, assume‐se que cada matriz X tem dimensão mX x nX, X ϵ {A,B,C}. 

Considera‐se a decomposição de dados em duas dimensões. Para todos os algoritmos, 

a partição é feita da seguinte forma: 

 

 

C

o pro

matr

N

C a p

S

 

R

5.2 I

A

como

arqu

matr

C

os  d

MPIC

Cada partiçã

oduto C = α

rizes, logo o

Nota‐se que

partir das co

Sendo cada 

Resultando 

Implemen

A aplicação 

o  a multipl

ivos, as ma

rizes. 

Como dito a

ados  para 

CH2,  como 

ão Xij é subm

αAB + βC, se

os elemento

e as linhas d

olunas de B,

bloco Ai(c‐1)

em: 

ntação da 

foi desenv

icação é  fe

trizes que s

anteriormen

os  nós  do 

já  citado  a

metida para

endo α = 1 e

os de C são d

de C são com

, logo, a sub

: 

Aplicação

volvida de  t

eita. Assim, 

serão multi

nte, a interf

cluster,  e 

anteriormen

a um nó. Pa

e β = 0. E ai

dados por:

mputadas a

b‐matriz Cij 

o

tal  forma q

é preciso 

plicadas e a

face de com

a  impleme

nte. Usando

ra este estu

ij, bij e cij de

 a partir das 

é calculada 

 

ue  fique  tr

apenas que

a chamada 

municação M

entação  esc

o esta mes

 udo de caso

enotam o el

linhas de A,

da seguinte

 

 

ransparente

e  sejam de

da função 

MPI foi utiliz

colhida  des

ma  interfac

o foi conside

emento (i, 

, e as colun

e maneira: 

e para o us

efinidas, em

multiplicaçã

zada para e

sse  padrão 

ce, o nó m

74 

erado 

j) das 

nas de 

suário 

m dois 

ão de 

enviar 

foi  a 

mestre 

 

 

receb

receb

5.2.

A

O

preci

elem

 A

leitu

be o  result

bidas, mont

1 Aplicaçã

A Figura 43 a

O primeiro 

isam  conte

mentos. A Fig

As  Figura  4

ra das matr

ado da mu

tando a ma

ão no Nó 

apresenta o

passo do  f

er  o  númer

gura 44 mo

Figura 44

45Figura  46

rizes respec

ultiplicação 

triz resultan

Mestre

o fluxo de e

Figura 43 ‐

fluxo é  ler o

ro  de  linha

ostra um exe

4 ‐ Disposição 

6  apresent

ctivamente

de  cada nó

nte. 

xecução de

‐ Diagrama no

os arquivos

as  e  de  co

emplo da d

dos números

am  as  cha

ó escravo  r

e tarefas na 

o nó mestre.

s de entrad

olunas  de  c

isposição do

s do arquivo d

madas  das

e‐organiza 

aplicação n

 

a. Os arqui

cada  matri

os números

e entrada 

s  funções  p

as várias p

no nó mestr

ivos de ent

z,  seguidos

s no arquivo

para  alocaç

75 

partes 

re. 

radas 

s  dos 

o. 

ção  e 

 

76  

 Figura 45 ‐ Alocação das matrizes. 

 Figura 46 ‐ Leitura dos elementos das matrizes. 

A segunda etapa do processo é o particionamento das matrizes e sua organização, 

de forma linear, para que seja possível enviá‐las de forma sequencial para cada nó do 

cluster. A Figura 47 apresenta a forma como as matrizes são particionadas, em linhas e 

colunas. 

Figura 47 ‐ Algoritmo de particionamento da matriz A. 

Após o particionamento, além do envio das  sub‐matrizes, alguns parâmetros  são 

enviados para os escravos, estes serão explicados posteriormente, para que os dados 

das matrizes possam  ser  recebidos de  forma  correta. O envio de dados entre nós é 

feita através da rotina MPI_Send, como explicada anteriormente no capítulo 4. Como 

dito  acima,  neste  estudo  de  caso,  apenas  dois  nós  são  considerados.  A  Figura  48 

mostra o envio dos dados das matrizes A e B para os dois nós existentes no cluster. 

 

77  

 Figura 48 ‐ Envio dos dados para os nós escravos. 

No passo seguinte, o nó mestre fica a espera dos resultados parciais oriundos dos 

nós escravos. Durante um processamento tipo pooling, o nó mestre através da rotina 

MPI_Recv,  aguarda  o  resultado  do  processamento  dos  nós  escravos.  Uma  vez 

recebidos  todos  os  resultados  parciais,  os  mesmos  podem  ser  adequadamente 

processados  (somados), chegando, assim a matriz resultante. A Figura 49 mostra um 

exemplo de duas rotinas responsáveis para recepção de dados dos nós do cluster. 

Figura 49 ‐ Recebimento dos dados dos nós escravos.  

5.2.2 Aplicação nos Nós Escravos

A Figura 50 mostra um diagrama que mostra o funcionamento da aplicação nos nós 

escravos. 

 

 

C

refer

Estes

perm

E

a qua

tama

servi

mest

rotin

U

co‐pr

dado

Como prime

rência aos p

s parâmetro

missão para 

Em seguida,

antidade to

anho de cad

rão para a 

tre;  os  dad

na MPI_Recv

Uma vez arm

rocessador 

os  é  feita  a

eiro passo, 

parâmetros

os  indicam 

leitura e es

Figur

 após a rece

otal de elem

da bloco e 

correta alo

dos  relativo

v. 

mazenados

aritmético

através  de 

Figura 50 ‐

cada nó es

 char_drive

o nome d

scrita neste.

a 51 ‐ Abertur

epção dos p

mentos das 

o total de 

ocação dos 

s  ao  conte

 nos buffer

,  a  FPGA,  p

chamadas 

Diagrama no 

scravo acess

er do device

o  arquivo q

. 

ra do arquivo 

parâmetros

matrizes, su

elementos 

buffers que

eúdo  das  su

rs do PC, as

para  serem

de  funções

nó escravo.

sa um arqu

e driver, com

que  será  cr

para o char_d

s de control

uas quantid

que será re

e armazena

ub‐matrizes

s matrizes p

m multiplica

s  de  um  d

 

uivo de cont

mo mostrad

riado no di

driver. 

e do nó me

dades de lin

ecebido po

arão os dad

s  são  coleta

podem ser 

adas.  Esta  t

evice  driver

trole que p

do na Figur

retório  /de

 

estre, sendo

nhas e colun

or cada nó, 

dos vindos d

ados  atravé

enviadas p

transferênc

r  especialm

78 

possui 

ra 51. 

ev e  a 

o eles: 

nas, o 

estes 

do nó 

és  da 

para o 

cia  de 

mente 

 

79  

desenvolvido para este fim. Este device driver foi apresentado no capítulo 4. A Figura 

52 exemplifica estas ações. 

Figura 52 ‐ Funções do device driver para trocar dados com o FPGA. 

Nesta, a primeira função é responsável por ler os dados da memória do PC e enviar 

para o FPGA, a segunda tem o comportamento oposto, sendo responsável por enviar 

os dados do FPGA para o PC. 

 E usando  a MPI_Send, o nó escravo envia para o nó mestre o  resultado, que é 

parte da matriz resultante final. 

 

5.3 Core de Multiplicação de Matrizes

O core de multiplicação de matrizes usado neste projeto é  fruto de um  trabalho 

conjunto de mestrado no grupo HPCIn. Como dito anteriormente, a plataforma usada 

como co‐processadora, denominada de ML555, contém um FPGA da Xilinx, o Virtex‐5 

VLX50T  f1136‐1,  uma  memória  DDR2  de  256  MB  e  um  conector  PCIe.  O  ip‐core 

utilizado  para  fazer  a  comunicação  do  PC  e memória  do  FPGA  via  PCIe  possui  uma 

largura de banda de 3.2 GB/sec [38].  

O  barramento  de  comunicação  possui  oito  lanes  e  os  dados  são  transferidos 

usando  o  PCI‐DMA wrapper,  possibilitando  a  troca  de  dados  em  forma  de  rajada. 

Usando este wrapper, é possível transferir pacotes de até 1 MB por vez. 

O  algoritmo  de  multiplicação  de  matrizes  usado  consiste  na  decomposição  da 

operação  de  soma  das multiplicações  de  vetores.  Com  esta  abordagem,  é  possível 

explorar o paralelismo intrínseco ao uso de FPGAs e o reuso de dados. 

Considerando  o  algoritmo  expressado  como  Cnxn  =  Anxn  *  Bnxn,  os  elementos  da 

matriz resultante C são o resultado da operação cij = aik*bkj. Como a estratégia é reusar 

os dados ao máximo, estes foram internalizados na memória interna do FPGA, até que 

não  fossem  mais  precisos  para  realização  dos  cálculos.  Este  procedimento  foi 

desenvolvido para  se minimizar  ao máximo o número de  acessos  à memória DDR2, 

diminuindo o gargalo da largura da memória. 

 

 

A

mult

O

matr

linha

resul

soma

E

mesm

feita

A

nó 

proce

nós e

A  Figura  53

iplicações d

Figura

Observa‐se 

riz B,  como

as de B. Ca

ltante, cont

ando‐se tod

Este  métod

mos foram 

s n² multipl

Abaixo, na F

mestre,  q

essamento 

escravos pa

3  mostra  c

dos vetores

 53 ‐ Decomp

que ao  inv

 é  feito no

da multipli

tendo os el

das as matri

o  permitiu

lidos apena

licações len

Figura 54, p

ue  são:  e

em cada u

ra o nó me

como  a  ma

. 

osição das ma

és de  se m

ormalmente

cação  resu

ementos pa

izes parciais

  atingir  o 

as uma vez 

do‐se apen

podemos vi

envio  de 

m dos nós 

stre; e final

Figura 54 ‐ Flu

atriz  é  que

atrizes no pro

multiplicar a

e, a multipl

lta  em uma

arciais dest

s. 

máximo  d

da memóri

nas 2n dado

isualizar as 

dados  pa

(Nó 1 e Nó

mente a m

uxo de dados 

ebrada  e  c

oduto da mult

as  linhas da

icação é  fe

a nova mat

a. O resulta

e  reuso  de

a. Em cada 

s da memó

três etapa

rticionados 

ó 2), envio 

ontagem da

no nó mestre

como  é  fe

iplicação de v

 matriz A p

ita das  colu

triz  já da o

ado final é p

e  dados,  u

multiplicaç

ria. 

s vistas aci

para  os 

dos resulta

a matriz fina

e. 

ita  a  soma

vetores. 

pelas colun

unas de A 

ordem da m

portando o

uma  vez  qu

ção de veto

ma aplicad

nós  escr

ados parciai

al no nó me

 

80 

a  das 

 

as da 

pelas 

matriz 

obtido 

ue  os 

r, são 

as ao 

ravos; 

is dos 

estre. 

 

81  

5.4 Conclusões

Neste capítulo foi apresentado como foi desenvolvido o estudo de caso para que o 

cluster pudesse ser validado e  testado. Viu‐se que um algoritmo de particionamento 

de matrizes baseado no SUMMA foi implementado. 

Foi mostrado como se dá o algoritmo  tanto no nó mestre quanto nos escravos e 

como são feitas as chamadas ao device driver. 

Por  fim,  foi apresentado o  funcionamento do algoritmo de multiplicação que  foi 

prototipado nos FPGAs.   

 

82  

6. Resultados   Este  capítulo  tem  como  objetivo  apresentar  os  resultados  de  desempenho  da 

plataforma  desenvolvida.  Serão  exibidos  resultados  experimentais,  obtidos  com  a 

plataforma  em  funcionamento,  resultados  considerando  a  implementação  em  um 

único  FPGA,  e  resultados  obtidos  através  da  implementação  do  algoritmo  de 

multiplicação de matrizes em software. 

6.1 Análise Quantitativa dos Códigos

Como  primeira mostra  de  resultados  deste  trabalho, métricas  que mostram  a 

quantidade de linhas de códigos foram obtidas. A Tabela 7 mostra este esforço. 

  Número de Linhas de Código Aplicação em C  798 Device Driver  855 

Tabela 7 ‐ Número de linhas de código A  ferramenta Core Generator da Xilinx gerou um  core PCIe  com um  total de 65 

arquivos.  

6.2 Uso da Arquitetura

Como um dos resultados expressivos deste trabalho, pode‐se observar a facilidade 

do uso desta arquitetura. Para o usuário, com uma simples chamada ao sistema e uma 

fácil  organização  dos  arquivos  de  entrada,  é  possível  obter  o  resultado  da 

multiplicação das matrizes. Para isto, a seguinte chamada pode ser feita: 

mpirun ‐np <num_procs> blas_mpi <Arquivo da Matriz A><Arquivo da Matriz B> 

O parâmetro <num_procs>  indica quantos nós  serão usados no  cluster. No  caso 

deste estudo de caso o número usado é 2, devido à existência de apenas dois nós com 

FPGAs.  

Esta chamada é  responsável por  todo o processamento das matrizes, desde suas 

alocações, particionamentos, até a  comunicação  com os nós e os  respectivos FPGAs 

para que a multiplicação seja efetuada. 

 

 

 

83  

6.3 Estimativa de desempenho da plataforma

Com  a  descrição  de  todos  os módulos,  bem  como  o  funcionamento  deles,  foi 

possível  desenvolver  um  modelo  que  estimasse  o  desempenho  do  cluster  de 

multiplicação de matrizes. 

O modelo foi desenvolvido de forma a  levar em consideração todas as etapas do 

processo  de multiplicação  das matrizes,  sabendo  que  as matrizes  de  entradas  são 

menores  que  280x280,  devido  a  uma  limitação  do  hardware  que  só  permite 

multiplicação  de matrizes  de,  no máximo,  140x140. O  tempo  para multiplicar  duas 

matrizes  em  um  FPGA  foi  medido  experimentalmente  e  consiste  no  tempo  de 

processamento  gasto  pela  arquitetura  do  FPGA  para  realizar  a  operação  rodando  a 

uma freqüência de 200 MHz, somado ao tempo gasto para escrever os dados, vindos 

do PC, na memória DDR2 da placa. Este foi chamado de  FPGAT . 

Porém, é sabido que o tempo total de multiplicação, considerando dois nós, não 

poderia ser  )2/( FPGAT , pois existem alguns atrasos no sistema que devem ser  levado 

em consideração. 

Por isto foi chamado de  PARTT o tempo para o software particionar as matrizes da 

forma que serão enviadas para os nós do cluster, de  SOMAT  o tempo para o nó mestre 

somar  os  resultados  obtidos  dos  nós  escravos  e  de  MPIT   o  tempo  de  transmissão 

usando o MPI, tanto para enviar os dados quanto para recebê‐los. 

Com isto, pôde‐se concluir que o tempo de processamento da arquitetura,  ARQT , é 

da seguinte maneira:  SOMAFPGAMPIPARTARQ TTTTT +•++= 4 . O  fator multiplicador 4 é 

explicado devido ao fato que em uma multiplicação de matrizes que são particionadas 

em quatro blocos, cada nó realiza 4 multiplicações, como explicado no capítulo 5. 

 

6.4 Atrasos gerados pelo barramento PCIe 

Para que fosse possível analisar o atraso gerado pelo barramento pelo PCIe, foram feitas 

medições da seguinte forma: só considerando o tempo de processamento no FPGA, uma vez 

que os dados  já estariam na memória da placa, e o  tempo  total de processamento desde o 

envio dos dados, através do device driver, até o recebimento dos mesmos. A Figura 55 mostra 

matrizes de diferentes tamanhos sendo executada a multiplicação em um único FPGA, porém, 

 

 

prime

esse t

F

 

P

trans

Esse 

quan

orde

 

6.5 C

N

envo

em u

E

nó,  q

segu

proce

P

matr

quad

prim

eiramente  c

tempo. 

Figura 55 - Ex

Pode‐se  ob

smissão de 

atraso  se 

ndo  se  aum

m 140, o te

Comparaç

Nesta  seção

olvendo um

um único FP

Esta  implem

que  multip

nda  matriz

essamento 

Para efeito 

rizes  quadr

dradas  de  o

eiro cenári

onsiderando

xecução do alg

bservar  qu

dados via 

deu  em m

menta o  tam

empo de atr

ção de de

o,  serão m

 cluster de 

PGA. 

mentação do

plica  os  ele

z,  com  isto

deste clust

de compar

radas  de  o

ordem  280

o pudesse 

o o  tempo d

goritmo de mu

ue,  obviam

PCIe é maio

édia  8  vez

manho das 

raso se deu 

sempenho

ostradas  as

CPUs, o clu

o cluster de

ementos  da

o  foram  co

ter consider

ação,  foram

ordem  140 

0.  Esta  dife

ser feito um

de  transmiss

ultiplicação de

mente,  o  te

or que o  te

es  para ma

matrizes, q

de 1,3 veze

o hardwa

s  comparaç

uster de FP

e CPUs é  fe

a  linha  da 

olhidos  res

rando difere

m considera

  foram  ut

rença  de  t

ma compar

ão de dados

e matrizes con

empo  de 

empo desco

atrizes  peq

que para du

es. 

re x softw

ções  dos  r

GAs e esta 

eita utilizan

primeira  m

sultados  qu

entes taman

ados dois c

ilizadas;  no

tamanhos  f

ação entre 

s  via PCIe e 

nsiderando ape

execução 

onsiderando

uenas,  poré

uas matrize

ware

esultados  d

operação s

do um algo

matriz  pelo

ue  mostram

nhos de ma

enários. No

o  segundo,

foi  usada  p

o cluster e

 desconside

 

enas um FPGA

consideran

o a  transm

ém  é  dimin

es quadrad

de  desemp

sendo execu

oritmo, em 

os  da  colun

m  o  temp

atrizes. 

o primeiro, 

,  duas  ma

para  que  co

e um único 

84 

rando 

A.

do  a 

issão. 

nuído 

as de 

penho 

utada 

cada 

na  da 

po  de 

duas 

trizes 

om  o 

FPGA 

 

 

roda

softw

maio

O

<mes

códig

Figur

A

poss

matr

plata

imple

 

 

 

ndo  a mult

ware, visto 

ores que 140

Os  tempos

sure_time.h

go. A Figura

ra 56 ‐ Tempo

Ao  observar

ui um dese

rizes quadra

aforma  ati

ementação 

tiplicação. 

que o FPG

0. 

s  PARTT , 

h>, com fun

a 56 mostra

o de execução

r  os  resulta

empenho m

adas de ord

ngiu  um 

 do cluster 

No  segundo

GA usado nã

SOMAT   e 

nções que r

 os resultad

o em usec conclus

ados  do  grá

melhor que 

dem superio

speed‐up

de CPUs. 

 

o  cenário  f

ão  suporta 

MPIT   foram

retornam o 

dos encontr

siderando umster com dois áfico,  pode

o  cluster d

ores a 220. 

de,  aprox

 

foi  feita  ap

multiplicaç

m  obtidos

tempo de 

rados. 

ma implementnós. e‐se  perceb

de CPUs pa

Para matriz

ximadament

enas  a  com

ções de ma

s  utilizando

um determ

ação em softw

er  que  o  c

ra a multip

zes de tama

te,  1,25x 

mparação  c

atrizes de o

o  a  bibli

minado trech

ware, um FPG

cluster  de  F

plicação de 

anho 280x2

em  relaçã

85 

om o 

ordem 

oteca 

ho de 

 

GA e o 

FPGAs 

duas 

280, a 

ão  à 

 

86  

7. Conclusões e Trabalhos Futuros O estudo e sugestão de uma plataforma híbrida, baseada em um cluster, com nós 

controlados por CPUs de propósito geral e FPGAs, como co‐processadores foram aqui 

apresentadas.  Este  trabalho  voltado  para  o  processamento  de  algoritmos  que 

trabalham  com  processamento  massivo  de  dados  abordou  problemas  relativos  à 

comunicação entre nós,  comunicação entre CPU e  co‐processador, desenvolvimento 

de device drivers e interface com aplicações do usuário. 

Concluiu‐se  ser  possível  desenvolver  uma  estrutura  que  permita  abstrair  do 

usuário  recursos  de  hardware,  geralmente  difíceis  de  serem  programados  e/ou 

manipulados por programadores de aplicações.  

Para tal alguns dos principais problemas em comunicação entre computadores e 

entre FPGA e processadores foram estudados, bem como, device drivers especiais para 

comunicação  de  alto  desempenho  entre  dispositivos  e  entre  as  aplicações/sistema 

operacional e o co‐processador.   

Observou‐se  também  a  importância  do  uso  da  interface  MPI,  que  permitiu 

transparência e compatibilidade com vários dos sistemas de clusters já existentes. 

Um  estudo  de  caso  voltado  para  a  biblioteca  BLAS,  visando  multiplicação  de 

matrizes  densas  foi  implementada  no  cluster  com  sucesso.  Embora,  ainda  em  sua 

versão preliminar, a plataforma demonstrou aceleração nos nós do cluster com o uso 

dos  co‐processadores  em  FPGA.  Infelizmente,  devido  ao  tamanho  da  FPGA  e  da 

restrição  de  banda  da  interface  PCI  utilizada,  não  foi  possível  um maior  ganho  de 

desempenho. 

Os  resultados  experimentais  mostraram  que  quanto  maior  forem  as  matrizes 

maior  será  o  rendimento  do  uso  de  co‐processadores  como  os  FPGAs,  pois  será 

possível se valer cada vez mais do paralelismo intrínseco destes dispositivos.   

Como futuros trabalhos destacaram‐se a necessidade do uso de FPGAs com mais 

recursos  lógicos,  visando  um maior  número  de  elementos  de  processamento,  para 

aumentar  o  fator  paralelismo  e,  por  conseguinte  desempenho.  Também  será 

necessário mais memória  acoplada  ao  FPGA  para  otimizar  transferência  de  dados 

durante o processamento. Uma nova plataforma já está sendo desenvolvida com este 

propósito. Neste projeto também esta sendo estudados problemas relativos à redução 

 

87  

de  precisão,  novas  representações  aritméticas  e  compactação  de  dados  para 

otimização de processamento com algoritmos customizados em FPGAs.  

 Um outro estudo  importante a ser feito   é a comparação de   desempenho desta 

arquitetura com aquelas que usam GPUs como co‐processadores.   

 

88  

8. Referências Bibliográficas [1] Moore, G.E  1997.  The Microprocessor:  Engine  of  the  Technology Revolution.  In: 

Communications of the AMC. 1997 

[2] Brown, S., Vranesic, Z. 2000. Fundamentals of Digital Logic with vhdl Design. In: Mc 

Graw Hill, Toronto. 

[3] AMD. Multi‐core processros  the next evolution  in  computing.  In AMD Multi‐core 

technology whitepaper, 2005 

[4]  Intel.  Intel multi‐core processor architecture development backgrounder.  In  Intel 

whitepaper, 2005 

[5] Kalla, R., Sinharoy, B., Tendler, J. M. IBM Power5 Chip: A Dual‐Core Multithreaded 

Processor. IEEE Micro, 24(2):40‐47,Mar./Apr. 2004 

[6] McNairy, C., Montecito, R. A Dual‐Core, Dual‐Thread Itanium Processor. IEEE Micro, 

25(2): 10‐20,2005 

[7]  AMD,  http://multicore.amd.com/us‐en/AMD‐Multi‐Core/Multi‐Core‐

Advantages.aspx. 

[8] Intel, http://www.intel.com 

[9] AMD, http://www.amd.com 

[10]  Eigenmann,  R.,  Lilja,  D.  Von  Neumann  Computers,  In  Wiley  Encyclopedia  of 

Electrical and Eletronics Engineering, Volume 23, pages 387‐400, 1999 

[11] Brown, S., Rose, J. Architecture of FPGAs and CPLDs: A Tutorial,  IEEE Design and 

Test of Computers, vol. 13, no. 2, 1996, pp. 42–57. 

[12] DeHon, A. The Density Advantage of Configurable Computing. California Institute 

of Technology. 

[13]  Mackin,  B.,  Woods,  N.  FPGA  Acceleration  in  HPC:  A  Case  Study  in  Financial 

Analytics,Novembro2006.URL:http://www.xtremedatainc.com/pdf/FPGA_Acceleration

_in_HPC.pdf. Consultado em: 21 de janeiro de 2008. 

[14] http://www.mcs.anl.gov/research/projects/mpi/ 

[15] http://www.rpcmod.org 

[16] Lawson, C., Hanson, R., Kincais, D., Krogh, F. Basic Linear Algebra Subprograms for 

FORTRAN usage. ACM Trans. Math. Software, 5(3):308‐323,1979. 

 

89  

[17]  Kirk,  D.  Innovation  in  graphics  technology.  Talk  in  Canadian  Undergraduate 

Technology Conference, 2004. 

[18] Harris, M. GPGPU: Beyond graphics. Eurographics Tutorial,August 2004. 

[19] Patel, A., Madill, C.A., Saldana, M., Comis, C., Pomes, R., Chow, P. A Scalable FPGA‐

based Multiprocessor. Field‐Programmable Custom Computing Machines, 2006. FCCM 

apos; 06. 14th Annual IEEE Symposium on Volume, Issue, 24‐26 April 2006 Page(s): 111 

‐ 120. 

[20] Worley, P., et al., Comparative Analysis of Interprocess Communication on the X1, 

XD1, and XT3, Proc. Cray User Group Conference, USA, 2005 

[21] Extraordinary Acceleration of Workflows with Reconfigurable Application‐specific 

Computing  from  SGI.  Technical  report,  Silicon  Graphics,  Inc.,  Nov.2004. 

http://www.sgi.com/pdfs/3721.pdf 

[22] General Purpose Reconfigurable Computing Systems. 2005, SRC Computers,  Inc. 

http://www.srccomp.com/. 

[23] Extraordinary Acceleration of Workflows with Reconfigurable Application‐specific 

Computing  from  SGI.  Technical  report,  Silicon  Graphics,  Inc.,  Nov.2004. 

http://www.sgi.com/pdfs/3721.pdf 

[24] http://www.intel.com/technology/usb/spec.htm 

[25] Walters, J., Meng, X., Chaudhary, V., Oliver, T., Yeow, L., Schmidt, B., Nathan, D., 

Landman,  L.. MPI‐HMMER‐Boost: Distributed FPGA Acceleration;  in  the Special  Issue 

on  Computing  Architectures  and  Acceleration  for  Bioinformatics  Algorithms,  The 

Journal of VLSI Signal Processing.  2007. 

[26] Che, S., Li, J., Lach, J., Skadron, K. Accelerating compute intensive applications with 

GPUs  and  FPGAs.  In Proceedings of  the 6th  IEEE  Symposium on Application  Specific 

Processors, June 2008 

[27]  Fan,  Z.,  Qiu,  F.,  Kaufman,  A.,  Yoakum‐Stover,  S.  2004.  GPU  cluster  for  high 

performance computing. In Proceedings of SC’04, –. 

[28]  Thomas,  D.B.,  Howes,  L.,  Luk, W.  A  comparison  of  CPU’s,  GPU’s,  FPGA’s,  and 

massively  parallel  processor  arrays  for  random  number  generation,  ACM/SIGDA 

International Symp. on Field‐Programmable Gate Arrays, 2009, pp. 63‐72. 

[29] http://www.pisig.com 

[30] Corbet, J., Rubini, A., Kroah‐Hartman, G. Linux Device Drivers, Third Edition 

 

90  

[31]  Jeff,  T.  Grabianowoski  Ed.  How  PCI  works.  How  Stuff  Works:  Disponível  em 

http://computer.howstuffworks.com/pci.htm. Acesso em janeiro/2007 

[32] DeHon, A. The Density Advantage of Configurable Computing, Abril 2000. 

[33] Altera White Paper, Accelerating High‐Performance Computing With FPGAs 

[34] User's guide; Xilinx® Virtex™‐II Development Kit 

[35] http://www.actel.com/ 

[36] http://www.latticesemi.com 

[37] http://www.quicklogic.com/ 

[38] http://www.xilinx.com/itp/xilinx6/books/docs/cgn/cgn.pdf 

[39] http://www.gpgpu.org 

[40] http://www.gigabit‐ethernet.org/ 

[41] http://www.intel.com/technology/infiniband/ 

[42] https://dspace.ist.utl.pt/bitstream/2295/75926/1/artigo_exemplo_2.pdf 

[43]  Gokhale,  M.B.,  Graham,  P.S.  Reconfigurable  Computing:  Accelerating 

Computations  with  Field‐Programmable  Gate  Arrays.  Springer,  Dordretch,  The 

Netherlands, 2005 

[44] http://www.xilinx.com/products/devkits/HW‐V5‐ML555‐G.htm 

[45] R.A. Geijin. "SUMMA: Scalable Universal Matrix Multiplication Algorithm"