CLUSTER DE Cs USAN DO NÓS BASEA MÓDULOS...
Transcript of CLUSTER DE Cs USAN DO NÓS BASEA MÓDULOS...
“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Ê[email protected]/~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"