caracterizaÇÃo de decodificadores de cÓdigo...
TRANSCRIPT
CARACTERIZAÇÃO DE DECODIFICADORES DE CÓDIGO SOBRE OS SOFT-
CORES ρ-VEX E LEON3 EM PLATAFORMAS FPGA
Márcio Afonso Soleira Grassi1 & Ricardo Ribeiro dos Santos
2
1Aluno do Curso de Engenharia Elétrica da UFMS, bolsista de Iniciação Científica CNPq – PIBIC 2012/13 2Professor da UFMS, Faculdade de Computação; e-mail: [email protected]
Resumo: Este trabalho apresenta o projeto de um circuito decodificador baseado na técnica de
codificação PBIW (Pattern Based Instruction Word) e implementado sobre o processador
soft-core Leon3 que utiliza a arquitetura SPARCV8. Além disso, tem por objetivo, comprovar
que a técnica PBIW é uma alternativa aos problemas conhecidos por Memory Wall e Power
Wall. Inicialmente, esse processador foi sintetizado e prototipado em uma plataforma FPGA
(Field Programmable Gate Array) por meio do software Altera Quartus II Web Edition e
depois simulado com o ModelSim-Altera 10.0c Starter Edition. Os experimentos mostraram
que o circuito decodificador impactou um acréscimo de 4,9% na área do processador, sem
levar em consideração a memória de padrões. Entretanto, com a prototipação de uma ROM
para executar um programa grande que armazena muitos padrões esse número pode aumentar
significativamente.
Palavras-chave: PBIW, decodificador, circuitos digitais, circuitos reconfiguráveis
1 INTRODUÇÃO
Nos últimos anos, várias propostas foram desenvolvidas na tentativa de minimizar o
problema de Memory Wall [7-9], que é definida como a diferença entre a velocidade da CPU
e a taxa de acesso à DRAM (Dynamic Random Access Memory). Muitas dessas técnicas
focam em novos esquemas de codificação enquanto outras utilizam técnicas para redução do
tamanho dos programas, conhecidas como técnicas de compressão. Contudo, todas possuem
um único objetivo em comum, que é reduzir a quantidade de dados armazenados na memória
principal e, consequentemente, diminuir os cache misses e o volume de dados transferidos
entre memória e processador. Especificamente, estas técnicas têm sido aplicadas em
arquiteturas que buscam instruções largas na memória e em arquiteturas voltadas para
domínios específicos de aplicações, como os sistemas embarcados [10-15].
Destarte, o limite Memory Wall recentemente vem trazendo preocupação e sendo
reconhecido por fabricantes de chips como Intel, AMD, NVIDIA e ARM. Alguns trabalhos
não muito recentes já mostravam que a taxa de melhora na velocidade dos
microprocessadores supera a taxa de melhora na velocidade das memórias DRAM [9].
A técnica de codificação de instruções PBIW (Pattern Based Instruction Word) [4] é
voltada para arquiteturas que buscam instruções longas na memória e surge como alternativa a
solução desse problema. A técnica é composta por um algoritmo baseado em fatoração de
operandos [9, 12] e por uma memória cache chamada de Pattern Cache (P-Cache).
Este trabalho buscou caracterizar o mecanismo decodificador PBIW sobre a via de
dados do processador Leon3 [2]. Em particular, o trabalho investiga o impacto na inserção do
circuito decodificador na via de dados do processador implementado em uma plataforma de
hardware com tecnologia FPGA (Field Programmable Gate Array) com relação à área. Não
foi possível realizar a análise do consumo de potência de potência dinâmica e freqüência
máxima de operação devido a restrições em programa do conjunto de ferramentas do
processador Leon3. A escolha da tecnologia FPGA como plataforma para implementação e
síntese em hardware se dá pela flexibilidade dessa tecnologia (pode-se programá-la e
reprogramá-la) e sua disponibilidade para utilização imediata no Laboratório de Sistemas
Computacionais de Alto Desempenho (LSCAD) da UFMS. Este projeto está relacionado com
o desenvolvimento de um projeto maior voltado para o desenvolvimento de técnicas,
algoritmos e implementação em hardware em arquiteturas avançadas de computadores.
2 MATERIAL E MÉTODOS
O trabalho foi desenvolvido no Laboratório de Sistemas Computacionais de Alto
Desempenho (LSCAD) da UFMS em Campo Grande. A P-cache e o módulo de decodificação
foram implementados utilizando linguagem VHDL e inicialmente sintetizados no ambiente da
ferramenta Altera Quartus R II Web Edition [16]. O Altera Quartus II é um software da
empresa Altera focado no projeto de circuitos digitais que possibilita a prototipação sobre
dispositivos de lógica programável. O software possui as seguintes características: suporte
para implementação em VHDL e Verilog para descrição de hardware, edição de circuitos
lógicos utilizando esquemáticos e simulação temporal utilizando vetores de onda. A
simulação e a validação da funcionalidade da implementação foi realizada utilizando o
software ModelSim-Altera 10.0c Starter Edition.
2.1 A ARQUITETURA SPARCV8
A arquitetura SPARC (Scalable Processor Architecture) está publicada como padrão
na IEEE 1754-1994, foi formulada pela Sun MicroSystems baseado nos projetos da
Universidade da Califórnia Berkeley. Ela define registradores de propósito geral, de ponto
flutuante, de controle/status e 72 instruções, todas codificadas em formatos de 32 bits. Um
processador SPARC, logicamente compreende uma Unidade de Inteiro (UI), uma Unidade de
Ponto Flutuante (UPF) e opcionalmente, um coprocessador, cada com seus respectivos
registradores. A seguir são listadas algumas características da arquitetura SPARCv8 [1]:
Alinhamento: Espaço de endereços linear de 32 bits.
Poucos e simples formatos de instruções: Todas as instruções têm 32 bits de
tamanho e possuem alinhamento de 32 bits na memória. Há apenas três formatos de
instruções básicos, nos quais os campos de opcode e endereço de registradores estão alocados
em posições uniformes. Apenas instruções load e store acessam memória e I/O.
Poucos modos de endereçamento: Endereços de memória são formados pelo par
registrador+ registrador ou registrador+imediato.
Tríade de endereços de registradores: A maioria das instruções opera em dois ou
três operandos (ou um registrador e um imediato) e atribui o resultado em um terceiro
registrador.
Banco de registradores em janelas "windowed": A qualquer instante estão visíveis
ao programa oito registradores inteiros globais, mais uma janela de 24 registradores, em um
banco de registradores maior. Os registradores da janela podem ser descritos como uma cache
de argumentos de procedimentos, valores locais e endereços de retorno.
Banco de registradores de ponto flutuante separado: Configurável por software em
32 de precisão simples (32 bits), 16 de precisão dupla (64 bits), oito de precisão quádrupla
(128 bits), ou uma combinação destes.
2.1.1 CONJUNTO DE INSTRUÇÕES
As instruções da ISA SPARCv8 são codificadas em três formatos de 32 bits. Os três
formatos são mostrados na Figura 1. O campo op é o único campo comum, sendo ele o
identificador do formato da instrução. A Figura 3 mostra a codificação do campo op. O
campo op com valor 1, indica o formato 1, utilizado apenas pela instrução CALL, que além
do campo op possui campo disp30, um imediato de 30 bits. Esse campo é deslocado dois bits
à esquerda e somado ao Program Counter (PC) quando a instrução CALL é executada. Dessa
forma, todos os endereços de memória podem ser alcançados pela instrução CALL. Quando
op é zero, o formato 2 é utilizado por uma instrução de extensão de sinal (SETHI), NOP ou
branch (Bicc, FBicc, CBccc). O formato 3 é utilizado, quando op é 3, por instruções de
memória ou quando op é igual a 2, por instruções aritméticas, lógicas, de deslocamentos e
demais instruções.
Figura 1. Formato das instruções da arquitetura SPARC.
Tabela 1: Significado dos campos das instruções SPARCv8 [11].
Campo Significado
op Formato da instrução
op2/op3 Opcode da instrução.
rd Registrador (operando) de destino.
a Bit que anula a execução de um branch.
cond Seleciona uma condição para testar uma instrução branch.
imm22 Um valor imediato que localiza SETHI na parte mais significativa de um
registrador de destino.
disp22 e disp30 São campos para palavras alinhadas, sinais estendidos, deslocamentos
relativos ao PC (para instruções call ou branch, respectivamente.
i Bit que seleciona um segundo operando da ALU, para instruções load
store e aritméticas (de inteiros). Se i=0, o operando _e r[rs2]. Se i=1 o
operando _e simm13 com sinal estendido de 13 para 32 bits.
asi Utilizado por instruções load store alternativas, para indicar que é um
programa do super-usuário e se a operação deve ser realizada na memória
de instruções ou na memória de dados.
rs1 Registrador (operando) de origem 1.
rs2 Registrador (operando) de origem 2, utilizado quando o campo i=0.
simm13 Valor imediato utilizado como segundo operando da ALU quando i=1.
opf Codifica instruções de ponto flutuante ou instruções do coprocessador.
Figura 2: Codificação do campo op2 [11].
Figura 3: Codificação do campo op [11].
Em instruções do formato 2 o valor do campo op2 determina o tipo de instrução,
conforme mostra a Figura 2. O valor 0 é utilizado para codificar a instrução UNIMP, que
causa uma interrupção do tipo ilegal_instrucion. Os valores 2, 6 e 7 determinam instruções de
branchs de três tipos: branchs de inteiros, tipo Bicc; branchs de ponto flutuante, tipo FBfcc;
branchs de coprocessador, tipo CBccc. Cada um dos três tipos possuem diversas instruções de
branchs que são definidas com base em um código de condição, armazenado no campo cond
da instrução. O campo a é utilizado para anular a execução de instrução de branch. Quando o
valor de a=1, o branch é condicional e não tomado ou, incondicional e tomado. As instruções
SETHI ou NOP são definidas pelo campo op2=4, que interpretam os campos a e cond como
campo rd. Nesse caso, se rd=0 indica uma instrução NOP, caso contrário SETHI. Os valores
de op2 1, 3 e 5 estão disponíveis para futuras extensões da ISA. As instruções do formato 3
utilizam op3 em conjunto com o bit menos significativo do campo op (0 quando op=2 e 1
quando op=3). Esse mecanismo é necessário para distinguir entre instruções de memória
(op=2) e instruções aritméticas, lógicas, de deslocamento e as restantes (op=3), pois há alguns
valores idênticos de op3 para ambos. As instruções de ponto flutuante também seguem o
formato 3, porém não possuem o campo i. Nesse caso, essas instruções são idênticas quando
op3=110100 (FPop1) e op3=110101 (FPop2). A operação em si é definida pelo campo opf.
Os registradores rd, rs1 e rs2 são de ponto flutuante.
2.1.2 REGISTRADORES
Um processador SPARC inclui dois tipos de registradores: de propósito geral e
controle/status. Os registradores de propósito geral da UI são chamados de registradores r
enquanto que os registradores de propósito geral da UPF são chamados de registradores f. Os
registradores de coprocessador dependem da implementação.
Registradores de Propósito Geral:
Uma implementação da UI pode conter de 40 até 520 registradores de propósito geral
de 32 bits. Eles são divididos em 8 registradores globais, mais um conjunto de 16
registradores. A quantidade dos conjuntos de 16 registradores _e dependente de
implementação. Um conjunto de registradores _e dividido em 8 registradores de entrada (in) e
8 registradores locais (local). Os agrupamentos de registradores são mostrados na Figura 4.
Figura 4: Endereçamento da janela [11].
Em um dado momento, uma instrução pode acessar os 8 registradores globais e uma
janela com 24 dos registradores r. Uma janela de registradores compreende os 8 registradores
in e 8 registradores local de um conjunto de registradores, junto com os 8 registradores in de
um conjunto de registradores adjacente, que são endereçados pela janela atual como
registradores out. Os registradores do conjunto adjacente, ao serem utilizados pela janela atual
como registradores out, estão realizando uma sobreposição entre janelas. A sobreposição de
três janelas e os 8 registradores globais podem ser vistos na Figura 5. O número de janelas ou
conjuntos de registradores, NWINDOWS, estão compreendidos no intervalo de 2 até 32
conjuntos, dependendo da implementação. O número total de registradores r em uma dada
implementação é 8 (para registradores globais), mais o número de conjuntos x 16
registradores (por conjunto). Assim, o número mínimo de registradores r é 40 (2 conjuntos), e
o número máximo é 520 (32 conjuntos). A janela atual de registradores r é dada pelo ponteiro
da janela atual, Current Window Pointer (CWP), um campo contador de 5 bits localizado no
registrador de estado do processador, Processor State Register (PSR). O CWP é incrementado
por 1 pelas instruções RESTORE ou RETT, e decrementado por uma instrução SAVE ou trap
(uma exceção). O registrador de máscara de janela inválida, Window Invalid Mask (WIM) é
responsável por detectar overflow e underflow de janela. O registrador WIM é controlado por
software no modo supervisor. Cada janela compartilha seus registradores ins e outs com duas
janelas adjacentes. Os registradores outs da janela CWP+1 são endereçáveis aos ins da janela
atual, e os outs da janela atual são os ins da janela CWP-1. Os registradores locais são únicos
para cada janela. Os registradores de saída (out) da janela CWP são endereçáveis como
registradores de entrada (in) na janela CWP1. Do mesmo modo, os registradores de entrada
(in) da janela CWP são endereçáveis como registradores de saída (out) na janela CWP+1. A
Figura 6 mostra como é realizada a sobreposição de janelas. A Figura 6 exemplifica a
sobreposição de janelas em uma configuração da arquitetura com 8 janelas. Os registradores
de saída em w0 outs são as entradas em w7 ins e os registradores de entrada em w0 ins são as
saídas em w1 outs. As instruções RESTORE e RETT são responsáveis por incrementar a
janela, enquanto as instruções SAVE e trap são responsáveis por decrementar.
Figura 5: Sobreposição das três janelas e os 8 registradores globais [11].
Figura 6: Sobreposição de janelas [11].
2.2 O PROCESSADOR LEON3
Leon3 [2] é um processador soft-core de 32 bits que segue a especificação da
arquitetura (SPARCv8) IEEE-1754, como mostra a Figura 7. Leon foi projetado para
aplicações embarcadas, combina alto desempenho com baixa complexidade e baixo consumo
de energia. Dentre as principais características do Leon3, estão [5]:
Unidade de Inteiro: Implementa completamente a unidade de inteiro do padrão
SPARCv8, incluindo hardware para instruções de multiplicação e divisão. O número de
janelas de registradores é configurável até o limite do padrão SPARC (2-32), com uma
configuração padrão de 8. O pipeline consiste de 7 estágios com interface de cache de
instruções e dados separadas (arquitetura Harvard).
Cache de instruções e dados: As caches são configuráveis, e podem ter até 4 vias,
com tamanho de 1 até 256 KBytes, pode adotar uma das três políticas de substituição: Least
Recently Used (LRU), Least Recently Replaced (LRR) ou aleatória.
Unidade de ponto flutuante e coprocessador: A unidade de inteiro fornece
interfaces para UPF e um coprocessador personalizado. As instruções de ponto flutuante e
coprocessador executam em paralelo com a unidade de inteiro. Não há bloqueio de operações
a menos que exista uma dependência de dados ou recursos.
Hardware de multiplicação e divisão: Suporte em hardware para instruções de
multiplicação (UMUL, SMUL, UMULCC, SMULCC) e divisão (SDIV, UDIV, SDIVCC,
UDIVCC).
Suporte à memória virtual: A memória virtual está disponível quando há uma
Memory Manegement Unit (MMU) ativa.
Interface de Interrupção: Suporta o modelo de interrupções do SPARCv8 com um
total de 15 interrupções.
Depuração em hardware: Unidade de depuração é controlada por uma interface de
suporte à depuração que armazena cada instrução executada em um buffer.
Interface AMBA: Implementa um sistema de cache mestre Advanced
Microcontroller Bus Architecture (AMBA) Advanced High-performance Bus (AHB) para
load/store de dados para/da cache. A interface é compatível com o padrão AMBA-2.0 [17].
Figura 7: Diagrama de blocos do processador Leon3.
2.3 PROJETO DA TÉCNICA PBIW PARA O CONJUNTO DE INSTRUÇÕES
E ARQUITETURA SPARCV8
A codificação PBIW (Pattern Based Instruction Word) é uma técnica baseada na
fatoração de operandos. O algoritmo da técnica percorre o programa extraindo os padrões a
partir de operandos redundantes [4]. A ideia principal dessa codificação é não só ter uma
compressão do código, mas também explorar a sobrejeção entre o conjunto de instruções e o
conjunto de padrões [3].
A fatoração de operandos é realizada pelo compilador no estágio final de compilação.
O compilador gera instruções codificadas sem dados redundantes e armazena essas instruções
em uma cache de instruções. Por sua vez, os padrões contêm os dados necessários para formar
a instrução original e são armazenados em uma cache ou tabela chamada de Tabela de
Padrões (P-Tabela ou P-Cache). É importante salientar que a técnica PBIW não depende de
um conjunto de instruções específico para utilização, ou seja, independente do conjunto de
instruções ou o processador alvo sob estudo.
O projeto de uma instrução codificada PBIW deve levar em consideração o número de
registradores de leitura e escrita, número de imediatos, tamanho do índice para tabela de
padrões em memória (P-cache), entre outros. Além disso, deve-se levar em conta, no projeto
de instruções codificadas PBIW, que os operandos de uma instrução devem ser mantidos na
instrução codificada, enquanto que sinais de controle devem ser armazenados no padrão
obtido [6].
Cada campo da instrução precisa ter R > 0 para representar os registradores de leitura,
em que R é o número máximo de portas de leitura do banco de registradores. A instrução
precisa ter log2 Regs bits para endereçar cada registrador, onde Regs é o número total de
registradores da arquitetura.
A instrução codificada, por meio do seu campo de índice, aponta para o seu respectivo
padrão na Tabela de Padrões cujo tamanho é log2|P-Cache|, em que |P-Cache| é a quantidade
de bits para endereçar as entradas da Tabela de padrões.
A codificação da técnica PBIW-SPARC [19] codifica todas as instruções da ISA
SPARCv8. Para cada instrução codificada PBIW-SPARC há exatamente uma correspondente
SPARCv8. Nenhuma instrução adicional foi criada. A codificação PBIW-SPARC realiza sua
codificação sobre um arquivo binário ELF gerado por uma compilador com back-end para o
conjunto de instruções SPARCv8. Diante das características inerentes aos conjuntos de
instruções RISC e, em particular, o conjunto de instruções SPARCv8, duas características
presentes na técnica PBIW original [18] não foram utilizados nesta abordagem, são elas: a
fatoração de operandos e a utilização, no padrão, de índices (ponteiros) para os campos da
instrução codificada. A utilização da fatoração de operandos implica na utilização de campos
de ponteiros que apontam para campos da instrução codificada, pois cada campo de ponteiro
no padrão é armazenado na posição original do operando na operação. Este mecanismo é
interessante em aplicações da técnica PBIW para ISAs VLIW, que geralmente possuem
instruções compostas por diversas operações e que podem se beneficiar do reúso de
operandos na instrução. A não utilização da fatoração de operandos e de ponteiros para os
campos da instrução codificada se justifica devido às instruções SPARCv8 representarem
apenas uma operação.
Para definição do tamanho do padrão e instrução codificada PBIW-SPARC optou-se
por reduzir o tamanho da instrução com relação ao padrão, tendo em vista explorar o reuso de
padrões, pois sempre haverá uma instrução codificada para representar cada instrução
original. Supondo um padrão de 24 bits, restam 8 bits dos 32 da instrução original para serem
armazenadas na instrução codificada. No entanto, há de se considerar a existência de um
campo/ponteiro de índice de padrões junto aos demais campos da instrução codificada. Esse
campo indica o endereço/índice de memória em que o respectivo padrão da instrução pode ser
encontrado. As Figuras 8 e 9 mostra o leiaute do padrão e da instrução PBIW-SPARC.
Figura 8: Leiaute do padrão PBIW-SPARC.
Figura 9: Leiaute de instrução PBIW-SPARC.
A codificação com instruções de 16 bits, conforme o leiaute mostrado na Figura 9, está
limitada a endereçar no máximo 256 padrões (considerando os 8 bits do campo de índice de
padrão). Para superar essa limitação e permitir a codificação de programas que geram mais de
256 padrões, pode-se utilizar o leiaute mostrado na Figura 10, que estende o campo de índice
do padrão para 24 bits.
Figura 10: Leiaute de instrução PBIW-SPARC de 24 bits.
2.4 PROJETO DO CIRCUITO DECODIFICADOR PBIW
Após os estudos sobre a arquitetura do processador SPARC e a técnica de codificação
PBIW, iniciou-se estudos sobre a implementação dessa arquitetura por meio do soft-core
Leon3. Em primeiro lugar, estudou-se o estágio de DECODE do processador Leon3 com a
finalidade de descobrir qual a melhor localização para a implementação do circuito
decodificador PBIW. A Figura 11 mostra um exemplo do caminho de dados de uma instrução
do formato 1.
Figura 11: Esquemático do fluxo de dados da instrução CALL.
Após o estudo do datapath e do projeto VHDL do processador Leon3, utilizando
como exemplo uma instrução de cada formato, podemos notar que todas elas são armazenadas
no registrador r.d.inst e no estágio DECODE a instrução passa do registrador ao sinal de_inst,
na qual é decodificada por meio de procedimentos e funções com seus respectivos campos
sendo escritos em registradores de controle do pipeline. Com essas informações, constatou-se
que a melhor alternativa para implementação do circuito decodificador seria depois do
registrador r.d.inst e antes de a instrução ser escrita no sinal de_inst, desse modo os
procedimentos e funções do estágio DECODE não precisariam ser totalmente alterados. A
Figura 12 mostra o projeto do circuito decodificador.
Figura 12: Visão geral do decodificador PBIW-SPARC para Leon3.
Apesar da Figura 12 mostrar uma visão geral do circuito decodificador para uma
instrução de 16 bits, deve-se ressaltar que não há diferença do circuito decodificador para
instruções de 16 bits ou 24 bits em termos de decodificação, o que muda é apenas o índice
para acessar a P-Cache que pode ser de 8 bits ou 16 bits e os campos da instrução original
permanecem os mesmos para qualquer tipo de codificação.
A partir da busca da instrução na cache de instruções, realiza-se a leitura do campo de
índice de padrões e então, o padrão é endereçado e buscado na tabela de padrões (P-cache).
De acordo com o campo op presente no padrão define-se o formato da instrução, que em
combinação com o campo opcode (exceto o formato 1, que não possui este campo),
respectivo ao formato, configura os multiplexadores para selecionar a instrução decodificada.
Observe que as entradas de dados dos multiplexadores são oriundas das unidades de
reordenação que atuam, paralelamente, reorganizando os dados e sinais de controle de acordo
com cada formato específico. Após esse passo, a instrução original já está recomposta e pode
ser despachada para o estágio de DECODE do pipeline. As Figuras 13 e 14 mostram a
unidade de decodificação dos formatos 0 e 3, respectivamente.
Figura 13: Visão geral da unidade de reordenação do formato 0 decodificador PBIW-SPARC.
De modo geral, há dois barramentos de entrada (do padrão e instrução) que se dividem
em vários fluxos para distribuir os bits de acordo com as posições especificadas nos dois sub-
formatos. Cada ramo com origem em um dos dois barramentos de entrada da unidade
reordenação está com etiquetas com o nome da origem (padrão ou instrução) e indicando um
intervalo de bits que será “concatenado” na posição de destino do ramo, na instrução original.
Por fim, outros dois barramentos de 32 bits saem da unidade de reorganização, sendo
selecionados pelo multiplexador (conforme mostrado nas Figuras 13 e 14).
3 RESULTADOS E DISCUSSÃO
Para a prototipação do processador Leon3 com o circuito decodificador PBIW-SPARC foi
utilizado uma placa FPGA da Altera Cyclone®
II 2C35, dentre as características da mesma,
estão:
8-Mbyte SDRAM;
512-Kbyte SRAM;
USB Blaster(on board) para programação e controle de usuário API;
Interface Ethernet 10/100.
A Tabela 2 mostra os resultados de área ocupada para síntese do circuito decodificador.
Tabela 2: Área ocupada e configuração utilizada do processador Leon3.
Recurso Configuração
número de janelas de registradores 8
i-cache 2 sets de 8Kbytes
d-cache 2 sets de 4Kbytes
jtag e uart Sim
Pci Sim
unidade de gerenciamento de memória Sim
mul/div em hardware Sim
trace buffer 128 linhas
unidade de ponto flutuante Não
número original de elementos lógicos 12710
número de elementos lógicos com o
descompressor
12776
aumento da área 4,9%
Pelas informações da Tabela 2, vale ressaltar que embora não exista unidade de ponto
flutuante implementada na síntese do Leon 3, tanto o circuito decodificador quanto o
algoritmo de codificação PBIW-SPARC são compatíveis com instruções de ponto flutuante,
não havendo necessidade de alteração em ambos, caso a implementação do Leon ofereça
suporte para instruções de ponto flutuante.
Deve-se ressaltar que a área ocupada pelo decodificador PBIW-SPARC pode ser
aumentada se a tabela de padrões for sintetizada junto à plataforma alvo na forma de uma
ROM (tabela ROM de padrões). Experimentos realizados mostraram que uma tabela de
padrões com, aproximadamente, 100 padrões ocupa 909 elementos lógicos. Logo, ao utilizar
essa tabela de padrões sintetizada em hardware, a área ocupada pelo circuito decodificador
PBIW-SPARC passa a ser de 13685 com impacto de 12,44% na área ocupada pelo
processador Leon3.
O pacote de ferramentas do processador Leon3 inclui um programa chamado
GRMON, que um interface monitor de debug, cujas funcionalidades são:
Acesso de leitura/escrita a todos os registradores do sistema e da memória;
Gerenciamento de trace buffer;
Carregamento e execução de aplicações no Leon 3;
Gerenciamento de breakpoints;
Conexão remota ao GNU Debugger (gdb);
Suporte à USB, JTAG, RS232, Ethernet e SpaceWire;
Dentre essas características, destaca-se o trace buffer que um buffer circular capaz de
armazenar as últimas instruções executadas e as últimas transferências que ocorreram no
barramento AHB. Por meio dele, é possível verificar que as instruções SPARCv8 são
decodificadas de forma correta. Entretanto, até a entrega desse relatório um problema na
execução dos programas codificados no GRMON não foi resolvido impossibilitando desse
modo à análise de consumo de potência dinâmica e frequência máxima de operação. Apesar
disso, a validação do circuito decodificador foi comprovada por meio de simulações
utilizando o software ModelSim-Altera 10.0c Starter Edition.
4 CONCLUSÕES
Este relatório final apresentou a implementação de um decodificador de instruções,
baseado na técnica de codificação PBIW aplicada sobre um processador soft-core embarcado
denominado Leon3. Em particular, apresentou os efeitos do mecanismo decodificador PBIW
sob a via de dados do processador bem como o impacto da área causada pelo circuito
adicional da P-Cache e do circuito decodificador.
Deve-se ressaltar que a área ocupada pelo decodificador PBIW-SPARC, 4,9%,
considera a existência apenas do circuito decodificador de instruções. Se uma tabela de
padrões for sintetizada, como memória ROM, junto ao circuito, essa área pode aumentar
significativamente.
Como trabalho futuro objetiva-se a avaliação experimental do decodificador de
instruções PBIW-SPARC considerando potência dinâmica dissipada e aumento do caminho
crítico do processador e experimentos envolvendo a codificação parcial de programas PBIW-
SPARC de forma parecida com as demais técnicas de codificação de programas.
REFERÊNCIAS
[1] The SPARC Architecture Manual, tech. rep., SPARC International, Inc., 1992.
[2] A. Gaisler, “Leon3 processor”.
http://www.gaisler.com/index.php/products/processors/leon3?task=view&id=13, Mar 2012.
[3] MARKS, R. A.; ARAUJO, F. O.; SANTOS, R. . PBIW Instruction Encoding Technique
on the r-Vex Processor: Design and First Results, Technical Report, 01-2012, School of
Computing, Federal University of Mato Grosso do Sul, 2012.
[4] R. Batistella. Pbiw: Um esquema de codificação baseado em padrões de instrução.
Master’s thesis, Instituto de Computação – Universidade Estadual de Campinas, Campinas-
SP, Fevereiro 2008.
[5] A. Gaisler, ”GRLIB IP Core User’s Manual”.
http://www.gaisler.com/index.php/products/ipcores/soclibrary.
[6] MARKS, R. Infraestrutura para Codificação de Instruções Baseada em Fatoração de
Padrões. 2012. 116f. Dissertação(Mestrado em Ciência da Computação) – Faculdade de
Computação, Universidade Federal de Mato Grosso do Sul, Campo Grande. 2012.
[7] W. A. Wulf and S. A. McKee, “Hitting the Memory Wall: Implications of the Obvious,"
ACM SigArch, vol. 23, pp. 20-24, March 1995.
[8] A. Saulsbury, F. Pong, and A. Nowatzyk, “Missing the Memory Wall: The Case for
Processor/Memory Integration," in ISCA, (Philadelphia), pp. 90-101, ACM, October 1996.
[9] S. A. McKee, “Reflections on the Memory Wall," in Procs. of the 1st ACM Computing
Frontiers, pp. 162-167, ACM, April 2004.
[10]G. Araujo, P. Centoducatte, M. Cortes, and R. Pannain. Code compression based on
operand factorization. In 31st International Symposium on Microarchitecture. ACM, 1998.
[11]S. K. Menon and P. Shankar. Space/time tradeoffs in code compression for the
tms320c62x processor. Technical Report IISc-CSA-TR-2004-4, Indian Institute of Science,
2004.
[12]R. Montserrat and P. Sutton. Compiler optimization and ordering effects on vliw code
compression. In Proceedings of the International Conference on Compilers, Architectures,
and Synthesis for Embedded Systems. ACM, 2003.
[13]S-J. Nam, I-C. Park, and C-H. Kyung. Improving Dictionary-Based Code Compression in
VLIW Architectures. IEICE Transactionson Fundamentals, E82-A(11):2318-2324, November
1999.
[14]M. Ros and P. Sutton. Code compression based on operand-factorization for vliw
processors. In International Conference on Compilers, Architectures, and Synthesis for
Embedded Systems. ACM, 2004.
[15]E. Billo, R. Azevedo, G. Araujo, P. Centoducatte, and E. Wanderley Netto. Design of a
Decompressor Engine on a SPARC Processor. In Procs. of the 18th SBCCI, pages 110-114,
Florianopolis, SC, Brazil, 2005.
[16] ALTERA. Quartus II Handbook 11.1. Altera Corporation, 2011.
[17]ARM, “AMBA protocol specifications and design tools."
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.amba/index.html, ARM
2010.
[18] R. Batistella, R. Santos, and R. Azevedo, ”A New Technique for Instruction Encoding in
High Performance Architectures," Tech. Rep. IC-07-27, Institute of Computing - State
University of Campinas, September 2007.
[19] SANTOS, R. F. PBIW-SPARC: Uma Estratégia de Codificação de Instruções para
Programas SPARC. 2013. 93f. Dissertação (Mestrado em Ciência da Computação) –
Faculdade de Computação, Universidade Federal de Mato Grosso do Sul, Campo Grande.
2013.