sistema de multiprocessamento numa fpga - ulisboa · 2.sistemas de multiprocessamento em fpgas ......
TRANSCRIPT
Sistema de multiprocessamento numa FPGA
Wilson Maltez José
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e de Computadores
Júri
Presidente: Prof. Nuno Cavaco Gomes Horta
Orientador: Prof. Horácio Cláudio de Campos Neto
Vogais: Prof. Mário Pereira Véstias
Prof. Pedro Filipe Zeferino Tomás
Outubro 2011
iii
Resumo Com o passar do tempo, surgem aplicações cada vez mais complexas e exigentes motivando
o avanço da tecnologia. Na área dos sistemas embebidos, os MPSoC (Multiprocessor Systems-on-
Chip) são uma solução cada vez mais adoptada pela indústria, possibilitando aos sistemas atingirem
as metas de tempo real e superarem as restrições de área e potência consumida. Nesta vertente, as
FPGAs são uma plataforma promissora para o desenvolvimento deste tipo de sistemas, já que os
sistemas de multiprocessamento em FPGAs apresentam um custo menor e um tempo de
desenvolvimento associado mais curto, relativamente às soluções ASIC.
Com este trabalho, pretendeu-se demonstrar que a FPGA é uma plataforma viável para
implementação de sistemas de multiprocessamento. Foi projectado e testado com sucesso numa
FPGA um sistema de multiprocessamento homogéneo com base num processador soft-core open
source. Foi utilizada uma aplicação de multiplicação de matrizes para estudar a aceleração e
eficiência do sistema. O atraso de comunicação revelou-se como o principal bottleneck do sistema de
multi-processamento desenvolvido. Foram desenvolvidas, comparadas e sintetizadas para um
dispositivo Virtex-6 duas arquitecturas capazes de suportar comunicação entre oito processadores.
Os sistemas baseados na arquitectura de comunicação comutador Crossbar e NoC mesh 2D com oito
núcleos de processamento tiveram um desempenho idêntico, no entanto, o comutador Crossbar
apresenta uma área de ocupação menor.
Palavras-chave:
Multiprocessamento, MPSoC, FPGA, sistemas embebidos, arquitecturas de comunicação
iv
Abstract As time goes by, new applications emerge more complex and demanding than ever, pushing
technology forward. In the embedded systems area, the MPSoC (Multiprocessor Systems-on-Chip)
solution is being increasingly adopted by industry, as it enables systems to reach their real time
deadlines and at the same time to overcome the area and power restrictions. In this respect, FPGAs
have emerged as a promising platform to develop these kind of systems. FPGA-based
multiprocessors can be a cheaper and faster to market solution when compared to ASIC-based
multiprocessors.
With this project, we intended to show that the FPGA is a practicable platform to design and
implement multiprocessing systems. A homogenous multiprocessing system based on a open source
soft-core has been designed and tested with success in a FPGA. A matrix multiplication application
has been parallelized and used to study the system acceleration and efficiency. The communication
delay has revealed itself as the main performance bottleneck of the multiprocessor system designed.
Two architectures capable of supporting communication between eight processors were designed,
compared and synthesized for a Virtex-6 device. The systems with the crossbar switch and with the
NoC mesh 2D based communication architectures, with 8 cores, have shown an identical
performance. However, the crossbar switch based system has a smaller occupied area
Keyword:
Multi-processing, MPSoC, FPGA, embedded systems, communication architectures
v
Índice
1. Introdução................................................................................................................................ 1
1.1 Multiprocessamento .................................................................................................................... 2
1.2 Objectivos ..................................................................................................................................... 6
1.3 Estrutura da tese .......................................................................................................................... 6
2.Sistemas de Multiprocessamento em FPGAs .............................................................................. 8
2.1 Viabilidade dos sistemas de multiprocessamento em FPGAs ....................................................... 8
2.2 Elemento de processamento ...................................................................................................... 10
2.2.1 Características importantes ................................................................................................. 10
2.2.2 Comparação de soft-cores ................................................................................................... 12
2.3 Arquitecturas de multiprocessamento ....................................................................................... 14
2.3.1 Classes principais de sistemas de multiprocessamento....................................................... 14
2.3.2 Implementações de sistemas de multiprocessamento........................................................ 18
2.4 Arquitecturas de Comunicação .................................................................................................. 22
2.4.1 Funcionalidades básicas ...................................................................................................... 22
2.4.2 Análise de arquitecturas ...................................................................................................... 23
3.Processador MB-LITE ............................................................................................................... 26
3.1. Arquitectura MB-LITE ................................................................................................................ 26
3.2 Teste do MB-LITE ........................................................................................................................ 30
4.Arquitectura De Multiprocessamento ...................................................................................... 32
4.1. Bloco Base ................................................................................................................................. 33
4.2. Arquitectura de comunicação ................................................................................................... 35
4.2.1 Dois Núcleos de Processamento .......................................................................................... 36
4.2.2. Comutador Crossbar ........................................................................................................... 37
4.2.2 NoC ...................................................................................................................................... 46
5.Resultados .............................................................................................................................. 52
5.1. Aplicação e metodologia de teste ............................................................................................. 52
5.1.1 Aplicação ............................................................................................................................. 52
5.1.2 Metodologia de teste .......................................................................................................... 59
5.2. Resultados de performance e utilização de recursos ................................................................ 60
5.2.1 Análise do Comutador Crossbar .......................................................................................... 61
5.2.2 Comutador Crossbar versus NoC ......................................................................................... 65
5.3. Implementação na FPGA ........................................................................................................... 68
vi
6.Conclusões e Trabalho Futuro .................................................................................................. 71
6.1 Conclusões.................................................................................................................................. 71
6.2 Trabalho Futuro .......................................................................................................................... 73
Referências Bibliográficas ........................................................................................................... 74
vii
Lista de Figuras
Figura 2.1 – Exemplos de topologias NoC ............................................................................................ 24
Figura 3.1 – Formato das instruções na arquitectura MicroBlaze ....................................................... 27
Figura 3.2 – Formato dos dados na arquitectura MicroBlaze .............................................................. 27
Figura 3.3 - Estrutura do MB-LITE e sinais de interface ....................................................................... 28
Figura 3.4. Estrutura do descodificador de endereços com dois escravos .......................................... 29
Figura 3.5 - Fluxograma de geração de uma memória de inicialização do sistema ............................. 31
Figura 4.1 - Estrutura do bloco base .................................................................................................... 34
Figura 4.2 – Sistema de multiprocessamento com dois núcleos de processamento ........................... 37
Figura 4.3 – Arquitectura do sistema de multiprocessamento com base no comutador crossbar ...... 39
Figura 4.4 - Estrutura dos pacotes do tipo cabeçalho e dados, respectivamente ................................ 40
Figura 4.5 - Estrutura simplificada do router com 4 entradas e 4 saídas. ............................................ 41
Figura 4.6 - Esquema representativo do Adaptador de Rede .............................................................. 43
Figura 4.7 – Estrutura do árbitro com suporte para broadcast ........................................................... 45
Figura 4.8 – Estrutura básica de um nó constituinte da NoC ............................................................... 46
Figura 4.9 – Estrutura da NoC desenvolvida com 8 elementos de processamento e topologia mesh2D
............................................................................................................................................................. 47
Figura 4.10 – Estrutura dos pacotes para arquitectura NoC ................................................................ 48
Figura 4.11 – Estrutura do router da arquitectura NoC ....................................................................... 50
Figura 5.1 – Algoritmo básico de paralelização da multiplicação de matrizes ..................................... 54
Figura 5.2 – Fases do algoritmo 2 ......................................................................................................... 56
Figura 5.3 – Fluxograma representativo do funcionamento do algoritmo 2 ........................................ 57
Figura 5.4 – Gráfico do speedup dos sistemas com dois, quatro e oito processadores ....................... 64
Figura 5.5 – Gráfico da eficiência dos sistemas com dois, quatro e oito processadores ..................... 65
Figura 5.6 – Spartan-3E e interfaces relevantes .................................................................................. 68
Figura 5.7 – Circuito responsável pelo envio dos resultados para o PC ............................................... 69
Figura 5.8 – Máquina de estados controladora do envio de dados para o PC ..................................... 69
viii
Lista de Tabelas
Tabela 1.1 – Taxonomia de Flynn ........................................................................................................... 3
Tabela 2.1 – Características principais dos processadores estudados. ................................................. 13
Tabela 2.2 – Arquitecturas de MPSoC ................................................................................................. 15
Tabela 2.3 – Arquitecturas de comunicação ........................................................................................ 16
Tabela 2.4 – Métodos de troca de informação .................................................................................... 17
Tabela 3.1 – Resultados da síntese do MB-LITE sob diferentes configurações .................................... 30
Tabela 4.1 - Mapeamento de memória dos elementos do bloco base ................................................ 34
Tabela 5.1. Comparação entre o algoritmo 1 e 2 ................................................................................. 58
Tabela 5.2 – Resultados da síntese do sistema de multiprocessamento para um, dois, quatro e oito
núcleos de processamento .................................................................................................................. 62
Tabela 5.3 – Resultados da síntese individual dos módulos router e adaptador de rede para cada
arquitectura ......................................................................................................................................... 62
Tabela 5.4 – Resultados de performance do sistema de multiprocessamento para um, dois, quatro e
oito núcleos de processamento .......................................................................................................... 63
Tabela 5.5 – Resultados da síntese de três sistemas configurados com oito núcleos de processamento
............................................................................................................................................................. 65
Tabela 5.6. – Resultados da síntese dos routers em cada um dos três sistemas comparados ............ 66
Tabela 5.7. – Resultados temporais das arquitecturas comutador crossbar e NoC ............................. 67
ix
Lista de Abreviações
ALU Arithmetic Logic Unit
ASIC Application Specific Integrated Circuit
BRAM Block Random Access Memory
CMP Chip-Scale Multiprocessor
CPU Central Processing Unit
DIMEM Data Instruction Memory
DIMMA Distribution Independent Matrix Multiplication
DSP Digital Signal Processors
EDK Embedded Development Kit
EX Execute
FFT Fast Fourier Transform
FIFO First In First Out
FPGA Field Programmable Gate Array
FPU Floating Point Unit
FSL Fast Simplex Link
FWFT First Word Fall Through
GCC GNU Compiler Collection
GPU Graphical Processing Unit
HDL Hardware Description Language
HIBI Heterogeneous IP Block Interconnection
ID Instruction Decode
IF Instruction Fetch
IP Intellectual property
IPv4 Internet Protocol version 4
ISA Instruction Set Architecture
x
LE Logic Element
LED Light-emitting diode
LUT Lookup Table
MEM Memory
MIMD Single Instruction Stream, Single Data Stream
MIN Multistage Interconnection Network
MISD Multiple Instruction Stream, Single Data Stream
MMU Memory Management Unit
MPEG-4 Moving Picture Experts Group- 4
MPI Message Passing Interface
MPSoC Multiprocessor System on Chip
NA Network Adapter
NoC Network on Chip
PC Program Counter
POSIX Portable Operating System Interface for Unix
PUMMA Parallel Universal Matrix Multiplication
RAM Random Access Memory
RAW Read After Write
RISC Reduced Instruction Set Computer
ROM Read Only Memory
RS232 Recommended Standard 232
RSSA Scalable Multi-Processor Resource Sharing and Synchronization Arbiter.
SDRAM Synchronous Dynamic Random Access Memory
SIMD Single Instruction Stream, Multiple Data Stream
SISD Single Instruction Stream, Single Data Stream
SMP Symmetric Multiprocessor
SUMMA Scalable Universal Matrix Multiplication
UART Universal Asynchronous Receiver/Transmitter
xi
VHDL VHSIC hardware description language
WB WriteBack
XST Xilinx Synthesis Technology
1
Introdução
Durante muitos anos confiou-se na diminuição da dimensão dos transístores como meio de
projectar processadores mais rápidos. A abordagem tradicional de aumentar a frequência de relógio
com o objectivo de obter uma maior performance atingiu um limite, devido a problemas como o
consumo de potência e dissipação de calor. Uma das alternativas estudada e implementada é a
exploração do paralelismo a nível das instruções. Este tipo de paralelismo é explorado pelos
processadores super-escalares, e permite a execução de mais do que uma instrução em simultâneo.
Os processadores super-escalares são bastante complexos e o ganho de performance nem sempre
compensa a complexidade adicional [1]. Outra solução consiste nos chamados sistemas de
multiprocessamento. Sistemas de multiprocessamento são sistemas com mais de um elemento de
processamento que permitem a execução de vários processos ou tarefas em simultâneo. Os sistemas
de multiprocessamento apareceram primeiramente como múltiplos chips conectados. Com o
avançar da tecnologia, começaram a aparecer também sistemas de multiprocessamento completos
integrados num único chip. Estes tipos de sistemas são designados por sistemas de
multiprocessamento em chip, MPSoC (Multi Processor Systems on Chip). O aparecimento dos MPSoC
ou também chamados CMP (Chip Scale Multiprocessors) permitiram reduzir a latência de
comunicação entre os elementos do sistema já que os atrasos de comunicação dentro de um chip
são menores [1].
Actualmente, os MPSoC são uma solução bastante atractiva mesmo para sistemas
embebidos. Os MPSoC são uma solução que permite aos sistemas embebidos atingirem as suas
metas de tempo-real superando, ao mesmo tempo, restrições críticas em termos de consumo de
energia e área ocupada [2]. Diversas aplicações beneficiam deste tipo de sistemas como, por
exemplo, codificação de áudio/vídeo, processamento de imagem, entre outras. Um exemplo da
exigência requerida nos sistemas embebidos actuais é o telemóvel. Os modelos actuais têm um
consumo baixo de potência e integram um grande número de funcionalidades tais como codificação
de áudio e vídeo, processamento de imagem e acesso à internet. Os MPSoC oferecem a melhor
performance com um consumo de potência mais baixo neste tipo de sistemas complexos em
comparação com sistemas embebidos com um só processador [2].
No campo dos MPSoC, as FPGAs (Field Programmable Gate Array) aparecem como uma
plataforma nova e promissora para implementação de sistemas de multiprocessamento. As FPGAs
1
2
facilitam a rápida prototipagem e permitem a pesquisa de novas arquitecturas e formas de
comunicação sem os problemas da produção ASIC (Application Specific Integrated Circuit). As FPGAs
apareceram primeiramente como meio de implementar e testar protótipos para subsequente
implementação em ASIC. No entanto, começam já a emergir projectos finais em FPGAs também.
Actualmente, as FPGAs têm já uma complexidade muito significativa, o que permite implementar
dezenas de processadores no mesmo dispositivo oferecendo assim uma capacidade considerável
para computação paralela. Para além disso, as companhias de FPGAs disponibilizam processadores
soft-core projectados especificamente para ocupar o mínimo de recursos. São também
disponibilizados, em certas FPGAs, processadores hard-core embebidos optimizados para uma
melhor performance. Processadores soft-core consistem em processadores projectados com o
objectivo de serem mapeados nos recursos lógicos de um ASIC ou FPGA, enquanto os processadores
hard-core são componentes embutidos nos dispositivos e projectados a nível de transístor.
Na secção 1.1 aborda-se o conceito de multiprocessamento, incluindo aspectos importantes
a ter em consideração no projecto de um sistema de multiprocessamento. A secção 1.2. refere os
principais objectivos deste trabalho. Na secção 1.3 é descrita a estrutura da tese.
1.1 Multiprocessamento
Os multi-processadores podem ser categorizados segundo vários tipos. Uma boa forma de
categorizar o tipo de multi-processadores existentes consiste na taxonomia de Flynn, ver tabela 1.1.
Esta categorização baseia-se no paralelismo do fluxo de dados e instruções e exibe quatro categorias:
Fluxo de instruções único, fluxo de dados único (single instruction stream, single data stream,
SISD) Os processadores com um único núcleo de processamento pertencem a esta
categoria [3].
Fluxo de instruções único, múltiplos fluxos de dados (single instruction stream, multiple data
streams, SIMD) A mesma instrução é executada por múltiplos processadores usando
fluxos diferentes de dados. Os sistemas SIMD exploram paralelismo a nível dos dados,
aplicando as mesmas operações a múltiplos blocos de dados em paralelo. Cada processador
tem a sua própria memória de dados, existe no entanto uma única memória de instruções e
um processador de controlo que busca e emite as instruções. Esta abordagem pode ser
bastante eficiente para aplicações que apresentam um elevado grau de paralelismo a nível
dos dados, por exemplo aplicações gráficas.
3
Múltiplo fluxo de instruções, fluxo de dados único (multiple instruction streams, single data
stream, MISD) N processadores, cada um com a sua própria unidade de controlo,
partilham uma unidade de memória. O paralelismo é obtido deixando os processadores
operar de forma diferente sobre os mesmos dados, em simultâneo. Máquinas MISD são úteis
em aplicações onde a mesma entrada é submetida a diferentes operações, por exemplo:
problemas de classificação. O tipo de operações que podem ser realizadas eficientemente
nos computadores MISD é bastante especializado. Não foi ainda construído nenhum multi-
processador comercial deste tipo até à data.
Múltiplo fluxo de instruções, múltiplo fluxo de dados (multiple instruction streams, multiple
data streams, MIMD) Cada processador busca as suas próprias instruções e opera nos
seus próprios dados. Os computadores do tipo MIMD exploram paralelismo a nível de tarefas
já que múltiplas tarefas operam em paralelo. Em geral, paralelismo a nível das tarefas é mais
flexível que paralelismo a nível dos dados e por isso mais aplicado. Um MIMD pode ser tanto
aplicado num único processador como numa rede de processadores separados tal como um
cluster.
Tabela 1.1 – Taxonomia de Flynn [3]
Single Instruction Multiple Instruction
Single Data SISD MISD
Multiple Data SIMD MIMD
Fundamentos de processamento paralelo
Processamento em paralelo consiste basicamente em vários processadores trabalharem em
conjunto com o objectivo de completar uma tarefa. A ideia principal é dividir a computação em
unidades mais pequenas que são distribuídas entre os processadores. Desta forma, o tempo de
computação é reduzido por um factor máximo de N, em que N é número de processadores que
constituem um sistema de multiprocessamento. A maioria dos algoritmos paralelos implica dois tipos
básicos de custo [4]:
Atraso computacional – que engloba todas as operações lógicas/aritméticas e relacionadas.
Atraso de comunicação – que inclui o movimento de dados.
Numa análise realística, devem ser tomados em conta ambos os factores.
4
Esquemas de partição
Do ponto de vista do software, existem duas abordagens básicas usadas para criar uma aplicação
paralela.
Partição funcional: Neste caso, a tarefa consiste numa única função que é subdividida entre
os processadores. Cada processador é responsável por executar uma partição desta função
aplicada aos dados, enquanto estes são movidos num esquema pipeline de um processador
para o outro.
Partição de dados: Neste caso, a tarefa é particionada para que cada processador execute
exactamente a mesma função, mas em diferentes sub-blocos de dados. Esta abordagem
requer algoritmos com um grande paralelismo intrínseco. Neste trabalho a aplicação
escolhida é paralelizada desta forma.
Aspectos arquitecturais
Do ponto de vista do hardware, duas importantes questões devem ser consideradas:
A configuração da memória (memória partilhada versus distribuída): Num sistema de
memória distribuída, cada processador tem a sua memória local, e a informação é trocada
através de mensagens entre processadores. Em contraste, os processadores num sistema de
memória partilhada partilham uma memória em comum. Embora os dados sejam facilmente
acedidos por qualquer processador, os acessos à memória podem gerar conflitos que limitam
o desempenho.
A rede de comunicação define a forma como os processadores estão interligados. As redes
em que todos os processadores estão directamente conectados uns aos outros são as redes
ideais do ponto de vista de facilidade de uso. No entanto, são impraticáveis em grandes
sistemas de multiprocessamento devido ao overhead em termos de hardware associado.
Arrays lineares, malhas (meshes), hiper-cubos (hypercubes), árvores (trees), e redes
totalmente interligadas são algumas das topologias mais comuns utilizadas. As topologias
hiper-cubo são bastante populares nos sistemas de multiprocessamento comerciais porque
fornecem uma boa conectividade e uma excelente capacidade de mapeamento. De facto, é
possível embeber praticamente qualquer outra topologia numa rede hiper-cubo. As
topologias malha são comuns e têm o objectivo de criar sistemas modulares e facilmente
expansíveis. Quando são usados sistemas de memória distribuída, questões de inter-
conectividade são relevantes para o mecanismo de troca de mensagens.
5
Medidas de performance
A performance de um sistema de multiprocessamento pode ser caracterizada através da Lei
de Amdhal, a qual relaciona a performance de um dado programa num multi-processador com a
porção sequencial e paralela do código [6].
𝑇 𝑁 = 𝑆 + 𝑃
𝑁 (1.1)
Na equação 1.1, T(N) refere-se ao tempo total de execução do programa, sendo S o tempo de
execução da parte sequencial do código, P o tempo de execução da porção paralela do código
quando executado sequencialmente e N o número de núcleos de processamento. O speedup pode
ser então definido pela equação:
𝑆𝑝 𝑁 = 𝑇 1
𝑇 𝑁 (1.2)
T(1) é o tempo de execução do algoritmo quando este é completado sequencialmente, e T(N) é o
tempo de execução do programa quando utilizados N processadores. Teoricamente, o speedup
máximo que se pode obter por um computador paralelo com N processadores idênticos a trabalhar
concorrentemente num único problema é N. No entanto, outros factores importantes (tais como a
concorrência intrínseca do problema a ser computado, conflitos de acesso à memória, e atraso de
comunicação) devem ser considerados. Estes factores podem reduzir o speedup.
𝐸 𝑁 = 𝑆𝑝(𝑁)
𝑁 (1.3)
Eficiência, definida como na equação 1.3, com valores entre 0 e 1, é uma medida da utilização de um
processador. Um valor próximo de 1 revela um algoritmo eficiente. Se a eficiência é menor que 0,5, é
normalmente melhor utilizar menos processadores porque usar mais processadores não oferece
6
vantagem [4]. Geralmente, o custo da comunicação deve ser minimizado utilizando esquemas de
particionamento inteligentes e através da sobreposição de operações de CPU e E/S [44].
1.2 Objectivos
O objectivo principal foi o projecto e implementação de um sistema de multiprocessamento
numa FPGA, de modo a acelerar uma aplicação. De acordo com este objectivo, o projecto foi divido
em três fases. A primeira fase correspondeu à escolha de um elemento de processamento como base
do sistema. A segunda fase prendeu-se com o dimensionamento de uma arquitectura simples de
comunicação para interligação entre os elementos de processamento. Por último, foi escolhida uma
aplicação a mapear no hardware e foi desenvolvido o sistema demonstrador.
O sistema desenvolvido destina-se a aplicações que têm como base operações matriciais
e/vectoriais e foi optimizado nesse sentido. Este tipo de aplicações encontra-se em diversas áreas,
seja redes de comunicação, processamento de imagem, aprendizagem automática, entre outras.
Além disso, este tipo de aplicações apresenta em geral, um bom grau de paralelismo, o que facilita a
programação e mapeamento num sistema de multiprocessamento. O sistema é, no entanto,
genérico o suficiente para mapear outro tipo de aplicações.
1.3 Estrutura da tese
O texto está dividido em seis capítulos. No segundo capítulo são abordados especificamente
os sistemas de multiprocessamento em FPGAs. Primeiramente são apresentadas as vantagens e
desvantagens de conceber sistemas de multiprocessamento baseados em FPGAs. Depois analisam-se
vários processadores e é escolhido um como elemento base para o nosso sistema de
multiprocessamento. Em seguida apresenta-se uma descrição geral das arquitecturas de
multiprocessamento existentes e analisa-se um conjunto de implementações já existentes. Por fim a
análise é particularizada para arquitecturas de comunicação apresentando-se os seus fundamentos
teóricos e comparando-se diversos tipos de arquitecturas.
No capítulo 3, o processador escolhido é caracterizado. A arquitectura do processador é
descrita e apresentam-se os resultados de síntese para um dispositivo alvo. São também descritos de
forma breve os passos a seguir para o desenvolvimento de software para o processador.
7
No capítulo 4 é especificado o sistema de multiprocessamento desenvolvido e discutidas as
opções arquitecturais tomadas. Primeiramente apresentam-se as fases do projecto e algumas
considerações a ter antes de iniciar o projecto da arquitectura do sistema. Na secção seguinte
descreve-se o bloco base (processador e periféricos) a ser replicado nos sistemas de
multiprocessamento desenvolvidos. Seguidamente detalham-se as arquitecturas de comunicação
desenvolvidas e suas particularidades.
No capítulo 5 é em primeiro lugar descrita a aplicação escolhida para testar o sistema de
multiprocessamento projectado. Seguidamente é discutida a metodologia de teste do sistema de
multiprocessamento. Em seguida são apresentados e analisados os resultados de área/performance
do sistema. Por fim descreve-se a implementação do sistema de multiprocessamento numa FPGA e
discutem-se os resultados obtidos.
Por fim no capítulo 6 é feita uma reflexão geral sobre o trabalho efectuado e apresentadas
propostas para o trabalho futuro. Primeiramente são destacadas as contribuições do trabalho e em
seguida retiradas conclusões do estudo concretizado ao longo do projecto. No final são discutidas
optimizações futuras para o sistema projectado e quais são os passos a seguir no âmbito da área dos
sistemas de multiprocessamento em FPGAs.
8
Sistemas de Multiprocessamento em FPGAs
Neste capítulo são revistos trabalhos existentes sobre sistemas de multiprocessamento em
FPGAs. Começa-se por efectuar uma reflexão sobre a viabilidade das FPGAs como plataforma para
desenvolvimento de sistemas de multiprocessamento na secção 2.1. Na secção 2.2 é apresentado
um estudo sobre os processadores baseados em FPGAs, e escolhido o elemento de processamento
que melhor se adequa ao nosso projecto. A secção 2.3 descreve as arquitecturas actuais de sistemas
de multiprocessamento em FPGAs. É apresentada uma base teórica que descreve os tipos de
arquitecturas conhecidas e em seguida descritos vários sistemas de multiprocessamento
implementados em FPGAs (vantagens/desvantagens). Por fim, na secção 2.4 a discussão dos sistemas
de multiprocessamento é particularizada para as arquitecturas de comunicação.
2.1 Viabilidade dos sistemas de multiprocessamento em FPGAs
Os sistemas de multiprocessamento baseados em FPGA são cada vez uma importante
tendência na área dos MPSoC. As FPGA facilitam a rápida prototipagem e permitem a pesquisa de
novas arquitecturas e técnicas de comunicação sem os problemas envolvidos na produção de MPSoC
em ASIC (custos elevados e dificuldade de correcção de erros). Os sistemas de multiprocessamento
em FPGA apresentam-se normalmente como uma forma de realizar protótipos de sistemas para
subsequente implementação em ASIC. No entanto actualmente são também já implementados
produtos finais com recurso a este tipo de sistemas. O crescimento na capacidade das FPGAs permite
actualmente aos projectistas implementar um sistema completo de multiprocessamento com
dezenas de processadores num único dispositivo [2]. As principais empresas de FPGAs oferecem a
possibilidade de usar processadores soft-core especialmente projectados para ocupar o mínimo de
área possível nos seus dispositivos. Para além disso alguns dispositivos incluem processadores hard-
core embebidos. A maioria das FPGAs inclui também blocos de memória on-chip, periféricos e
circuitos de interligação. Algumas FPGA podem ser reconfiguradas em tempo real o que constitui
uma área de investigação bastante promissora adicional. Esta característica das FPGA permite
projectar sistemas de multiprocessamento que se adaptam a uma aplicação em particular
fornecendo uma grande flexibilidade ao sistema.
2
9
Uma questão preponderante que se põe é se compensa implementar este tipo de sistemas,
ou mesmo faz sentido. A resposta é que depende. Depende dos objectivos, das metas a cumprir no
sistema implementado. A principal desvantagem de implementar sistemas de multiprocessamento
em FPGA é a performance reduzida e o maior consumo de potência face aos sistemas em ASIC. No
entanto as FPGA apresentam diversas vantagens que podem compensar de alguma forma esse facto:
1) Flexibilidade e reconfiguração: O número de soft-cores que podem ser incluídos é apenas
limitado pela capacidade da FPGA. Além disso, é possível configurar cada processador
independentemente, seja adicionando uma cache, unidades funcionais extra, co-
processadores, etc. [2]
2) Menos tempo para chegar ao mercado: O processo de projecto não inclui o fabrico do IC
(Integrated-Circuit) reduzindo consideravelmente o tempo de projecto [2].
3) Menos custo: O processo é mais barato. É possível implementar um projecto numa FPGA
com recurso a uma pequena equipa. Além disso, se existir um erro no sistema não é decisivo
[2].
4) Escalabilidade: Sistemas de multiprocessamento em FPGAs podem comportar um cada vez
maior número de microprocessadores ou periféricos caso existam recursos disponíveis na
FPGA [2].
Por isso, usar uma FPGA é a melhor escolha em determinados casos:
a) Baixo-volume. Projectos com um objectivo crítico (e.x: radar, aplicações militares);
b) Projecto rápido de novos sistemas de multi-processadores baseados em hardware
reconfigurável;
c) Investigação. Podem ser desenvolvidas e testadas novas arquitecturas, sistemas de
comunicação com facilidade;
d) Sistemas de crescimento contínuo. Sistemas que necessitam de crescer nas características
que apresentam dependendo do estágio de desenvolvimento.
O uso da tecnologia FPGA apresenta ainda diversos benefícios para sistemas embebidos.
Estes benefícios incluem a habilidade corrigir bugs de projecto no hardware da FPGA, fazer upgrade
do sistema em campo, ou simplesmente trocar a funcionalidade do hardware sem ter que projectar
novamente a placa que contém o circuito [2].
As ferramentas fornecidas pelas empresas são primariamente desenvolvidas para projectar
sistemas com um só processador, pelo que as soluções que disponibilizam para projectar sistemas de
multiprocessamento são muito limitadas. Apresentam por isso diversas deficiências no que toca a
providenciar a flexibilidade necessária para explorar todas as possibilidades no projecto de sistemas
10
de multiprocessamento. Em [5] são apresentadas algumas destas deficiências em detalhe.
Resumidamente tem-se:
Limitações nas arquitecturas para comunicação entre processadores. São apenas permitidas
ligações ponto a ponto ou com recurso a um bus partilhado;
Falta de mecanismos eficientes para partilha de recursos;
Limitação na utilização de núcleos IP. Os núcleos que se podem incluir no projecto estão
limitados à biblioteca do vendedor.
Na secção seguinte serão discutidos os aspectos mais importantes a considerar na escolha de
um elemento de processamento para projecto de um sistema de multiprocessamento. Serão
também discutidas e analisadas a importância e viabilidade dos processadores soft-core.
2.2 Elemento de processamento
Implementar sistemas de multiprocessamento de raiz representa por vezes custos
proibitivos. Como foi referido no capítulo anterior a FPGA é uma plataforma que apresenta um custo
de desenvolvimento baixo. Ainda assim projectar circuitos em HDL (High Description Language)
consome bastante tempo e pode ser penoso para os projectistas. Uma alternativa ao projecto de um
processador de raiz em HDL consiste no uso de processadores soft-core. Neste projecto será utilizado
um processador soft-core. Mais à frente neste capítulo serão avaliados diversos processadores soft-
core e escolhido um. Subsequentemente o foco do projecto passará para implementação da
arquitectura de comunicação do sistema de multiprocessamento.
Os processadores soft-core apresentam um conjunto de benefícios que os tornam apelativos.
Estes permitem uma maior rapidez de projecto de um sistema e baixo custo. Outras vantagens a
considerar consistem na maior facilidade de teste, portabilidade e o facto destes se encontrarem
optimizados em termos de área e performance para uso em FPGA.
2.2.1 Características importantes
A escolha do processador considerou principalmente três características fundamentais:
performance, área ocupada e facilidade de programação. No entanto, outras características
importantes foram também tidas em conta:
11
Rapidez de simulação e síntese do processador, de modo a facilitar o rápido teste do
sistema;
Flexibilidade do processador, isto é, facilidade/possibilidade de remoção/adição de unidades
funcionais (co-processadores, unidades de floating-point, unidades de divisão ou
multiplicação).
Compatibilidade com um bus de comunicação simples e eficiente, de forma a facilitar a
ligação do processador a outros componentes do sistema e evitar latência adicional derivado
dos meios de comunicação.
Documentação/Legibilidade do código/ Organização hierárquica do projecto, está
directamente relacionado com a usabilidade do processador.
Portabilidade, se o softcore está restringido em termos de plataformas a utilizar, FPGAs.
Algumas deficiências dos soft-core implementados em dispositivos reconfiguráveis têm a ver
com o facto de os recursos lógicos serem mais limitados e a velocidade de processamento ser mais
reduzida. A implementação de uma arquitectura RISC tenta minimizar estes problemas porque
permite velocidades de processamento mais altas com menor utilização de recursos. Por esta razão,
a maior parte dos softcore existentes implementa uma arquitectura RISC [6]. Para além disso estes
são normalmente baseados em arquitecturas previamente existentes, MIPS, PowerPC, ARM, ou
SPARC que são simples e fáceis de implementar. Arquitecturas CISC são complexas e morosas de
implementar e testar [6].
Rapidez na simulação e síntese do processador são cruciais em trabalhos de investigação
visto que normalmente se pretende experimentar diferentes configurações rapidamente. Portanto, a
utilização de processadores muito complexos, com vários andares de pipeline, arquitecturas de
memória complexas, ou buses de interfaces menos amigáveis não é aconselhável.
A facilidade de programação está directamente relacionada com a existência ou não de uma
toolchain que possibilite programar em C/C++. Programar em Assembly, apesar de possibilitar uma
maior optimização por ser uma linguagem mais próxima da arquitectura, é extremamente penoso
para o programador. A existência de um debugger contribui também para uma maior facilidade de
programação já que implica facilidade na detecção e correcção de erros no código.
Quanto à flexibilidade há alguns softcores que incluem os meios para facilitar a inclusão ou
não de unidades funcionais adicionais. Poder configurar o processador de forma a ter uma versão
mais simples e leve deste pode ser importante a nível de testes ou optimização dada uma
determinada aplicação, por exemplo. Uma interface com um bus simples e rápido é também uma
característica a ter em conta visto que permite uma maior facilidade de interligação do processador
com outros blocos IP. Documentação, legibilidade do código e organização hierárquica do projecto
12
são importantes principalmente no caso de existir a necessidade de fazer modificações ao
processador e de forma a compreender o seu funcionamento e acelerar o processo de aprendizagem
na sua utilização. Por fim, a portabilidade prende-se com a intenção de não limitar a implementação
do sistema desenvolvido a uma única plataforma. Como já foi referido em cima, a utilização de soft-
cores descritos puramente de forma comportamental aumenta a portabilidade.
2.2.2 Comparação de soft-cores
De forma a ter-se uma comparação razoavelmente padronizada e actualizada teve-se como
base os estudos publicados em [7] e [8]. Os dados relativos a cada processador apresentados nesta
secção são portanto retirados na sua maioria destes dois documentos. Na tabela 2.1 estão
representados os atributos principais respectivos a cada softcore, os quais se consideram ser
representativos das características apontadas anteriormente como preponderantes na escolha de
um softcore para o sistema. Da escolha dos processadores a incluir na comparação excluíram-se a
priori os de 8 bits, derivado da sua reduzida capacidade de endereçar memória. Processadores com
arquitecturas muito complexas como o OpenSPARC foram excluídos também, até porque estes não
são direccionados a sistemas embebidos que é o foco neste trabalho.
Na análise efectuada concluímos então que se iria optar por um processador soft-core open
source, não só pela vantagem de não ser limitado a determinada plataforma mas também porque se
tem acesso ao código fonte do softcore para possíveis alterações que possam ser necessárias
efectuar. Além disso a diferença de performance entre os soft-core open source e as versões
comerciais é relativamente pequena.
A comparação entre os softcores open source efectuada daqui para a frente tem por base o
estudo em [7], no qual os autores referem que todos os softcores foram sintetizados tendo como
alvo um dispositivo Virtex 5 (XC5VLX110-3FF1760) usando o Xilinx XST 10.1.03 e configurados de
forma a utilizarem o menor número de recursos possíveis para ter uma comparação o mais válida
possível [7]. Em termos de desempenho os processadores foram avaliados com a execução dos
programas de benchmark Dhrystone e Fibonacci e comparados com base no tempo de execução [7].
Depois de uma análise cuidada, o softcore escolhido foi o MB-LITE. O MB-LITE apresenta os
melhores resultados em termos de performance com um tempo de execução inferior aos outros
softcores open source, e mesmo inferior ao MicroBlaze da Xilinx. Para além disso apresenta uma
utilização de recursos muito baixa.
13
Tabela 2.1 – Características principais dos processadores estudados.
CPU Licença FCLK
máxima (MHz)
Área (LUT)
Arquitectura Flexibilidade Tools Pipeline
Interface
MicroBlaze Xilinx (close source)
200 [9]
1324 [8] MicroBlaze 32-bit RISC
MMU, FPU e MUL opcionais [8]
MB-GCC toolchain
3,5 andares
FSL
Nios II/f Altera (close source)
200 [9]
1800 [8] Nios II 32-bit RISC
MMU, FPU e MUL; MUL é opcional [8]
GNU toolchain
6 andares Avalon
Leon 3 Gaisler (open source)
183 [9]
4581 [7] SPARC-v8 32-bit RISC
MMU, FPU e MUL opcionais [7]
GNU toolchain
7 andares AMBA 2.0 AHB e UART
AEMB Aeste (open source)
279 [7]
1637 [7] MicroBlaze 32-bit RISC
MUL opcional [7]
MB- GCC toolchain
3 andares Wishbone e FSL
OpenFire Open Source
198 [7]
959 [7] Microblaze 32-bit RISC
MUL opcional[7]
GNU toolchain
3 andares FSL
MB-Lite Open Source
229 [7]
1450 [7]
Microblaze 32-bit RISC
MUL opcional [7]
MB- GCC toolchain
5 andares Wishbone
Plasma Open Source
73 [7]
4754 [7] MIPS 32-bit RISC
MUL opcional [7]
GNU toolchain
2,3 ou 4 andares
UART
OpenRISC Open Source
185 [7]
5379 [7] OpenRisc 1000 32-bit RISC
MMU, MUL [7]
GNU toolchain
5 andares Wishbone
Relativamente às interfaces e de acordo com o objectivo de um bus simples e fácil de
adaptar, o MB-LITE fornece um bus Wishbone e um bus de dados com uma interface simples.
Providencia ainda um dispositivo para descodificar endereços que facilita a comunicação do MB-LITE
com outros periféricos. A latência do bus Wishbone é comparável com o FSL (Fast Simplex Link) com
potencial para melhoramento [7]. Buses como o AMBA utilizado com o Leon 3 são demasiado
complexos e por isso difíceis de adaptar [7].
Em termos de arquitectura o MB-LITE apresenta uma arquitectura relativamente simples
com 5 andares de pipeline [7]. Soft-cores como o Leon 3 e o AEMB apresentam arquitecturas mais
complexas. O Leon 3 apresenta 7 andares de pipeline. Já o AEMB suporta a utilização de duas
threads, o que torna mais complexo o desenvolvimento de programas para este processador. Quanto
à flexibilidade, o Leon 3 e o MB-LITE são ambos bastante configuráveis, com unidade de floating-
point, de multiplicação e gestão de memória opcionais. No entanto, o Leon 3 mesmo tirando as
14
unidades funcionais opcionais continua a ter uma implementação bastante pesada, ocupando muitos
recursos . O OpenFire e o AEMB destacam-se pela positiva em termos de área ocupada. No entanto
estão pior documentados [7]. Por fim e em termos de ferramentas de programação, é possível
programar em C para qualquer um dos softcores comparados. De referir que o MB-LITE é compatível
com o MicroBlaze a nível de instruções e a nível cíclico. Portanto, à partida é possível correr
programas feitos para o MicroBlaze no MB-LITE. Este facto permite também poder recorrer à
documentação do MicroBlaze, o que facilita a programação no MB-LITE.
2.3 Arquitecturas de multiprocessamento
A qualidade da arquitectura de comunicação é um dos factores importantes que define o
desempenho de um sistema de multiprocessamento. É portanto importante concentrar os esforços
em providenciar uma arquitectura de processamento o mais eficiente e flexível possível. Na secção
2.3.1 os sistemas de multiprocessamento em FPGAs são classificados e descritos em termos de
arquitectura, infra-estruturas e métodos de comunicação. Na secção 2.3.2 são apresentadas e
discutidas diversas implementações de sistemas de multiprocessamento em FPGAs.
2.3.1 Classes principais de sistemas de multiprocessamento
No projecto de sistemas de multiprocessamento em FPGA a arquitectura é geralmente
definida pela aplicação em questão. Podem-se definir três tipos principais de arquitecturas: 1)
Master-Slave; 2) Pipeline; 3) “Net”. Existem também arquitecturas híbridas que consistem em
combinações das arquitecturas anteriormente definidas. Uma combinação bastante comum é por
exemplo Master-Slave com pipeline.
(1) Nos sistemas Master-Slave, um ou mais processadores funcionam como processadores
mestres, controlando o comportamento dos processadores escravos [2].
(2) A abordagem Pipeline é útil por exemplo para aplicações de streaming (e.x: aplicações de
multimédia em que há um fluxo permanente de dados a chegar). A arquitectura é composta
por uma cadeia de processadores e cada processador funciona como um andar de “pipeline”.
As tarefas são assim particionadas no tempo resultando numa melhor performance caso a
aplicação seja adequada [2].
15
(3) A arquitectura Net refere-se a sistemas de multiprocessamento nos quais não existe
hierarquia entre processadores, podendo estes comunicar uns com os outros quando
necessário. Um exemplo deste tipo de sistemas é o multi-processador simétrico (SMP ()).
Uma característica dos SMPs (Symmetric MultiProcessor) é que todos os processadores são
idênticos, são por isso sistemas de multiprocessamento homogéneos [2].
A tabela 2.2 resume as características principais destas arquitecturas.
Tabela 2.2 – Arquitecturas de MPSoC [2]
Arquitectura Fluxo de dados
Master-slave Mestre estabelece o comportamento dos escravos.
Pipeline Dados atravessam os vários andares de pipeline.
Net Não existe hierarquia, comunicação dá-se quando necessário.
Outro aspecto importante no projecto de sistemas de multiprocessamento consiste na forma como
as ligações entre os vários elementos são estabelecidas fisicamente. Definimos então três categorias:
(1) Ponto a ponto. Processadores estão ligados directamente. A disponibilidade de uma
grande largura de banda é uma vantagem já que não é necessário partilhar canais de
comunicação, no entanto quando os sistemas crescem esta não é uma solução eficiente
em termos de área [2].
(2) Bus partilhado, a abordagem tradicional que deriva dos sistemas com apenas um
processador. É o mecanismo mais popular (ou mais bem conhecido) para comunicação
entre os núcleos de processamento. Mas não é eficiente em termos de performance já
que o bus apenas pode ser utilizado por um processador de cada vez [2].
(3) NoC (Network on Chip). A base para este método de interligação entre os vários núcleos
consiste em aplicar o conhecimento que se tem de redes de comunicação aos sistemas
em chip. Quando existem muitos núcleos de processamento em chip é a solução que
melhor combina área e performance. A ideia é usar pequenos routers dentro do chip que
permitam a comunicação entre os vários núcleos do sistema com uma latência baixa [2].
A tabela 2.3 refere os tipos de arquitecturas de comunicação e algumas propriedades características
destas.
16
Tabela 2.3 – Arquitecturas de comunicação [2]
Arquitectura Propriedades
Ponto a ponto
Grande largura de banda mas não é adequada para uma
grande quantidade de dispositivos dado que não é eficiente
em termos de área
Bus partilhado Fraca performance em sistemas de multiprocessamento já que
apenas um dispositivo pode transmitir dados de cada vez
Network-on-Chip Pouco suporte a nível das ferramentas comerciais disponíveis
Em termos de métodos para troca de informação entre componentes definem-se três abordagens
diferentes: (1) Memória partilhada; (2) Troca de mensagens (message-passing); (3) Streaming.
(1) Memória partilhada é o método usado mais frequentemente. Uma das razões principais
para este facto consiste nas FPGAs apresentarem uma quantidade limitada de memória
em chip. Este método permite assim poupar memória. Sistemas com partilha de
memória, como os SMPs, têm o problema de sincronização e consistência de memória.
Nos sistemas baseados em FPGAs estas são questões importantes em investigação, já
que os processadores soft-core mais utilizados não apresentam uma solução para lidar
estes problemas. Normalmente sistemas de multiprocessamento com memória
partilhada usam um bus partilhado mas há também alguns sistemas que efectuam as
ligações através de uma NoC [2].
(2) Troca de mensagens é principalmente utilizada em sistemas de memória distribuída, e
consiste no envio de mensagens com informação entre processadores. Um protocolo
para troca de mensagens é requerido [2].
(3) Streaming consiste no envio unidireccional de dados da fonte para o destino. Permite
protocolos extremamente simples e evita o overhead da espera resultante da resposta
do destino.
A tabela 2.4 refere os métodos de comunicação entre dispositivos juntamente com as suas
vantagens e desvantagens.
17
Tabela 2.4 – Métodos de troca de informação [2]
Método Vantagens Desvantagens
Memória Partilhada Eficiente em termos de
memória utilizada.
Sincronização, consistência,
reserva de recursos (locking)
Troca de mensagens Interface de software simples Deadlock, ordenação
Streaming Grande largura de banda Unidireccional
Classificação dos sistemas de multiprocessamento
A classificação tradicional de sistema de multiprocessamento divide-se em duas categorias: (1)
heterogéneos; (2) homogéneos;
Heterogéneos quando existem diferentes processadores (ou mesmo aceleradores) no
mesmo sistema.
Homogéneos quando todos os processadores do sistema são idênticos.
Normalmente, sistemas dedicados (específicos para determinada aplicação) são
heterogéneos. Este tipo de sistemas é comum nos MPSoC. Isto justifica-se com o facto de os MPSoC
serem normalmente implementados com o objectivo de mapear aplicações embebidas. Estas
comportam-se de forma intrinsecamente heterogénea e logo necessitam de processadores
diferentes. Este tipo de sistemas permite também uma maior optimização em termos de área e
potência consumida [1]. Os MPSoC homogéneos são normalmente sistemas de uso geral, nos quais
todos os processadores são idênticos. Neste tipo de sistemas é possível aumentar o número de
processadores sem mudar a arquitectura. São portanto sistemas mais flexíveis. É também mais fácil
desenvolver software para sistemas homogéneos [2].
Outra forma de classificar os sistemas é de acordo com a arquitectura da sua memória.
Existem sistemas com memória partilhada e sistemas com memória distribuída. Em sistemas com
memória partilhada todos os processadores partilham os mesmos recursos de memória. Sendo
assim, todas as mudanças feitas por um processador a determinada localização de memória tornam-
se visíveis para os outros processadores no sistema. Do ponto de vista arquitectural, máquinas de
memória partilhada são dificilmente escaláveis, devido à limitada largura de banda da memória. Para
além disso, sistemas de memória partilhada necessitam de mecanismos de sincronização, tal como
semáforos, barreiras ou trancas (locks), já que não existe comunicação explícita. Threads POSIX [10] e
OpenMP [11] são duas implementações populares para o modelo das threads em arquitecturas com
memória partilhada [2]. Nas arquitecturas com memória partilhada, processos diferentes podem
18
trocar informação facilmente através de variáveis partilhadas. No entanto, há que ter cuidado como
se lida com a sincronização e protecção da memória.
Nos sistemas com memória distribuída cada processador tem a sua própria memória privada
e, logo, um processador não pode ler directamente da memória do outro. As transferências de dados
são efectuadas com recurso a protocolos de troca de mensagens. Sistemas com memória distribuída
são mais escaláveis já que apenas os meios de comunicação são partilhados entre os processadores.
Neste tipo de sistemas são também necessários mecanismos de suporte à comunicação explícita
entre processos. Normalmente é usada uma biblioteca de primitivas que permite escrever nos canais
de comunicação. MPI (Message Passing Interface) [12] é o padrão mais popular utilizado. Numa
arquitectura de memória distribuída é necessária uma infra-estrutura de comunicação de forma a
ligar os vários elementos de processamento com as respectivas memórias e possibilitar a troca de
informação.
Por último, os sistemas de multiprocessamento em FPGA podem também ser classificados de
acordo com a sua reconfigurabilidade: (1) sistemas de multiprocessamento reconfiguráveis e (2)
sistemas reconfiguráveis em tempo de execução (run-time). Os sistemas reconfiguráveis em tempo
de execução conseguem-se reconfigurar dinamicamente em tempo de execução adaptando-se a uma
aplicação específica. Tem-se então diversos módulos dinâmicos que são carregados por um árbitro
dependendo da aplicação alvo [7]. No entanto este tipo de sistemas encontra-se fora do âmbito
desta tese.
2.3.2 Implementações de sistemas de multiprocessamento
Neste capítulo são apresentadas diversas soluções existentes na comunidade científica e na
indústria para sistemas de multiprocessamento. Dividiu-se o capítulo em duas subsecções, uma
dedicada aos sistemas de multiprocessamento heterogéneos e outra dedicada aos sistemas de
multiprocessamento homogéneos.
Sistemas Heterogéneos
Em geral os sistemas de multiprocessamento em FPGA são projectados com uma aplicação
específica em mente. Sistemas heterogéneos são projectados de forma a adaptarem-se o melhor
possível à aplicação em causa. Existem diversas áreas de implementação deste tipo de sistemas
como é o caso da biologia computacional, controladores, redes de comunicação e multimédia [7].
Em [13] é proposta uma arquitectura para encaminhamento de pacotes IPV4. A arquitectura
é master/slave e a comunicação entre os processadores é efectuada ponto a ponto através do bus
19
FSL. Existem diferentes ramos pipeline replicados no espaço de forma a aumentar o rendimento do
sistema. Com o objectivo de demonstrar a viabilidade da solução projectada os autores comparam
uma implementação do sistema baseada numa FPGA com um MPSoC em ASIC com a mesma
funcionalidade. O sistema baseado numa FPGA apenas perde num factor de 2.6X em termos de
performance normalizada face à área ocupada.
Em [14] é apresentado um codificador de MPEG-4 com uma arquitectura master-slave com
suporte para troca de mensagens e uma SDRAM partilhada para interligação entre os processadores
NIOS. Utiliza um bus partilhado para ligar uma memória de instruções partilhada e um bloco HIBI
(Heterogeneous IP Block Interconnection) para ligar a memória de dados partilhado pelo método plug
and play. O sistema é facilmente escalável. A escalabilidade é obtida através de uma paralelização
especial: cada imagem é dividida em segmentos horizontais, e cada segmento é processado por 4
soft-cores numa configuração master-slave.
Uma arquitectura CMP com o objectivo de acelerar aplicações na área da biologia
computacional é apresentada em [15]. O sistema tem uma arquitectura master-slave/pipeline e a
hierarquia de memória é configurada para aplicação alvo. É fácil aumentar o número de
processadores se existirem recursos suficientes na FPGA. Os autores comparam a utilização de CPU,
GPU ou FPGA para aplicações de stream. Implementações em GPU alcançam uma aceleração uma
ordem de magnitude acima das implementações optimizadas para CPUs. Implementações
personalizadas para FPGA também exploram o paralelismo dos dados e alcançam acelerações
(speedups) superiores aos CPUs [16]. Os autores pretendem fazer o protótipo na FPGA e a seguir
migrar para uma implementação numa GPU.
O sector automotor é outra área de aplicação para sistemas de multiprocessamento
baseados em FPGAs. Em [17] é apresentada uma solução embebida. O sistema apresenta uma
arquitectura de comunicação baseada num bus partilhado com memória partilhada, mas oferece a
possibilidade de trocar pequenos pacotes de dados utilizando o mecanismo de troca de mensagens
através de um crossbar.
Em [18] é projectado um sistema de multiprocessamento de arquitectura master-slave com
bus e memória partilhada. É usado o soft-core Nios II da altera e o bus Avalon com meio de
comunicação entre os núcleos. Neste artigo são discutidas as vantagens de usar sistemas de
multiprocessamento baseados em FPGA para aplicações industriais. O sistema projectado prova a
viabilidade da utilização deste tipo de sistemas para aplicações industriais. É referido que as
máquinas de produção industrial necessitam de ser bastantes flexíveis de forma a suportar as
mudanças derivadas dos requisitos de novos produtos.
20
Sistemas Homogéneos
Embora actualmente os MPSoC sejam na sua maioria heterogéneos, com uma aplicação em
mente, sistemas homogéneos começam a aparecer como uma alternativa viável. Este tipo de
arquitectura é normalmente aplicado em sistemas de dados paralelos, isto é, sistemas nos quais um
determinado algoritmo é aplicado a diferentes fluxos de dados. Este tipo de algoritmos é comum em
por exemplo estações wireless ou na área do processamento de imagem no qual diferentes partes da
imagem podem ser tratadas de forma independente. Os sistemas homogéneos de
multiprocessamento são normalmente sistemas de uso geral. Segue em seguida a análise de algumas
implementações relevantes na área.
Em [19] é apresentado o projecto de uma arquitectura de multiprocessamento baseada em
arrays de processadores tendo em a vista a aceleração de uma aplicação de filtro mediano de
imagem. A arquitectura é master-slave/pipeline e tem uma memória externa partilhada. A
arquitectura de comunicação é efectuada ponto a ponto entre quatro núcleos de processamento
apresentando uma topologia em anel. É utilizado um esquema simples de ligação entre os
dispositivos baseado em FIFOs (First In First Out). Os autores utilizam um soft-core MicroBlaze como
mestre e três soft-cores OpenFire como escravos. O MicroBlaze funciona como interface com a
memória e controlador de rede. Os soft-cores OpenFire são responsáveis pelo processamento dos
dados. É conseguida uma aceleração quase linear da aplicação com o aumento do número de
processadores.
Em [20] é apresentada uma arquitectura de multiprocessamento de memória partilhada
composta por IP (Intellectual Property) comerciais (MicroBlaze). É proposto um modelo de
programação que expõe o paralelismo de aplicações multimédia. Os autores providenciam uma
camada hardware para suporte à sincronização de tarefas e um mecanismo via software para
garantir a consistência dos dados. É concluído que algoritmos de coerência de cache são difíceis de
implementar e verificar em hardware. Para além disso as ferramentas comerciais dificultam a
organização de um sistema de multiprocessamento porque estão primariamente orientadas para o
projecto de sistemas com um único processador. Os resultados experimentais dos autores mostram
que a arquitectura de multiprocessamento desenvolvida pode ter uma performance equivalente a
um processador hard-core mais potente.
Um sistema de multiprocessamento com uma arquitectura de comunicação baseada num
bus partilhado e memória partilhada é apresentado em [6]. O objectivo principal dos autores é o
projecto de uma plataforma que facilite a investigação na área do multiprocessamento mas com uma
performance superior à dos simuladores. É desenvolvido um núcleo de processamento designado
por HoneyComb que consiste numa versão expandida e melhorada do soft-core Plasma com suporte
21
para memória virtual e tratamento de excepções. O acesso ao bus partilhado e interface com a
memória é mediado através de um árbitro desenvolvido pelos autores. A performance do sistema é
baixa, no entanto os autores afirmam ser superior à de um simulador cumprindo o objectivo
principal.
Em [21] apresentado o projecto de um sistema de multiprocessamento com uma
arquitectura de comunicação ponto a ponto e troca de mensagens como paradigma de comunicação.
O MicroBlaze é utilizado como elemento de processamento do sistema. Os autores estudam várias
topologias para as ligações ponto-a-ponto (malha, anel, estrela) e a viabilidade do bus FSL da Xilinx
como meio de comunicação entre os processadores. É escolhida uma topologia em estrela na qual
existe um processador central que distribui os dados e é também responsável por agrupá-los. Os
autores justificam a escolha desta topologia pela escalabilidade que oferece. É concluído também
que o bus FSL apresenta resultados suficientemente bons para ser aplicado em sistemas paralelos. O
sistema projectado é testado com duas aplicações, uma aplicação de multiplicação de matrizes e
outra de encriptação de dados. É verificado que a comunicação entre os processadores limita a
eficiência do sistema e portanto é um factor crítico na obtenção da performance resultante do
paralelismo das aplicações. É referido também que os processadores soft-core são apropriados para
desenvolver MPSoC e que o factor limitativo no número de núcleos de processamento de um
sistema de multiprocessamento numa FPGA é claramente a quantidade de BRAM (Block Random
Access Memory).
Um sistema de multiprocessamento escalável de arquitectura master-slave/pipeline com
base no soft-core MicroBlaze é apresentado em [22]. Os autores projectaram um dispositivo
escalável baseado em ligações ponto a ponto que permite reserva de recursos e arbitragem de um
bus partilhado, o RSSA (Scalable Multi-Processor Resource Sharing and Synchronization Arbiter). A
arquitectura proposta é genérica e é testada com uma aplicação para calcular a FFT (Fast Fourier
Transform). É demonstrado que o mecanismo de comunicação implica um overhead insignificante no
sistema em geral. A arquitectura evita o tráfego no bus partilhado e melhora a performance do
sistema. Os autores fornecem suporte para integração do RSSA no EDK (Embedded Development
Tool Kit) reduzindo o tempo de desenvolvimento do sistema. É afirmado que o overhead de
comunicação devido às ligações ponto a ponto na implementação da FFT é inferior a 4%.
Em [23] é desenvolvido um processador (especificado em VHDL) de arquitectura RISC
denominado mizzouRISC. Este processador serve como núcleo do sistema de multiprocessamento
desenvolvido, o MizzouSMP. Os autores projectam um sistema de multiprocessamento com duas
arquitecturas diferentes que são comparadas depois de simuladas e sintetizadas numa placa. Estas
arquitecturas envolvem duas taxonomias diferentes, MIMD e SIMD. Em ambas as arquitecturas os
dados são partilhados e a comunicação entre os processadores faz-se através de um bus também
22
partilhado. Numa arquitectura existe apenas uma ROM (Read Only Memory) partilhada enquanto na
outra existem ROMs locais para cada processador. Após medição do tempo de execução do
programa num sistema com 1 a 10 cores em simulação e de 1 a 4 cores para síntese, os autores
concluíram que o MizzouSMP obteve desempenho esperado como previsto pela lei de Amdahl.
A questão essencial entre sistemas heterogéneos e homogéneos resume-se à troca entre
generalidade e performance. Generalidade providencia capacidade de reutilização do hardware,
sistemas operativos e praticas de desenvolvimento, enquanto a performance (atrasos, custos,
potência, etc.) é alcançada pela utilização de estruturas específicas de uma aplicação.
2.4 Arquitecturas de Comunicação
2.4.1 Funcionalidades básicas
A arquitectura de comunicação de um sistema de multiprocessamento consiste na infra-
estrutura de inter-ligação entre os vários componentes do sistema. A abordagem mais simples de
implementar para interligar os componentes é através de ligações dedicadas. No entanto, está
abordagem seria dificilmente escalável, já que seria necessária uma ligação dedicada de cada fonte
para cada destino. É por esta razão que as ligações entre diferentes dispositivos são normalmente
partilhadas. A forma como estas ligações são partilhadas define a topologia de rede. A topologia de
uma rede permite-nos saber quais os caminhos disponíveis para os pacotes chegarem ao seu destino.
Ora qualquer rede que ligue mais do que dois dispositivos necessita de um mecanismo que
possibilite a cada pacote chegar ao seu destino correcto. A função responsável por isto chama-se
encaminhamento (routing). Encaminhamento pode ser definido como o conjunto de operações
necessárias a computar um caminho válido desde a origem ao destino de um pacote. Dependendo
da rede, o caminho para um pacote pode ser computado totalmente na fonte, nos nós intermédios
(onde são computados fragmentos de caminho no momento), ou mesmo através da verificação em
cada nó se aquele corresponde ao destino definitivo. Em geral as redes apresentam caminhos
partilhados. Se mais que um pacote apresenta o mesmo destino em simultâneo, é necessário um
sistema de arbitragem para resolver o conflito. Arbitragem em conjunto com fluxo de controlo trata
a importante questão de quando é que existem caminhos disponíveis para os pacotes. Fluxo de
controlo serve essencialmente para prevenir o overflow dos buffers e consequente perda de pacotes.
O pacote procede então para o seu destino assim que lhe é providenciado um caminho para avançar.
Está função de alocar os caminhos para os pacotes denomina-se comutação (switching). Estas três
23
funções, encaminhamento, arbitragem e comutação devem ser implementadas em qualquer rede
que contenha mais que dois dispositivos independentemente da topologia da rede [3].
2.4.2 Análise de arquitecturas
As infra-estruturas de comunicação têm que suportar um cada vez maior número de
componentes. Torna-se importante portanto, implementar arquitecturas que permitam uma
comunicação eficiente e ao mesmo tempo a fácil integração de um número elevado de
componentes. As soluções inicialmente adoptadas para interligação de dispositivos consistiam em
buses partilhados ou comutadores centralizados partilhados. Estas soluções revelam-se vantajosas
para a indústria por serem relativamente baratas e simples de implementar. No entanto, com a
complexidade das aplicações e crescente número de módulos numa rede, estas soluções não são
escaláveis. Os buses partilhados apenas permitem o envio de dados a um dispositivo de cada vez,
limitando a largura de banda disponível [2]. Os comutadores centralizados partilhados apresentam-
se popularmente sobre a forma de uma de duas topologias. Topologia crossbar ou MIN (Multistage
Interconnection Network). A topologia crossbar é simples de implementar e permite a qualquer
destino ser alcançado a partir de qualquer que seja a fonte. No entanto, a complexidade de um
crossbar aumenta quadraticamente com o aumento das portas [3]. Uma forma vulgar de resolver
este problema r é dividir o comutador crossbar maior em diferentes andares. Cada andar consiste em
comutadores mais pequenos, ligados de forma a possibilitar a chegada a qualquer destino a partir de
qualquer fonte, com uma única passagem pela infra-estrutura [3]. Em [24] é apresentada uma
solução baseada numa MIN e comparada com uma arquitectura baseada num comutador crossbar.
Neste trabalho é demonstrado que a solução MIN apresenta menos recursos utilizados que a solução
baseada num crossbar.
As arquitecturas NoC aparecem como uma solução flexível e escalável [25]. As NoCs
apresentam um carácter altamente modular permitindo a fácil integração de vários módulos, e
potencialmente uma maior largura de banda, dependendo da topologia escolhida. Numa NoC os
módulos podem ser processadores, DSPs (Digital Signal Processor), memórias, dispositivos de
entrada/saída de dados, entre outros. Na figura 2.1 estão representadas algumas topologias
possíveis para uma arquitectura NoC. Existem diversos artigos a explorar a implementação de
arquitecturas NoC em sistemas de multiprocessamento em FPGAs [26, 27]. Sistemas como o
Heracles[28] e o HIBI[29] apresentam um elevado grau de configurabilidade, permitindo a escolha de
diversas topologias, algoritmos de encaminhamento, arquitecturas de memória, para além da
modificação de outros parâmetros. Estes sistemas possibilitam a investigação de novas as
24
arquitecturas ou a aceleração de aplicações. Existem também vários artigos que comparam a
arquitectura NoC com outras arquitecturas de comunicação existentes. Em [30] é feita uma
comparação entre um sistema de multiprocessamento baseado num bus partilhado open source
(ConBus), e uma implementação NoC, com topologias tree e fat tree (no trabalho referida como
stree). A comunicação é efectuada através de uma memória partilhada. As implementações NoC
apresentam uma performance baixa visto que as topologias tree apresentam um nó que limita a
comunicação e não permite comunicação totalmente paralela. A implementação do sistema de
multiprocessamento baseado no bus partilhado apresenta estranhamente uma performance maior
que a implementação NoC. É referido que estes resultados são provavelmente uma consequência do
projecto ser relativamente pequeno e simples. Assim a implementação bus partilhado não sofre de
nenhumas das falhas associadas ao mesmo. É também verificado que arquitectura fat tree apresenta
melhores resultados em termos de área e performance que a arquitectura tree. Estes resultados são
associados ao facto da topologia fat tree permitir um melhor aproveitamento dos comutadores,
resultando em menos sinais e logo numa implementação mais pequena. É sugerida uma
configuração para o sistema baseada numa topologia mesh, que por permitir comunicação
totalmente paralela não sofre da falha das arquitecturas tree. No artigo [31] é efectuada uma
comparação entre duas arquitecturas de multiprocessamento homogéneas. Uma arquitectura
baseada numa NoC com uma topologia mesh e uma arquitectura baseada num bus/memória
partilhada. É concluído que para aplicações paralelas uma eficiente implementação de uma NoC
numa FPGA pode aumentar a velocidade de comunicação até sete vezes relativamente à
arquitectura com bus partilhado, e com reduzido aumento na área de circuito utilizada. Sendo que
estes resultados dependem da dimensão dos dados e número de processadores ligados na rede. No
artigo [32] é apresentada uma metodologia para projecto de NoC.
Figura 2.1 – Exemplos de topologias NoC. Da esquerda para a direita: Mesh 2D, Torus 2D e Binary
Tree [28].
Claramente, um sistema baseado numa NoC não será sempre a solução preferida para todo o
tipo de aplicações. É esperado que os projectos baseados em NoCs providenciem boas soluções para
25
produtos flexíveis que devam ser reconfiguráveis e programáveis. Para projectos que são a base para
diferentes variantes de produtos e aplicações com um conjunto de tarefas heterogéneas. Para
aplicações com restrições de tempo a nível das exigências do mercado. Para aplicações com uma
mistura heterogénea de tarefas. E para produtos cuja reutilização tanto a nível do bloco como a nível
de funcionalidade seja considerado valioso [32].
26
Processador MB-LITE
O processador escolhido como base do sistema de multiprocessamento a desenvolver é o
soft-core MB-LITE [7], tal como foi determinado na secção 2.2 do capítulo anterior. A organização do
MB-LITE é baseada nas conhecidas arquitecturas DLX e MIPS [3]. Existem no entanto alguns pontos
cruciais no qual a arquitectura do MB-LITE diverge de forma a ser compatível com arquitectura
MicroBlaze. Tal facto possibilita a utilização de ferramentas da Xilinx que permitem a criação de
programas para o MicroBlaze, nomeadamente o compilador MB-GCC. Na secção 3.1 é descrita a
arquitectura do MB-LITE e destacadas algumas das diferenças relativamente à arquitectura do
MicroBlaze. Na secção 3.2 são apresentados os resultados de síntese do MB-LITE para um dispositivo
Virtex-6. E descreve-se brevemente os passos para a criação de um programa para o mesmo.
3.1. Arquitectura MB-LITE
O MB-LITE é um processador RISC de 32 bits e define dois tipos básicos de instruções: Tipo A
(i.e. Tipo Registo) e Tipo B (i.e. Tipo Imediato). A operação a ser executada é determinada pelo
campo Opcode de 6 bits. Nas instruções do Tipo A são especificados dois registos fonte e um registo
destino. Instruções do tipo B têm um registo fonte, um registo destino e uma constante de 16 bits
(imediato) como operandos. O formato das instruções e correspondente numeração dos bits está
representado na figura 3.1. Como se pode observar os autores do MB-LITE optaram por uma
ordenação dos bits contrária à do MicroBlaze. Se uma operação requer além dos 16 bits disponíveis
para o operando imediato (para aceder a endereços mais altos de memória ou adicionar números
grandes) a instrução pode ser precedida de uma instrução IMM que carrega previamente a parte alta
do valor imediato. A instrução IMM afecta apenas o valor imediato da instrução seguinte. Usando a
instrução IMM todos os 32 bits da memória podem ser endereçados efectivamente [7].
O MB-LITE disponibiliza trinta e dois registos de uso geral (general purpose registers). Parte
destes registos encontram-se reservados por razões específicas, como por exemplo endereços de
retorno para interrupções. Já no MicroBlaze, existem ainda trinta e dois registos de uso particular
(special purpose registers). Alguns destes registos contêm informação sobre a actual configuração do
processador e do PC (Program Counter) para além de outras funcionalidades. O MB-LITE não suporta
3
27
instruções relacionadas com os registos especiais, já que estas geralmente não são utilizadas.
O MicroBlaze usa o formato Big-Endian bit-reversed para numerar os bytes e os bits
individualmente. Já os autores do MB-LITE consideram o bit 31 como o mais significativo ao passo
que o bit 0 é o menos significativo. Como os acessos à memória são efectuados ao byte e as leituras e
escritas na memória têm de ser alinhadas, a numeração dos bits do MicroBlaze pode ser modificada
de acordo com a nossa preferência. Na figura 3.2 pode-se observar o formato dos dados bem como o
endereçamento ao byte e a numeração dos bits do MicroBlaze e do MB-LITE.
Figura 3.1 – Formato das instruções na arquitectura MicroBlaze [7]
Figura 3.2 – Formato dos dados na arquitectura MicroBlaze [7]
As instruções implementadas no MB-LITE apresentam uma latência igual à definida na
especificação da arquitectura MicroBlaze. A maioria das instruções é executada num ciclo de relógio.
As instruções de salto tomadas que implementam salto retardado são executadas em dois ciclos de
relógio. Já as instruções de salto tomadas que não implementam salto retardado são executadas em
três ciclos de relógio [7].
No MB-LITE as interrupções podem ser utilizadas tal como na implementação original do
MicroBlaze. Tem portanto suporte para apenas uma interrupção. Significa isto que apenas se pode
activar uma interrupção e associar a esta uma função para tratamento.
O MB-LITE apresenta os clássicos cinco andares de pipeline, IF (Instruction Fetch), ID
(Instruction Decode), EX (Execute), MEM (Memory) e WB (Write-back). É o módulo IF que alimenta o
pipeline com a instrução requisitada e armazena o PC (program counter) actual. O PC corresponde ao
endereço da instrução dividido por quatro e é também referido como número de instrução. O PC é
incrementado automaticamente todos os ciclos de relógio. No andar ID as instruções são traduzidas
em sinais de controlo. Estes sinais de controlo atravessam o pipeline juntamente com a instrução. As
interrupções são avaliadas no andar de descodificação. Se o fluxo normal de execução pode ser
interrompido sem problemas, os sinais de controlo serão sobrecarregados com um salto para rotina
28
de interrupção. O andar de execução determina os operandos da ALU e a operação que necessita de
ser executada. Para além de todas as funcionalidades básicas como deslocamentos, somas e
operações lógicas, a ALU pode incluir, adicional e opcionalmente, um multiplicador e um barrel
shifter. A tarefa do módulo MEM é a de controlar a interacção com a memória de dados. Gera os
sinais de selecção de bytes (i.e. o sinal de enable de 4 bits), o sinal de enable (que só por si permite a
leitura) e o sinal write enable.
O MB-LITE implementa controlo distribuído de forma a eliminar a necessidade de um
controlador pipeline complexo e centralizado [33]. Deste modo todas as dependências são resolvidas
localmente. Estas dependências podem gerar conflitos, os quais são resolvidos recorrendo a várias
técnicas. Para o conflito de dados, também chamado RAW (Read After Write), forwarding é utilizado
com o intuito de diminuir ao máximo o número de bolhas (stalls) que é necessário introduzir no
sistema. O conflito estrutural que ocorre quando existe uma leitura e uma escrita concorrentes de
um registo é resolvido também com recurso a forwarding dos operandos. Quando o resultado de
uma instrução de load é imediatamente utilizado é possível configurar o MB-LITE para usar bolhas ou
lógica adicional para fazer forwarding do resultado da memória. Por fim os conflitos de controlo são
resolvidos com recurso à descarga do pipeline (pipeline flush) e como já foi referido é implementada
a técnica do salto retardado.
Na figura 3.3 é possível observar sem grande detalhe a estrutura do MB-LITE com as
entradas e saídas de cada módulo do processador. Três tipos de sinais são distinguíveis: sinais de
dados (verde), sinais de endereço (azul) e sinais de controlo (vermelho). No topo da figura estão
desenhados os sinais de write-back, os sinais na base representam os sinais para conflitos de dados e
controlo.
Figura 3.3. Estrutura do MB-LITE e sinais de interface [7]
29
Interface de dados
Com o objectivo de simplificar a ligação de componentes como memórias, co-processadores,
pontes (bridges), adaptadores, entre outros periféricos, os autores do MB-LITE projectaram um
descodificador de endereços específico. O descodificador de endereços é responsável por
descodificar os endereços com base num mapeamento de memória genérico, e encaminhar os sinais
de controlo, endereço e dados para os portos de saída apropriados (ver figura 3.4). O descodificador
pode ser directamente conectado ao bus de dados do MB-LITE e não introduz atraso adicional
significativo. Neste momento existem já bastantes periféricos open source compatíveis com o bus
Wishbone. Nesse interesse os autores do MB-LITE desenvolveram um adaptador de forma a
converter o bus de dados do MB-LITE para uma interface Wishbone mestre. O adaptador pode ser
directamente ligado ao núcleo MB-LITE ou ao descodificador de endereços. O bus Wishbone foi
modelado de acordo com a revisão 3B da especificação Wishbone[falta aqui uma referência]. O
protocolo Wishbone utiliza um protocolo de handshake síncrono para trocar dados e demora pelo
menos dois ciclos a completar. Durante um ciclo Wishbone a execução do processador é
interrompida até a transacção estar completa, o que limita o desempenho do sistema.
Figura 3.4. Estrutura do descodificador de endereços com dois escravos [7]
É possível adicionar unidades funcionais extra ao processador MB-LITE. Para isso tem que se
seguir o seguinte procedimento. Adicionar uma nova operação na definição do tipo alu_operation
(core_Pkg). Definir uma constante do tipo boolean para activivar/desactivar a nova unidade funcional
(config_Pkg). Esta constante é utilizada através dos vhdl generics no módulo execute [EX].
Acrescentar uma nova condição ao case exec_i.ctrl_ex.alu_op e por fim definir a função
correspondente à nova unidade funcional (esta função deve estar definida no pacote std_Pkg).
30
3.2 Teste do MB-LITE
O processador MB-LITE foi sintetizado sobre diferentes configurações com o objectivo de
compreender o impacto das unidades funcionais opcionais, na área, performance do sistema. Os
resultados da síntese do MB-LITE, representados na tabela 3.1, foram obtidos usando a ferramenta
XST (Xilinx ISE 13.1) tendo como alvo o dispositivo Virtex-6 (XC6VLX130t-3ff1156).
Tabela 3.1 – Resultados da síntese do MB-LITE sob diferentes configurações. A primeira coluna
refere-se ao MB-LITE sem nenhuma unidade funcional opcional activa.
MB-LITE % C/ MUL 32bits
% C/ BSHIFT 32bits
% C/ AMBOS 32bits
%
LUTS 795 1 854 1 1109 1 1097 1
BRAMs 2 0 2 0 2 0 2 0
Block DSPs
- 3 0 - - 3 0
F. Máx (MHz)
238 - 118 - 213 - 114 -
T. Min* (ns)
4,2 - 8,4 - 4,7 - 8,8 -
* T. Min = 1 / F. Máx
Observa-se que a inclusão do multiplicador implica uma severa redução da frequência
máxima de funcionamento do sistema. No entanto, em aplicações com um elevado número de
multiplicações a utilização de um multiplicador embebido no hardware geralmente melhora a
performance do sistema. O multiplicador é mapeado nos blocos DSP sem grande overhead adicional
de LUTs. Já a utilização do barrel shifter implica principalmente um aumento significativo nas LUTs
utilizadas. Mais uma vez dependendo da aplicação pode ser compensador ou não.
Para correr um programa no MB-LITE é necessário primeiro de tudo compilar o programa
com o compilador do MicroBlaze (MB-GCC). A versão é a mesma utilizada pelos autores do MB-LITE
para garantir a compatibilidade dos programas (EDK 10.1). O compilador gera um binário de formato
elf. Através do programa MB-OBJCOPY é gerado um binário. Utilizando uma aplicação simples
fornecida pelos autores do MB-LITE, BIN2VHD é criado um ficheiro vhd que constitui uma RAM
inicializada com as instruções, pronta a ser adicionada ao projecto. Na figura 3.5 ilustra-se este
processo através de um fluxograma. Estes passos são automaticamente gerados por um Makefile.
31
Figura 3.5 - Fluxograma de geração de uma memória de inicialização do sistema.
32
Arquitectura De Multiprocessamento
Neste capítulo é descrita em pormenor a arquitectura de multiprocessamento projectada. O
sistema de multiprocessamento projectado é homogéneo e apresenta uma arquitectura de memória
distribuída com comunicação entre os processadores via streaming. Foram desenvolvidas duas
arquitecturas de comunicação diferentes, cujo desempenho é comparado. A primeira é baseada num
comutador central partilhado, um comutador crossbar. A segunda consiste numa NoC.
O projecto do sistema foi progressivo e envolveu diversas etapas até se chegar às
arquitecturas definitivas. As várias etapas podem ser descritas resumidamente nos seguintes pontos:
Teste do processador MB-LITE;
Desenvolvimento e teste de uma arquitectura simples de comunicação entre dois elementos
de processamento.
Desenvolvimento e teste de uma arquitectura de comunicação entre quatro núcleos de
processamento.
Integração do módulo de comunicação num sistema completo de multiprocessamento e
respectivo teste.
Generalização do módulo de comunicação para suportar N núcleos de processamento.
Integração do módulo de comunicação num sistema completo de multiprocessamento com
oito núcleos de processamento e respectivo teste.
Desenvolvimento de uma arquitectura NoC com suporte para oito núcleos de processamento
e respectivo teste.
O MB-LITE foi testado com diversas aplicações simples e sob diversas configurações de forma
a verificar e compreender o seu funcionamento, antes de se começar a projectar a arquitectura de
multiprocessamento. Em seguida foram projectadas arquitecturas progressivamente mais
complexas.
Na secção 4.1 é definido o bloco base do sistema de multiprocessamento. Este bloco é
comum a todas as arquitecturas desenvolvidas e constitui os nós do sistema. A sua estrutura nunca é
significativamente alterada para nenhuma das implementações testadas. Na secção 4.2 é
apresentada uma arquitectura simples para ligação entre dois processadores, 4.2.1, e descritas as
4
33
duas arquitecturas de comunicação desenvolvidas para interligar mais que dois processadores. Em
4.2.2 introduz-se a arquitectura comutador crossbar. Na secção 4.2.3 é descrita a arquitectura NoC.
4.1. Bloco Base
O bloco base funciona essencialmente como um invólucro para o processador MB-LITE,
englobando os elementos necessários à comunicação com outros processadores do sistema. O bloco
base é constituído pelos seguintes elementos: MB-LITE, DIMEM (Data Instruction Memory),
descodificador de endereços, caixa de correio, e controlador de dados recebidos. Na figura 4.1 é
possível observar a estrutura do bloco base e como os vários elementos se interligam. O MB-LITE é o
núcleo de processamento e portanto o módulo central do bloco base. (Não foram efectuadas
modificações ao MB-LITE relativamente à implementação original dos autores). Visto que todos os
dispositivos se encontram mapeados em memória, o MB-LITE pode comunicar com estes através de
instruções load (leitura de dados), store (escrita de dados). Esta comunicação é efectuada sob o
paradigma master/slave. O MB-LITE é o componente master e os outros elementos são os slaves. O
descodificador de endereços é o responsável por encaminhar os dados entre o MB-LITE e os outros
elementos do bloco base. O módulo DIMEM consiste na memória local de instruções e dados do MB-
LITE (memória unificada). A interface para leitura de instruções está directamente ligada ao MB-LITE.
O encaminhamento dos sinais para escrita e leitura de dados da memória é efectuado através do
descodificador de endereços. A caixa de correio consiste numa pequena memória onde são
recebidos os dados oriundos de outros processadores. Esta memória recebe dados directamente da
rede de comunicação e pode ser lida pelo MB-LITE. O controlador de dados recebidos é o módulo
responsável por avisar o processador de que chegaram dados à caixa de correio. Este módulo é um
contador que incrementa cada vez que recebe um sinal de aviso da rede. O contador pode também
ser acedido pelo MB-LITE para leitura ou escrita. Por fim, o acesso do MB-LITE à rede de
comunicação é efectuado através de um porto de escrita mapeado em memória. Na secção seguinte
é apresentado o mapeamento de memória do sistema e a arquitectura de memória local escolhida.
34
Figura 4.1. - Estrutura do bloco base.
Arquitectura da memória
O MB-LITE permite o endereçamento de 232 localizações de memória. Estas localizações
estão divididas em várias zonas de memória de modo a ser possível aceder a componentes
diferentes. Na tabela 4.1 encontra-se representado um exemplo de um mapeamento de memória
possível, para os elementos do bloco base.
Tabela 4.1 - Mapeamento de memória dos elementos do bloco base. R -> Read. W-> Write.
Endereço Base Descrição Modo de Acesso
0x00000000 Memória de instruções e dados (R/W)
0x00010800 Rede de comunicação (W)
0x00010E00 Caixa de correio (R)
0x00010F00 Controlador de dados recebidos (R/W)
A decisão quanto à arquitectura de memória escolhida está intimamente ligada com o
mapeamento de memória efectuado pelo linker do MicroBlaze. No início do projecto deparámo-nos
com o problema do linker do MicroBlaze alocar endereços em zonas de memória demasiado altas,
impossibilitando a redução da memória de dados e instruções como se desejava. Procurou-se então
uma forma de modificar o mapeamento de memória. Este mapeamento é feito pelo linker com base
num script, o linker script, que permite definir os endereços e dimensões de cada secção da
memória, sejam instruções, dados não inicializados, dados inicializados, stack, heap, etc. Embora não
seja trivial modificar ou verificar o mapeamento de memória através do linker script, a ferramenta
35
MB-READELF, fornecida pela Xilinx, permite obter o mapeamento completo de memória, entre
outras informações [34]. A zona mais simples de modificar foi a stack, pois corresponde à secção
mais alta em memória. Optou-se por reduzir a stack de 4 Kbytes para 256 bytes, o que não gerou
problemas pois optou-se pelo uso de variáveis globais na sua maioria. Além disso se a memória não
for suficiente o compilador emite um erro e pode-se sempre aumentar a stack. Observou-se também
que as instruções estão mapeadas sequencialmente em endereços mais baixos e os dados em
endereços mais altos. Optou-se também por unificar a memória de dados e instruções. Esta solução
permite um maior aproveitamento da memória disponível, simplifica o dimensionamento das
memórias (apenas se tem que modificar uma memória e a sua verificação é directa a partir do
visionamento do mapeamento de memória) e o seu endereçamento (visto que não é necessário
adaptar o mapeamento a uma outra memória). A memória de arquitectura Harvard (instruções e
dados separados) simplificaria o acesso às memórias caso estas tivessem apenas um porto de leitura,
o que não é o caso, já que é possível mapear a memória de instruções e dados numa BRAM com um
porto de escrita e dois de leitura.
4.2. Arquitectura de comunicação
A primeira decisão tomada foi projectar um sistema de memória distribuída. Sendo assim,
cada núcleo de processamento tem acesso exclusivo a uma memória local de instruções e dados. O
processador acede à memória através de buses dedicados e não através da rede, de forma a diminuir
o tráfego imposto na rede de comunicação.
A comunicação é efectuada utilizando um método de streaming. Cada processador tem
acesso a uma pequena memória que se designou por caixa de correio. Esta memória só pode ser lida
pelo processador a que pertence, mas pode ser escrita por qualquer outro processador via a rede de
comunicação. A comunicação é assim unidireccional. Neste caso, esta abordagem permite por um
lado evitar os conflitos de acesso simultâneo a uma memória partilhada (e.g. sincronização,
coerência de memória são problemas evitados que se tornam pesados para o programador e são
difíceis de implementar em hardware) e por outro a latência originada do protocolo que envolve
uma abordagem por troca de mensagens (e.g. bloquear o processador mestre à espera de resposta
do escravo). A cada processador está associado um contador, o que permite o controlo da chegada
de dados à respectiva caixa de correio. O contador incrementa cada vez que um bloco de dados é
completamente recebido na caixa de correio.
36
Para dois núcleos de processamento cada processador recebe dados apenas um do outro.
Por esta razão, decidiu-se por uma comunicação ponto a ponto entre os dois sistemas base. Na
secção 4.2.1 encontra-se a descrição deste sistema.
A primeira arquitectura de comunicação projectada para ligação de mais que dois
processadores baseia-se num meio de comunicação partilhado, no qual um comutador crossbar é
responsável por gerir e encaminhar os dados através da rede e em que toda a comunicação é
centralizada através deste nó. Esta arquitectura foi escolhida por ser simples de implementar e
permitir o envio simultâneo de dados através da rede de comunicação. Além disso, caso o número de
módulos interligados no sistema seja reduzido, o overhead em termos de área é pequeno. Este facto
favorece a implementação do sistema numa FPGA. A secção 4.2.2 descreve esta arquitectura.
A segunda arquitectura de comunicação desenvolvida consiste numa NoC. A comunicação
neste caso é efectuada de forma distribuída. Cada nó constituinte da rede consiste em três
elementos. O bloco IP, o router e o adaptador de endereços. O bloco IP pode ser uma memória, um
periférico para entrada/saída de dados, um processador ou outro qualquer componente. O router
responsabiliza-se pelo encaminhamento dos pacotes ao longo da rede. O adaptador de rede funciona
como interface de dados entre o router e o bloco IP. Qualquer bloco IP pode fazer parte da rede,
desde que tenha uma interface de dados compatível com a definida no adaptador de rede. Esta
arquitectura foi escolhida por apresentar uma grande facilidade na integração de um número
elevado de componentes e permitir um grau elevado de paralelismo na comunicação de dados,
dependendo claro está, da topologia da rede. Na secção 4.2.3 é detalhada a arquitectura NoC.
4.2.1 Dois Núcleos de Processamento
A definição de uma arquitectura de comunicação entre dois núcleos de processamento
começou ainda antes da definição do bloco base. Apresenta-se portanto, duas abordagens. Uma
abordagem anterior a definição do bloco base e uma abordagem pós definição do bloco base.
Na primeira abordagem, o envio de dados é efectuado em bloco, isto é, são enviados
sequencialmente para o processador destino e armazenados na memória local deste. Este facto
implica que o bus de escrita na memória local seja partilhado. De forma a resolver este conflito foi
desenvolvida lógica adicional, o que atrasa a comunicação entre os dois processadores. Na
eventualidade da memória estar a ser acedida pelo processador, os dados vindos do outro
processador eram armazenados numa fila. Cada processador tinha associado um módulo baseado
num contador para avisar o processador da chegada dos dados. No caso da chegada de dados ao
outro processador era então gerada uma interrupção. Optou-se pelo envio de dados em bloco
37
precisamente para evitar a constante interrupção do sistema. Este sistema apresentava diversas
limitações. Para além da referida partilha da memória local do processador, tem-se ainda o facto de
o MB-LITE permitir apenas uma interrupção durante a execução de um programa. Isto é, cada um
dos processadores podia apenas receber um bloco de dados. Esta razão e o facto de as interrupções
implicarem um overhead adicional (derivado da troca de contexto no processador) em termos de
ciclos de relógio levou a que fosse procurada outra solução.
Com a definição do bloco base e paradigma de comunicação baseado no streaming de dados,
a arquitectura de comunicação entre dois processadores tornou-se bastante simples, ver figura 4.2.
Nesta segunda abordagem, o envio de dados de um processador para o outro é efectuada através de
um barramento dedicado. No barramento vão especificados os dados, o endereço e o sinal de enable
para escrita na caixa de correio do processador destino. Como já foi referido, cada processador tem
acesso a um contador, que permite supervisionar a chegada de dados. Neste caso, o contador
apresenta um limite de contagem igual à dimensão da caixa de correio. Cada vez que é escrita uma
palavra na caixa de correio o contador incrementa. A gestão da memória da caixa de correio é
deixada à responsabilidade do programador. Como já foi referido na secção 4.1, o envio de dados é
feito através de um porto mapeado em memória. Os N bits menos significativos do bus de
endereçamento definem a posição de memória a escrever na caixa de correio. A definição da
primeira arquitectura foi importante como meio de se obter experiência para projecto das
arquitecturas finais. No entanto, com a segunda abordagem são superadas as limitações impostas
pela primeira e tem-se um sistema que permite a aceleração de aplicações com dois núcleos de
processamento.
A latência de comunicação através das ligações ponto a ponto corresponde a um ciclo de
relógio.
Figura 4.2 – Sistema de multiprocessamento com dois núcleos de processamento
4.2.2. Comutador Crossbar
A comunicação entre mais que dois processadores torna-se mais complexa devido ao
aumento do número de destinos possíveis para cada fonte. A arquitectura projectada pode-se
classificar como uma arquitectura de comunicação baseada num meio partilhado de topologia
38
crossbar. Define-se de seguida o protocolo utilizado e a descrição estrutural e funcional dos blocos
constituintes do nó de comunicação. Na última subsecção (optimizações) são descritas duas
optimizações relativas à arquitectura projectada.
Protocolo
A função de arbitragem permite resolver as situações em que mais do que um pacote
pretende o mesmo destino. Optou-se pelo algoritmo round robin, já que é simples e de fácil
implementação, e além disso como não tem prioridades logo, não é grandemente afectado pelo
problema de starving (o algoritmo é justo e nenhum pedido é negligenciado face a outros). O
algoritmo round robin consiste em alternadamente, seguindo uma determinada ordem, possibilitar o
acesso a determinado recurso. Os pacotes que não são escolhidos são armazenados em buffers. De
forma a simplificar o controlo de fluxo, admite-se que os buffers têm uma capacidade
suficientemente grande para que não ocorra overflow.
A função comutação permite alocar caminhos para os pacotes avançarem. Foram
consideradas para este projecto duas abordagens, comutação de circuitos e comutação de pacotes. A
comutação de circuitos estabelece um caminho a priori e reserva largura de banda para a
transmissão de pacotes ao longo desse caminho, enquanto a comutação de pacotes permite que a
largura de banda da rede seja partilhada e usada mais eficientemente quando os pacotes são
transmitidos intermitentemente. Considerando que, para o tipo de aplicações de computação
matricial alvo, a comunicação entre os núcleos de processamento é maioritariamente contínua,
decidiu-se implementar uma abordagem baseada no conceito de comutação de circuitos.
O bloco router é o responsável pelas funções descritas em cima. A interface necessária à
comunicação entre os processadores e o router é providenciada por um bloco que se denominou
adaptador de rede. O adaptador de rede é o responsável por interpretar os pacotes vindos do router
e gerar os sinais necessários para escrever na caixa de correio e avisar o processador de quando é
que os dados estão prontos. Na figura 4.3 encontra-se representada a disposição básica do sistema
de multiprocessamento baseado na arquitectura de comunicação comutador crossbar com quatro
processadores.
39
Figura 4.3 – Arquitectura do sistema de multiprocessamento com base no comutador crossbar. NA
– Adaptador de Rede (Network Adapter)
O envio de dados de um processador para outro divide-se em duas fases. Na primeira fase é
enviado o cabeçalho. O cabeçalho contém a informação necessária a reservar um caminho através da
rede para os dados subsequentes. Inclui também informação necessária à escrita dos dados na caixa
de correio do processador destino. Na segunda fase são transmitidos os dados correspondentes a
esse cabeçalho sequencialmente. Existem por isso pacotes do tipo cabeçalho e do tipo dados. A
estrutura de ambos os tipos de pacotes encontra-se representada na figura 4.4. O bit mais
significativo em ambos os pacotes identifica o tipo de pacote (type). ‘0’ identifica um pacote de
dados e ‘1’ um pacote do tipo cabeçalho.
Relativamente ao pacote do tipo cabeçalho, o campo destino indica o processador a que se
destina a mensagem. Cada processador é identificado por um número. A dimensão deste campo
depende do número de número de processadores interligados no sistema. No caso do sistema com
quatro núcleos, o campo dest identifica um de três destinos possíveis. No caso do sistema com oito
núcleos, representa um de sete destinos possíveis. O campo denominado por offset consiste no
endereço base onde os dados serão armazenados na caixa de correio do processador destino. O
campo datasize contém a dimensão do bloco de dados a ser enviado. A dimensão destes dois
campos depende da dimensão definida para as caixas de correio do sistema, o que dependerá por
sua vez da quantidade des dados a armazenar. Os outros bits não têm qualquer significado,
simplesmente não é possível suprimi-los pois o mínimo denominador comum para a dimensão dos
pacotes que viajam através da rede é o pacote de dados.
40
O pacote do tipo dados tem apenas dois campos. O campo type já referido e o campo payload. O
campo payload tem o comprimento fixo de 32 bits e comporta os dados a serem enviados para o
processador destino. Em baixo descreve-se o funcionamento e estrutura de cada um dos módulos
constituintes do comutador crossbar.
Cabeçalho
33 32 - 16 15 - 9 8 - 2 1 - 0
Type Datasize Offset Dest
Dados
33 32 - 0
Type Payload
Figura 4.4 - Estrutura dos pacotes do tipo cabeçalho e dados, respectivamente. Os campos do
pacote do tipo cabeçalho encontram-se dimensionados para suportar a comunicação entre quatro
núcleos de processamento.
Router
A estrutura do router encontra-se representada na figura 4.5 (na figura está representada
apenas a lógica correspondente a um destino, por motivos de simplificação do esquema). Um pacote
quando chega ao router é escrito na fila (referida até agora como buffer) correspondente à sua
origem. Ao chegar à cabeça da fila o pacote é então avaliado pelo árbitro, que dá ou não, permissão
para o pacote avançar. Se o pacote recebe permissão para avançar, a fila recebe permissão para ser
lida através de um sinal direccionado pelo RDE_Crossbar (RD_EN). O pacote é então direccionado
pelo crossbar em direcção ao seu destino. O destino do pacote passa por um dos quatro adaptadores
de rede que controlam o acesso à caixa de correio do respectivo processador. Deve-se referir que
existem diferenças entre o tratamento de pacotes do tipo cabeçalho ou do tipo dados. No router
existe um banco de registos responsável por armazenar o destino de um pacote lido. Assim, quando
o pacote é do tipo cabeçalho, o destino é directamente lido a partir do campo Dest do pacote, e
armazenado no registo correspondente à fila de onde foi lido. Quando o pacote é do tipo dados, o
destino não está especificado no corpo do pacote e por isso é lido do registo correspondente.
Crossbar e RDE_Crossbar
O crossbar permite a um pacote chegar a qualquer destino independentemente da sua
origem. O número de entradas tem que ser maior ou igual ao número de saídas. O crossbar é
implementado com multiplexers de N entradas, um por cada destino possível para os pacotes. Em
41
que N depende do número de componentes que comunicam através do router. O crossbar recebe
um sinal de selecção do árbitro que permite encaminhar os pacotes para o respectivo destino.
O módulo RDE_Crossbar encaminha os sinais de enable de leitura dos árbitros para as filas a que se
destinam. Este módulo é implementado através de demultiplexers. O sinal de selecção dos
demultiplexers corresponde ao sinal de selecção de pacotes para o crossbar. Cada demultiplexer
apresenta N saídas. Sendo assim tem-se N sinais de enable de leitura, um para cada fila. Sendo que
cada fila recebe N sinais de origens diferentes. Através de uma porta OR é gerado apenas um sinal de
enable de leitura por cada fila. Basta assim apenas o pedido de um árbitro para ler de determinada
fila, para o pacote ser lido.
Figura 4.5 - Estrutura simplificada do router com 4 entradas e 4 saídas.
Buffers
Os buffers são os módulos responsáveis por armazenar os dados que chegam dos núcleos de
processamento. Estes são essenciais já que o árbitro pode impedir a leitura e avanço imediato dos
pacotes. Os buffers consistem em filas do tipo FIFO, têm uma largura de 33 bits e profundidade de
128 palavras. Uma característica chave das FIFOs implementadas consiste na habilidade de ler a
42
primeira palavra da FIFO sem ela ser retirada. Esta característica denomina-se por FWFT (First Word
Fall Through) e é essencial para que se possam analisar os pacotes sem que estes sejam
automaticamente retirados da fila. Para permitir esta funcionalidade as filas têm de ser mapeadas
nas BRAMs da FPGA ou em FIFOs directamente programadas nas FPGAs (built-in FIFOs), sendo que as
últimas estão apenas presentes em certos modelos [35]. As FIFOs são mapeadas nas BRAMs então,
para uma maior flexibilidade no modelo de FPGA escolhido para implementar o sistema. A leitura da
FIFO com o modo FWFT activado é imediata. No entanto, quando existe apenas uma palavra na FIFO
a leitura apresenta uma latência de 2 ciclos de relógio.
Árbitro
A estrutura do árbitro encontra-se representada na figura 4.7. A cada destino corresponde
um árbitro. O árbitro gera um sinal de selecção para o crossbar para encaminhamento dos pacotes, e
um sinal de enable para permitir a leitura efectiva das filas (em que os pacotes são retirados da fila).
O árbitro é portanto o principal responsável por manter um caminho para o envio de dados de um
núcleo de processamento para outro. Basicamente um registo armazena o sinal de selecção prévio.
Este registo é apenas actualizado com o valor seguinte quando um bloco de dados terminou de ser
enviado ou não está em progressão a leitura de nenhum bloco de dados. Com base no estado do
registo e no algoritmo round robin projectou-se um circuito combinatório que gera o sinal de
selecção de acordo com os destinos possíveis. O destino igual à origem é especificado como inválido
e por isso o circuito combinatório muda de árbitro para árbitro. O sinal enable para ler das filas é
activado quando o pacote na fila escolhida é válido (dados escritos na fila prontos a ler), e o destino
deste corresponde ao destino pelo qual o árbitro em questão é responsável.
Adaptador de Rede
Cada núcleo de processamento tem um adaptador de rede associado. O adaptador de rede
funciona como uma interface com o sistema base onde se encontra o processador. Tem como
principais objectivos a escrita na caixa de correio dos dados recebidos do router, e notificar o
processador relativamente à prontidão dos dados. O esquema do adaptador de rede encontra-se na
figura 4.6. Ao receber um pacote do tipo cabeçalho, o adaptador de rede procede ao
armazenamento dos campos type, offset e datasize. No ciclo seguinte o circuito espera a recepção de
dados da mesma origem que o cabeçalho. À chegada destes dados activa o contador, dando inicio à
contagem. A recepção completa de um bloco de dados é verificada através de um comparador que
verifica se a contagem igualou a dimensão definida no campo datasize do cabeçalho. No caso
afirmativo, se o último pacote de dados referente a determinado cabeçalho já foi escrito, o sinal
Clear é activado e o processador avisado de que os dados se encontram prontos para ler, na caixa de
43
correio. Este sinal de aviso é o mesmo que reinicializa o contador e o registo (que contém cabeçalho).
Relativamente à escrita de dados na caixa de correio o endereço é gerado por um somador. O
somador adiciona ao endereço base, proveniente do campo offset do registo, o valor da contagem
no contador resultando no endereço absoluto de escrita. Os dados são sempre escritos
sequencialmente a partir do endereço base definido no cabeçalho. Os dados a escrever
correspondem ao campo payload do pacote de tipo dados. O sinal de enable para a escrita na caixas
de correio é originado tal como o sinal de enable do contador, isto é, na identificação da chegada de
um pacote de dados válido.
Figura 4.6 - Esquema representativo do Adaptador de Rede
Optimizações
Arquitectura de comunicação genérica
A arquitectura descrita anteriormente foi primeiramente, implementada para um sistema
com quatro núcleos de processamento. O objectivo em seguida seria tornar a arquitectura genérica,
para que facilmente se pudesse modificar o número de processadores suportados. No entanto,
algumas dificuldades arquitecturais e falta de tempo impediram que este objectivo se concretizasse.
A dificuldade em generalizar o sistema reside principalmente no árbitro. Cada árbitro apresenta
lógica combinatória específica e portanto torna-se difícil de generalizar. No final adaptou-se a
arquitectura para oito núcleos de processamento.
44
Broadcast
À arquitectura de comunicação comutador crossbar foi adicionado suporte para broadcast.
Em algoritmos paralelos, como a multiplicação de matrizes, é frequente a necessidade de
distribuição dos mesmos dados por vários processadores, oriundos da mesma fonte. O broadcast
permite o envio simultâneo destes dados para todos os destinos possíveis na rede. O que permite
ganhos significativos em termos de latência na comunicação de dados (mais concretamente N vezes
menos tempo que para comunicação unicast, em que N refere-se ao número de destinos possíveis).
A nível de protocolo os pacotes passam a ter um bit adicional que identifica se estão ser
enviados no modo broadcast ou não. A nível arquitectural tiveram de ser feitas algumas alterações
para suportar este modo de transmissão de dados. As modificações mais significativas ocorreram nos
árbitros. Na figura 4.7 encontra-se um esquema do árbitro para melhor percepção da nova estrutura
dos árbitros. O comparador verifica se existe um pedido de broadcast por parte de algum dos
elementos da rede. Se for esse o caso o pacote seleccionado para ser lido, corresponderá ao pacote
cuja origem fez o pedido para broadcast. Este sinal de selecção servirá também para encaminhar os
sinais correctos necessários a gerar o sinal de enable para leitura da fila. As condições a verificar para
este sinal ficar activo consistem basicamente nas seguintes: primeiro o pacote tem de ser válido;
segundo, a origem do pacote tem de ser diferente da origem do pedido (não faz sentido o pacote
voltar para trás); terceiro, tem de se verificar se o modo broadcast está activo ou caso não esteja, se
o destino do pacote lido corresponde ao destino pelo qual o árbitro é responsável.
45
Figura 4.7 – Estrutura do árbitro com suporte para broadcast. A cinzento mais carregado estão os
módulos acrescentados ou modificados em relação ao árbitro descrito em 4.2.2.
Concluindo, projectou-se um sistema de multiprocessamento com quatro e oito núcleos de
processamento baseado na arquitectura de comunicação comutador crossbar, com suporte para
unicast e broadcast de dados. A latência de comunicação é de um ciclo de relógio para o melhor caso
possível e de 3 + N-2 ciclos de relógio para o pior caso possível (em que N corresponde ao número de
entradas do router). O melhor caso possível corresponde a ler um pacote imediatamente da fila
(apenas possível quando se tem mais que um elemento na fila) e quando o árbitro se encontra no
estado correspondente à escolha do pacote em questão. O pior caso possível corresponde a demorar
dois ciclos a ler um pacote de uma fila (situação em que a fila contém apenas um pacote) mais N-2
ciclos de espera, para que o árbitro atinja o estado correspondente à escolha do pacote em questão,
mais um ciclo para atravessar a rede e ser escrito na caixa de correio.
46
4.2.2 NoC
Nesta secção é descrita a arquitectura NoC projectada. Nas subsecções seguintes é definido o
protocolo de comunicação e descrita a estrutura dos vários elementos da rede. Na última subsecção,
optimizações, é descrita a implementação da abordagem comutação de circuitos na NoC. Na NoC
projectada cada nó corresponde a três elementos base. Estes elementos interligam-se como está
representado na figura 4.8. No caso do sistema projectado o bloco IP corresponde ao bloco base.
Escolheu-se uma topologia mesh 2D para a configuração da NoC. Este tipo de topologia não só é mais
simples em termos de configuração dos vários elementos constituintes, como as ligações locais entre
os recursos e o router são independentes da dimensão da rede (torna o sistema facilmente
escalável). Além disso, o encaminhamento de pacotes numa arquitectura 2D é fácil, resultando em
routers potencialmente mais pequenos e mais rápidos. A configuração do NoC projectada encontra-
se representada na figura 4.9. A configuração do sistema está directamente relacionada com a
aplicação mapeada, a qual será descrita no capítulo seguinte.
Figura 4.8 – Estrutura básica de um nó constituinte da NoC.
47
Figura 4.9 – Estrutura da NoC desenvolvida com 8 elementos de processamento e topologia mesh
2D
Protocolo
O encaminhamento através da rede é efectuado na fonte. Escolheu-se esta abordagem por
ser a mais simples de implementar e permitir um router menos complexo. Em cada adaptador de
rede existe uma tabela definida. Esta tabela contém os caminhos para os vários destinos possíveis
para um pacote partindo do respectivo nó.
A função de arbitragem é semelhante à efectuada na arquitectura anterior 4.2.1, na medida
em que implementa o mesmo algoritmo round robin.
A função de comutação é desta vez efectuada com base na comutação de pacotes, visto que
é de mais fácil implementação. Na implementação por comutação de pacotes apenas existe um tipo
de pacotes, já que o cabeçalho viaja juntamente com os dados. O formato dos pacotes está
representado na figura 4.10. O caminho a percorrer na rede para chegar ao respectivo destino é
definido pelos campos DIR e ROUTE. O campo DIR contém a próxima direcção a seguir pelo pacote. O
campo ROUTE contém o restante caminho para o pacote chegar ao destino. Existem quatro
direcções que o pacote pode tomar, pois o circuito não permite que o pacote volte para trás. A
dimensão total definida para estes dois campos corresponde ao caminho mais longo que um pacote
pode percorrer na rede. O campo ADDRESS representa o endereço da caixa de correio destino, onde
os dados transportados no pacote serão escritos. O comprimento deste campo é variável
dependendo da dimensão da caixa de correio. Por fim o campo PAYLOAD consiste nos dados
propriamente ditos. Tem comprimento fixo igual a 32 bits.
48
Cabeçalho Dados
48 – 47 46 - 39 38 – 32 31 – 0
DIR ROUTE ADDRESS PAYLOAD
Figura 4.10 – Estrutura dos pacotes para arquitectura NoC
Controlo de fluxo
Há três situações que podem congestionar o tráfego na rede: situações de deadlock, em que
pacotes se encontram bloqueados em determinado nó à espera que um recurso seja libertado;
situações de livelock, em que os pacotes são encaminhados para saídas inválidas nos routers da
periferia; e situações de overflow das filas. Relativamente aos deadlocks e livelocks, o algoritmo de
encaminhamento implementado permite evitar este tipo de situações já que os caminhos são pré-
definidos. Quanto à sobrelotação das filas, estas estão dimensionadas para que nunca fiquem
sobrelotadas. Tal como na arquitectura com comutador crossbar admite-se que as filas nunca
enchem totalmente.
Router
O router apresenta a estrutura representada na figura 4.11. Os routers apresentam todos a
mesma estrutura, simplesmente não recebem dados de determinadas direcções (o sinal de enable de
escrita nas filas é colocado a zero). Um pacote que chegue ao router é armazenado numa fila. Os
pacotes na cabeça da fila são analisados pelo árbitro e se este o permitir são avançados através do
crossbar em direcção à saída respectiva. O RDE_crossbar encaminha o sinal de enable de leitura
gerado nos árbitros para a fila respectiva. O crossbar é implementado com recurso a cinco
multiplexers 4:1. Cada multiplexer corresponde a um destino possível para um pacote. A razão para
se terem multiplexers de quatro entradas quando existem cinco entradas num router é porque os
pacotes não podem voltar para trás. O RDE_crossbar consiste em cinco demultiplexers 1:4. De resto
apresenta uma estrutura equivalente à descrita para o RDE_crossbar da secção 4.2.1.
Buffers
Os buffers correspondem a filas do tipo FIFO tal como na arquitectura anterior. A única
característica que muda é a largura da fila, derivada do maior comprimento dos pacotes.
Árbitro
A estrutura do árbitro é semelhante ao árbitro da arquitectura anterior, no entanto um
pouco mais simples. Um registo contém o sinal de selecção de pacotes prévio. A cada ciclo de relógio
49
o sinal é actualizado conforme o algoritmo round robin implementado pelo circuito combinatório. E
escolhida uma das quatro origens possíveis. Se o pacote analisado for válido e a direcção a tomar
corresponde ao árbitro em questão, então o sinal de enable de leitura para a fila é activado. No caso
do árbitro IP é verificado de uma forma diferente para onde é que os pacotes pretendem ir. Já que
não se permite que os pacotes voltem por onde vieram (não faz sentido), utiliza-se esta
particularidade para verificar se o pacote vai para o bloco IP. Se o pacote apresentar a direcção
actual contrária à direcção prévia tomada, é encaminhado para o bloco IP.
Adaptador de rede
Os pacotes a ser enviados para rede são formados no adaptador de rede. É no adaptador de
rede também que os pacotes recebidos da rede são “descascados” e passados ao bloco IP. Cada vez
que é recebido um pacote é lançado um sinal de aviso para o sistema base, sendo incrementado o
contador (controlador de dados recebidos). Cada nó tem um identificador que é apenas único dentro
do adaptador de rede respectivo. Um componente ao enviar dados para a rede deve especificar este
destino (será um dos oito nós). Este sinal selecciona a rota do pacote a partir da tabela de
encaminhamento.
50
Figura 4.11 – Estrutura do router da arquitectura NoC.
Optimizações
Comutação de circuitos
Depois de implementada a abordagem mais simples baseada na comutação de pacotes
decidiu-se implementar uma NoC baseada na comutação de circuitos. Assim é possível comparar
directamente as duas abordagens e verificar qual a que de facto apresenta melhores resultados dada
a aplicação escolhida. No sistema baseado na comutação de circuitos necessitaram de ser efectuadas
algumas modificações de forma a possibilitar o estabelecimento de caminhos através da rede.
Relativamente ao protocolo existem agora três tipos de pacotes. Pacote do tipo cabeçalho, pacote de
dados e pacote de terminação. O pacote do tipo cabeçalho contém a informação necessária a
configurar a rede de forma a reservar um caminho para os pacotes subsequentes. O pacote do tipo
dados contém os dados a enviar. O pacote do tipo terminação identifica o último pacote de dados a
51
enviar e permite libertar o caminho reservado para a comunicação do bloco de dados. Os dois bits
mais significativos dos pacotes definem o seu tipo. A nível arquitectural o árbitro sofreu algumas
modificações. Durante a transmissão de um bloco de dados o registo responsável por guardar o sinal
prévio de selecção de pacotes, não pode mudar. Sendo assim o sinal de enable que antes estava
sempre ‘1’, agora é apenas activado quando o pacote analisado não for do tipo cabeçalho ou de
dados (sinónimo de envio de dados a ocorrer). Portanto o registo não deve ser modificado se o
pacote for do tipo cabeçalho ou dados. Foi necessário incluir também um banco de registos no
router tal como na arquitectura descrita em 4.2.1. Cada registo corresponde a uma origem diferente.
Caso o pacote seja do tipo dados ou terminação, o destino deste vai ser buscado ao banco de
registos. Se for do tipo cabeçalho, o valor do destino é obtido directamente do pacote lido, e
armazenado no registo correspondente. O endereçamento da caixa de correio nesta abordagem é
feito pelo contador existente no bloco base, ao qual o programador tem acesso.
Concluindo a abordagem baseada na comutação de circuitos apresenta nós mais complexos
derivado ao banco de registos extra e ao árbitro mais complexo. No entanto, a diminuição da
dimensão dos pacotes resulta em componentes mais pequenos, como as filas e o crossbar.
A latência de comunicação na NoC depende da distância entre os processadores (número de
nós pelos quais os pacotes têm de passar), do número de elementos nas filas de cada router e por
fim do estado do árbitro.
Numa rede mesh 2D tem-se uma distância máxima de 2* 𝒑 – 1. A escrita numa fila demora
um ciclo de relógio. O tempo do pacote chegar à cabeça da fila depende do número de elementos
nesta. Para filas com mais que um elemento, a leitura da fila demora dois ciclos de relógio. Caso
contrário, a leitura é imediata. A latência derivada da leitura de um pacote de uma fila depende
também do estado do árbitro em questão. Se este não se encontrar no estado correspondente à
origem do pacote a ser lido, a espera pode ir até N – 2 ciclos de relógio (em que N corresponde ao
número de entradas do router).
No pior caso possível, a leitura de um pacote da cabeça da fila num router apresenta uma
latência de 2 + (N - 2). No melhor caso, a leitura é imediata. Por fim a escrita na caixa de correio
demora um ciclo de relógio.
52
Resultados
Neste capítulo são apresentados os resultados obtidos com a implementação das
arquitecturas desenvolvidas em dispositivos Virtex-6. Primeiro é descrita a aplicação e a metodologia
escolhida para testar os sistemas, na secção 5.1. Na secção 5.2 são apresentados e analisados os
resultados obtidos. Por fim, na secção 5.3, é apresentada a implementação, para demonstração, do
sistema de multiprocessamento numa FPGA residente numa placa de desenvolvimento.
5.1. Aplicação e metodologia de teste
5.1.1 Aplicação
A aplicação escolhida para testar o sistema de multiprocessamento desenvolvido consiste
num programa para multiplicar matrizes. Operações sobre matrizes, como a multiplicação de
matrizes, são bastantes comuns aparecendo em praticamente todas as áreas de pesquisa científica,
tais como teoria de grafos, algoritmos numéricos, processamento de sinais e controlo digital [36].
Além disso a complexidade da operação de multiplicação de matrizes iguala a complexidade de
“quase” todos os problemas envolvendo matrizes, seja resolver sistemas lineares, avaliar
determinantes, ou representação de grafos, entre outros. A multiplicação de matrizes é assim, uma
aplicação que apresenta um bom grande grau de generalidade, e por isso ideal para testar o sistema
de multiprocessamento desenvolvido.
Dadas duas matrizes A e B, de dimensão n x m e m x l respectivamente, a sua multiplicação
resulta numa matriz produto C de dimensão n x l. Cada elemento da matriz C pode ser definido da
forma seguinte:
𝐶𝑖𝑗 = 𝐴𝑖𝑘𝐵𝑘𝑗 𝑚−1𝑘=0 𝑜𝑛𝑑𝑒, 0 ≤ 𝑖 < 𝑛, 0 ≤ 𝑗 < 𝑙 (5.1)
A multiplicação de matrizes requer nml operações de multiplicação e nl(m-1) operações de adição.
5
53
A maior parte dos algoritmos de paralelização da multiplicação de matrizes decompõe as
matrizes em sub-matrizes, com base no número de processadores disponíveis. Durante o processo
de execução, cada processador calcula o resultado parcial utilizando as sub-matrizes que se
encontram a ser acedidas no momento. Efectua em seguida o mesmo cálculo nas novas sub-matrizes
adicionando os novos resultados aos anteriores. Quando o sub-processo da multiplicação está
completo, o processador raiz (root) reúne os resultados parciais e gera o resultado completo da
multiplicação das matrizes.
O algoritmo sistólico [37], o algoritmo Cannon [38], o algoritmo de Fox [39], o PUMMA
(Parallel Universal Matrix Multiplication) [40], o SUMMA (Scalable Universal Matrix Multiplication)
[41] e o DIMMA (Distribution Independent Matrix Multiplication) [42, 43] são exemplos de algoritmos
sofisticados para computação paralela de produtos matriciais. Em [36] é efectuado um estudo para
determinar qual destes algoritmos é o mais adequado para ser utilização na paralelização da
multiplicação de matrizes. A análise feita pelos autores mostra que o algoritmo sistólico é o melhor
algoritmo considerando a sua alta eficiência, seguido pelo PUMMA, DIMMA e depois o SUMMA.
Qualquer um dos algoritmos acima referidos é complexo e moroso de implementar. No
âmbito deste trabalho e dado que o objectivo foi o de usar o programa para verificar e caracterizar as
arquitecturas desenvolvidas, optou-se inicialmente por programar um algoritmo de maior
simplicidade (algoritmo 1). Um factor importante consiste na escrita de programas escaláveis face ao
número de núcleos de processamento que se pode utilizar e dimensão das matrizes suportada. Desta
forma pode-se aumentar facilmente a performance de um sistema aumentando o número de
núcleos de processamento utilizados. O algoritmo 1 foi desenvolvido, tendo este factor em mente.
No entanto, ao se implementar este algoritmo reparou-se que a memória necessária para o sistema
escalava bastante rapidamente com o número de processadores. Um segundo algoritmo (algoritmo
2) para paralelização da aplicação de multiplicação de matrizes foi desenvolvido com o objectivo de
baixar a utilização da memória e manter a performance do algoritmo 1.
Consideraram-se os seguintes pressupostos no desenvolvimento dos algoritmos. A e B são
matrizes quadradas de dimensão n x n, em que n é um inteiro e sempre potência de 2. O número de
processadores num sistema, p, é também um inteiro e sempre potência de 2. Apenas o processador
root ou 0 tem acesso à matriz A e B.
Algoritmo 1
Considere-se n = q * p, em que q ≥ 1 é um inteiro (potência de 2). A matriz A é particionada
em p regiões na qual cada região contém q linhas que são atribuídas a cada processador. A Matriz B é
disponibilizada a todos os processadores. O processador 0 funciona como processador anfitrião
sendo o responsável por distribuir os dados necessários pelos outros processadores e esperar pelos
54
resultados dos outros processadores, tal como ilustrado na figura 5.1. A fase de distribuição/recolha
de dados depende do sistema e pode não ser necessária para certas aplicações. De forma a tornar o
algoritmo 1 mais escalável com o número de processadores, a matriz B é segmentada em sub-
matrizes de dimensão n x p de forma a reduzir a memória necessária para a caixa de correio de cada
processador. Assim o processo definido na figura 5.1 é repetido n/p vezes.
Figura 5.1 – Algoritmo básico de paralelização da multiplicação de matrizes. Representado para o
caso de quatro núcleos de processamento.
55
Algoritmo 2
Seja A e B duas matrizes de dimensão n x n e d = n / p, com n ≥ p (isto é, o número de linhas
de uma matriz nunca é inferior ao número de processadores). A matriz B é particionada em d sub-
matrizes n x p e a matriz A em n linhas. O algoritmo 2 pode ser descrito pelos seguintes pontos:
Processador root lê e envia para cada processador uma coluna diferente da sub-
matriz B (passo 1 da figura 5.2).
O processador root lê e envia uma linha de A para todos os processadores (passo 2
da figura 5.2).
Cada processador gera um elemento da matriz C e envia-o para o processador root
(passo 3 e 4 da figura 5.2).
O ponto 2 e 3 são repetidos até se obter uma sub-matriz n x p da matriz C.
Repete-se 1, 2, 3 e 4 até se obter a matriz C final.
Na figura 5.3 encontra-se um fluxograma que representa de forma simplificada o algoritmo 2 no seu
todo.
56
Figura 5.2 – Fases do algoritmo 2. Representado para o caso de quatro núcleos de processamento.
57
Figura 5.3 – Fluxograma representativo do funcionamento do algoritmo 2.
58
Algoritmo 1 versus Algoritmo 2
Nesta secção é efectuada uma comparação teórica entre os dois algoritmos. Existem três
factores importantes a ter em conta na comparação destes dois algoritmos: a latência de
comunicação com a memória de entrada (onde residem as matrizes A e B), a latência de
comunicação na fase da distribuição e recolha de dados (i.e. comunicação com a rede), e a memória
necessária ao sistema (caixas de correio e memória de dados local) para conter os operandos. A
comunicação tanto com a memória de entrada como com a rede é caracterizada pelo número de
operações envolvidas em função do número de processadores (p) e dimensão das matrizes (n). Cada
operação envolve o movimento de um inteiro (4 Bytes). A memória necessária é caracterizada pelo
número máximo de inteiros que são necessários armazenar na memória do sistema dado o algoritmo
utilizado, também em função do número de processadores (p) e dimensão das matrizes (n). Na
tabela 5.1 apresentam-se os resultados obtidos depois da análise dos dois algoritmos.
Tabela 5.1. Comparação entre o algoritmo 1 e 2
Comunicação Memória de entrada
Comunicação Rede
Memória Necessária
Algoritmo 1 2n2 n2 + pn2 + n2 2np
Algoritmo 2 n3 + n2 n3 + n2 + n2 2n
O primeiro aspecto a reparar é o facto do algoritmo 2 ser completamente independente do
número de processadores implementados, já que apenas depende de n. Em termos da comunicação
com a memória de entrada a vantagem é do algoritmo 1 visto que apresenta uma complexidade com
uma ordem de grandeza menor que o algoritmo 2 (O(n2) < O(n3)). O algoritmo 1 apresenta também
uma menor latência de comunicação para p < n, apenas quando n = p é que os dois algoritmos se
equiparam. Quanto à memória necessária o algoritmo dois apresenta uma ocupação menor (evolui
sempre linearmente), e para mais não depende do número de processadores existentes logo
apresenta uma melhor escalabilidade neste aspecto.
Concluindo o algoritmo 1 apresenta uma performance melhor que o algoritmo 2 visto que
movimenta menos dados. No entanto, em termos de utilização de memória, apresenta uma pobre
escalabilidade comparativamente com o algoritmo 2, podendo limitar o potencial do sistema para
aceleração da multiplicação de matrizes maiores e com recurso a mais processadores.
O algoritmo 1 acabou por ser o escolhido para testar os sistemas, dado que as matrizes utilizadas
apresentam sempre a mesma dimensão 8 x 8. Além disso, nos estudos efectuados o bottleneck do
algoritmo 1 não apresenta grande relevância.
59
5.1.2 Metodologia de teste
A performance do sistema de multiprocessamento desenvolvido foi comparada sobre
diferentes arquitecturas de comunicação e número de processadores envolvidos. Todos os projectos
analisados na secção 5.2 foram sintetizados utilizando a ferramenta XST (Xilinx ISE 13.1) e tendo
como alvo o dispositivo Virtex-6 (XC6VLX130t-3ff1156). Os resultados são apenas pós síntese e não
post placed and route. O MB-LITE foi utilizado apresentando uma configuração sem unidades
funcionais adicionais (i.e multiplicador, barrel shifter) ou suporte para interrupções. A cada
processador foi associada uma memória local de 4 KBytes e uma caixa de correio de 512 Bytes.
De forma a verificar o correcto funcionamento dos circuitos escreveu-se e compilou-se um
programa em C utilizando a tool chain do MicroBlaze (i.e. MB-GCC do EDK 10.1). O programa é
carregado na memória de instruções e dados do processador e consiste no algoritmo de
paralelização de multiplicação de matrizes descrito na secção anterior (mais especificamente para
matrizes de inteiros de 32 bits e dimensão fixa 8 x 8). Em seguida é executado um testbench
utilizando o ISim (Xilinx ISE 13.1). Para um sistema com mais que um processador é necessário
desenvolver um programa para o processador root e um programa para os outros processadores de
acordo com o algoritmo 1, descrito na secção anterior. Os dados de entrada são lidos de uma
memória RAM a que apenas o processador root tem acesso. Na NoC é aproveitada a localização dos
nós para se ter uma comunicação mais rápida. Olhando para a figura 4.9 da secção 4.2.3 pode-se
constatar que o processador root se encontra no nó central. O nó central apresenta globalmente
uma distância menor para chegar a todos os outros nós e portanto a distribuição de dados torna-se
mais rápida. Os resultados são verificados utilizando uma interface standart de E/S (Entrada/Saída)
que lê os dados de um bus e escreve-os na consola do ISim com recurso ao pacote TEXTIO. Esta
interface está mapeada na memória do processador root no caso do sistema de arquitectura
crossbar. No caso da NoC a interface de entrada/saída de dados consiste no nó situado no canto
inferior direito da NoC. Os resultados são então verificados por inspecção.
Os sistemas são caracterizados em termos da área ocupada e da performance. A área
ocupada é definida de acordo com o número de recursos utilizados (LUTs e BRAMs) e respectiva
percentagem de ocupação no dispositivo. A performance é comparada com base no tempo de
execução, que tem em conta a frequência de relógio e o número de ciclos que constituem a
execução da aplicação do inicio ao fim. O número de ciclos é contabilizado a partir dos dados
temporais retirados da simulação (behavioural simulation). O tempo de execução é calculado pela
equação 5.2.
𝑇𝑒𝑚𝑝𝑜 𝑑𝑒 𝑒𝑥𝑒𝑐𝑢çã𝑜 = 𝑁𝐶𝑖𝑐𝑙𝑜𝑠 ∗ 𝑇𝑀𝑖𝑛 , 𝑇𝑀𝑖𝑛 = 1𝐹𝑀á𝑥
(5.2)
60
Para sistemas paralelos os programas dividem-se em duas partes, a parte sequencial do
programa (S) e a parte paralelizável do programa (P). A equação 5.3 baseada na lei de Amdahl
permite prever o tempo total de execução teórico para um sistema paralelo com N processadores.
𝑇 𝑁 = 𝑆 + 𝑃
𝑁 (5.3)
A partir do tempo de execução total é possível calcular o speedup e a eficiência de um
sistema de multiprocessamento para um determinado algoritmo paralelo. O speedup é dado pela
equação 5.4 e a eficiência pela equação 5.5.
𝑆𝑝 𝑁 = 𝑇 1
𝑇 𝑁 5.4
𝐸 𝑁 = 𝑆𝑝(𝑁)
𝑁 (5.5)
Estas métricas permitem avaliar o ganho de paralelismo obtido mapeando uma aplicação
num sistema de multiprocessamento. Na secção 5.2.1 o sistema de multiprocessamento projectado
com 2, 4 e 8 núcleos de processamento é analisado como meio de acelerar a aplicação de
multiplicação de matrizes. Esta análise é efectuada com base na comparação entre os valores de
speedup/eficiência esperados (teóricos) e os obtidos experimentalmente.
5.2. Resultados de performance e utilização de recursos
A arquitectura comutador crossbar é avaliada na secção 5.2.1. Primeiro é feita uma análise
sobre a escalabilidade do sistema face ao aumento do número de processadores, em termos de área
e performance. Em segundo lugar é efectuado um estudo que permite constatar sobre a
performance e eficiência do sistema em conseguir acelerar a aplicação em causa. Por fim na secção
5.2.3 é efectuada uma comparação entre a arquitectura NoC e a arquitectura comutador crossbar
em termos de área de circuito e performance.
61
5.2.1 Análise do Comutador Crossbar
Escalabilidade
Nesta secção são analisadas as arquitecturas definidas em 4.2.1. Tem-se como objectivo verificar
como é que ocupação de recursos numa FPGA evolui com o aumento do número de processadores. É
analisada ainda como é que a frequência de relógio da arquitectura de comunicação é afectada com
o aumento do número de processadores. Na tabela 5.2 encontram-se os resultados de síntese para
as arquitecturas comparadas.
Considerando apenas os sistemas sem broadcast, observa-se que a área dos sistemas é
aproximadamente proporcional ao número de processadores existentes. Tanto a nível das LUTs com
das BRAMs utilizadas observa-se a evolução esperada face ao aumento de componentes do sistema.
Os componentes mapeados nas BRAMs consistem nas memórias locais de instruções e dados, caixas
de correio, banco de registos do processador, FIFOs do router e memória com os dados de entrada.
Na tabela 5.3 apresentam-se os resultados de síntese para os módulos individuais router e
adaptador de rede. O primeiro aspecto a reparar é que a arquitectura do adaptador de rede é
independente do número de processadores, já que o número de LUTs ocupadas se mantém
constante. A dimensão do adaptador de endereços é sim dependente da dimensão das matrizes
operando. Olhando para os resultados relativos ao router verifica-se que o número de LUTs triplica
com a duplicação do número de processadores suportados no sistema. Este facto evidencia a pobre
escalabilidade da arquitectura com comutador crossbar. O principal responsável por este aumento
significativo de recursos ocupados é o crossbar, cuja área evolui quadraticamente com o aumento do
número de entradas (como é comprovado pelos resultados na tabela 5.3).
O suporte para broadcast implicou principalmente um aumento da complexidade dos
árbitros (comprovado pelos resultados da tabela 5.3). Na figura 4.7 encontra-se representada a
estrutura do árbitro com e sem suporte para broadcast. Os componentes adicionais ou modificados
para suportar o broadcast estão representados num tom cinzento mais escuro. Pode-se verificar
através dos dados da tabela 5.2 que este aumento de complexidade tem um overhead baixo em
termos da área global do sistema. Este overhead é proporcional ao número de processadores.
O aumento do número de núcleos de processamento tem um impacto mínimo na frequência
máxima de funcionamento dos sistemas. Este facto deve-se a em geral a arquitectura de
comunicação funcionar a uma frequência mais elevada que o bloco base. No entanto, para o sistema
com oito núcleos de processamento com suporte para broadcast este já não é o caso. Na tabela 5.3
pode-se observar o decréscimo significativo da frequência de funcionamento do router
(aproximadamente 20%). Este facto deve-se à complexidade acrescida do árbitro (complexidade esta
62
com origem no aumento do número de processadores e suporte de broadcast) que constitui o
caminho crítico do sistema.
Tabela 5.2 – Resultados da síntese do sistema de multiprocessamento para um, dois, quatro e oito
núcleos de processamento (Cores).
1Core % 2Core % 4Core % 4CoreB*1 % 8Core % 8CoreB*1 %
LUTS 833 1 1736 2 3817 5 3830 5 7999 10 8074 10
BRAMS (36 Kb)
3 1 7 3 15 5 15 5 29 10 29 10
FMáx
(MHz)
206 - 197 194 - 194 - 192 - 174 -
TMin
(ns)
4.9 - 5.1 5.2 - 5.2 - 5.3 - 5.8 -
*1Sufixo B refere-se a suporte para broadcast.
Tabela 5.3 – Resultados da síntese individual dos módulos router e adaptador de rede para cada
arquitectura.
4Cores 4CoresB* 8Cores 8CoresB
Router NA Router NA Router NA Router NA
LUTS 324 (132/44/144)*2
41 336 (136/74/144) *2
41 1007 (528/168/288) *2
41 1184 (544/170/288) *2
41
BRAMS (36 Kb)
2 - 2 - 4 - 4 -
F. Máx (MHz)
267 547 272 547 226 547 187 517
*1 Sufixo B refere-se a suporte para broadcast.
*2Entre parêntesis refere-se o número de LUTs ocupado por cada um dos componentes Crossbar/Arbitro/FIFOs.
Aceleração da aplicação
Designando como Tr(1) o tempo total de execução de um programa, como Sr(1) o tempo de
execução da parte sequencial do programa e como Pr(1) o tempo de execução da parte paralela do
programa num único processador, obteve-se: Tr(1) = 320 us; Sr(1) = 291 us; Pr(1) = 290 us. Estes
valores são obtidos com base na equação 5.2 e nas temporizações obtidas a partir das simulações
dos sistemas. A partir do Tr(1), Sr(1) e Pr(1) determinaram-se os valores experimentais (r) e teóricos
(t) do speedup e eficiência relativos a cada um dos sistemas. Na tabela 5.4 encontram-se os
63
resultados obtidos. O tempo de execução total experimental (Tr(N)) foi obtido a partir das
simulações. O tempo de execução total teórico é calculado através da equação 5.3. O speedup
teórico e experimental foi calculado com base na equação 5.4. A eficiência teórica e experimental
dos sistemas é determinada com recurso à equação 5.5. As equações são apresentadas também na
primeira coluna da tabela 5.4.
Tabela 5.4 – Resultados de performance do sistema sistema de multiprocessamento para um, dois,
quatro e oito núcleos de processamento.
2Cores 4Cores 4CoresB*1 8Cores 8CoresB*1
Tr (N) (us) 213 169 149 188 117
Tt = Sr(1)+Pr(1)/N (us) 174 102 102 654 654
Spr = Tr(1)/Tr(N) 1,5 1,9 2,2 1,7 2,7
Spt = Tr(1)/Tt(N) 1,8 3,1 3,1 4,9 4,9
Er = Spr / N 0,75 0,48 0,55 0,21 0,34
Et = Spt / N 0,92 0,79 0,79 0,61 0,61
*1 Sufixo B refere-se a suporte para broadcast.
No gráfico da figura 5.4 representou-se a evolução do speedup em função do número de
núcleos de processamento. O speedup de um sistema está à partida restringido pelo algoritmo de
paralelização da aplicação alvo. O speedup máximo que se pode atingir pelo sistema de
multiprocessamento será então o ideal teórico representado no gráfico. O valor de speedup para
dois núcleos de processamento é claramente o que se encontra mais próximo do valor ideal teórico.
Isto acontece porque a latência de comunicação entre um processador e outro é igual à de um
normal acesso à memória (1 ciclo apenas). Como se pode observar no gráfico da figura 5.4, o
speedup para o sistema sem broadcast encontra-se longe do valor ideal teórico. Aliás para oito
processadores o speedup diminui inclusivé. A razão principal deve-se à matriz B ter que ser
transmitida integralmente para cada processador, processador a processador. E quanto maior o
número de processadores maior o número de transmissões da matriz B. Como se pode verificar pela
tabela 5.1, para n = p, a comunicação através da rede tem complexidade O(n3) tal como a
multiplicação das matrizes, o que dificulta grandemente o ganho do paralelismo. A implementação
com broadcast vem resolver esse problema, apesar da redução da frequência de funcionamento do
sistema para oito núcleos de processamento. Com broadcast a comunicação através da rede passa a
implicar um número de transmissões na ordem de n2 (O(n2)), o que implica uma melhoria significativa
64
no speedup do sistema. Existem outros problemas que afectam o speedup do sistema, mas de forma
menos significativa. Um desses problemas é o modo FWFT implementado nas FIFOs, o qual implica
dois ciclos de latência na leitura de pacotes, quando existe apenas um pacote na fila (de outra forma,
a leitura é imediata). O algoritmo de arbitragem apresenta também pobre escalabilidade, isto é,
quanto maior o número de processadores, maior poderá ser a espera de um pedido de
encaminhamento na rede. Por exemplo, no sistema com oito processadores, se existe um pacote na
fila 0 à espera de ser lido e encaminhado para o processador 2, encontrando-se o algoritmo de
arbitragem no estado 3, demora cinco ciclos de relógio até o pedido da fila 0 ser atendido.
Idealmente, isto é, quando a fila apresenta mais que um elemento armazenado na fila e o árbitro se
encontra no estado correspondente à escolha do pacote em questão, um pacote demorara apenas
um ciclo de relógio para atravessar o router e chegar ao adaptador de rede onde os dados são
preparados para ser escritos.
Figura 5.4 – Gráfico do speedup dos sistemas com dois, quatro e oito processadores
Relativamente à eficiência do sistema, pode ser visto através do gráfico da figura 5.5 que a
eficiência decresce rapidamente com o aumento do número de processadores, alcançando mesmo
uma eficiência de 20% para o sistema com 8 processadores sem broadcast. Isto é porque quando o
número de processadores aumenta, mais tempo é passado em comunicações e consequentemente o
tempo poupado no paralelismo é gasto na comunicação dos dados. Mesmo com broadcast a
eficiência continua a decrescer, longe dos valores ideais teóricos devido ao overhead das
comunicações.
0
1
2
3
4
5
6
2 4 8
Spee
du
p
Numéro de processadores
Sem Broadcast
Com Broadcast
Ideal Teórico
65
Figura 5.5 – Gráfico da eficiência dos sistemas com dois, quatro e oito processadores
5.2.2 Comutador Crossbar versus NoC
Resultados de síntese
Nesta secção a arquitectura comutador crossbar (Crossbar) é comparada com a arquitectura
NoC em termos de área de circuito ocupada. A arquitectura NoC apresenta-se sob duas versões,
NoCps implementa a função de comutação através da comutação de pacotes, e NoCcs utiliza
comutação de circuitos. As três arquitecturas apresentam oito processadores e não suportam
broadcast, portanto são equivalentes. Na tabela 5.5 encontram-se os resultados da síntese dos três
sistemas diferentes.
Tabela 5.5 – Resultados da síntese de três sistemas com oito núcleos de processamento.
Crossbar % NoCps*1 % NoCcs*2 %
LUTS 7999 10 18438 23 18723 23
BRAMS (36 Kbits)
29 10 63 23 40 15
FMáx (MHz) 192 - 195 - 195 -
TMin (ns) 5.2 - 5.1 - 5.1 -
*1 O sufixo ps refere-se à implementação packet switched.
*2 Sufixo cs refere-se à implementação circuit switched.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
2 4 8
Efic
iên
cia
Número de Processadores
Sem Broadcast
Com Broadcast
Ideal Teórico
66
Ao comparar os três sistemas nota-se uma diferença pronunciada entre o sistema Crossbar e
as NoCs em termos de recursos ocupados. Visto que ambos os sistemas apresentam sistemas base
equivalentes e o mesmo número de processadores, a diferença reside na arquitectura de
comunicação. Os routers são os elementos mais relevantes em termos de área na arquitectura de
comunicação e por isso são comparados com recurso à tabela 5.6.
Tabela 5.6 – Resultados da síntese dos routers em cada um dos três sistemas comparados.
Crossbar Router NoCps*1 Router NoCcs*2 Router
LUTS 1007 (528/168/288)*3
465 (245/24/180) *3
433 (170/60/180)*3
BRAMS (36 Kbits)
4 5 3
FMáx (MHz) 226 266 261
*1O sufixo ps refere-se à implementação packet switched.
*2Sufixo cs refere-se à implementação circuit switched.
*3Entre parêntesis refere-se o número de LUTs ocupado por cada um dos componentes Crossbar/Arbitro/FIFOs.
Portanto parte da diferença entre as duas arquitecturas tem origem na existência de apenas
um router no sistema Crossbar face aos nove routers existentes nos sistemas com NoCs, apesar de
mais pequenos. Como é óbvio o router das NoCs é mais pequeno derivado principalmente ao
número menor de entradas. Menos entradas implicam um crossbar mais pequeno, e com menos
impacto na área ocupada, para além de um árbitro menos complexo (ver tabela 5.6). O árbitro
menos complexo explica também, a maior frequência de relógio dos routers da NoC e
consequentemente do sistema baseado na NoC.
Entre as duas abordagens NoC a diferença maior reside nas BRAMs utilizadas como era
esperado. Os pacotes que atravessam o sistema NoCcs são mais pequenos que os pacotes que
atravessam o sistema NoCps. Isto implica filas com menor largura, o que se reflecte directamente no
número de BRAMs utilizadas. Componentes como o crossbar ocupam também menos área porque os
pacotes que têm de suportar são de menor dimensão. Conclui-se assim que a lógica adicional da
implementação NoCcs (registos destino e árbitro mais complexo) é compensada pelo facto de certos
componentes apresentarem uma menor largura de bits (crossbar, FIFOs são os mais
preponderantes).
67
Dos resultados apresentados na tabela 5.5. é claro que um sistema com oito núcleos de
processamento ocupa apenas 10 % do dispositivo alvo, o que implica que sistemas maiores podem
ser incluídos nesta FPGA sem problema.
Análise temporal
De forma a comparar a performance entre os três sistemas determinou-se o tempo de
execução referente a cada um dos sistemas. Mais precisamente, mediu-se o tempo de execução da
parte paralela do código, pois consiste na parte relevante a comparar. Estes resultados encontram-se
na tabela 5.7. O tempo de execução foi calculado com base na equação 5.2.
Tabela 5.7. – Resultados temporais das arquitecturas comutador crossbar e NoC.
Crossbar NoCps*1 NoCcs*2
TMin (ns) 5.2 5.1 5.1
Nº ciclos 30678 34880 30492
Tempo de execução (us) 160 178 156
*1 O sufixo ps refere-se à implementação packet switched.
*2 Sufixo cs refere-se à implementação circuit switched.
A vantagem em termos de performance é claramente dos sistemas que implementam comutação de
circuitos (Crossbar e NoCcs). Este facto é justificado pelo esquema de arbitragem. O algoritmo de
arbitragem implementado implica uma latência variável dentro do router devido à espera para que o
pedido seja atendido. Como a abordagem baseada na comutação de circuitos reserva um caminho
para o envio de um bloco de dados, está muito menos susceptível a esta espera já que apenas os
pacotes do tipo cabeçalho são sujeitos a esta espera. Na abordagem baseada na comutação de
pacotes, todos os pacotes estão sujeitos a este problema. Para mais, quanto maior o bloco de dados
a ser enviado, maior a vantagem da abordagem baseada na comutação de circuitos, pois o overhead
de enviar um pacote a mais por cada bloco de dados torna-se pouco significativo.
68
5.3. Implementação na FPGA
O sistema de multiprocessamento de quatro núcleos de processamento de arquitectura
comutador crossbar foi implementado numa FPGA. A FPGA utilizada consiste no dispositivo Spartan-
3E (XC3S500E-5FG320) residente na placa de desenvolvimento representada na figura 5.6.
Figura 5.6 – Spartan-3E e interfaces relevantes.
Para verificação dos resultados o sistema envia os dados para o PC através da interface RS232
disponível na placa. Os dados são enviados através da porta série, byte a byte através da
componente UART. O circuito especificado para o envio de dados para o PC encontra-se
representado na figura 5.7. Este circuito envia os dados série através dos sinais TDX e lê-os da
memória de saída.
69
Figura 5.7 – Circuito responsável pelo envio dos resultados para o PC.
Os dados são enviados como um ficheiro de texto, usando o “HyperTerminal” (Capture Text),
como uma sequência de caracteres hexadecimais terminada com o carácter ‘L’. O inteiro de 4 bits
lido da memória de saída é convertido internamente para carácter hexadecimal (8 bits) a enviar,
correspondente. O envio de dados para o PC é controlado pela máquina de estados especificada na
figura 5.8. O botão 0 (“btn(0)”) do dispositivo reinicializa a máquina de estados. O botão 1 (“btn(1)”)
do dispositivo, inicia a sequência de envio de dados para o PC. O sinal “tbeSig” verifica se a interface
RS232 se encontra livre para o envio de dados. O sinal “endSending” verifica que os dados
terminaram de ser enviados. Para efeito de debug é possível, no estado final (“doDebug” = ‘1’)
visualizar os dados na memória de saída através de 8 LEDS existentes no dispositivo, usando os
switches da placa para introduzir o endereço das posições a visualizar. Visto que apenas existem
quatro switches, apenas é possível observar as dezasseis primeiras posições de memória.
Figura 5.8 – Máquina de estados controladora do envio de dados para o PC.
Performance e área
O circuito representado na figura 5.7 implementado na Spartan-3E apresenta uma
frequência máxima de relógio de 57 MHz. O circuito é testado com um relógio de 50 MHz. O sistema
utiliza 7.717 LUTs e 20 BRAMs (18 Kbits cada), apresentando uma ocupação do dispositivo de 82% e
100%, respectivamente. O recurso mais crítico consiste claramente nas BRAMs. Algumas LUTs são
inclusivé utilizadas para mapear as RAMs, derivado à escassez de BRAMs. O sistema foi testado com
70
a aplicação para multiplicação de matrizes 8 x 8, tal como o mesmo sistema tinha sido testado via
simulação, secção 5.2. Os resultados apresentados no “HyperTerminal” coincidiram com os
esperados, o que permitiu verificar o correcto funcionamento do sistema. O sistema poderia
provavelmente ser optimizado em termos de área já que essa não foi a principal preocupação. A
implementação do algoritmo 2 ajudaria a diminuir a utilização de RAM ainda que à custa de
performance do sistema. Para multiplicação de matrizes maiores provavelmente seria necessária a
adição de uma memória externa.
71
Conclusões e Trabalho Futuro
6.1 Conclusões
O principal objectivo do trabalho consistiu no projecto e implementação de um sistema de
multiprocessamento numa FPGA. Com este objectivo cumprido foram definidas novas metas, que se
acharam relevantes para o trabalho. As principais contribuições do trabalho envolvem os seguintes
pontos, não se encontrando necessariamente dispostos por ordem cronológica:
Projecto de um sistema de multiprocessamento homogéneo, de memória distribuída e com
comunicação de dados via streaming.
Desenvolvimento e comparação de duas arquitecturas de comunicação diferentes: uma
arquitectura de comunicação centralizada baseada num comutador crossbar e uma
arquitectura de comunicação distribuída baseada numa estrutura NoC de topologia mesh 2D.
Comparação de duas abordagens diferentes de comutação de dados na arquitectura NoC:
comutação de circuitos versus comutação de pacotes.
Estudo sobre a escalabilidade e performance da arquitectura comutador crossbar.
Aceleração de uma aplicação de multiplicação de matrizes mapeada no sistema de
multiprocessamento via aumento do número de processadores.
Comparação teórica entre dois algoritmos de paralelização da aplicação de multiplicação de
matrizes.
Implementação do sistema de multiprocessamento baseado na arquitectura de
comunicação comutador crossbar, com quatro núcleos de processamento, no dispositivo
Spartan-3E.
A aplicação de multiplicação de matrizes mapeada no sistema de multiprocessamento foi
acelerada através do aumento do número de processadores do sistema. Verificou-se que o speedup
obtido está longe do previsto teoricamente pela lei de Amdahl. Aliás, para a implementação do
sistema baseado no comutador crossbar sem suporte para broadcast, o speedup chega mesmo a
descer, devido ao overhead da comunicação. Com broadcast são obtidos melhores resultados visto
que é possível fazer broadcast da matriz B, e observa-se que a característica do speedup aproxima-se
6
72
do previsto teoricamente. No entanto, a eficiência continua a decrescer devido ao overhead da
comunicação. Crê-se que serão necessárias optimizações ao nível do nó de comunicação. A nível de
hardware o sistema necessita de um algoritmo de arbitragem mais eficiente. O algoritmo simples
round robin apresenta uma pobre escalabilidade para um número elevado de processadores.
Com a comparação entre as duas arquitecturas de comunicação concluiu-se que o
comutador crossbar e NoC (com comutação de circuitos) apresentam performances equivalentes. No
entanto é de notar que o principal bottleneck da arquitectura comutador crossbar consiste no
árbitro, que se torna mais complexo com o aumento do número de processadores suportados. A NoC
não apresenta este problema visto que o número de entradas do router não depende do número de
processadores do sistema e logo o árbitro mantém sempre a mesma complexidade. Em termos de
área ocupada a implementação NoC apresenta um overhead enorme relativamente ao comutador
crossbar. Crê-se ainda assim, que para um número elevado de núcleos de processamento a
implementação NoC compense, dado que o router da arquitectura comutador crossbar evolui
quadraticamente com o número de processadores, enquanto a arquitectura NoC evolui linearmente.
Em suma, a arquitectura NoC é mais escalável que a arquitectura comutador crossbar.
Entre as duas arquitecturas NoC desenvolvidas, verificou-se que a abordagem baseada na
comutação de circuitos apresenta uma performance mais elevada e uma utilização menor de
recursos, como era previsto.
Depois de comparados teoricamente os dois algoritmos de paralelização da multiplicação de
matrizes desenvolvidos, conclui-se que apresentam uma fraca performance e terão de ser
melhorados. No entanto, o algoritmo 2 apresenta uma maior escalabilidade relativamente ao
aumento da dimensão das matrizes.
Conclui-se por fim que é importante trabalhar conjuntamente a nível do software e do hardware
de forma a obter a maior performance possível. A nível de software é importante também explorar
melhor o paralelismo das aplicações e conceber novos modelos.
73
6.2 Trabalho Futuro
O projecto de um sistema de multiprocessamento com base numa NoC, apoiada no
paradigma de comutação de circuitos, verificou-se como a opção mais promissora realizada. O
trabalho que se segue foca-se na optimização desta arquitectura. A arquitectura deverá ser
optimizada em três vertentes. A nível de performance, a nível de escalabilidade e por fim a nível de
flexibilidade ou usabilidade. As optimizações deverão ser efectuadas num esforço conjunto a nível do
hardware e software.
A nível de performance pretende-se suportar a transmissão de dados via broadcast. Tal como
se viu na secção 5.2.1 para a arquitectura comutador crossbar, o broadcast melhora
significativamente a performance do sistema. Deve-se também desenvolver um novo algoritmo de
arbitragem que seja mais eficiente mas não demasiado complexo de forma a não acarretar um
grande overhead em termos de área utilizada. O algoritmo de paralelização será melhorado tendo
em conta os algoritmos mais complexos referidos na secção 5.1.
Em termos de escalabilidade pretende-se tornar a arquitectura do sistema genérica de forma
aumentar facilmente o número de unidades de processamento.
Em termos de usabilidade/flexibilidade deve-se potenciar o carácter modular da NoC. Isto é
importante para que se seja facilitada a integração de novos componentes e o mapeamento de
novas aplicações. Esta característica baseia-se em dois aspectos fulcrais. Por um lado uma interface
standard fácil de adaptar, por outro um protocolo simples fácil de implementar. A ideia é aproveitar
o adaptador para suporte do protocolo Wishbone providenciado pelos autores do MB-LITE e
implementar a NoC com suporte para componentes Wishbone. Isto aumenta grandemente a
usabilidade do sistema dado o cada vez maior número de componentes que suportam este bus
opensource (por exemplo, a comunidade Open Cores disponibiliza um número razoável de IPs que
suportam o bus Wishbone [44]). No entanto, deve ser primeiro estimado o impacto na performance
da utilização do bus Wishbone.
Seria importante também efectuar um estudo de como é como sistema se comporta com o
aumento da dimensão de matrizes (em termos performance e área ocupada).
Finalmente, seria interessante implementar e testar o sistema numa FPGA sobre várias
configurações e avaliar a performance obtida e o potencial para crescimento do sistema de
multiprocessamento.
74
Referências Bibliográficas
[1] Asanovic, K. et al., “The Landscape of Parallel Computing Research: A View from Berkeley”,
UCB/EECS-2006-183, University of California, Berkeley, December 2006.
[2] T. Dorta, J. Jiménez, Martín. J, Bidarte, U and Astarloa. A, “Overview of FPGA-Based
Multiprocessor Systems”, International Conference on Reconfigurable Computing and FPGAs,
pp.273-278, 2009.
*3+ J. Hennessy and D. Patterson, “Computer Architecture - A Quantitative Approach”, Morgan
Kaufmann Publishers, Fourth Edition, May 2007.
[4] J. Modi, “Parallel Algorithms and Matrix Computation”, New York: Oxford University Press, 1988.
[5] Somen Barma, “Design, Development and Performance Evaluation of multiprocessor systems on
FPGA”, Master Thesis, Indian Institute of Technology Delhi, 2007.
[6] Oriol Arcas Abella, “Beehive: an FPGA-based multiprocessor architecture”, Master Thesis,
Universitat Politècnica de Catalunya, September 2009.
[7] Tamar Kranenburg, “Design of a Portable and Customizable Microprocessor for Rapid System
Prototyping”, Master Thesis, Delft University of Technology, 2009.
[8] Soft CPU Cores for FPGA, http://www.1-core.com/library/digital/soft-cpu-cores.
*9+ J. G. Tong, I. D. L. Anderson and M. A. S. Khalid, “Soft-Core Processor for Embedded Systems”, in
Proceeding of the International Conference on Microelectronics (ICM '06), pp. 170 – 173, December
2006.
[10] B. Nichols, D. Buttlar, and J. P. Farrell, “Pthreads Programming”, O’Reilly & Associates,
Sebastopol, Calif, USA, 1996.
[11+ “The OpenMp API specification for parallel programming”, http://openmp.org/wp.
[12] W. Gropp, E. Lusk, and A. Skjellum, Using MPI: Portable Parallel Programming with the Message
Passing Interface, MIT Press, Cambridge, Mass, USA, 1994.
[13] K. Ravindran, N. Satish, Y. Jin, and K. Keutzer, “An FPGA-based soft multiprocessor system for
IPV4 packet forwarding,” in Proceedings of the International Conference on Field Programmable
Logic and Applications (FPL ’05), pp. 487–492, August 2005.
[14] O. Lehtoranta, E. Salminen, A. Kulmala,M. H¨ annik¨ ainen, and T. D. H¨ am¨ al¨ ainen, “A parallel
MPEG-4 encoder for FPGA based multiprocessor SOC,” in Proceedings of the International
Conference on Field Programmable Logic and Applications (FPL ’05), pp. 380–385, August 2005.
75
[15] R. K. Karanam, A. Ravindran, and A. Mukherjee, “A stream chipmultiprocessor for
bioinformatics,” SIGARCH Computer Architecture News, vol. 36, no. 2, pp. 2–9, 2008.
[16] T. Oliver, B. Schmidt, D. Maskell, D. Nathan, and R. Clemens, “Multiple sequence alignment on
an FPGA,” in Proceedings of the 11th International Conference on Parallel and Distributed Systems
Workshops (ICPADS ’05), vol. 2, pp. 326–330, IEEE Computer Society,Washington, DC, USA, July 2005.
[17+ A. Tumeo, M. Branca, L. Camerini et al., “A dual-priority real-time multiprocessor system on
FPGA for automotive applications,” in Proceedings of the Conference on Design, Automation and
Test in Europe (DATE ’08), pp. 1039–1044, ACM, New York, NY, USA, March 2008.
[18] Ralf Joost , Ralf Salomon , “Advantages of FPGA-Based Multiprocessor Systems in Industrial
Applications”, Industrial Electronics Society, 2005. IECON 2005. 31st Annual Conference of IEEE,
2005.
[19] Stephen Craven, Cameron Patterson, and Peter Athanas, “Configurable Soft Processor Arrays
Using the OpenFire Processor”, Military and Aerospace Programmable Logic Devices International
Conference, Washington DC, Sep 2005.
[20] Antonino Tumeo, Matteo Monchiero, Gianluca Palermo, Fabrizio Ferrandi, Donatella Sciuto , “A
Design Kit for a Fully Working Shared Memory Multiprocessor on FPGA”, Application-Specific
Systems, Architectures and Processors, 2008. ASAP 2008. International Conference on, July 2008.
[21] P. Huerta, J. Castillo, J. I. Mártinez, and V. López, “A microblaze based multiprocessor SoC,” WSEAS Transactions on Circuits and Systems, vol. 4, no. 5, pp. 423–430, 2005. [22] R. Sahni and N. Vaish, “Multiprocessor Systems on Field Programmable Arrays”, Indian Institute
of Technology Delhi , May 2007.
*23+ Sean Nash, “MIZZOUSMP”, Master Thesis, University of Missouri, July 2009
[24] B. Neji, Y. Aydi, R. Ben-atitallah, S. Meftaly, M. Abid, and J.-L. Dykeyser, “Multistage
interconnection network forMPSoC: performances study and prototyping on FPGA,” in Proceedings
of the 3rd International Design and Test Workshop (IDT ’08), pp. 11–16, December 2008.
[25] L. Benini and G. De Micheli, “Networks on Chips: A New SoC Paradigm”, Computer, vol. 35, no. 1, pp. 70–78, January 2002. [26] Z. Wang and O. Hammami, “External DDR2-constrained NOC-based 24-processors MPSOC design
and implementation on single FPGA,” in Proceedings of the 3rd International Design and Test
Workshop (IDT ’08), pp. 193–197, December 2008.
[27] P.Huerta,J.Castillo,J.I.Mart´ ınez, and C. Pedraza, “Exploring FPGA capabilities for building
symmetric multiprocessor systems,” in Proceedings of the 3rd Southern Conference on
Programmable Logic (SPL ’07), pp. 113–118, February 2007.
[28] M. A. Kinsy, M. Pellauer, S. Devadas, “Heracles: Fully Synthesizable Parameterized MIPS-Based
Multicore System”, in Proceedings of the International Conference on Field Programmable Logic and
Applications (FPL’2001), pp. 356 – 362, September 2011.
76
[29] E. Salminen, A. Kulmala, and T . D. Hamalainen, “HIBI-based multiprocessor soc on FPGA,” in
Proceedings of the IEEE International Symposium on Circuits and Systems (ISCAS ’05), vol. 4, pp.
3351–3354, May 2005.
[30] Nikolaj Dalgaard To rring, “Multiprocessor in a FPGA”, B.Sc Thesis, Technical University of
Denmark, 2007.
[31] H.C Freitas, D.M. Colombo, F.L. Kastensmidt, P.O.A. Navaux, “Evaluating Network-on-Chip for Homogeneous Embedded Multiprocessors in FPGAs”, in Proceedings of the IEEE International Symposium on Circuits and Systems (ISCAS’2007), pp. 3776 – 3779, May 2007. [32] S. Kumar, A. Jantsch, J.-P Soininen, M. Forsell, M. Millberg, J. Oberg, K. Tiensyrja, A. Hemani, “A Network on Chip Architecture and Design Methodology”, in Proceedings of the IEEE Computer Society Annual Symposium on VLSI (2002), pp. 105 – 112, April 2002. [33] T. Kranenburg and R. van Leuken, “MB-LITE: A robust, light-weight soft-core Implementation of
the MicroBlaze architecture”, in Proceedings of the Design, Automation & Test in Europe Conference
& Exhibition (DATE ‘10), pp. 997 – 1000, April 2010.
[34] Xilinx. MicroBlaze Processor Reference Guide, January 2008.
[35] FIFO Generator v4.3 documentation.
[36] A. Ziad, A. Musbah and E.E. Ibrahiem, “Performance Analysis and Evaluation of Parallel Matrix
Multiplication Algorithms”, World Applied Sciences Journal, pp. 211 – 214, 2008.
[37] J. Choi, J.J. Dongarra and D.W. Walker, “Level 3 BLAS for distributed memory concurrent
computers”, in Proceedings of the Workshop on Environments and Tools for Parallel Scientific
Computing (CNRS-NSF’1992), Elsevier Sci. Publishers, September 1992.
[38] P. Alpatov, G. Baker, C. Edwards, J. Gunnels, G.Morrow, J. Overfelt, R. van de Geijn and J. Wu,
“Plapack: Parallel Linear Algebra Package”, in Proceedings of the SIAM Parallel Processing
Conference, 1997.
[39] R.C. Agarwal, S.M. Balle, F.G. Gustavson, M. Joshi and P. Palkar, “A 3-Dimensional Approach to
Parallel Matrix Multiplication”, IBM J.Res. Develop., Volume 39, Number 5, pp: 1-8, September 1995
[40] J. Choi, J.J. Dongarra and D.W. Walker, “Pumma: Parallel Universal Matrix Multiplication
Algorithms on distributed memory concurrent computers, Concurrency: Practice and Experience”,
Vol 6(7): pp. 543-570, 1994.
[41] L.E. Cannon, “A Cellular Computer to Implement the Kalman Filter Algorithm”, Ph.D. Thesis
Montana State Universit, 1969.
[42] A. Chtchelkanova, J. Gunnels, G. Morrow, J. Overfelt, R. van de Geijn, “Parallel Implementation
of BLAS: General Techniques for Level 3 BLAS”, TR-95-40, Department of Computer Sciences,
University of Texas, October, 1995.
77
[43] J. Choi, J.J. Dongarra, R. Pozo and D.W. Walker, “Scalapack: A Scalable Linear Algebra Library for
Distributed Memory Concurrent Computers”, Proceedings of the Fourth Symposium on the Frontiers
of Massively Parallel Computation. IEEE Comput. Soc. Press, pp: 120-127, 1992.
[44] http://www.opencores.org.