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: ricardo@facom.ufms.br

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.

Fig

Figura 14: Visão geral da unidade de reordenação do formato 2 e 3 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.