Um Caminho de Dados Pipeline Para a ISA MIPS: Aprendendo na Prática

Transcrição

1 Um Caminho de Dados Pipeline Para a ISA MIPS: Aprendendo na Prática Francisco Carlos Silva Junior 1, Ivan Saraiva Silva 1 1 Departamento de Computação Universidade Federal do Piauí (UFPI) Caixa Postal Piauí PI Brazil juninho.ufpi@hotmail.com, ivan@ufpi.edu.br Abstract. This paper presents a pipeline implementation of the MIPS architecture supporting all conflicts and stalls, including some ones not addressed in the literature. It also presents a performance comparison between a pipelined implementation and a multicycle one. The conflicts and stalls are carefully explained, their reasons for occurring, how they are resolved and what loss in performance they can cause in the pipeline. An architecture that supports such conflicts is proposed and implemented in VHDL. An explanation on the ISA MIPS and how it has evolved through time is given as well. The results section shows that the pipelined datapath is 3 time faster than the multi-cycle implementation and requires 50% less logic elements in an FPGA implementation. Resumo. Este artigo apresenta uma implementação pipeline da arquitetura MIPS tratando todos os conflitos, incluindo alguns não documentados na literatura. Ele também apresenta uma comparação de desempenho entre a implementação pipeline e multiciclo. Os conflitos são cuidadosamente explicados, suas razões, como eles são resolvidos e a perda de desempenho que podem causar no pipeline. Uma arquitetura que trata tais conflitos é proposta e implementada em VHDL. Uma explicação da ISA MIPS e como ela evoluiu ao longo do tempo é dada também. A seção de resultados mostra que a implementação pipeline é 3 vezes mais rápida do que a multiciclo e requer 50% menos elementos lógico. 1. INTRODUÇÃO O microprocessador MIPS é uma arquitetura RISC (Reduced Instruction Set Computer) e é usada tanto como exemplo de ISA(Instruction Set Architecture) como exemplo de microarquitetura em muitos cursos de graduação em todo o mundo. Em [Henessy 2014], um dos livros mais respeitado usado em cursos de arquitetura e organização de computadores, são apresentadas três versões de microarquitetura para a implementação da ISA MIPS. No entanto, todas as versões são concebidas com um subconjunto de instruções. Tal abordagem, embora na maioria das vezes seja suficiente para transmitir o conhecimento necessário para a disciplina, não é quando se deseja implementar um caminho de dados com tal complexidade. Este artigo apresenta uma implementação do caminho de dados para a ISA MIPS usando a técnica de execução em pipeline, bem como cada instrução listada em [Wikipedia ]. Essa implementação trata todos os potenciais conflitos, inserindo a menor

2 quantidade de bolhas no pipeline. O artigo apresenta também um ambiente de desenvolvimento que foi criado para permitir estudantes desenvolver aplicações usando linguagens de alto nível, particularmente C, e fazer simulações ou execuções com precisão de ciclos, usando a ferramenta ModelSim [Quartus ] ou placas prototipáveis com dispositivos reconfiguráveis, em particular, nós usamos a Altera DE2-115 board. A microarquitetura proposta foi desenvolvida em VHDL e,conforme apresentado em [Henessy 2014], utiliza-se da sobreposição temporal das diversas fases de execução das instruções, dividindo-as em cinco estágios: Instruction Fetch (IF); Instruction Decode and Register Read (ID); ALU Execution (EX); Data Memory Access (MEM) e Write Result Back (WB). Essa implementação aumenta a vazão de instruções, possibilitando a execução de uma instrução por ciclo quando o pipeline está cheio. Espera-se portanto a obtenção de melhor desempenho, quando comparado com caminhos de dados monociclo, onde a instrução é executada em um único ciclo, e multiciclo, onde a instrução é executada em no mínimo 3 ciclos. Neste artigo, a implementação proposta foi comparada em termos de área e desempenho com a implementação de um caminho de dados multiciclo também implementado em VHDL. 2. A ISA MIPS A ISA (Instruction Set Architecture) define o conjunto de instruções suportado por um microprocessador ou arquitetura em particular. A definição normalmente inclui também o formato das instruções, o conjunto de registradores e seu uso, os modos de endereçamento, os tipos de dados nativos, a arquitetura da memória, as interrupções e o tratamento de exceções. A ISA MIPS especifica um conjunto de instruções composto de instruções de cinco categorias: Aritmética; Transferência de dados; Lógica; Deslocamento de bits; Saltos condicionais e incondicionais. Tais instruções operam sobre um conjunto de 32 registradores, cujos usos específicos são também definidos pela ISA, sendo que nem todos são acessíveis ao programador. A definição da ISA MIPS evoluiu com o tempo da MIPS I ISA à MIPS V ISA [Sagar Bhavsa 2013]. Para a implementação da microarquitetura apresentada neste artigo foram adotadas as definições disponíveis em [Wikipedia ]. Essas instruções possui três formato de instruções sendo eles R, I e J. O formato R especifica instruções que realizam operações entre registradores e suporta três endereços de registrador. O formato I especifica instruções que usam operandos imediatos, incluindo aritméticas, como ADDI (Add immediate); Lógicas, como ORI (Or Immediate); Salto condicionais, como BEQ (Branch on Equal) ou Tranferência de dados, como LW (Load Word). O formato J especifica instruções do tipo salto incondicional e, na implementação aqui apresentada, inclui apenas as instruções JUMP e JAL (Jump and Link). A tabela completa com todas as instruções pode ser vista em várias fontes, algumas delas são [Henessy 2014], [Wikipedia ]. 3. A ARQUITETURA PROPOSTA Na implementação e execução em pipeline da arquitetura MIPS há alguns conflitos não documentados. Esses conflitos são envolvendo a execução do BEQ (Branch on EQual) ou BNE (Branch Not Equal) ou JR (Jump Register) e uma instrução anterior que modifica o valor de um dos registradores a ser comparado no BEQ ou BNE ou registrador onde

3 está armazenado o endereço de desvio do JR. Nesse artigo, BEQ refere-se a BEQ e BNE, porque essas instruções fazem a mesma coisa, mudando somente a comparação, BEQ compara se é igual e o BNE compara se não é igual. Esses conflitos existem devido á escrita no banco de registradores ocorrer somente no quarto ciclo após a instrução ter sido buscada na memória e uma instrução subsequente necessitar do dado que ela irá escrever no banco de registradores. A instrução que necessita do dado lerá o banco de registradores no segundo ciclo da execução, ou seja, a instrução irá ler o dado errado, pois a escrita no banco de registradores ocorrerá somente no quinto ciclo da execução, caso esse conflito não seja tratado, isso implicará em uma falha na execução, uma vez que os dados estarão incorretos ao final da execução. Uma tabela que mostra esses conflitos pode ser vista na Tabela 1. Para tratar esses conflitos foi utilizado uma unidade de forwarding, um hardware adicional para antecipar o dado para a instrução que precisa desse dado, e uma unidade de detecção de hazard, um hardware adicional que verifica se há a necessidade da inserção de uma bolha que é inserida impedindo no próximo ciclo a escrita no PC(Program Counter) e no registrador de pipeline IF/ID e escrevendo um nop 1 (no operation) nos sinais de controle do registrador ID/EX. Tipo R ou I (exceto LW,BEQ e BNE) Tabela 1. Principais conflitos Tipo I ou R (exceto LW,BEQ e LW BNE) Conflito acontece quando pelo menos um dos operandos é igual ao registrador destino da instrução que a precede. É resolvido com a unidade de forwading. BEQ Conflito acontece quando a instrução do tipo I ou R precede o BEQ e se o registrador destino dessa instrução for igual a um dos operandos do BEQ. É resolvido com a inserção de uma bolha e forwarding no próximo ciclo. JR Conflito acontece quando o registrador destino da instrução tipo I ou R é igual ao operando do JR e se essa instrução preceder o JR. É resolvido com a inserção de uma bolha e forwading no ciclo seguinte. Conflito acontece quando o registrador destino do LW é igual a um dos operandos da próxima instrução e se o LW preceder essa instrução. É resolvido com a inserção de bolha e forwarding no próximo ciclo. Conflito acontece quando o LW preceder o BEQ e o registrador destino do LW for igual a um dos operando do BEQ. É resolvido com a inserção de duas bolhas e forwarding no ciclo seguinte a inserção da segunda bolha. Conflito acontece quando o LW precede o JR e o registrador destino do LW é igual ao operando do JR. É resolvido com a inserção de duas bolhas e com o forwarding no ciclo seguinte a inserção da segunda bolha. 1 Uma instrução que não faz nada

4 3.1. TRATANDO OS CONFLITOS DO BEQ E JR Existem três tipos de conflitos envolvendo o BEQ e JR: Sem bolhas: A instrução BEQ ou JR está no registrador de pipeline IF/ID; A instrução será executada durante o próximo ciclo; O dado que será usado pela instrução (BEQ ou JR) foi gerado nos ciclos anteriores, mas não foi escrito no banco de registradores ainda. Uma bolha: A instrução BEQ ou JR está no registrador de pipeline IF/ID; A instrução será executado durante o próximo ciclo; O dado que será usado pela instrução (BEQ ou JR) será gerado por uma instrução anterior no próximo ciclo. Duas bolhas: A instrução BEQ ou JR está no registrador de pipeline IF/ID; A instrução será executado durante o próximo ciclo; O dado que será usado pela instrução (BEQ ou JR) será gerada dois ciclo depois (quando o LW é a instrução que precede BEQ ou JR). A execução das instruções BEQ e JR são muito similar: (i) Ambas são instruções de salto; (ii) O cálculo de endereço de ambas é feito no estágio de decodificação da instrução; (iii) Ambas tem as mesmas dependências de dados, a única diferença é que o BEQ deve verificar a condição de salto que deve ser verdadeira para que o salto seja tomado. Então, para tratar os conflitos envolvendo tais instruções serão feitas as mesmas verificações. No primeiro caso apresentado acima, como o dado já está válido, o conflito pode ser resolvido usando a unidade de forwarding. Ele detectará esse conflito verificando se um dos registradores fonte RS e/ou RT (no registrador de pipeline IF/ID) é o mesmo do registrador destino usado pela instrução que está no registrador de pipeline EX/MEM e/ou MEM/WB. É também necessário verificar se a instrução que está no registrador de pipeline EX/MEM não é um lw (load word). Caso seja uma leitura à memória de dados, o dado que está no EX/MEM é um endereço. Depois de tais verificações, o dado deve ser antecipado pegando o dado do registrador de pipeline EX/MEM ou MEM/WB, assim resolvendo o conflito. No segundo caso, o dado não foi gerado ainda, uma bolha é necessária. O dado necessário para a comparação da instrução BEQ ou o cálculo de endereço da instrução JR será gerada no próximo ciclo de clock. A unidade de detecção de hazard verifica a necessidade da bolha comparando o registradores fonte no registrado de pipeline IF/ID como o registrador destino ID/EX. Se a instrução no registrador de pipeline ID/EX for uma instrução lw, uma bolha é inserida, mas o conflito não é resolvido ainda, pois esta é a situação que é tratada no terceiro caso. No terceiro caso, a instrução que precede o BEQ ou JR é uma instrução de LOAD. Nesse caso, duas bolha são necessárias. A primeira é inserida seguindo a verificação descrita no caso anterior. A segunda bolha é inserida quando a unidade de hazard verifica que a instrução que está no registrador de pipeline EX/MEM é uma instrução de LOAD e o registrador fonte da instrução que está no registrado de pipeline IF/ID é o mesmo do registrador alvo da instrução de LOAD. Depois da segunda bolha, o dado será antecipado, assim resolvendo o conflito.

5 4. O CAMINHO DE DADOS O caminho de dados proposto pode ser visto na figura 1. Essa é uma figura simplificada, i.e, ela esconde algumas parte que faria a figura muito complexa e dificultaria o entendimento do trabalho. Para tratar os conflitos envolvendo BEQ e JR é necessário selecionar adequadamente as entradas do mux 3, mux 4 e mux 5, alem disso, a unidade de forward deve funcionar corretamente. Como foi visto na seção anterior, há três tipo de conflitos envolvendo BEQ e JR. Quando o primeiro caso acontece, a unidade de forward trata o conflito enviando sinais para o mux 3 e mux 4 para selecionar a entrada correta, que pode ser: (i) Dado da ULA (Unidade Lógica e Aritimética); (ii) Dado para o banco de registradores (registrador de pipeline MEM/WB); (iii) Dado do banco de registradores. Assim, o dado dos registradores fonte do BEQ e do JR estarão corretos. Quando o segundo ou terceiro caso acontece, a unidade de hazard é responsável por inserir as bolhas. A unidade de hazard envia um sinal para o mux 5. O mux 5 tem como entrada sinais de controle para a instrução decoficada e o nop. Se a unidade de hazard detecta o conflito, ele selecionará o nop e assim a bolha é inserida no pipeline. Dessa maneira, os conflitos envolvendo BEQ e JR são resolvidos. Figura 1. Caminho de dados 5. RESULTADOS Para que fosse possível obter a comparação envolvendo o desempenho e área foi feita uma descrição do MIPS multiciclo. A análise de desempenho foi baseado em resultados de simulações e a análise de área foi baseada no resultado de síntese. A simulação foi feita usando a ferramenta ModelSim [Quartus ] e a síntese foi feita usando a ferramenta Quartus II [Quartus ]. O bechmark usado foi uma multiplicação de matriz 2 2. Ela foi feito na linguagem C e compilada com o GNU Cross-Compiler [Cpmware ]. Entre outras

6 configurações, o GNU Cross-Compiler precisa informar como o espaço de memória deve ser usado. Ele gera um arquivo.elf [Cpmware ]. Uma ferramenta ELF2MIF foi desenvolvida para obter um arquivo.mif [MIF ] que foi compilado com a descrição VHDL. Embora seja um benchmark simples, o assembly gerado pelo GNU Cross-Compile tem 257 instruções. Para o objetivo de análise de desempenho do artigo, esse simples aplicação é suficiente. A execução em pipeline levou 1038 ciclos, 52 desses sendo nop inseridos devido às instruções de salto condicionais. Sempre que um salto é tomado uma bolha é inserida. E outras 48 bolhas devido aos conflitos de dados, assim tendo 100 ciclos de bolhas. Esse desempenho de execução é satisfatório, pois somente 10% do total de ciclos foram bolhas ao final da execução. Contudo, essas bolhas não afetam tanto a performance quando comparada ao multiciclo, que levou 3171 ciclos, mais de três vezes o número de ciclos da execução em pipeline, reduzindo para menos de 1 a quantidade de ciclos necessários para a execução 3 da multiplicação de matriz. Para a comparação em área foi considerado o número de elementos lógicos em cada implementação da microarquitetura. Para a implementação pipeline foi usada 3223 elementos lógicos, que corresponde a 47% do número de elementos lógicos na implementação multiciclo, que foi de Esse resultado é provavelmente devido ao estilo de implementação e uso de megafunctions da ALTERA ( lpm mult, lpm divide, lpm cssshift). Apesar de alguns hardwares adicionais que o pipeline necessita para o tratamento de conflitos, o numero de componentes lógicos foi menor do que o multiciclo. Isso mostra que além de ser mais eficiente, a implementação em pipeline ocupa menos espaço em chip. Referências [Cpmware ] Cpmware, I. Building a gnu gcc cross compile. BuildingGcc.pdf. Acessado: 31/07/2014. [Henessy 2014] Henessy, D. A. P. E. J. L. (2014). Computer organization and design the hardware/software interface. Morgan Kaufmann, Oxford, USA, 5th edition. [MIF ] MIF. Memory inicialization file /mergedProjects/reference/glossary/def_mif.htm. Acessado: 31/07/2014. [Quartus ] Quartus. Altera. quartus ii handbook version volume 3. [Sagar Bhavsa 2013] Sagar Bhavsa, Akhil Rao, A. S. R. J. (2013). A 16-bit mips based instruction set architecture for risc processor. International Journal of Scientific and Research Publications (IJSRP), Volume 3. [Wikipedia ] Wikipedia. Wikipedia mips architecture. wiki/mips_architecture. Acessado: 19/03/2014.