UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

INSTITUTO DE INFORMTICA
CURSO DE ENGENHARIA DE COMPUTAO





MAURCIO COSTA




Deteco de Falhas em Processadores VLIW






Trabalho de Graduao.





Prof. Dr. Luigi Carro
Orientador










Porto Alegre, Junho de 2010.



1




































UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
Reitor: Prof. Carlos Alexandre Netto
Vice-Reitor: Prof. Rui Vicente Oppermann
Pr-Reitora de Graduao: Profa. Valquiria Link Bassani
Diretor do Instituto de Informtica: Prof. Flvio Rech Wagner
Coordenador do ECP: Prof. Gilson Incio Wirth
Bibliotecria-Chefe do Instituto de Informtica: Beatriz Regina Bastos Haro


2

AGRADECIMENTOS

3

SUMRIO
AGRADECIMENTOS ........................................................................... 2
SUMRIO ........................................................................................... 3
LISTA DE ABREVIATURAS ................................................................. 5
LISTA DE FIGURAS ............................................................................ 6
LISTA DE TABELAS ............................................................................ 7
RESUMO ............................................................................................ 8
1 INTRODUO E MOTIVAO ....................................................... 9
2 TRABALHOS RELACIONADOS E ESTADO DA ARTE .................... 13
2.1 ARQUITETURAS DE PROCESSADORES EMBARCADOS ............................ 13
2.2 PROCESSADORES SOFT-CORE ........................................................ 14
2.3 TOLERNCIA A FALHAS EM PROCESSADORES VLIW ............................ 15
3 FUNDAES DO PROJETO .......................................................... 18
3.1 A ARQUITETURA E ISA VEX E IMPLEMENTAO DO -VEX ................. 18
3.1.1 Arquitetura VEX ................................................................ 18
3.1.2 ISA, Layout das Instrues e Slabas ....................................... 19
3.1.3 Organizao e Implementao do -VEX.................................. 21
3.2 FERRAMENTAS .......................................................................... 22
3.2.1 ISE Xilinx ......................................................................... 22
3.2.2 Compilador VEX ................................................................ 22
3.2.3 Montador -ASM................................................................ 24
3.2.4 Fluxo e uso da Toolchain ...................................................... 24
3.3 BENCHMARKS ........................................................................... 25
4 DETECO DE FALHAS NO PROCESSADOR R-VEX..................... 27
4.1 EXECUO DOS BENCHMARKS NO -VEX ........................................ 27
4.2 DESCRIO E IMPLEMENTAO DA TCNICA ..................................... 28
4.2.1 Replicao das Operaes ..................................................... 28
4.2.2 Comparao ...................................................................... 31
4.3 TIPOS DE FALHAS A SEREM DETECTADOS ......................................... 32
5 RESULTADOS E ANLISE DA TCNICA PROPOSTA .................... 33
5.1 IMPACTO NO DESEMPENHO DOS BENCHMARKS................................... 33
5.2 COMPARAO COM OUTRAS TCNICAS............................................ 36
5.3 AVALIAO DA TCNICA ATRVES DE INJEO DE FALHAS .................. 37
4

6 CONCLUSO ............................................................................... 38
REFERNCIAS ................................................................................. 41
APNDICE A: TABELAS .................................................................... 43



5

LISTA DE ABREVIATURAS
ASIC Application-Specific Integrated Circuit
CPI Ciclos Por Instruo
CTR, CTRL Unidade de execuo de operaes de desvio
DSP Digital Signal Processors
ECC Error-Correcting Code
FPGA Field Programmable Gate Array
HDL Hardware Description Language
IPC Instrues Por Ciclo
ISA Instruction Set Architecture
MEM Unidade de execuo de operaes de leitura e escrita da memria
MUL UF de multiplicao
NP Network Processor
PPG Processador de Propsito Geral
RISC Reduced Instruction Set Computer
SoC System-on-Chip
SSE Streaming SIMD Extensions
TB Tradutor Binrio
UF Unidade Funcional
UFR Unidade Funcional Reconfigurvel
ULA UF de operaes lgicas e aritmticas
VEX VLIW Example
VHDL VHSIC Hardware Description Language
VHSIC Very High Speed Integrated Circuit
VLIW Very Long Instruction Word
6

LISTA DE FIGURAS
FIGURA 1.1: NCLEO DO PROCESSADOR SUPERESCALAR HP-PA 8000. ...................... 10
FIGURA 3.1: CLUSTER VEX DE CONFIGURAO PADRO. ...................................... 18
FIGURA 3.2: VEX MULTI-CLUSTER.................................................................. 19
FIGURA 3.3: LAYOUT PADRO DAS INSTRUES. ................................................ 20
FIGURA 3.4: TEMPLATES BSICOS DEFINIDOS PARA AS SLABAS USADAS NO -VEX. ..... 20
FIGURA 3.5: FLUXO DA TOOLCHAIN. ................................................................. 25

7

LISTA DE TABELAS
TABELA 1: RESULTADOS DOS PROFILINGS DOS BENCHMARKS .................................. 43
TABELA 2: AUMENTO DO CDIGO.................................................................... 44

8

RESUMO
A proposta deste trabalho a de fornecer um mtodo de confiabilidade de baixo cus-
to para processadores VLIW, mesclando modificaes no cdigo das aplicaes e no
hardware do processador alvo. O mtodo foi aplicado ao processador -VEX, processa-
dor VLIW embarcado soft-core desenvolvido na TU Delft (Delft University of Techno-
logy). A tcnica de base adotada a de replicao de cdigo no nvel mais baixo de gra-
nularidade, o de instruo, e posterior comparao dos resultados produzidos pela ope-
rao original e de sua rplica durante a execuo. Procura-se produzir o impacto nega-
tivo menor possvel tanto no tamanho do cdigo como no desempenho das aplicaes,
atravs da replicao apenas das operaes necessrias, uso dos recursos livres do pro-
cessador quando possvel (unidades funcionais no utilizadas por uma instruo VLIW)
e comparao realizada em hardware e apenas nos pontos crticos de execuo da apli-
cao. O mtodo consiste unicamente na deteco de erros, a correo dos erros no
realizada. Uma avaliao feita: onze benchmarks so utilizados para estimar o cresci-
mento do cdigo e a degradao do desempenho e uma campanha de injeo de falhas
em FPGA foi feita para evidenciar a robustez da tcnica e os seus pontos fracos.













Palavras-chave: confiabilidade, tolerncia a falhas, deteco de erros, processador,
VLIW, soft-core, FPGA.
9

1 INTRODUO E MOTIVAO
O contexto geral deste trabalho de diplomao em Engenharia de Computao est
nos tpicos de sistemas embarcados, hardware reconfigurvel, processadores
VLIW (Very Long Instruction Word) e tolerncia a falhas. De acordo com [1], a com-
putao embarcada deve ser a prxima gerao da computao, superando a era do
computador pessoal, com dispositivos eletrnicos inteligentes, baratos, computacional-
mente poderosos e interconectados por tecnologias cabeadas ou, principalmente, sem
fio. A cada indivduo, diversas unidades computacionais sero (na verdade, j so) as-
sociadas atravs de telefones celulares, PDAs, freios ABS e outros sistemas automoti-
vos, pagers, videogames portteis e futuramente geladeiras que encomendam leite
quando da falta deste. Por esta razo, as pesquisas e trabalhos mais interessantes estaro,
na rea da computao, diretamente ligados aos sistemas embarcados, que tambm res-
pondero pela maior fatia do mercado.
O foco maior nos sistemas embarcados deve ser justamente nos processadores em-
barcados. A tendncia que circuitos perifricos que executavam determinadas tarefas
sejam absorvidos pelos processadores, cada vez mais poderosos. Uma das arquiteturas
dominantes destes processadores deve ser a VLIW.
Um processador embarcado pode ser definido como no sendo um processador de
propsito geral (PPG), usados em notebooks, PCs e servidores. As principais diferenas
esto no desempenho, tamanho, potncia e custo. Processadores embarcados podem ter
desempenho superior em determinadas aplicaes e desempenho inferior para as de-
mais, devido sua arquitetura especializada. Exemplos de processadores com desempe-
nho superior queles de uso geral so DSPs (Digital Signal Processors) e NPs (Network
Processors). O tamanho outra caracterstica importante, sendo que sistemas embarca-
dos geralmente tm o espao fsico como uma das maiores restries. O consumo em
sistemas portteis deve ser extremamente baixo, logo, processadores embarcados que
executem tarefas especficas de maneira mais eficiente em termos de energia so bem-
vindos. O custo normalmente deve ser inferior: diversos sistemas eletrnicos completos,
incluindo um processador embarcado, tm custo inferior a um nico PPG, como um
Intel Pentium, por exemplo.
Os processadores embarcados tambm devem ser comparados com o outro extremo,
ASICs (Application-Specific Integrated Circuit circuito integrado de aplicao espec-
fica), tcnica que no envolve processamento (no sentido usado para processadores). O
desenvolvimento de ASICs normalmente extremamente complexo e custoso e respon-
de a uma nica aplicao. Logo, se um dispositivo programvel responde adequadamen-
te aos requisitos da tarefa a ser realizada, o uso deste dispositivo pode tornar o projeto
em questo muito mais barato e flexvel (mudanas e correes em software so poss-
veis, no em ASICs).
10

Em [1], a arquitetura VLIW apresentada como uma tima soluo para processa-
dores embarcados (de acordo com os autores em [1], VLIW o martelo correto para o
prego computao embarcada). VLIW uma arquitetura projetada para tirar grande
proveito do paralelismo das instrues encontrado nos programas. Basicamente, uma
palavra de instruo muito longa uma instruo que comporta diversas instrues no
sentido RISC (somas, loads, stores, desvios, multiplicaes, etc.), neste contexto cha-
madas de operaes para no haver confuso com as instrues VLIW. Estas opera-
es, identificadas previamente pelo compilador como paralelas, executam contempora-
neamente em unidades funcionais (UF) diferentes. Assim sendo, um processador VLIW
comporta mltiplas instncias de uma mesma UF. Como resultado, possvel a obten-
o de um CPI (ciclos de relgio por instruo) inferior a um, ou seja, um IPC (instru-
es por ciclo de relgio) superior a um. Processadores superescalares tambm atingem
IPC superior a um, no entanto, o paralelismo extrado em hardware. O hardware de
processadores VLIW no desperdia silcio em nada que no seja estritamente ligado
ao caminho crtico da computao a ser realizada por uma determinada operao. No
h o hardware de controle presente nos processadores superescalares (ver Figura 1.1)
necessrio para, em tempo de execuo, identificar dependncias de dados, disponibili-
dade das UFs, realizar previso de desvios entre outras tarefas realizadas pelo compila-
dor de um processador VLIW.
Logo, dois fortes argumentos para o uso de processadores VLIW em sistemas em-
barcados se evidenciam. A extrao do paralelismo em tempo de compilao elimina a
necessidade do hardware para este fim. Isto resulta em menor espao fsico utilizado e
menor consumo. O segundo argumento o prprio uso de paralelismo. Muitas aplica-
es em sistemas embarcados apresentam bastante paralelismo em seus cdigos. O de-
sempenho extrado deste paralelismo com VLIW pode se reverter em uma reduo da
frequncia de operao com consequente reduo no consumo.


Figura 1. 1: ncleo do processador superescalar HP-PA 8000.
Uma grande vantagem dos processadores superescalares no mbito da computao
de propsito geral a compatibilidade entre diferentes implementaes. A mesma se-
quncia de instrues que era processada em uma verso anterior funcionar e usufruir
das novas potencialidades de novas verses de um processador superescalar. Esta a
11

caracterstica que garantiu o sucesso e a hegemonia de sistemas PC rodando um sistema
operacional Microsoft. Entre processadores VLIW, entretanto, esta compatibilidade
muito pequena ou inexistente. O cdigo compilado para um processador VLIW no
funcionar ou no ir tirar nenhum proveito das caractersticas de outro processador
VLIW: compiladores diferentes so necessrios, logo, a recompilao dos programas
necessria. Porm, em muitos sistemas embarcados, no h necessidade de se manter os
mesmos programas de uma verso para outra do sistema e os programas so recompila-
dos para cada novo produto. O usurio raramente precisa instalar novos programas e por
diversas vezes no h um sistema operacional e, quando h, estes tambm so recompi-
lados para diferentes produtos. Ou seja, em alguns casos, a compatibilidade em sistemas
embarcados no de suma importncia. Por outro lado, em alguns segmentos a tendn-
cia cada vez mais que os dispositivos sejam capazes de aceitar novos softwares sem
necessidade de modificaes no hardware e talvez nestes segmentos VLIW j no seja o
martelo mais adequado.
FPGAs (Field Programmable Gate Array), como visto em [2], nas suas duas dca-
das de existncia, mudaram radicalmente a forma com que se desenvolve lgica digital.
Casando o desempenho de ASICs e a flexibilidade de microprocessadores, FPGAs su-
peraram ambos ASICs e DSPs em algumas aplicaes tradicionais. FPGAs no so
mais vistos somente como portas lgicas ASIC lentas ou como apenas um mtodo para
criar e testar um prottipo antes da fabricao do hardware real. Atualmente, j pos-
svel desenvolver sistemas complexos, com processadores inteiros, em FPGAs.
Um FPGA um hardware programvel. Da mesma forma que um hardware tradi-
cional, computaes so executadas em vrios recursos distribudos sobre um chip de
silcio de forma paralela, atingindo desta forma grande desempenho. Entretanto, as fun-
es implementadas num FPGA podem ser apagadas e reprogramadas, ou seja, no es-
to ali gravadas de uma vez por todas como acontece no processo de fabricao de um
ASIC. FPGAs so quase to facilmente programveis quanto microprocessadores: utili-
za-se uma linguagem (como VHDL) para descrever o hardware, o cdigo criado ento
compilado (na verdade, o processo mais complexo do que isso) e gravado no FPGA
(de forma similar a compilar um programa e carreg-lo em um computador). Isto permi-
te a fcil correo de defeitos (potencialmente identificados em fases tardias dos proje-
tos) e a adio de novas funcionalidades ou simplesmente o aprimoramento do disposi-
tivo em questo.
O avano dos hardwares reprogramveis inspirou a master thesis [3] de Thijs van
As, na Delft University of Technology (TU Delft). O -VEX (reconf igurable VEX), de-
senvolvido nesse trabalho, um processador VLIW reconfigurvel inteiramente descrito
em VHDL e implementado em FPGA, o que o caracteriza como um processador sof t-
core. possvel customiz-lo de diversas formas, como modificando o nmero de ins-
trues despachadas por ciclo para as UFs, o nmero de UFs e ainda adicionando-se
novas instrues capazes de executar em hardware em poucos ciclos o que levaria di-
versos ciclos caso fosse programado em software utilizando as instrues bsicas do
processador.
O -VEX baseado na ISA (Instruction Set Architecture) VEX (VLIW Example),
uma arquitetura de processadores VLIW com propsitos didticos descrita em [1], e
esta, por sua vez, baseada na arquitetura para processadores embarcados comerciais
VLIW chamada Lx, desenvolvida em parceria pela HP e pela ST Microelectronics [4].
A ISA VEX utilizada como base para o -VEX, pois j existe para esta ISA uma ca-
deia de softwares (toolchain) sobretudo um compilador e porque ela bastante fle-
12

xvel, permitindo a customizao de diversos parmetros, as mesmas mencionadas aci-
ma para o -VEX.
O projeto de Thijs van As, concludo em 2008, foi retomado por outro aluno da TU
Delft, Roel Seedorf, em sua master thesis [?]. Nesse trabalho, diversas modificaes
foram feitas, sendo a mais importante tornar o -VEX pipelined. Ainda, diversas corre-
es foram feitas e o estilo de codificao VHDL foi modificado para melhorar o de-
sempenho.
Como em qualquer outro domnio de computao, processadores embarcados tam-
bm devem ser confiveis. As tcnicas de tolerncia a falhas a serem aplicadas devem
ser desenvolvidas levando em conta as restries que o sistema em questo apresenta,
por exemplo:
rea, consumo energtico e desempenho;
Nvel de tolerncia a falhas e abrangncia de falhas a serem toleradas, dependendo
da criticidade do sistema. Por exemplo, controle de freios ABS comparado com pro-
cessador embarcado em um celular;
Necessidade de corrigir as falhas ou apenas detect-las;
Deteco/correo em tempo real ou no.
Dentro do contexto apresentado acima, este trabalho de graduao apresenta uma
tcnica de deteco de falhas de baixo custo voltada para processadores VLIW embar-
cados tendo como objeto de estudo o processador -VEX. O mtodo proposto uma
combinao de alteraes em software e em hardware, introduzindo-se um programa na
toolchain j existente para modificar o cdigo assembly e uma pequena adio ao hard-
ware. Onze benchmarks foram utilizados para desenvolver, avaliar e comparar a tcnica
com tcnicas existentes. O processador -VEX com a tcnica aplicada foi implementado
em uma placa XUPV5 da Xilinx em um chip FPGA Virtex-5 XCV5VLX110T e uma
campanha de injeo de falhas foi realizada neste ambiente.
O captulo dois inicia esta monografia apresentando o estado da arte e os trabalhos
relacionados com esta. Em seguida, o captulo trs apresenta as fundaes do trabalho,
ou seja, o processador -VEX e as ferramentas utilizadas ao longo do projeto. O captu-
lo quatro o captulo central e apresenta a tcnica desenvolvida e como foi implemen-
tada. No captulo cinco so apresentados e analisados os resultados obtidos, ou seja, a
tcnica proposta avaliada. Por fim, o captulo seis apresenta uma concluso para o
trabalho, expondo as dificuldades encontradas, os pontos em aberto e possibilidades de
futuros trabalhos.
O segundo semestre deste trabalho de graduao foi realizado nas dependncias do
Politecnico di Torino, em Turim, na Itlia, juntamente ao grupo de pesquisas de CAD e
confiabilidade, do Departamento de Automao e Computao (Dipartimento di Auto-
matica e Inf ormatica DAUIN). O trabalho foi realizado sob a orientao do professor
Dr. Luigi Carro, no Brasil, quem possibilitou este intercmbio, e dos professores Dr.
Luca Sterpone e Dr. Matteo Sonza Reorda, na Itlia.
13

2 TRABALHOS RELACIONADOS E ESTADO DA ARTE
Este captulo apresenta trabalhos que j foram realizados e o estado da arte relacio-
nados a este trabalho de graduaao, utilizados para aprofundar o contexto e como fonte
de informao para a tomada de decises. Inicialmente, faz-se um apanhado geral sobre
os tipos de arquiteturas de processadores embarcados existentes. Em seguida, so discu-
tidos os processadores sof t-core. Por fim, so apresentadas duas tcnicas de tolerncia a
falhas empregadas em processadores VLIW. Os dois artigos que apresentam essas duas
tcnicas foram utilizados como base para o desenvolvimento da tcnica apresentada
neste trabalho de graduao e tambm so utilizados para comparar com os resultados
obtidos.
2.1 Arquiteturas de Processadores Embarcados
As arquiteturas de processadores embarcados so extremamente variadas. Alm da
arquitetura VLIW, apresentada na introduo, utilizam-se arquiteturas RISC, de DSPs,
de NPs, vetoriais etc. Esta variedade surge principalmente porque estas so projetadas
para atender a necessidades especficas dos sistemas nos quais sero utilizadas.
Duas famlias de processadores embarcados bastante utilizadas e que possuem arqui-
teturas RISC (e diversas capacidades particulares) so ARM9 [15] e PowerPC 400 [16].
Ambas as famlias foram inicialmente desenvolvidas visando computadores pessoais e
acabaram encontrando sucesso em sistemas embarcados, juntando alto desempenho e
baixo consumo. Os processadores ARM9 so largamente utilizados, por exemplo, em
telefones celulares e no videogame porttil Nintendo DS. Os PowerPC 400 por sua vez
so utilizados em aplicaes SoC (system-on-chip), de redes e em FPGAs. O PowerPC
405 utilizado em alguns FPGAs da Xilinx, aparecendo como um PPG dentro destes e
existe em verses soft-core e em hardware. Outro exemplo bastante comum do uso de
arquitetura RISC nos microcontroladores, presentes em inmeros dispositivos eletr-
nicos. Logo, processadores RISC utilizados em sistemas embarcados aparecem como
PPGs, rodando principalmente os sistemas operacionais, aplicaes de propsito geral
e rotinas de controle.
DSPs e NPs aparecem como exemplos de processadores embarcados com arquitetu-
ras especializadas para suas aplicaes. Os DSPs, que fazem processamento digital de
sinais de udio, vdeo etc., dispem de hardware e um conjunto de instrues para exe-
cutar repetidamente instrues complexas como MPYA (Multiplicar e Acumular Pro-
duto Anterior) atravs de uma instruo prvia de repetio sem a necessidade de uma
instruo de desvio para se permanecer em um lao (tratamento contnuo de um sinal).
Os NPs, de maneira similar, dispem de funcionalidades especficas como deteco de
padres de bits ou bytes num fluxo de pacotes, pesquisa em bases de dados atravs de
chaves, gerenciamento de listas etc. Ao nvel arquitetural, os NPs apresentam, por e-
xemplo, uma estrutura de pipeline em que cada estgio um processador responsvel
14

por uma das funcionalidades listadas acima. Estes dois exemplos ilustram a especializa-
o de certos processadores embarcados.
Outro tipo de arquitetura proposta para processadores embarcados a vetorial. Em
[11] apresentado um estudo que compara processadores vetoriais, ressaltando as van-
tagens destes, com processadores superescalares e processadores VLIW em aplicaes
multimdia embarcadas, tais como vdeo, reconhecimento de voz e grficos 3D. A ca-
racterstica principal desse tipo de processadores a presena de instrues capazes de
operar ao mesmo tempo sobre diversos dados, ou seja, sobre um vetor de dados (este
tipo de instrues tambm aparece em PPGs, como no conjunto de instrues SSE, de-
senvolvida pela Intel).
Outros tipos mais especficos de arquitetura voltados para sistemas embarcados
tambm existem. Em [12], uma arquitetura reconfigurvel dinmica acoplada a um pro-
cessador RISC MIPS R3000 atravs de um tradutor binrio (TB) apresentada. Esta
arquitetura permite, em tempo de execuo, a extrao do paralelismo das aplicaes e
conseguinte configurao de uma unidade funcional reconfigurvel (UFR) que dispe
de recursos (ULAs, MULs, e unidades de operaes de memria) paralelamente distri-
budos para a execuo. Assim, pode-se obter uma acelerao considervel nas aplica-
es altamente paralelas, podendo-se utilizar um clock inferior com consequente redu-
o no consumo de energia.
2.2 Processadores Soft-Core
O -VEX um processador dito sof t-core, ou seja, feito para ser utilizado em hard-
ware reconfigurvel. A expanso da capacidade dos FPGAs permitiu o seu uso para
implementar sistemas inteiros, sendo a parte central desses sistemas os processadores
soft-core. Assim, alguns destes processadores comerciais surgiram nos ltimos anos,
como o Nios da Altera, o Microblaze da Xilinx, ARM922T da ARM e o PowerPC 405
da IBM. A Open Cores [17], por outro lado, tem o objetivo de desenvolver e disponibi-
lizar processadores sof t-core e os dispositivos necessrios para formar sistemas de ma-
neira livre e gratuita sob uma licena de hardware baseada na licena para software Les-
ser General Public License (LGPL). Logo, no site da Open Cores se encontram diversos
projetos que podem ser baixados, utilizados e modificados livremente. Um desses proje-
tos o j bem difundido processador soft-core OpenRISC.
Um estudo que trata em profundidade do desenvolvimento de processadores soft-
core se encontra na master thesis de Franjo Plavec [6], da Universidade de Toronto.
Nesse trabalho, o processador soft-core Nios da Altera modelado em Verilog e nome-
ado UT Nios, tendo como objetivo delinear as etapas de desenvolvimento de processa-
dores soft-core.
Durante o processo de desenvolvimento, cada etapa pode, e deve, ser testada atravs
de simuladores funcionais e temporais como as ferramentas ModelSim [18] e o simula-
dor integrado ISE da Xilinx [19], o ISE Simulator. Assim, diminuem-se as chances de
que um problema no incio do projeto venha a se tornar muito complicado de se corrigir
em fases finais. Tambm, relativamente simples avaliar o impacto de uma modifica-
o no desempenho do processador, tanto com simulaes como diretamente em hard-
ware (no FPGA).
No caso do UT Nios, o projeto foi feito em etapas. A primeira etapa consistiu em um
processador de 16 bits (o Nios 32 bits) que executava todas as instrues da ISA do
Nios em um ciclo depois de terem sido buscadas. Nesta fase, o nmero de ciclos do UT
15

Nios muito inferior ao do Nios, porm, a frequncia mxima atingvel tambm bas-
tante inferior, resultando em menor desempenho final. O autor cita que normalmente o
projeto deve ser feito de maneira a equilibrar estes dois parmetros, o nmero de ciclos
e a frequncia do processador, pois melhorando um, o outro tende a piorar.
A segunda etapa foi uma implementao de trs estgios, que resultou em um au-
mento do nmero de ciclos, porm atingiu maior frequncia. Esta implementao serviu
de base para a terceira etapa, uma implementao de quatro estgios. A partir desta l-
tima implementao, o UT Nios final de 32 bits foi desenvolvido.
2.3 Tolerncia a falhas em processadores VLIW
Cristiana Bolchini em seu artigo de 2003 A Software Methodology f or Detecting
Hardware Faults in VLIW Data Paths [20] apresenta uma tcnica cujo objetivo de,
modificando o cdigo compilado de um dado programa sem nenhuma modificao em
hardware, possibilitar a deteco de falhas de hardware (supe-se que o software livre
de falhas) permanentes e transientes durante a execuo deste em um processador
VLIW. Cada operao duplicada, isto , executada duas vezes e instrues adicionais
para verificao dos resultados, confronto entre resultado da instruo original e de sua
rplica, so introduzidas no cdigo original.
A arquitetura VLIW de referncia utilizada a seguinte:
4 ULAs para inteiros;
2 ULAs para ponto flutuante;
2 unidades para operaes de memria;
1 unidade de salto;
64 registradores de propsito geral;
At oito operaes podem ser executadas em uma instruo, ou seja, cada instruo
constituda de oito slabas (issue-width de 8).
A tcnica desenvolvida em [20] tem o objetivo de tornar o processador seguro contra
um determinado conjunto de falhas, o que significa que todas as falhas deste conjunto
devem ser detectadas (e um sinal de erro deve ser ativado) ou corrigidas em tempo de
execuo. No trabalho apresentado, as falhas so apenas detectadas.
A abrangncia de falhas detectveis com a tcnica proposta a seguinte:
Falhas simples em qualquer elemento computacional do caminho de dados;
Falhas transientes ou permanentes;
No so levadas em conta falhas nas unidades de controle e de salto e a execuo de
uma parte errada do cdigo (falha de software).
As aplicaes so inicialmente compiladas para a arquitetura alvo com metade dos
recursos e em seguida, no cdigo assembly resultante da compilao, so introduzidas
as operaes replicadas e operaes de verificao. Para que a deteco de falhas de
hardware permanentes seja efetiva com o uso de redundncia, a operao repetida
executada em uma unidade funcional diferente daquela usada pela operao original.
Caso contrrio, apenas falhas transientes poderiam ser detectadas. Por esta razo, meta-
de dos recursos da arquitetura alvo reservada para as rplicas. Um registrador sem-
pre comparado com sua rplica quando requisitado como operando em uma operao.
16

Caso este valor esteja incorreto, uma rotina chamada que ativa um sinal de erro e ter-
mina a execuo para evitar erros na memria principal.
Para cobrir falhas na memria, as instrues replicadas utilizam cpias dos dados em
memria: assim que um dado carregado da memria, este copiado e usado nas rpli-
cas. Criam-se assim dois fluxos concorrentes de execuo.
As instrues de store no precisam ser replicadas, uma vez que os dados a serem
gravados em memria e o endereo de destino so calculados nas UFs do caminho de
dados. Estes so verificados e ento a operao de store executada, previnindo dados
incorretos na memria principal. Em instrues de load, caso no tenha sido detectado
erro no registrador que porta o endereo de memria a ser acessado, o valor do registra-
dor de destino copiado para o registrador rplica correspondente e a execuo conti-
nua normalmente.
Como apenas metade dos recursos do processador visvel ao compilador, uma de-
gradao do desempenho j deve ser esperada com relao arquitetura original. De
acordo com a autora, esta fica entre 2% e 25% para o grupo de benchmarks utilizados e
a arquitetura utilizada. Alm disso, ciclos de clock adicionais so necessrios para os
pares de instrues de comparao entre registradores originais e rplicas e a instruo
de desvio condicional para a rotina de tratamento de erros, o que leva a uma degradao
do desempenho final entre 28% e 106% e um aumento no cdigo de 109% a 217% nos
benchmarks utilizados.
Em oposio ao trabalho apresentado em [20], Yung-Yuan Chen e Kuen-Long Leu
apresentam no artigo intitulado Reliable Data Path Design of VLIW Processor Cores
with Comprehensive Error-Coverage Assessment [21] uma tcnica inteiramente em
hardware para a construo de um caminho de dados tolerante a falhas em processado-
res VLIW. Trata-se de um f ramework que permite a escolha da complexidade do hard-
ware, desempenho e abrangncia de erros a serem detectados, cobrindo tanto a deteco
como a correo dos erros. O trabalho inclui uma fase de avaliao com injeo de fa-
lhas em um processador VLIW modelado em VHDL.
Os objetivos do trabalho so no modificar o cdigo dos programas e minizar a de-
gradao do desempenho e do aumento do consumo energtico. Segundo os autores, um
aumento no cdigo pode acarretar um aumento do consumo energtico superior ao au-
mento causado pelo hardware adicional em uma tcnica desenvolvida inteiramente em
hardware, pois o consumo devido ao trfico de memria representa boa parte do consu-
mo total em um sistema computacional.
O modelo de falhas proposto em [21] composto de trs tipos de falhas:
Falhas transientes correlatas, ou seja, mltiplas falhas causadas por uma causa co-
mum;
Falhas simples ou mltiplas causando a falha de um ou mais mdulos;
Rajadas de falhas, isto , uma nova falha acontece enquanto ainda se est recupe-
rando de uma falha anterior;
Os trs tipos podem ser transientes ou permanentes. Falhas de modo comum tam-
bm so levadas em conta. As falhas de modo comum so falhas onde mais de um m-
dulo que trabalham em conjunto em um sistema redundante apresentam o mesmo com-
portamento incorreto devido a uma causa comum, o erro passando assim despercebido.
Uma crtica feita em [21] ao [20] a no incluso no modelo de falhas das falhas de
17

modo comum, o que levaria a uma cobertura no de 100% das falhas com a tcnica a-
presentada. O banco de registradores considerado protegido contra falhas por um c-
digo ECC (error-correcting code).
A importncia da deteco dos erros com latncia zero enfatizada, por este ser o
tempo determinante no tempo de correo dos erros (importante em sistemas de tempo
real, por exemplo). Para se obter latncia nula na deteco dos erros, os resultados de
cada operao devem imediatamente ser verificados e, caso um erro seja detectado, as
operaes incorretas devem ser executadas novamente logo aps. Utiliza-se um mtodo
de deteco concorrente de erros que combina, segundo a disponibilidade das UFs, du-
plicao com comparao e tripla redundncia modular (TRM). Por exemplo, em uma
arquitetura que dispe de seis ULAs:
Se uma instruo comporta trs operaes de ULA, cada uma das trs operaes
ser executada em duas ULAs e os resultados da instruo original e de sua rplica
so comparados para detectar possveis erros. Em caso de erro, a instruo execu-
tada novamente;
Se uma instruo comporta duas operaes de ULA, ambas sero executadas em
trs ULAs e o resultado escolhido por um votador. Caso uma das trs ULAs tenha
falhado, a correo automtica, sendo o resultado correto o das duas ULAs que ge-
raram o mesmo resultado. Caso as trs ULAs apresentem resultados divergentes, a
instruo deve ser executada novamente;
Se uma instruo comporta quatro operaes de ULA, esta dever ser divida em
dois pacotes de duas instrues, sendo necessrio um ciclo extra de execuo. O
comportamento de cada pacote ser o mesmo do segundo caso acima.
Por usar duplicao com comparao e TRM, os seguintes tipos de falhas no po-
dem ser detectados:
Duas UFs produzem e enviam o mesmo erro a um comparador;
Duas ou trs UFs produzem e enviam o mesmo erro a um votador por maioria.
Um processador VLIW foi modelado em VHDL para avaliar a degradao de de-
sempenho na execuo dos programas e o custo em hardware. A arquitetura VLIW a-
presentada dispe de dois tipos de UFs, quatro ULAs e uma unidade de memria. A
tcnica aplicada apenas s ULAs. Para os benchmarks utilizados, a degradao do
desempenho com relao arquitetura sem a tcnica aplicada ficou entre 0,6% e 34,3%.
O aumento do hardware foi de 14,9%.


18

3 FUNDAES DO PROJETO
Este trabalho de graduao, como mencionado na introduo, trata do desenvolvi-
mento de uma tcnica de deteco de falhas voltada a processadores VLIW embarcados,
mais especificamente ao processador -VEX. Este captulo apresenta as fundaes deste
trabalho: inicia apresentando a arquitetura e ISA VEX, em seguida discute a implemen-
tao VHDL do -VEX, apresenta as ferramentas envolvidas no trabalho, explica o uso
da toolchain e apresenta os benchmarks utilizados.
3.1 A Arquitetura e ISA VEX e Implementao do -VEX
Este tpico descreve os pontos de partida deste trabalho: a arquitetura e ISA VEX e
apresenta como o -VEX foi implementado em [3] e em [?]. Desta anlise, espera-se
compreender a arquitetura (-)VEX com o objetivo de compreender nas sees subse-
quentes a tcnica de deteco de falhas desenvolvida.
3.1.1 Arquitetura VEX
A arquitetura VEX [1], derivada da arquitetura comercial Lx [4], flexvel e pode
derivar processadores com diferentes configuraes. Um processador derivado desta
arquitetura ter a configurao que melhor atende s exigncias de suas aplicaes alvo.
Esta arquitetura permite uma construo utilizando mltiplos clusters, onde cada cluster
age como um processador VLIW independente, ou seja, pode executar ao mesmo tempo
diversas operaes contidas numa mesma instruo. Os clusters compartilham uma
mesma unidade de busca de instrues e um mesmo controlador de memria. A Figura
3.1 abaixo representa um cluster de configurao padro.

Figura 3. 1: cluster VEX de configurao padro.
[MC1] Comentrio: Master thesis Roel
Seedorf
19

Cada cluster pode ter uma configurao diferente dos outros. Entre os parmetros
modificveis de um dado cluster esto:
Nmero de ULAs (unidades aritmticas e lgicas);
Nmero de MULs (unidades multiplicativas);
Nmero de GRs (registradores de uso geral);
Nmero de BRs (registradores de desvio).
Ainda, existem parmetros globais:
Nmero de instrues despachadas para as UFs por ciclo de clock;
Unidades funcionais acessveis por slaba (espao em uma instruo VLIW que cor-
responde a uma operao);
Largura dos barramentos de memria.
Os parmetros acima mencionados so os que podem ser modificados na implemen-
tao utilizada do -VEX. Para uma listagem completa dos parmetros modificveis na
arquitetura VEX, consultar [1]. A Figura 3.2 abaixo ilustra uma configurao multi-
cluster VEX.


Figura 3. 2: VEX multi-cluster.
No caso do uso de uma configurao multi-cluster, lgica suplementar adicionada
para controlar a comunicao entre os clusters. A implementao atual do -VEX no
suporta mltiplos clusters.
Naturalmente, o compilador VEX foi projetado de maneira a refletir essa flexibili-
dade e apenas deve ser configurado de acordo com a arquitetura alvo desejada. O com-
pilador discutido em maiores detalhes na seo 3.2.2.
3.1.2 ISA, Layout das Instrues e Slabas
A ISA VEX formada por 73 operaes (excluindo-se o NOP). Uma listagem com-
pleta encontra-se em [1]. O -VEX suporta apenas configuraes com um cluster, logo,
20

as instrues de comunicao entre clusters SEND, RECV so reservadas, mas no
so utilizadas (para futuras modificaes). Uma operao foi adicionada ao conjunto
original de instrues: STOP, que para a busca de instrues para garantir que a execu-
o ser terminada. No h suporte para nmeros em ponto flutuante, apenas a inteiros.
O nmero padro mximo de instrues despachadas por ciclo de um cluster qua-
tro. Logo, o layout padro de uma instruo o seguinte:

Figura 3. 3: Layout padro das instrues.
Na figura acima tambm est ilustrado um parmetro da ISA VEX: a cada slaba
podem ser associadas determinadas unidades funcionais. Na figura, est representada a
configurao padro de quatro ULAs, duas MULs, uma MEM e uma CTRL. Este par-
metro depende, obviamente, da quantidade de cada UF na configurao em questo. Isto
significa que a slaba ocupada por uma dada operao dentro de uma instruo
determina a UF em qual esta ser executada. Por exemplo, com a configurao da
Figura 3.3, uma operao de load s pode ser posicionada na slaba trs, sendo este tipo
de operao executado pela UF MEM, responsvel pelas operaes de acesso mem-
ria.
Cada slaba constituda de 32 bits que sero utilizados de forma distinta segundo o
tipo de operao a ser executada:
7 bits para o cdigo da operao;
6 bits para 64 registradores de uso geral (mximo permitido pela arquitetura VEX);
3 bits para 8 registradores para instrues do tipo branch (mximo permitido pela
arquitetura VEX);
2 bits para indicar o tipo de imediato: 00, sem imediato; 01, imediato curto; 10, ime-
diato para deslocamento em um desvio ; 11, imediato longo;
Bit F: indica que a slaba a primeira da instruo;
Bit L: indica que a slaba a ltima da instruo.
Trs tipos de dados imediatos podem ser usados: imediato curto de nove bits, imedi-
ato para deslocamento em desvios de 24 bits (apenas 12 bits no -VEX) e imediato lon-
go de 32 bits. Os templates bsicos das slabas definidos para uso no -VEX so os a-
presentados abaixo:

Figura 3. 4: templates bsicos definidos para as slabas usadas no -VEX.
21

Deve-se observar que quando um imediato longo utilizado, duas slabas da instru-
o so necessrias para armazenar uma operao, como se v na Figura 3.4.
Ainda, a VEX uma arquitetura do tipo load/store, o que significa que apenas es-
te tipo de instrues tem acesso memria principal. As memrias tambm so dividas
em memria de dados e memria de instrues (arquitetura de Harvard).
3.1.3 Organizao e Implementao do -VEX
O processador -VEX, refletindo a arquitetura VEX, foi projetado utilizando a ar-
quitetura de Harvard (memrias de dados e instrues separadas). Os dados tm 32 bits
enquanto que as instrues tm tamanho varivel, produto entre o tamanho de uma sla-
ba (32 bits) e o nmero de slabas em uma instruo (potncias de dois). Por exemplo,
na configurao padro, uma instruo tem 128 bits divididos em quatro slabas de 32
bits.
A segunda verso do -VEX, desenvolvida em [?], pipelined. Uma estrutura de
cinco estgios adotada: busca da instruo, decodificao, execuo em duas fases e
escrita. Os estgios tm as seguintes funes:
Estgio de busca: busca as instrues na memria e passa para o estgio de decodi-
ficao.
Estgio de decodificao: faz a diviso em slabas. Operandos contidos em regis-
tradores so lidos e passados ao estgio de execuo.
Estgio de execuo: execuo das operaes aritmticas e lgicas nas ULAs e de
multiplicao nas MULs. Na unidade CTRL, as operaes de desvio so executadas.
Operaes de load/store so executadas na unidade MEM.
Estgio de escrita: escreve os resultados nos registradores e na memria.
A verso do -VEX utilizada neste trabalho no dispunha ainda de uma unidade de
controle de hazards, ou seja, nenhum tipo de mecanismo era provido em hardware para
verificar as dependncias entre as operaes. Sendo os resultados escritos nos registra-
dores apenas no ltimo estgio, o quinto, e os registradores sendo utilizados no segundo
estgio, o de decodificao, seria necessrio ou introduzir duas bolhas entre duas instru-
es dependentes, ou seja, entre uma instruo que escreve em um registrador e outra
que l o mesmo registrador imediatamente aps ou realizar f orwarding quando possvel.
Esta limitao foi contornada em software, utilizando-se uma funo do compilador,
como explicado mais adiante na seo 3.2.2.
Juntamente ao processador, existe um mdulo UART que, aps uma operao STOP
no fim da execuo do programa, l e envia o contedo da memria de dados.
Deste ponto em diante, ser considerada apenas a configurao padro VEX,
com exceo do nmero de registradores, por esta ser a configurao utilizada no decor-
rer deste trabalho:
1 cluster;
Issue-width igual a 4;
4 ULAs;
2 MULs;
1 MEM;
1 CTRL;
[MC2] Comentrio: Master thesis Roel
22

32 GRs;
4 BRs.
Observao: o registrador GR $r0.63 por definio o link register, o GR $r0.1 o
stack pointer e o GR $r0.0 conectado diretamente ao nvel lgico zero.
3.2 Ferramentas
Este tpico apresenta as ferramentas utilizadas no projeto: a ISE da Xilinx, o compi-
lador VEX e o montador -ASM.
3.2.1 ISE Xilinx
A ISE da Xilinx a interface de desenvolvimento do modelo VHDL do -VEX. Os
processos de sntese, mapeamento, posicionamento e roteamento so feitos utilizando as
ferramentas disponibilizadas na prpria ISE. As simulaes tambm foram feitas utili-
zando o simulador da ISE, o ISim. O cdigo completo VHDL da primeira verso do -
VEX foi disponibilizado pelo autor em [14]. Logo, a ISE da Xilinx permite:
Modificao do cdigo VHDL;
Simulao;
Sntese, mapeamento, posicionamento e roteamento e programao da placa de de-
senvolvimento FPGA alvo XUPV5 (Xilinx University Program Virtex 5).
3.2.2 Compilador VEX
O compilador VEX, desenvolvido para a ISA VEX pela HP a partir do compilador
projetado para a ISA comercial Lx, disponibilizado livremente em [13]. Este compila-
dor gera o cdigo assembly a partir do cdigo em C dos programas (atravs da opo -
S).
Um arquivo opcional de extenso fmm pode passar ao compilador a configurao u-
tilizada pelo -VEX alvo atravs do parmetro fmm. Caso este arquivo no seja for-
necido ao compilador, a configurao considerada a padro. Neste arquivo podem ser
definidos todos os parmetros descritos na seo 3.1 e ainda podem ser definidos atra-
sos especficos para cada UF. Este recurso utilizado para contornar a falta de uma
unidade de controle de hazards no -VEX, problema exposto na seo 3.1.3. A todas
UFs atribudo um atraso de dois ciclos e com esta informao o compilador introduz
as bolhas necessrias diretamente no cdigo assembly, isto , o compilador respeitar o
espao de dois ciclos entre instrues dependentes. Infelizmente, este artifcio no se
mostrou inteiramente eficaz em todos os casos, como exposto na seo 4.1.
O cdigo assembly gerado pelo compilador tem o seguinte formato:
c0 cmpne $b0.3 = $r0.4, $r0.5
;;
O primeiro identificador, c0, define o cluster no qual a operao ser executada. Em
seguida aparece o mnemnico da operao, no caso, uma operao a ser executada em
uma ULA que retorna verdadeiro caso os dois registradores comparados no forem i-
guais (compare not equal). Aps, esto os operandos: $b0.3 o registrador de destino e
$r0.4 e $r0.5 so os registradores fonte. Um registrador do tipo $bx.y um registrador
de um bit que armazena o resultado de uma operao de comparao para depois ser
usado em operaes de salto condicionais. Os registradores do tipo $rx.y so os regis-
23

tradores de propsito geral de 32 bits. O nmero x nos registradores designa o cluster
onde est o registrador e y designa o registrador. Por fim, ;; o separador de instru-
es.
Exemplo 3.1:
No caso da configurao padro do -VEX (ver seo 3.1), podemos ter o seguinte
exemplo de trecho de cdigo assembly:
...
;; 0] -------------------------
c0 ldw $r0.6 = 0[$r0.3]
;; 1] -------------------------
c0 shl $r0.5 = $r0.14 , 8
c0 shru $r0.10 = $r0.14 , 24
;; 2] -------------------------
nop
;; 3] -------------------------
c0 add $r0.6 = $r0.6 , 1
;; 4] -------------------------
nop
;; 5] -------------------------
nop
;; 6] -------------------------
c0 stw 0[$r0.3] = $r0.6
c0 brf $b0.1 , L2?3
c0 add $r0.15 = $r0.4 , $r0.6
;; 7] -------------------------

...

;; 8] -------------------------
c0 and $r0.7 = $r0.2 , 15728640
c0 and $r0.6 = $r0.2 , 61440
;; 9] -------------------------
c0 and $r0.9 = $r0.2 , 15
c0 add $r0.4 = $r0.4 , 1
c0 shru $r0.3 = $r0.3 , 28
c0 shru $r0.5 = $r0.5 , 4
;; 10] -------------------------
...
Sobre este exemplo de cdigo interessante observar:
Em todas as instrues o nico cluster utilizado o c0;
Uma instruo vazia, isto , formada por quatro operaes NOP, representada por
apenas um nop;
Nas instrues 0, 3 e 6 o registrador $r0.6, em negrito, exemplifica um caso de de-
pendncia entre as instrues resolvido corretamente pelo compilador. Note que foi
necessria a introduo de trs instrues vazias: 2, 4 e 5;
As instrues 8 e 9 so exemplos de instrues cujas slabas foram todas ocupadas.
No caso da instruo 8, ambas operaes tem como operando um imediato longo,
logo, cada operao ocupa duas slabas. Imediatos curtos, que cabem em uma slaba,
podem ter no mximo 9 bits, ou seja, entre -256 e +255;
A instruo 6 mostra que o compilador no tem a funo de posicionar as operaes
nas slabas corretas (ver Figura 3.3), tarefa reservada ao montador (ver seo 3.2.3 a
seguir).
24

Naturalmente, o compilador respeita a configurao da arquitetura alvo escolhida e
nunca ir gerar operaes conflitantes dentro de uma instruo, como gerar trs instru-
es de multiplicao quando apenas duas MULs esto disponveis.
Um parmetro de otimizao tambm pode ser passado ao compilador: de -O1, nvel
mais baixo, a -O4, nvel mais alto de otimizao. Todos os benchmarks utilizados neste
trabalho foram compilados nos nveis O1 e O4.
O arquivo assembly gerado serve de entrada para o montador -ASM, apresentado
na seo a seguir. Entretanto, necessrio primeiro simplificar este cdigo assembly
utilizando o Vexasm, programa disponibilizado juntamente ao compilador VEX. Um
guia completo do compilador VEX est disponvel em [13].
3.2.3 Montador -ASM
O montador -ASM tem a funo de gerar, a partir do cdigo assembly, um arquivo
VHDL cujo contedo a memria de instrues correspondente. Basicamente, o -
ASM deve:
Gerar o cdigo binrio de cada instruo, posicionando as operaes nas slabas
correspondentes;
Inicializar o stack pointer, $r0.1;
Inicializar a memria de dados (atravs de instrues de store) quando necessrio a
partir de diretivas no cdigo assembly;
Chamar o procedimento main do programa;
Encerrar a execuo com a instruo STOP.
Exemplo 3.2:
Considere o cdigo assembly abaixo:
c0 stw 0[$r0.3] = $r0.6
c0 brf $b0.1 , L0?3
c0 add $r0.15 = $r0.4 , $r0.6
c0 mpyl $r0.5 = $r0.5, 20
;;
O -ASM posicionar as operaes seguindo o layout apresentado na Figura 3.3, ou
seja:
"00101010000011000001100000000010"& -- stw 0[$r0.3] = $r0.6 Slaba 3
"11000100000111100010000011000000"& -- add $r0.15 = $r0.4, $r0.6 Slaba 2
"00001110100010100010100001010000"& -- mpyl $r0.5 = $r0.5, 20 Slaba 1
"01001010000000000000000010100101"; -- brf $b0.1, L0?3, Slaba 0
No cdigo binrio gerado, a primeira linha corresponde slaba trs e a ltima linha
corresponde slaba zero. Operaes destinadas MEM so invariavelmente posicio-
nadas na slaba trs e aquelas destinadas CTRL so posicionadas na slaba zero. As
operaes destinadas MULs ocupam primeiramente a slaba um e em seguida a slaba
dois. Por fim, as operaes destinadas ULAs so posicionadas na primeira slaba dis-
ponvel encontrada procurando da slaba trs slaba zero. Estas ordens so sempre res-
peitadas.
3.2.4 Fluxo e uso da Toolchain
A toolchain, ou seja, a cadeia de ferramentas utilizada, como mencionado nas sees
anteriores, compreende:
25

Compilador VEX;
Vexasm;
Montador -ASM;
ISim;
Ferramentas para sntese, traduo, mapeamento, posicionamento e roteamento
(P&R) Xilinx.
A Figura 3.5 abaixo ilustra o fluxo a ser seguido:















Figura 3. 5: fluxo da toolchain.
Inicialmente compila-se o cdigo em C do programa desejado. Em seguida, utiliza-
se o Vexasm para simplificar o cdigo assembly gerado pelo compilador. Aps, gera-se
a memria de instrues contida em um arquivo VHDL que deve ento ser integrado no
restante do cdigo VHDL do -VEX. A partir da, simulaes podem ser realizadas e o
cdigo pode ser utilizado para programar um FPGA. Algumas correes devem ser fei-
tas manualmente no cdigo assembly gerado pelo compilador. Estas correes so apre-
sentadas de maneira detalhada na seo 4.1.

3.3 Benchmarks
Onze benchmarks foram escolhidos para serem utilizados ao longo deste projeto. As
limitaes da plataforma alvo, isto , o processador -VEX provido apenas da memria
disponvel no chip XCV5VLX110T (da ordem do MB, dividida em memria de dados e
de instrues) e ainda em um estgio de desenvolvimento com um nmero bastante
grande de bugs, influenciou fortemente a escolha destes benchmarks. So todos bench-
marks bastante simples, porm comumente utilizados. Cada benchmark executado com
.c
Compilador
VEX
VEXASM -ASM
-VEX
EM
VHDL
ISE Xilinx
ISim
Sntese
Mapeamento
P&R
.s .s
simplificado

sim
.vhd
Correes!
26

sucesso revelou algum bug em algum ponto na toolchain (ver seo 4.1). Os bench-
marks so:
Seis algoritmos de contagem de bits, retirados do conjunto de benchmarks Mibench
[5]: bitcounts1, bitcounts2, bitcounts3, bitcounts4, bitcounts5, bitcounts6;
Bubble sort em um vetor de inteiros de 100 elementos: bubble_sort;
Quick sort em um vetor de inteiros de 100 elementos: quick_sort;
Algoritmo de Dijkstra para encontrar o caminho mais curto entre dois nodos de um
grafo (tambm retirado do Mibench): dijkstra;
Algoritmo de compresso LZW: lzw;
Multiplicao de matrizes 20x20: matrixMUL.
A escolha dos benchmarks foi influenciada pela arquitetura alvo, VLIW. Determi-
nadas aplicaes exploram mais ou menos, dependendo do nvel de paralelismo (ILP -
instruction level parallelism), os recursos de um processador VLIW. Sendo assim, o
conjunto de benchmarks deve conter representantes de baixa a alta ILP, o objetivo sen-
do poder avaliar da melhor forma possvel a tcnica apresentada. No captulo cinco so
evidenciadas as ILPs dos benchmarks.
Foi necessrio efetuar modificaes nos cdigos originais de cada benchmark a fim
de poder execut-los no -VEX, j que no h o suporte de um sistema operacional. No
momento do desenvolvimento deste trabalho, tambm no existia um ligador na tool-
chain. Logo, foi necessrio retirar todas as chamadas de sistema e chamadas a funes
externas dos cdigos. Ainda, aos ponteiros foi necessrio atribuir um endereo fixo na
memria de dados, com o cuidado de no gerar conflitos entre as diversas variveis de
um dado programa. Sempre que possvel, listas foram substitudas por vetores de tama-
nho fixo.

27

4 DETECO DE FALHAS NO PROCESSADOR R-VEX
Este captulo apresenta em detalhe a tcnica proposta. Como explicado na seo 3.3,
foi necessrio adaptar os benchmarks para a execuo no -VEX. A primeira etapa,
descrita na seo 4.1, consistiu em executar com sucesso todos os benchmarks. Em se-
guida, a seo 4.2 apresenta a tcnica desenvolvida. Por fim, a seo 5.1 apresenta os
tipos de erros cobertos pela tcnica.
4.1 Execuo dos Benchmarks no -VEX
Esta primeira etapa consistiu em testar as implementaes utilizadas do -VEX e do
montador -ASM. Estas ainda no haviam passado por uma bateria de testes intensiva e
este trabalho acabou contribuindo um pouco neste sentido ao trabalho de Roel Seedorf.
Como no momento da execuo deste trabalho ainda no existia um documento deta-
lhado sobre as modificaes feitas por Roel Seedorf, no caso sua master thesis, a nica
maneira de compreender o funcionamento e as limitaes das implementaes foi ten-
tando executar programas e discutindo diretamente com os autores do trabalho, Thijs
van As e Roel Seedorf.
O principal objetivo desta etapa foi o de formar uma lista de problemas e como evi-
t-los ou resolv-los, quando possvel, para conseguir executar um programa com su-
cesso. O primeiro programa executado foi um algoritmo para calcular a raiz quadrada de
quadrados perfeitos (no includo entre os benchmarks). Em seguida, os benchmarks
foram sendo testados na ordem em que foram apresentados na seo 3.3.
O primeiro problema identificado foi um bug na instruo MTB (que transfere o
contedo de um GR para um BR). O problema estava no -ASM, que gerava incorreta-
mente o binrio desta instruo, colocando o registrador de destino como um GR e no
como um BR. Uma simples modificao no cdigo do -ASM resolveu este problema.
Como exposto nas sees 3.1.3 e 3.2.2, o -VEX utilizado no possua uma unidade
de deteco de hazards, problema contornado utilizando o compilador com algumas
excees. Nesses pontos os cdigos tiveram que ser modificados manualmente atravs
da introduo de NOPs entre as instrues dependentes. O problema pode aparecer
quando uma instruo de salto executada: quando se modifica um registrador e faz-se
um salto logo aps e imediamente se utiliza o mesmo registrador no ponto de destino do
salto. Acontece tambm no retorno de funes, pois logo antes de retornar de uma fun-
o o stack pointer atualizado e se este for utilizado imediatamente aps o retorno o
valor lido ser o incorreto. Para resolver o problema das instrues de salto, deve-se
adicionar dois NOPs aps cada label no cdigo assembly. No caso do retorno de fun-
es, deve-se adicionar um NOP logo aps cada instruo call. Em alguns casos a de-
pendncia simplesmente no resolvida pelo compilador, sendo necessrio revisar o
cdigo e adicionar operaes NOP onde for necessrio.
28

Abaixo, uma lista de outros problemas e como foram contornados:
O -ASM no suportava operaes do tipo MOV com link register, representado no
cdigo assembly por $l0.0. Soluo: substituir $l0.0 por $r0.63, que o link register
de fato na arquitetura;
Labels utilizados como dados imediatos em operaes no eram devidamente trata-
dos pelo -ASM. Soluo: substituir o label pelo seu valor numrico corresponden-
te;
O -ASM suportava a inicializao de no mximo 512 elementos na memria de
dados. Soluo: no cdigo fonte em C, inicializar variveis e constantes diretamente
no cdigo;
O -ASM no suportava instrues SLCT e SLCTF com imediatos como operandos.
Soluo: inserir uma operao MOV para inicializar o valor imediato desejado em
um registrador no utilizado e trocar o valor imediato pelo registrador como operan-
do na instruo SLCT ou SLCTF em questo.
Evidentemente, a adio de operaes NOP no cdigo assembly como controle de
hazards leva a um nmero de ciclos superior em comparao com um -VEX provido
de uma unidade de controle de hazards em hardware capaz de realizar f orwarding. Este
fato levado em considerao na seo 335.1, que apresenta o profiling dos bench-
marks.
Todos os benchmarks foram compilados nos nveis O1 e O4 de otimizao. Logo,
ao final desta etapa, os seguintes arquivos foram gerados para cada benchmark em cada
nvel de otimizao:
Arquivo assembly corrigido;
Memria de instrues i_mem.vhd.
4.2 Descrio e Implementao da Tcnica
A proposta deste trabalho a de fornecer um mtodo de confiabilidade de baixo cus-
to aplicvel a processadores VLIW, mais especificamente ao -VEX. O mtodo consiste
unicamente na deteco de erros, um mtodo de correo de erros no proposto. A
tcnica de base adotada a de replicao de cdigo no nvel mais baixo de granularida-
de, o de instruo. Nos pontos crticos de execuo do programa, os operandos so veri-
ficados (comparao) contra suas rplicas. Se divergentes, um sinal de erro acionado e
a execuo do programa interrompida. Caso contrrio, o fluxo de execuao segue
normalmente.
A seo 4.2.1 explica fase de replicao das operaes enquanto que a seo 4.2.2
explica a fase de comparao.
4.2.1 Replicao das Operaes
A primeira etapa da tcnica consiste na replicao das instrues. Na verdade, mais
precisamente so duplicadas as operaes, lembrando que as operaes esto contidas
nas instrues VLIW. Esta etapa se d em software e um programa que realiza a dupli-
cao das operaes no cdigo assembly foi desenvolvido e inserido na toolchain.
Na prtica, so criados dois fluxos concorrentes de execuo. Para isso, primeira-
mente os bancos de registradores foram duplicados no -VEX. Na arquitetura original
(seo 3.1.3), tem-se 32 GRs e 4 BRs. Na arquitetura modificada, passa-se a ter 64 GRs
29

e 8 BRs. Os registradores de 0 a 31 (registradores originais) so utilizados pelo progra-
ma original, isto , configura-se o compilador para gerar cdigo para 32 registradores
atravs do arquivo fmm (seo 3.2.2). O restante dos registradores, de 32 a 62 (registra-
dores rplica), utilizado pelas instrues duplicadas. As seguintes observaes devem
ser feitas:
O registrador $r0.63 sempre o link register e portanto no pode ser utilizado como
registrador rplica;
Os registradores $r0.1 (stack pointer) e $r0.63 (link register) so modificados por
operaes de chamada e retorno de funes que no podem ser replicadas;
O registrador $r0.0 sempre conectado ao nvel zero e no necessita de uma rplica.
Todas as operaes que modificam registradores devem ser duplicadas, isto , todas
as operaes destinadas a ULAs e MULs e instrues do tipo load. Assim, com base nas
consideraes anteriores, as seguintes regras so aplicadas quando da duplicao de
uma operao:
Registradores GR e BR so substitudos por suas rplicas, ou seja, respectivamente
o endereo incrementado de 31 e de 4;
Os registradores $r0.0, $r0.1 e $r0.63 no possuem rplicas;
Se os registradores $r0.0, $r0.1 ou $r0.63 aparecem como operandos fonte, estes so
mantidos nas operaes replicadas (no h rplicas para eles);
Se os registradores $r0.1 ou $r0.63 aparecem como destino, a operao em questo
no replicada.
Durante a duplicao, a fim de diminuir o impacto no desempenho, quando possvel
as operaes so duplicadas dentro da mesma instruo. Para tal, as regras apresentadas
a seguir devem ser observadas, baseadas na configurao alvo do -VEX. Observar que
as operaes devem ser posicionadas nas slabas corretas, seguindo o layout da configu-
rao padro (Figura 3.3).
A. Casos em que possvel duplicar as operaes dentro da mesma instruo
(STX representa qualquer operao do tipo store):
Instruo original Instruo contendo operaes replicadas
ULA3 NOP2 NOP1 NOP0 -> ULA3 ULA3 NOP1 NOP0
ULA3 ULA2 NOP1 NOP0 -> ULA3 ULA2 ULA2 ULA3
NOP3 NOP2 MUL1 NOP0 -> NOP3 MUL1 MUL1 NOP0
ULA3 NOP2 MUL1 NOP0 -> ULA3 ULA3 MUL1 NOP0
ULA3 NOP2 NOP1 CTR0 -> ULA3 ULA3 NOP1 CTR0
STX3 ULA2 NOP1 NOP0 -> STX3 ULA2 ULA2 NOP0
STX3 ULA2 NOP1 CTR0 -> STX3 ULA2 ULA2 CTR0
NOP3 NOP2 MUL1 CTR0 -> NOP3 MUL1 MUL1 CTR0
STX3 NOP2 MUL1 NOP0 -> STX3 MUL1 MUL1 NOP0
STX3 NOP2 MUL1 CTR0 -> STX3 MUL1 MUL1 CTR0
NOP3 ULA2 NOP1 NOP0 -> NOP3 ULA2 NOP3 ULA2
B. Casos em que necessrio introduzir uma nova instruo:
Instrues com apenas um NOP, exceto:
STX3 NOP2 MUL1 CTR0
STX3 ULA2 NOP1 CTR0
Instrues contendo uma operao do tipo load;
30

Instrues contendo duas operaes do tipo MUL.
Das informaes acima, o algoritmo aplicado ao cdigo assembly foi definido. Cada
instruo analisada separadamente. Duas variveis so declaradas: uma representa a
instruo original e outra representa uma instruo com as operaes a duplicar. As ope-
raes so lidas uma a uma dentro de uma instruo. Cada operao lida gravada na
varivel que representa a instruo de origem. Se for uma operao que deve ser dupli-
cada, esta ser gravada tambm na varivel que guarda as operaes a serem duplicadas.
Durante a avaliao de uma instruo, so contabilizados o nmero de operaes ULA,
o nmero de operaes MUL, o nmero de operaes do tipo load e o nmero de NOPs.
Terminada a avaliao de uma instruo, inicia-se escrevendo no arquivo assembly de
sada a varivel com as operaes a serem duplicadas. Logo aps, avalia-se se neces-
saria a introduo de uma instruo adicional para conter as operaes duplicadas, o que
acontece quando uma das trs condies abaixo verificada:
Nmero de operaes ULA mais o nmero de operaes MUL supera o nmero de
NOPs;
Nmero de operaes MUL igual a dois;
A instruo contm uma operao do tipo load.
Caso uma dessas condies for verificada, escreve-se no arquivo assembly de sada
um separador de instrues logo aps a escrita das operaes replicadas (";;") e ento
so escritas as operaes originais. Caso contrrio, apenas se procede escrita das ope-
raes originais.
Exemplo 4.1:
Exemplo de duplicao possvel dentro da mesma instruo.
Instruo lida no assembly original:
c0 stw 400[$r0.0] = $r0.6
c0 cmpeq $b0.0 = $r0.6 , 100
;;
Resultado no arquivo assembly de sada:
c0 cmpeq $b0.4 = $r0.37 , 100
c0 stw 400[$r0.0] = $r0.6
c0 cmpeq $b0.0 = $r0.6 , 100
;;
Exemplo 4.2:
Exemplo de duplicao em duas instrues.
Instruo lida no assembly original:
c0 cmplt $b0.0 = $r0.4 , $r0.0
c0 and $r0.3 = $r0.2 , -268435456
c0 and $r0.5 = $r0.2 , 240
;;
Resultado no arquivo assembly de sada:
31

c0 and $r0.36 = $r0.33 , 240
c0 and $r0.34 = $r0.33 , -268435456
c0 cmplt $b0.4 = $r0.35 , $r0.0
;;
c0 cmplt $b0.0 = $r0.4 , $r0.0
c0 and $r0.3 = $r0.2 , -268435456
c0 and $r0.5 = $r0.2 , 240
;;
4.2.2 Comparao
A segunda etapa se d em hardware e consiste no confronto entre o contedo dos re-
gistradores resultantes do fluxo original e dos registradores resultantes do fluxo das ope-
raes replicadas. Este confronto feito apenas nos pontos crticos de execuo do pro-
grama, ou seja, quando so executadas:
Operaes do tipo store, pois estas modificam o contedo da memria de dados,
onde estar o resultado final da execuo. So elas: STW, STH e STB, respectiva-
mente, store word, store half word e store byte;
Operaes de desvio condicional, que controlam o fluxo do programa. Um registra-
dor BR incorreto pode causar o desvio para um ponto incorreto no programa. So
elas: BR e BRF, respectivamente, desvia quando condio verdadeira e desvia
quando condio falsa.
As operaes de store fazem uso de dois registradores: um registrador que a base
para calcular o endereo de destino na memria (o deslocamento um dado imediato) e
o registrador fonte que contm o dado a ser armazenado. Se o contedo destes registra-
dores for incorreto, ambos podem levar a um resultado indesejado, ou seja, um dado
incorreto armazenado no endereo correto na memria, um dado correto armazenado no
endereo incorreto ou ainda um dado incorreto armazenado no endereo incorreto. Lo-
go, ambos devem ser confrontados com suas rplicas quando uma operao de store
detectada. As operaes de desvio condicional fazem uso de apenas um registrador e
este deve ser confrontado com a sua rplica quando este tipo de operao detectado.
Um bloco destinado a comparar os registradores originais e replicados foi adiciona-
do em paralelo com o primeiro estgio de execuo no cdigo VHDL do -VEX. Sendo
assim, no h nenhum tipo de modificao no fluxo de execuo. O estgio de decodifi-
cao recebeu modificaes para detectar as operaes de store e de desvio condicional,
calcular o endereo dos registradores replicados a partir do endereo dos originais e
enviar para o bloco de verificao o contedo dos registradores a serem comparados
(GRs e BRs). Ainda, foi necessrio modificar os bancos de registradores para permitir a
leitura contempornea dos registradores originais e replicados. Como os registradores
$r0.0, $r0.1 e $r0.63 no possuem rplicas, quando uma operao de store contendo um
desses registradores (seja como base ou como fonte) como operando detectada, estes
so apenas comparados com eles mesmos.
Quando o estgio de decodificao detecta uma operao de store ou de desvio con-
dicional, o bloco de verificao sinalizado e compara os registradores recebidos em
entrada. Em caso de diferena, um sinal de erro acionado e este interrompe a execu-
ao, a fim de manter a memria de dados livre de erros (o que ser til caso se queira
realizar futuramente correo dos erros).

[MC3] Comentrio: Conclusao, traba-
lhos futuros.
32

4.3 Tipos de Falhas a Serem Detectados
As falhas alvo da tcnica proposta so falhas simples ou mltiplas (que no sejam
do tipo modo comum) transientes em qualquer elemento computacional do caminho
de dados. Falhas permanentes no so 100% detectadas, pois a tcnica no permite
sempre a execuo de uma operao original e de sua rplica em UFs distintas. Entre-
tanto, a escrita das operaes replicadas no arquivo assembly se d sempre em ordem
inversa com relao s operaes originais. Isto feito com o intuito de possibilitar a
deteco de falhas permanentes, ainda que no sempre.
Exemplo 4.3:
O exemplo abaixo mostra a inverso das operaes duplicadas com relao s ope-
raes originais:
c0 mtb $b0.4 = $r0.36
c0 mov $r0.37 = $r0.35
c0 mov $r0.36 = $r0.33
;;
c0 mov $r0.5 = $r0.2
c0 mov $r0.6 = $r0.4
c0 mtb $b0.0 = $r0.5
;;
Neste exemplo, as trs operaes sero executadas em UFs distintas, j que as trs
so destinadas ULAs e o -ASM apenas as colocar nas slabas na mesma ordem em
que aparecem no cdigo assembly. Neste caso, h a deteco de falhas permanentes nas
trs ULAs em questo.
Exemplo 4.4:
O exemplo abaixo mostra um caso em que a inverso incua para a deteco de fa-
lhas permanentes:
c0 add $r0.35 = $r0.34 , -1
c0 ldw $r0.33 = 0[$r0.1]
;; 99] -------------------------
c0 ldw $r0.2 = 0[$r0.1]
c0 add $r0.4 = $r0.3 , -1
;; 13] -------------------------
O -ASM obrigado a posicionar a operao de load (ldw) na slaba trs. Logo, a
operao add ser invariavelmente posicionada na prxima slaba livre, ou seja, a slaba
dois em ambos os casos (original e rplica).
Para que as operaes sejam sempre executadas em UFs distintas, basta integrar a
fase de introduo das rplicas no cdigo assembly ao -ASM e deixar a este o papel de
utilizar UFs diferentes para as operaes originais e replicadas. Ainda, no estado atual e
como o nico objetivo a deteco das falhas, em um programa sempre existiro opera-
es para as quais originais e rplicas sero executadas em UFs distintas, como no E-
xemplo 4.3. Ou seja, mais cedo ou mais tarde durante a execuo do programa, uma
falha permanente ser detectada, ainda que no se tenha garantia de que esta no passou
despercebida anteriormente.
[MC4] Comentrio: Concluso, traba-
lhos futuros.
33

5 RESULTADOS E ANLISE DA TCNICA PROPOSTA
Este captulo apresenta os resultados obtidos neste trabalho e realiza uma anlise da
tcnica proposta. A seo 5.1 discute o impacto no desempenho e o aumento do cdigo
nos benchmarks utilizados e em seguida uma comparao com os resultados obtidos em
[20] e [21] feita na seo 5.2. A seo 5.3 apresenta a fase de injeo de falhas reali-
zada a fim de avaliar a robustez da tcnica proposta e expor pontos que devem ser me-
lhorados.
5.1 Impacto no Desempenho dos Benchmarks
A fim de realizar uma avaliao do impacto da tcnica proposta no desempenho dos
benchmarks (ainda antes de t-la implementada), procedeu-se a um profiling dos mes-
mos. O objetivo principal deste profiling foi o de identificar nos benchmarks em quan-
tas instrues as operaes poderiam ser duplicadas sem a necessidade da introduo de
uma instruo adicional (que o que causa reduo no desempenho e aumento do cdi-
go), quantas instrues no contm operaes a serem replicadas e extrair a razo entre
o nmero de instrues executadas no programa original e no programa modificado.
Ao cdigo VHDL do -VEX original foi adicionado um bloco para realizar o profi-
ling. Este bloco recebe como entrada as instrues provenientes da unidade de busca.
Analisa-se cada instruo recebida e se escreve em um arquivo, executando uma simu-
lao no ISim, uma linha com o seguinte formato:
ABCD EFGH IJ K L M
As letras representam:
A,B,C,D: slabas no ocupadas, contendo NOPs.
E,F,G,H: slabas ocupadas por operaes ULA.
I,J: ocupao das slabas 2 e 1 por MULs.
K: ocupao da slaba 3 por operaes do tipo load.
L: ocupao da slaba 3 por operaes do tipo store.
M: ocupao da slaba 0 por operaes de desvio.
Exemplo 5.1:
No arquivo de sada resultante da simulao podemos ter:
0011 0100 00 0 1 0
0001 1110 00 0 0 0
Estas duas linhas representam respectivamente (STX representa qualquer operao
do tipo store):
STX3 ULA2 NOP1 NOP0
ULA3 ULA2 ULA1 NOP0
34

Ao final da simulao, o arquivo de sada contm um nmero de linhas correspon-
dente ao nmero de ciclos de execuo do programa. Este arquivo ento analisado
(por um programa escrito em C) para extrair as seguintes informaes:
1. Nmero total de instrues (ciclos);
2. Nmero total de NOPs;
3. Instrues para as quais se podem replicar as operaes dentro da mesma;
4. Instrues para as quais ser necessrio introduzir uma instruo adicional para con-
ter as operaes replicadas;
5. Instrues que no contm operaes a serem replicadas;
6. Clculo do total de instrues no programa contendo as operaes replicadas;
7. Razo entre 1 e 6.
O apndice apresenta uma tabela com estes dados para todos os benchmarks. O n-
mero de instrues do programa com as operaes replicadas simplesmente o nmero
de instrues do programa original adicionado do nmero de instrues que geraro
uma instruo adicional, j que os outros nmeros no sofrero modificaes e contam
em ambos os totais. Por fim, feita a razo entre 1 e 6 para avaliar a diminuio do de-
sempenho com a tcnica aplicada.
Grfico 5. 1: reduo no desempenho, aumento do tempo de execuo.
Como explicado nas sees 3.1.3 e 3.2.2, os hazards que aparecem no cdigo so
resolvidos pelo compilador, que mantm sempre o nmero de ciclos necessrio entre
instrues dependentes. Entretanto, o nmero de NOPs executados se torna muito ele-
0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 55% 60% 65% 70%
bitcounts1 O1
bitcounts1 O4
bitcounts2 O1
bitcounts2 O4
bitcounts3 O1
bitcounts3 O4
bitcounts4 O1
bitcounts4 O4
bitcounts5 O1
bitcounts5 O4
bitcounts6 O1
bitcounts6 O4
bubble_sort O1
bubble_sort O4
dijkstra O1
dijkstra O4
LZW O1
LZW O4
matrixMUL O1
matrixMUL O4
quick_sort O1
quick_sort O4
Com forwarding
Sem forwarding
[MC5] Comentrio: Adiconar este
anexo.
[MC6] Comentrio: Conclusao: discutir
se umprocessador pipelined factvel com
a resoluo dos hazards feita pelo compil a-
dor atravs da i ntroduo de bolhas.
35

vado, o que diminui o impacto no desempenho gerado pela introduo das operaes
replicadas. Uma unidade de controle de hazards capaz de realizar f orwarding eliminaria
quase a totalide destes NOPs, j que todos so dependncias de dados e que no existem
harzards do tipo estrutural e nem harzards causados por desvios condicionais (as con-
dies so sempre calculadas previamente e o resultado armazenado em um registrador
BR). O nico tipo de dependncia que no pode ser resolvido por f orwarding no -VEX
causado por instrues do tipo load. Quando este caso aparece, realmente necessria
a introduo de operaes NOP para resolver a dependncia.
Logo, duas avaliaes podem ser feitas, uma considerando um -VEX sem a unida-
de de controle de hazards e outra com esta unidade. Claramente, os resultados sero
diferentes, sendo o impacto no desempenho causado pelas instrues duplicadas maior
quando o nmero de NOPs for menor, j que este nmero contribui igualmente no n-
mero total de instrues do cdigo original e do cdigo contendo as rplicas. O profiling
foi ento realizado uma segunda vez para detectar os NOPs reais, ou seja, aqueles intro-
duzidos para resolver dependncias causadas por operaes do tipo load e os novos to-
tais foram calculados. O Grfico 5.1 apresenta a reduo de desempenho (aumento no
nmero de ciclos executados) quando da introduo das rplicas no cdigo dos bench-
marks para o -VEX utilizado no trabalho, sem f orwarding, e para um -VEX hipotti-
co, com forwarding.
Alm do aumento do nmero de ciclos necessrio execuo do programa, h tam-
bm o aumento do cdigo.
Grfico 5. 2: aumento do cdigo.
0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 55% 60% 65% 70%
bitcounts1 O1
bitcounts1 O4
bitcounts2 O1
bitcounts2 O4
bitcounts3 O1
bitcounts3 O4
bitcounts4 O1
bitcounts4 O4
bitcounts5 O1
bitcounts5 O4
bitcounts6 O1
bitcounts6 O4
bubble_sort O1
bubble_sort O4
dijkstra O1
dijkstra O4
LZW O1
LZW O4
matrixMUL O1
matrixMUL O4
quick_sort O1
quick_sort O4
Com
forwarding
Sem
forwarding
36

Da mesma forma que o nmero de ciclos, o aumento do cdigo tambm afetado
pela presena ou no de forwarding no -VEX. Sendo assim, o Grfico 5.2 acima apre-
senta o aumento do cdigo para o -VEX com e sem forwarding.
Logo, para os benchmarks apresentados e a configurao alvo do -VEX utilizada:
A reduo do desempenho para o caso sem f orwarding fica entre 6,5%, para o ben-
chmark bitcounts1 com otimizao O1, e 44,6% para o benchmark bitcounts3 com
otimizao O4, com mdia de 19,6%. Para o caso com f orwarding, a reduo fica
entre 12,9% e 64,8% para os mesmos benchmarks e a mdia fica em 31,8%.
O aumento do cdigo para o caso sem forwarding fica entre 8,1%, para o bench-
mark bubble_sort com otimizao O1, e 36,8%, para o benchmark bitcounts3 com
otimizao O4, com mdia de 19,5%. Para o caso com f orwarding, o aumento fica
entre 16,7% e 63,6% para os mesmos benchmarks e a mdia fica em 34,2%.
5.2 Comparao com Outras Tcnicas
Em comparao com os resultados obtidos em [20] (degradao do desempenho en-
tre 28% e 106% e aumento no cdigo de 109% a 217%) a degradao do desempenho
inferior neste trabalho pois os programas so compilados expondo ao compilador todos
os recursos da arquitetura (exceto o nmero de registradores que a metade) ao invs de
compilar os programas para a arquitetura com metade dos recursos. Assim, quando as
rplicas so introduzidas no cdigo assembly, sempre que possvel so utilizadas as s-
labas (e consequentemente os recursos) disponveis nas instrues. Alm disso, em [20]
a fase de comparao tambm feita atravs da introduo de mais operaes para este
fim, sendo feita sempre que um registrador requisitado por uma operao, ao passo
que neste trabalho a comparao feita em hardware e somente quando operaes do
tipo store ou desvios condicionais so identificadas durante a execuo. Esta introduo
de operaes para realizar a comparao tambm culpada pelo aumento do cdigo
muito superior tcnica proposta neste trabalho. Deve-se observar que o aumento do
cdigo e a reduo no desempenho causados pela tcnica proposta neste trabalho de
graduao no podem ultrapassar 100%, j que no so todas as operaes que devem
ser duplicadas e que nem todas as instrues contendo operaes a serem duplicadas
resultam em uma instruo extra. Por fim, a tcnica apresentada em [20] no inclui ne-
nhuma modificao em hardware, medida que neste trabalho o processador tem os
bancos de registradores dobrados e a adio de uma unidade de comparao.
Com relao tcnica proposta em [21], esta no apresenta nenhum aumento no c-
digo dos programas, afinal todas as modificaes foram feitas em hardware. Entretanto,
a replicao do cdigo durante a execuo acarreta uma degradao no desempenho que
fica entre 0,6% e 34,3%, resultado melhor do que o obtido neste trabalho. Ainda, em
[21] o processador com a tcnica aplicada tem um aumento do hardware considervel,
porm deve ser lembrando que esta tcnica capaz tambm de realizar a correo dos
erros.
Deve-se observar por fim que a comparao direta dos resultados obtidos em cada
trabalho no totalmente vlida, sendo que cada um utiliza processadores diferentes,
compiladores diferentes e benchmarks diferentes. A melhor comparao seria obtida
aplicando as trs tcnicas aos trs processadores, ou seja, o melhor ponto de vista seria
comparar as tcnicas aplicadas a um dado processador, levando em conta as restries
do projeto deste.
37

5.3 Avaliao da Tcnica Atrves de Injeo de Falhas
Uma etapa de injeo de falhas foi realizada neste trabalho com o intuito de avaliar a
robustez da tcnica proposta e identificar os problemas desta. Para tal, foi gerado um
bitstream (arquivo resultante dos processos de sntese, mapeamento, roteamento e posi-
cionamento utilizado para configurar o FPGA) do -VEX para cada benchmark, ou seja,
um total de 22 bitstreams. Para cada bitstream, foram gerados mil bitstreams corrompi-
dos, cada um com um bit da memria de instrues alterado, simulando uma falha sim-
ples transiente.
Da forma como foi implementada a tcnica, sabe-se antecipadamente que as seguin-
tes falhas injetadas desta maneira no sero detectadas:
Falha em uma operao que modifica $r0.1 ou $r0.63, j que estas operaes no
so replicadas;
Quando uma instruo store for alvo de erro. Se uma operao de store for modifi-
cada ainda na memria, por exemplo, o endereo dos registradores modificado, es-
te erro passar despercebido, j que os registradores, ainda que incorretos, so com-
parados com suas rplicas e nenhum erro ser acusado;
Quando uma instruo de desvio for alvo de erro, que apresenta o mesmo problema
do caso anterior.
Claramente, mtodos devem ser propostos para contornar estes pontos fracos e me-
lhorar a tcnica proposta.
[MC7] Comentrio: A fazer............
38

6 CONCLUSO

Este trabalho de graduao props um mtodo de confiabilidade de baixo custo que
consiste na deteco de erros utilizando replicao das operaes e comparao dos
resultados aplicvel a processadores VLIW, mais especificamente ao processador em-
barcado soft-core -VEX. Justamente por este processador ser sof t-core, a tcnica se
adapta particularmente bem, sendo simples implementar neste as modificaes em
hardware necessrias e porque estas no so muito complexas, causando um baixo im-
pacto na complexidade global do processador, fator importante em se tratando de um
processador que utilizado em FPGAs, ambiente em que normalmente rea e consumo
so bastante restritivos. Ainda, a tcnica prosposta busca minimizar os consequentes
crescimento do cdigo e degradao do desempenho causados pela replicao das ope-
raes. Sempre que possvel, recursos livres do processador so utilizados para evitar a
introduo de instrues suplementares para conter as operaes replicadas (lembrando
que instrues VLIW so formadas por mais de uma operao). Somente as operaes
necessrias so replicadas e a comparao somente feita quando so detectadas opera-
es do tipo store ou desvios condicionais.
Os resultados obtidos com relao ao impacto da tcnica aplicada ao processador -
VEX nos benchmarks utilizados revelou-se satisfatria, com uma mdia da degradao
do desempenho (aumento do nmero de ciclos de execuo) de 19,6% para o processa-
dor sem f orwarding (como foi utilizado) e de 31,8% para o caso com f orwarding (que
no momento da realizao deste trabalho estava em desenvolvimento na TU Delft). J
as mdias para o aumento do cdigo ficaram em 19,5% e 34,2% para os casos sem e
com f orwarding, respectivamente. Estes dados deixam em aberto a possibilidade de um
estudo para indagar se seria factvel ou no manter o processador -VEX da maneira
como est, ou seja, usando o compilador para resolver os hazards introduzindo bolhas
diretamente no cdigo das aplicaes. Isto poderia se justificar caso a introduo de
forwarding tornasse o processador complexo demais para uso em FPGA ou tornasse o
consumo alto demais. Seria necessrio entretanto verificar que o aumento de instrues
a serem lidas da memria causado pela introduo dos NOPs no aumentariam demais o
consumo, superando os pontos negativos da introduo de forwarding, problema discu-
tido em [21] (ver seo 2.3). Ainda, poderia se pensar em uma soluo intermediria,
com deteco da dependncia de dados em hardware porm apenas com introduo de
bolhas no pipeline, sem forwarding, o que resultaria em menor complexidade e elimina-
ria o aumento do cdigo e o consequente aumento de acessos memria. Para este caso,
teramos o aumento de cdigo em 34,2% e a degradao do desempenho em 19,6% (j
que os NOPs apareceriam apenas durante a execuo e minimizariam o impacto da in-
troduo das operaes replicadas no nmero de ciclos de execuo).
39

Como previsto, a tcnica no cobre falhas em operaes que modificam $r0.1 (stack
pointer) ou $r0.63 (link register), j que estas operaes no so replicadas. Claramente,
um mtodo deve ser proposto para contornar este ponto fraco e melhorar a tcnica pro-
posta, de maneira a proteger estes registradores especiais da arquitetura. A abrangncia
do tipo de falhas detectadas tambm pode ser objeto de melhorias. Pode-se facilmente
estender a tcnica para suportar a deteco de falhas permanentes, alm das falhas tran-
sientes. Para isto, necessrio que as operaes originais e suas respectivas rplicas
sejam executadas sempre em UFs distintas, o que no acontece na forma em que a tc-
nica est implementada. Seria necessrio integrar a fase de introduo das rplicas no
cdigo assembly ao montador -ASM e modificar este de maneira que posicionasse
sempre as operaes originais e rplicas em UFs diferentes.
A incluso da correo das falhas pode tambm ser objeto de um estudo futuro, po-
rm provavelmente j descaraterizaria demais a tcnica aqui proposta. A deteco das
falhas no poderia mais ser feita apenas quando stores ou desvios condicionais forem
executados, pois isto tornaria complicado (propagao do erro) encontrar a operao
que gerou inicialmente o erro e execut-la novamente (nica opo para correo quan-
do se realiza apenas a duplicao das operaes). Ainda, mesmo realizando a fase de
comparao a cada operao, seria necessrio manter algum tipo de controle para retor-
nar ao ponto em que seria necessrio executar uma operao novamente.
Outro estudo que poderia ser feito futuramente a implementao da tcnica intei-
ramente em hardware, ou seja, passar tambm a fase de replicao para o hardware do
processador. Provavelmente, um estgio adicional responsvel por duplicar as opera-
es seria introduzido logo aps o estgio de busca das instrues. Quando possvel a
duplicao das operaes dentro de uma mesma instruo, este estgio precisaria conter
a lgica necessria para posicionar corretamente as operaes duplicadas dentro da ins-
truo em questo (conforme as regras apresentadas na seo 4.2.1). Quando necessria
uma instruo adicional para conter as operaes replicadas, este estgio seria repons-
vel por paralisar o estgio de busca por um ciclo para poder introduzir a instruo adi-
cional no pipeline. Como vantagens, no seriam mais necessrias modificaes no cdi-
go assembly das aplicaes, seja atravs de um programa a mais na toolchain ou no
montador -ASM. Teria-se entretanto um inevitvel aumento na complexidade do
hardware do processador. Ainda, como outro ponto negativo, o fato de introduzir as
rplicas no cdigo da aplicao permite a deteco de falhas durante o estgio de busca
(ou na memria de instrues), ao passo que quando a replicao feita em hardware,
se a instruo buscada j contiver algum erro, este ser replicado e passar despercebi-
do.
Os produtos obtidos ao final deste trabalho foram os seguintes:
Programa em C que realiza a replicao das operaes no cdigo assembly das apli-
caes;
Cdigo VHDL do -VEX incluindo as modificaes necessrias no estgio de de-
codificao e a unidade adicional que realiza a comparao;
Bloco VHDL para realizar o profiling das aplicaes;
Programa em C para extrair as informaes do arquivo de sada do profiling.
Uma das maiores dificuldades encontrada no trabalho foi a necessidade de utilizar o
processador -VEX ainda no testado, o que resultou em grande consumo de tempo
para identificar os motivos pelos quais os benchmarks no funcionavam. No sem sur-
40

presas, programar o FPGA com o -VEX tambm resultou inicialmente em insucesso
(apesar de sucesso na simulao), descobrindo-se que o bloco UART utilizado para en-
viar os contedos da memria de dados atravs da porta serial da placa XUPV5 conti-
nha um bug. Resolvido este bug, a maior parte dos benchmarks ainda no funcionava
com sucesso no FPGA, isto , funcionar ou no dependia do programa carregado na
memria -VEX. O lado positivo que sempre que um benchmark no funcionava
quando no FPGA, o sinal de erro do bloco de deteco de falhas era acionado (ligado a
um led da placa XUPV5). Aps certo nmero de modificaes (incluindo o uso da me-
mria de instrues gerada atravs do Core Generator da Xilinx), seis benchmarks do
total de 22 (contando os dois nveis de otimizao) ainda no puderam ser executados
corretamente no FPGA, no tendo participado ento da fase de injeo de falhas. Prova-
velmente a implementao VHDL do -VEX ainda necessita de melhorias.
Por fim, gostaria de salientar a contribuio deste trabalho na minha formao como
futuro Engenheiro de Computao. Este projeto me possibilitou explorar a fundo con-
ceitos que considero fundamentais em Engenharia de Computao. Precisei estudar os
detalhes da arquitetura de um processador e o compilador desenvolvido para este para
poder propor e implementar uma tcnica de deteco de falhas aplicvel a este. Sobre
tolerncia a falhas, este era um assunto por mim desconhecido antes do incio deste tra-
balho, no tendo feito nenhuma disciplina relacionada. Pude aprender bastante sobre o
assunto, mas certamente no o suficiente, o que deve se evidenciar em alguns pontos
deste trabalho. Ainda, o fato de ter utilizado um trabalho feito por terceiros (o -VEX e
sua toolchain) adicionou um nmero de imprevistos no percurso que necessitaram de
momentos de reflexo e busca por solues, o que natural em projetos no mundo
real. importante tambm salientar que este trabalho foi em prtica desenvolvido em
cooperao com trs universidades distintas, a UFRGS, o Politecnico di Torino e a TU
Delft, e as discusses com atores destas trs instituies pde enriquecer este trabalho e
consequentemente a minha formao.
41

REFERNCIAS
[1] J. Fisher, P. Faraboschi, e C. Young. Embedded Computing: A VLIW Approach to
Architecture, Compilers and Tools. Morgan Kaufmann, 2004.
[2] S. Hauck e A. Dehon. Reconfigurable Computing - The Theory And Practice of
FPGA-Based Computing. Morgan Kaufmann, 2008.
[3] T. van As. -VEX: A Reconfigurable and Extensible VLIW Processor. Master thesis,
Delft University of Technology (TU Delft), 2008.
[4] P. Faraboschi, G. Brown, J.A.Fisher, G. Desoli, e F. Homewood. Lx: A Technology
Platform for Customizable VLIW Embedded Processing, em Proceedings of the
27th annual International Symposium of Computer Architecture, junho de 2000,
p.203 213.
[5] M. R. Guthaus, J. S. Ringenberg, D. Ernst, T. M. Austin, T. Mudge, R. B. Brown.
"MiBench: A f ree, commercially representative embedded benchmark suite, em
IEEE 4th Annual Workshop on Workload Characterization, Austin, Texas, dezem-
bro de 2001.
[6] F. Plavec. Soft-core processor design. Master thesis, Departamento de Engenharia
Eltrica e de Computao da Universidade de Toronto, 2004.
[7] Bryan H. Flet cher. FPGA Embedded Processors: Revealing True System Perf or-
mance, em Embedded Systems Conference, So Francisco, 2005.
[8] EEMBC homepage. Disponvel em: <http://www.eembc.org/>. Acesso em 19 de
outubro de 2009.
[9] Altera. Nios II Perf ormance Benchmark data sheet. Verso 4.0, junho de 2009.
[10] Xilinx homepage. Disponvel em: <http://www.xilinx.com/>. Acesso em 19 de ou-
tubro de 2009.
[11] C. Kozyrakis, D. Patterson. Vector Vs. Superscalar and VLIW Architectures f or
Embedded Multimedia Benchmarks, em Proceedings of the 35th International
Symposium on Microarchitecture, Istambul, Turquia, novembro de 2002.
[12] M. B. Rutzig. Gerenciamento Automtico de Recursos Reconfigurveis Visando a
Reduo de rea e do Consumo de Potncia em Dispositivos Embarcado. Disserta-
o de mestrado, Universidade Federal do Rio Grande do Sul (UFRGS), 2008.
[13] HP VEX toolchain homepage. Disponvel em:
<http://www.hpl.hp.com/downloads/vex/>. Acesso em 19 de Novembro de 2009.
[14] -VEX google code homepage. Disponvel em: <http://r-vex.googlecode.com/>.
Acesso em 19 de Novembro de 2009.
[15] ARM9 homepage. Disponvel em:
<http://www.arm.com/products/CPUs/families/ARM9Family.html>. Acesso em 30
de Novembro de 2009.
[16] PowerPC 405 homepage. Disponvel em:
<http://www-03.ibm.com/technology/power/licensing/cores/ppc405.html>. Acesso
em 30 de Novembro de 2009.
42

[17] Open Cores homepage. Disponvel em: <http://www.opencores.org/>. Acesso em
30 de Novembro de 2009.
[18] ModelSim homepage. Disponvel em: <http://www.model.com/>. Acesso em 1 de
Dezembro de 2009.
[19] Xilinx ISE homepage. Disponvel em:
<http://www.xilinx.com/tools/designtools.htm/>. Acesso em 1 de Dezembro de
2009.
[20] C. Bolchini. "A Sof tware Methodology f or Detecting Hardware Faults in VLIW Da-
ta Paths, em IEEE Transactions on Reliability, VOL. 52, No. 4, dezembro de
2003.
[21] Y.-Y. Chen, Kuen-Long Leu. Reliable Data Path Design of VLIW Processor Cores
with Comprehensive Error-Coverage Assessment, em Elsevier, 22 de novembro de
2009.




43

APNDICE A: TABELAS
Bench. I1 I2 I3 N.C.F. N.S.F. I.C.F. I.S.F I.R.C.F. I.R.S.F. D.C.F. D.S.F.
bit count s1 O1 10739 4084 7162 9744 40889 31729 62874 35813 66958 12,9% 6,5%
bit count s1 O4 8114 5096 3305 5653 16210 22168 32725 27264 37821 23,0% 15,6%
bit count s2 O1 5504 3505 1003 0 16017 10012 26029 13517 29534 35,0% 13,5%
bit count s2 O4 5253 3264 509 755 5765 9781 14791 13045 18055 33,4% 22,1%
bit count s3 O1 2519 6514 525 1005 6549 10563 16107 17077 22621 61,7% 40,4%
bit count s3 O4 2018 6507 518 1005 5547 10048 14590 16555 21097 64,8% 44,6%
bit count s4 O1 6005 9153 8669 10315 35967 34142 59794 43295 68947 26,8% 15,3%
bit count s4 O4 4843 8659 7515 11477 33303 32494 54320 41153 62979 26,6% 15,9%
bit count s5 O1 2760 4503 1259 2505 8030 11027 16552 15530 21055 40,8% 27,2%
bit count s5 O4 1757 4504 759 503 3688 7523 10708 12027 15212 59,9% 42,1%
bit count s6 O1 20093 13230 12729 18594 85736 64646 131788 77876 145018 20,5% 10,0%
bit count s6 O4 8314 16726 6855 11772 27058 43667 58953 60393 75679 38,3% 28,4%
bubble_sort O1 25497 10020 19917 17551 83485 72985 138919 83005 148939 13,7% 7,2%
bubble_sort O4 12272 10685 12495 10585 49748 46037 85200 56722 95885 23,2% 12,5%
dijkst ra O1 5002 3932 2512 6052 18772 17498 30218 21430 34150 22,5% 13,0%
dijkst ra O4 3803 3758 2472 6074 16556 16107 26589 19865 30347 23,3% 14,1%
lzw O1 8444 8899 6540 9719 35082 33602 58965 42501 67864 26,5% 15,1%
lzw O4 7085 7670 4958 8096 27370 27809 47083 35479 54753 27,6% 16,3%
mat rixMUL
O1
67363 42127 9684 17286 106685 136460 225859 178587 267986 30,9% 18,7%
mat rixMUL
O4
53165 31127 9363 8926 85361 102581 179016 133708 210143 30,3% 17,4%
quick_sort O1 4015 4029 4149 3659 14978 15852 27171 19881 31200 25,4% 14,8%
quick_sort O4 2057 4604 4080 3590 12678 14331 23419 18935 28023 32,1% 19,7%

Tabela 1: resultados dos profilings dos benchmarks
I1: instrues contendo operaes a replicar cujas rplicas cabem dentro da mesma
instruo.
I2: instrues contendo operaes a replicar cujas rplicas necessitam de uma ins-
truo adicional.
I3: instrues que no contm operaes a serem replicadas.
N.C.F.: nmero de NOPs com f orwarding.
N.S.F.: nmero de NOPs sem forwarding.
I.C.F.: nmero total de instrues com forwarding.
I.S.F.: nmero total de instrues sem f orwarding.
I.R.C.F.: nmero total de instrues para o benchmark j contendo as operaes
replicadas, com f orwarding.
44

I.R.S.F.: nmero total de instrues para o benchmark j contendo as operaes
replicadas, sem forwarding.
D.C.F.: degradao do desempenho, com forwarding.
D.S.F.: degradao do desempenho, sem f orwarding.

Bench. I.S.F. I.R.S.F. I.C.F. I.R.C.F. A.C.S.F. A.C.C.F.
bit count s1 O1 49 54 21 26 10,2% 23,8%
bit count s1 O4 112 125 59 72 11,6% 22,0%
bit count s2 O1 60 68 23 31 13,3% 34,8%
bit count s2 O4 82 105 42 57 28,0% 35,7%
bit count s3 O1 55 75 37 57 36,4% 54,1%
bit count s3 O4 38 52 22 36 36,8% 63,6%
bit count s4 O1 70 80 39 49 14,3% 25,6%
bit count s4 O4 81 96 52 67 18,5% 28,8%
bit count s5 O1 39 49 23 33 25,6% 43,5%
bit count s5 O4 71 100 48 77 40,8% 60,4%
bit count s6 O1 43 48 18 23 11,6% 27,8%
bit count s6 O4 129 151 70 92 17,1% 31,4%
bubble_sort O1 55 64 28 37 16,4% 32,1%
bubble_sort O4 222 240 108 126 8,1% 16,7%
dijkst ra O1 432 509 262 340 17,8% 29,8%
dijkst ra O4 549 656 349 454 19,5% 30,1%
lzw O1 278 330 158 210 18,7% 32,9%
lzw O4 496 571 278 354 15,1% 27,3%
mat rixMUL O1 94 109 43 58 16,0% 34,9%
mat rixMUL O4 215 242 110 138 12,6% 25,5%
quick_sort O1 111 130 59 78 17,1% 32,2%
quick_sort O4 97 119 56 78 22,7% 39,3%

Tabela 2: aumento do cdigo.
I.S.F.: nmero total de instrues sem f orwarding.
I.R.S.F.: nmero total de instrues para o benchmark j contendo as operaes
replicadas, sem forwarding.
I.C.F.: nmero total de instrues com forwarding.
I.R.C.F.: nmero total de instrues para o benchmark j contendo as operaes
replicadas, com f orwarding.
A.C.S.F.: aumento do cdigo, sem forwarding.
A.C.C.F.: aumento do cdigo, com f orwarding.