Universidade Federal do Rio Grande do Sul Instituto de Informática - PPGC CMP 114 - Arquitetura e Projeto de Sistemas VLSI I Prof. André Reis Prof. Flávio R. Wagner Prof. Luigi Carro Descrição VHDL do MIPS Pipeline Alunos: Lisane Brisolara de Brisolara Maurício Lima Pilla Porto Alegre, 7 de agosto de 2000. Sumário 1. 2. INTRODUÇÃO........................................................................................................................................................5 IMPLEMENTAÇÃO ..............................................................................................................................................7 2.1. ESTÁGIO DE BUSCA ...............................................................................................................................................7 2.2. ESTÁGIO DE DECODIFICAÇÃO .............................................................................................................................8 2.3. ESTÁGIO DE EXECUÇÃO .......................................................................................................................................9 2.3.1. Controle da ULA:.................................................................................................................................... 10 2.4. ESTÁGIO DE MEMÓRIA .......................................................................................................................................12 2.5. ESTÁGIO DE WRITEBACK.....................................................................................................................................12 2.6. UNIDADE DE CONTROLE DO MIPS....................................................................................................................12 3. INTERLIGAÇÃO DOS ESTÁGIOS............................................................................................................... 13 3.1. FORWARDING.......................................................................................................................................................13 3.2. DETECÇÃO DE DESVIOS ......................................................................................................................................14 4. VALIDAÇÃO E SIMULAÇÃO........................................................................................................................ 15 4.1. TESTE R-FORMAT ................................................................................................................................................15 4.2. TESTE DE A CESSO À M EMÓRIA .........................................................................................................................17 4.3. TESTE DA INSTRUÇÃO DE DESVIO.....................................................................................................................19 5. 6. CONCLUSÕES ...................................................................................................................................................... 20 BIBLIOGRAFIA................................................................................................................................................... 21 2 ........10 FIGURA 4 ..........................................................................................................................................................................................................................................................ESTÁGIO DE MEMÓRIA ............................11 FIGURA 5 .......ESTÁGIO DE DECODIFICAÇÃO .........................................................................................................7 FIGURA 2 ........................................................19 3 .............................................................18 FIGURA 9 – RESULTADO DO TESTE DA INSTRUÇÃO DE DESVIO CONDICIONAL.......................................16 FIGURA 7 – RESULTADO DO TESTE R-FORMAT........................................................................................GRAFO DE DEPENDÊNCIAS ...........................................................................................................12 FIGURA 6 ......................................................9 FIGURA 3 .........17 FIGURA 8 – RESULTADO DO TESTE DE ACESSO À MEMÓRIA ..........Índice de Figuras FIGURA 1 ............ESTÁGIO DE EXECUÇÃO...........CIRCUITO DE CONTROLE DA ULA.....................ESTÁGIO DE BUSCA................ ............TABELA-VERDADE PARA SINAL DA ULA ..........................11 4 ............CÓDIGOS E OPERAÇÕES DA ULA................................11 TABELA 3 .............................................................................................................Índice de Tabelas TABELA 1 ..............................10 TABELA 2 ..............................................................ALUOP CORRESPONDENTES ÀS INSTRUÇÕES ...................... Silicon Graphics. O MIPS é um processador com um conjunto de instruções reduzido (RISC). obtém-se um ganho em área que poderá ser utilizada para outros fins. Observa-se também a existência de um campo de função que só é usado para as instruções do tipo R-format para determinar a operação executada pela unidade lógica aritmética (ULA). mas estas não serão implementadas neste trabalho. Introdução O objetivo deste trabalho é desenvolver uma descrição VHDL do processador MIPS com pipeline de instruções. O MIPS possui três formatos de instruções diferentes: R-format. como acréscimo de mais blocos de memória cache. unidade de detecção de dependências e mecanismo para detecção e tratamento de salto condicionais (branchs). OR e SLT. Na Tabela 2.1. As instruções do tipo R-format executam operações de lógica e aritmética somente em dados armazenados em registradores. com modificações. As instruções do tipo I-format englobam dois tipos aquelas que fazem referência a memória como instruções de load e store e as instruções de branch. Em função do período de duração deste trabalho não foram implementadas todas as instruções do MIPS e o tratamento de exceções. I-format e Jformat. pode-se observar o formato das instruções do MIPS. SUB. O seu conjunto de instrução é utilizado ainda hoje. pela Sony. com isso. Na Tabela 1. O uso de uma arquitetura RISC permite simplificar a lógica de controle do processador e. pode-se observar o código de cada uma destas instruções implementadas. AND. A implementação apresentada neste trabalho foi baseada no MIPS original de Hennessy e Patterson [HEN98] e na versão monociclo de [HAM00]. 5 . As instruções do tipo J-format executam operações de jump incondicional. NEC e por diversos outros fabricantes de microprocessadores. operações estas como ADD. Tabela 1: Formato das instruções do MIPS 5 bits 5 bits 5 bits 5 bits Rs Rs Rt Rt Tamanho 6 bits do campo R-Format Opcode I-Format Opcode J-Format Opcode 5 bits Rd Shift Function Address/immeadiate value Branch target address A implementação do MIPS desenvolvida neste trabalho cobre um subconjunto das instruções do MIPS. desenvolvido em 1980. salto incondicional. Pode-se utilizar ainda o modo absoluto. adiciona-se quatro para o cálculo do próximo endereço da palavra de 32 bits da memória. obtido através do uso de $0 como registrador base. O endereçamento chamado registrador indireto pode ser obtido com o deslocamento igual a zero. 6 . pois seu valor é sempre zero. e o modo base e deslocamento.Mnemônico ADD SUB AND OR SLT LW SW BEQ Tabela 2: Código das instruções implementadas Formato Opcode R 0 R 0 R 0 R 0 R 0 I 35 I 43 I 4 Função 32 34 36 37 42 - A memória do MIPS é endereçada a byte e portanto. sendo os endereços de memória de 32 bits. que usa uma constante de16 bits contida na própria instrução. O MIPS possui somente dois modos de endereçamento: o modo imediato. no qual o endereço efetivo é o conteúdo de um registrador base somado com um deslocamento contido na instrução. Quando o relógio sobe para 1. no caso de um desvio condicional. foram usados pares de signals VHDL entre os mesmos. Nesta seção relata-se a implementação dos estágios de pipeline desta arquitetura. Estágio de Busca O estágio de Busca (Figura 1) é responsável pelo fornecimento de instruções para o pipeline. A implementação desenvolvida neste trabalho é uma arquitetura RISC com pipeline de cinco estágios. estágio de execução. Para a correta sincronização dos estágios. o estágio de busca (fetch). baseado em [HEN98]. 2. os estágios foram conectados e testados novamente. 4 Next PC PC A D D 0 ADD Result 1 M U X Memória E de Instruções Clock Zero Branch Figura 1 . desenvolveu-se separadamente cada um dos componentes que compõem os estágios do pipeline do MIPS. a partir da ordem definida no programa. Para determinar o valor da próxima instrução há duas possibilidades: •A próxima instrução a ser buscada segue a última instrução no código do programa (seqüencial. No segundo caso. •A próxima instrução a ser buscada é determinada por uma instrução de desvio. Depois de testados individualmente. IMPLEMENTAÇÃO Após o estudo da organização e arquitetura do processador. o PC é incrementado de 4). de memória e de escrita nos registradores (writeback). é necessário esperar pelo resultado do cálculo do desvio e se este realmente é tomado. o valor é copiado do primeiro para o segundo signal. Para cada par de signals. estágio de decodificação.Estágio de Busca 7 .1.2. um está conectado ao estágio anterior e o outro ao próximo estágio. 2. 2. o que dificulta o teste do microprocessador. O sinal Zero determina se o resultado da ULA na última operação foi zero. para diminuir o tempo necessário à compilação e simulação do projeto. O registrador $0 mantém permanentemente o valor 0 (zero) . que pode então ser operado no estágio de Execução. Este módulo acrescenta uma memória ROM. Além do banco de registradores com duas leituras e uma escrita por ciclo. A memória de instruções e o estágio de Busca encontram-se descritos em arquivos separados. usando um modelo Harvard (memória de instruções e de dados separadas). Para determinar o conteúdo da memória ROM. O sinal Branch depende da instrução no estágio de Execução. o PC recebe o endereço da próxima instrução no fluxo seqüencial de instruções (PC+4). o banco de registradores foi instanciado com apenas 4 registradores de 32 bits cada. Estágio de Decodificação O estágio de Decodificação é responsável pela interpretação das instruções e pelo gerenciamento do banco de registradores. para diminuir o tamanho necessário aos programas de teste [HAM00] . 8 . implementado como um componente parametrizado. podendo ser determinado na instanciação o número de registradores. O somador para calcular o PC+4 encontra-se dentro do estágio de Busca. foi usado um módulo lpm_rom da Altera. quando estes dois sinais são iguais a 1. A Figura 2 mostra os componentes do estágio de Decodificação. Cada registrador é inicializado com o valor correspondente ao seu índice no banco de registradores. Para as simulações. Para implementar a memória de instruções. sendo conectados no pipeline. é usado um arquivo com a descrição do programa em formato hexadecimal. torna-se mais fácil observar o acesso a esta memória. é necessário recompilar todo o pipeline.Na Figura 1. Para cada programa novo. O banco de registradores foi implementado como uma entidade separada. Desta forma. observa-se que a fonte do próximo PC (Program Counter) é determinado pelo AND entre Zero e Branch. sendo 1 quando esta for um desvio. o resultado da soma do próximo PC com o deslocamento na instrução de desvio determina o valor a ser armazenado no PC. Assim. bem como fazer futuras modificações. Em caso contrário. há ainda um estensor de sinal para transformar os 16 bits menos significativos da instrução em um valor de 32 bits. não foi encontrada uma forma simples de evitar a recompilação de todo o código. Porém. 2 em leitura Dados em leitura 1 Dados em leitura 2 5 5 Reg. o operando da ula pode ser o resultado de um estágio de execução de uma instrução anterior que escreve em um registrador que a instrução que está sendo executada lê. Estágio de Execução Neste estágio. Os outros dois multiplexadores foram inseridos para permitir o forwarding dos dados. Os sinais de controle dos multiplexadores. Agora. além do dado lido dos registradores. são gerados no bloco de detecção de harzard. permitindo que o valor possa ser repassado para instrução corrente antes do estágio de escrita dos registradores (write-back) da instrução anterior ocorra.3. AluSelA e AluSelB. ou ainda o resultado de uma busca na memória no qual o registrador destino é utilizado pela instrução corrente.0] 16 Sign extend 32 Figura 2 . em escrita Dados em escrita Banco de registradores Instrução [15 . existem duas unidades de execução (Figura 3): • Unidadde para cálculo de endereço de branch (apenas soma) • Unidade Lógica e Aritmética ( and. este pode ser o dado lido de um registrador. ou seja eliminar as bolhas inseridas no pipeline quando há uma dependência de dados. no caso das instruções Rtype e de branch ou um endereço no caso das instruções de load e store.Estágio de Decodificação 2. or. add e sub ). Os sinais de controle dos multiplexadores são detalhes importantes. 9 .RegWrite Reg1 em leitura 5 Reg. O sinal ALUscr é gerado pelo bloco de controle para selecionar o segundo operando da ULA. 1. Tabela 1 .3. gerado do opcode. denominado func.PC + 4 ADD Sign Extend Read Data 1 Memory Forward AluForward Read Data 2 Sign Extend 0 Shift Left 2 ADD Result 00 M U 01 X 10 source AluSelB 00 Zero ULA Result M U X 1 M U 01 X 10 AluSelA AluForward ALU Control Instrução [31 . ou seja. determina qual a operação que a ULA executará. observa-se a tabela-verdade para a geração do sinal de função da ULA a partir de um sinal conhecido como ALUOp.Estágio de Execução 2. Na Tabela 1. Este sinal.Códigos e Operações da ULA Código 000 001 010 110 111 Operação AND OR ADD SUB Set-on-less-than Na Tabela 2.26] ALUSrc Memory Forward Figura 3 . os 6 bits mais significativos da palavra de instrução e mais os 6 bits menos significativos da instrução. Controle da ULA O controle da ULA tem como entrada o opcode. pode-se observar os códigos e suas operações correspondentes executadas pela ULA. gerando a partir destes um sinal de três bits para a ULA. e dos seis bits menos 10 . BRO00]. o qual pode ser observado na Figura 4.significativos da instrução. pode-se observar o ALUOp correspondente a cada instrução desta implementação do MIPS. Tabela 2 . que é obtido a partir do opcode da instrução.ALUOp Correspondentes às Instruções Instrução Load e Store Beq R-format 00 01 1X ALUOp 11 .Circuito de Controle da ULA O sinal ALUOp.Tabela-Verdade para Sinal da ULA ALUOp AluOp1 AluOp0 0 X 1 1 1 1 1 0 1 X X X X X F5 X X X X X X X Código da Função (R-Format) F4 F3 F2 F1 F0 X X X X X X X X X X X 0 0 0 0 X 0 0 1 0 X 0 1 0 0 X 0 1 0 1 X 1 0 1 0 Operação da ULA 0 1 0 1 0 0 1 1 1 1 1 0 0 1 0 0 0 0 0 1 1 A partir da Tabela 2. é gerado nesta implementação no bloco de controle da ULA. Na Tabela 3. utilizados apenas para as instruções do tipo R-format (instruções lógicas e aritmética). e não no bloco de controle central conforme as outras versões consultadas [HEN98. AluOp1 AluOp0 Operation2 F3 F2 F1 F0 Operation1 Operation0 Figura 4 . obtém-se o circuito de controle da ULA. Tabela 3 . 2. implementado através de um componente lpq_ram_qd da Altera. a partir da palavra de instrução.5. que indica instrução de store. o dado proveniente da memória é selecionado.6. vindo da palavra de instrução e 12 . sendo assim adequado à implementação do MIPS pipeline. será passado para o estágio de Decodificação o resultado da ULA.Estágio de Memória A memória de dados foi implementada através de um bloco lpm_ram_dq da Altera [HAM00]. •MemToReg .sinal que indica que o dado a ser escrito no registrador de destino é um dado vindo da memória. podendo este ser o valor lido do segundo registrador.4. A escrita é habilitada apenas no final do ciclo e somente se o sinal MemWrite. Quando o dado a ser escrito é resultado de uma instrução de leitura da memória (lw). consistindo de uma máquina de estados finitos (FSM). estiver ativo. 2.2. Caso contrário. MemWrite Data Memory Address Read Data Write Data MemRead Figura 5 . Esta gera. permite a leitura e a escrita no mesmo ciclo. Este bloco permite dois acessos de leitura e um acesso de escrita no mesmo ciclo. Estágio de Memória O estágio de Memória (Figura 5). os seguintes sinais de controle: •RegWrite .sinal que habilita a escrita no banco de registradores. Unidade de Controle do MIPS A unidade de controle implementada é simples. •AluSrc .sinal que indica qual o segundo operando da ULA. ou um deslocamento de 16 bits. Estágio de Writeback O estágio de Writeback alimenta o estágio de Decodificação com o valor a ser escrito no banco de registradores. Interligação dos Estágios Após a conclusão da implementação dos estágios e da unidade de controle. gerado na instrução de store. Porém. então.sinal que habilita a leitura da memória. Este pipeline. gerado na instrução de load. •Branch . •RegDst . como as dependências de dados são comumente encontradas nos programas. Na subida do relógio. funcionando assim como um latch.estendido para 32 bits que servirá para o cálculo do endereço para as instruções de load ou store. o registrador pode ainda não ter recebido o valor e. Nesta etapa. Bolhas são instruções NOP que. Desta forma.1. através da detecção da dependência e introdução de bolhas (stalls) no pipeline.sinal que indica uma instrução de branch e juntamente com o sinal de zero obtido após o estágio de execução determina se ocorrerá ou não o salto. Uma solução para contornar estas dependências de dados é fazer com que o pipeline espere até que o registrador receba o valor correto.sinal que habilita a escrita na memória. Um exemplo de dependência de dados é quando uma instrução lê um registrador escrito por uma instrução anterior. cuida para que estes sinais acompanhem a instrução correspondente no pipeline de execução e ajam nos ciclos corretos. passouse para a etapa de interligação dos estágios do pipeline. foram usadas duplas de sinais. a execução da instrução que lê este registrador pode obter um valor diferente do esperado. No caso de uma implementação pipeline. Para interconectar dois estágios quaisquer do pipeline. a perda de desempenho ocasionada pelo uso do mecanismo de bolhas pode tornar-se muito elevada. que começa no componente que gera os sinais de controle. 3. •MemWrite . Para os sinais de controle. não modificam o estado do processador. foram desenvolvidos mecanismos que fornecem os valores dos registradores para o estágio de execução antes que estes possam ser escritos no banco de registradores. •MemRead . foi necessário levantar todos os sinais que deveriam ser passados de um estágio para outro. 3. chamados de forwarding [HEN98]. é possível encontrar muitas dependências de dados. desta forma. que em um pipeline geram bolhas na execução das instruções e afetam o desempenho do mesmo [HEN98]. foi utilizado um pipeline paralelo. 13 .sinal utilizado para selecionar o registrado destino. o sinal é copiado do primeiro para o segundo sinal. Forwarding Nos programas. Detecção de Desvios As instuções de desvio condicional (branch) modificam o fluxo de controle do processamento caso uma determinada condição seja verificada. podendo ser usado também um mecanismo de bolhas para tanto. Desta forma. Quando o desvio é resolvido.2. utiliza uma previsão estática de que o desvio é sempre não tomado e continua buscando instruções quando da ocorrência de uma instrução branch. o forwarding não deve atuar nestes casos. Isto é feito através do reset dos registradores entre os estágios de Busca e Decodificação e os estágios de Decodificação e Execução.Foram criados caminhos para o forwarding de valores dos estágios de Memória e Writeback para o estágio de execução. as dependências de controle geradas pelos desvios devem ser devidamente tratadas. Como a escrita de registradores somente ocorre no estágio de Writeback. Neste caso. é necessário descartar as instruções buscadas depois da instrução de branch. 3. Assim como nas dependências de dados. 14 . sendo então inserida uma bolha no pipeline de instruções. O mecanismo de forwarding criado verifica se o registrador da dependência é o $0. Como o registrador $0 possui sempre o valor zero. utilizada nesta implementação e de acordo com [HEN98]. bolhas são introduzidas no pipeline até que seja conhecido o resultado da execução do desvio. o reset dos registradores entre os estágios anteriores à Execução garante que o banco de registradores não será alterado inadvertidamente. quando um desvio condicional é encontrado. o hardware de controle verifica se o desvio foi tomado. Outra forma. As dependências entre instruções de load e qualquer outra instrução imediatamente posterior que leia o registrador de destino de instruções load é apenas detectado. • Instruções de acesso à memória (load e store). os estágios foram conectados e programas completos foram simulados. Além de verificar a validade dos resultados. Estes programas são pequenos. o registrador $2 recebe o valor 6. 421820. o valor 5 é armazenado em $1. $3. correspondentes aos três tipos de instruções: • Instruções R-format (lógico e aritméticas). Depois. em hexadecimal). $3. o valor do registrador $3 é mostrado na linha 05. Em 03. --add --sub --add --add --add --add $1. 611820. $0. Validação e Simulação Para validar o processador MIPS pipeline desenvolvido neste trabalho. Na linha 02. Teste R-Format As instruções R-Format são processadas pelos estágios de Busca. $3. passa os resultados de volta para o estágio de Decodificação. é armazenado no registrador $3 o valor 1. Os programas de teste criados exercitam cada uma das instruções implementadas. Os testes não foram mais complexos devido a restrições de tempo e pessoal para a elaboração e execução das mesmas. Decodificação e Execução. Depois. $3. bem como o forwarding e o armazenamento dos registradores: 00: 01: 02: 03: 04: 05: 430820. o mesmo registrador $3 recebe 17 (hexadecimal 11). $0. Finalmente. 30020. $3 $2 $3 $2 $1 $3 10000110000100000100000 11000100001100000100010 1000110001000000100000 10000100001100000100000 11000010001100000100000 110000000000100000 Inicialmente. Inicialmente. por sua vez. Após obter resultados satisfatórios nestas simulações. 15 . o registrador $3 recebe o valor 12 (0C. No estágio de Memória. dada a complexidade e dificuldade de visualizar os resultados em uma implementação pipeline. as simulações foram desenvolvidas em duas fases. O forwarding de dados e os aspectos relacionados à previsão de desvios também foram verificados nestes testes. 621822.4. onde são finalmente escritos. que.1. $2. $1. na linha 00. 4. O programa abaixo testa o resultado das operações. os resultados são apenas repassados para o estágio de Writeback. aumentando a complexidade desta validação. os aspectos de temporização dos estágios devem ser observados. Os testes foram divididos em três categorias. 231020. $3. • Instruções de desvio (branch). $2. os estágios e componentes foram simulados separadamente e os resultados foram comparados com os esperados. $2. Os nodos representam as instruções. Os sinais RegWriteAddrProbe e RegWriteDataProbe mostram o registrador destino e o dado a ser armazenado. respectivamente. a dependência entre 00 e 04 é resolvida pela escrita do registrador $1. 16 . os endereços do primeiro e do segundo registrador a serem lidos. O sinal ALUResultProbe mostra o resultado da ULA.Grafo de Dependências A Figura 7 mostra o resultado da execução do código acima. sendo anotados com o registrador que causa a dependência de dados verdadeira. respectivamente.Este código possui diversas dependências de dados. neste caso. Os resultados podem ser observados. Os sinais RegRead1Probe e RegRead2Probe mostram o valor lido do primeiro e do segundo registrador. A Figura 6 mostra o grafo de dependências entre as instruções. 02 e 03. não usando nenhum caminho de forwarding. Finalmente. Os valores obtidos com as simulações correspondem aos valores esperados. enquanto que os arcos representam as dependências. 03 e 04. As dependências entre 01 e 02. 00 $1 01 $3 $1 02 $2 03 $3 04 $3 05 Figura 6 . Os sinais RegAddr1Probe e RegAddr2Probe mostram. tanto na saída da ULA quanto no valor escrito nos registradores. Já a dependência entre 00 e 02 exercitam o caminho de forwarding proveniente do estágio de Writeback. 04 e 05 exercitam os caminhos de forwarding do estágio de Memória. 01. 03($1) 10001100001000100000000000000011 --sw $2. 06.2.Figura 7 – Resultado do Teste R-Format 4. AC020006. havendo a necessidade de um stall (bolha) no pipeline porque o valor de $1 ainda não foi buscado na memória no ciclo em que 01 executa. na instrução 06. 8C030006. 06($0) 10001100000000110000000000000110 --nop --nop --add $0. por sua vez. o valor da memória 06 é lido para o registrador $3. A instrução 01. --lw $1. foi utilizado o programa abaixo: 00: 01: 02: 03: 04: 05: 06: 8C010002. Depois. $3 Adicionalmente. $0. Finalmente. 06($0) 10101100000000100000000000000110 --lw $3. 30020. Teste de Acesso à Memória Para testar o acesso à memória executado por instruções de load e store. busca o valor da memória 5 (5). 04. 03. 0. 02($0) 10001100000000010000000000000010 --lw $2. 02. Na instrução 03. 0. o conteúdo do registrador $2 (5) é armazenado na posição 06. 8C220003. 05. a memória de dados foi inicializada com os seguintes valores: 00: 01: 02: 03: 04: 05: 06: 00. o valor do registrador $3 (5) é adicionado a zero. A linha 00 carrega o registrador $1 com o valor da célula de memória 02 (02). 17 . como observado na Figura 8. Apenas na execução das instruções de store. O programa executou corretamente quando. para este programa. 18 . No caso de acessos à memória. são necessárias duas bolhas para obter o resultado correto. é necessário esperar por um ciclo antes que o valor correto do registrador seja lido da memória. o sinal ALUResultProbe pode ser utilizado para observar este valor. o sinal RegWriteSignalProbe permanece em zero. Desta forma. Como as dependências referem-se a instruções imediatamente seguintes à loads. exigindo que o compilador colocasse uma instrução independente seguindo estas instruções [HEN98]. no final. verifica-se que há duas dependências de dados verdadeiras. o registrador $3 recebe o valor 5. Através da análise do código. as bolhas no pipeline são criadas apenas quando uma instrução qualquer possui uma dependência de dados verdadeira em relação a uma instrução de load que imediatamente lhe antecede.O resultado da execução deste teste pode ser observado na Figura 8. Os sinais MemoryReadProbe e MemoryWriteProbe mostram os valores que estão sendo lidos e escritos na memória de dados. Assim. o endereço é o resultado da ULA. A primeira implementação do MIPS não tratava deste tipo de dependência no caso de loads. O sinal RegWriteSignalProbe mostra o valor do sinal de escrita do registrador. Figura 9 – Resultado do Teste de Acesso à Memória Figura 8 – Resultado do Teste de Acesso à Memória O sinal PCProbeFD mostra o endereço da instrução que está no estágio de Decodificação. este programa executou corretamente. Já o sinal MemoryWriteSignalProbe mostra o sinal de escrita na memória. Nesta implementação do MIPS. Além dos sinais utilizados na Figura 7. entre 00 e 01 e entre 01 e 02. outros sinais importantes para a análise dos resultados são mostrados. Neste caso. sem nunca terminar. como o código abaixo. representada no sinal FetchedInstruction. FFFC 10000000000001111111111111100 O resultado da simulação deste programa pode ser observado na Figura 10. que é adicionado ao valor do PC da instrução incrementado de 4.4. esta instrução é buscada novamente. Depois. Assim. A primeira instrução buscada. o programa fica neste laço. As instruções de desvio condicional do MIPS utilizam um deslocamento. O programa utilizado para testar a instrução de desvio beq simplesmente compara o valor do registrador $0 com o próprio. 00: 1000FFFC.3. a instrução funcionou adequadamente. --beq $0. Portanto. é H1000FFFC. Teste da Instrução de Desvio A instrução beq (branch if equal) foi a única instrução de desvio implementada. cujo opcode é 04 (sinal OpcodeProbe). $0. sempre saltando para a posição 00 novamente. Figura 9 – Resultado do Teste da Instrução de Desvio Condicional 19 . por exemplo. O conjunto de instruções suportado pode ser acrescido de outras instruções ou tipos de endereçamento. sem um assembler. a ferramenta não compila automaticamente todas as dependências de um determinado projeto. mais otimizadas. foi desenvolvida uma versão pipeline do MIPS em VHDL. Como trabalhos futuros. sendo então necessário apagar todos os arquivos por ela gerados e recompilar todo o projeto.Também podem ser implementadas outras técnicas para a exploração do paralelismo em nível de instrução como. é possível descrever este processador em RTL (Register Transfer Level). Além disto. Altera MAX+plus II. já é complexa e que facilmente pode apresentar erros. por si só. Facilidades de saída (impressão na tela) não estão disponíveis nesta versão do MAX+plus II. O microprocessador resultante coube em um FPGA EPF10K30EFC484-1.5. utilizando 1310 células lógicas e 16384 bits de memória. tipos e packages. Outro trabalho possível é trocar componentes por novas versões. O desenvolvimento de programas de teste. A temporização do pipeline e a verificação dos resultados foi outra tarefa difícil. Apesar de já contar com uma versão multiciclo em VHDL do processador MIPS [HAM00]. Esta descrição também pode ser utilizada como caso de teste para disciplinas da área de Microeletrônica. dificultando a depuração. podendo então comparar e validar os resultados dos dois modelos. inclusive uma memória de instruções e uma memória de dados. é uma tarefa que. apresenta eventualmente problemas internos. sendo necessário compilar um a um os arquivos com as constantes. Conclusões Neste trabalho. várias dificuldades foram encontradas no desenvolvimento e validação desta versão pipeline. 20 . Neste chip. previsores de desvios dinâmicos. foram encerrados todos os blocos básicos para um microprocessador. A ferramenta utilizada. O. PATTERSON.. 2. ed.. L. 21 . Rapid Prototyping of Digital Systems: a tutorial approach. J.. Boston: Kluwer Academic Publishers. J. [HAM00] HAMBLEN. [HEN98] HENESSY. FURMAN. A. M. 2000. 2000.6. 1998. Computer Organization and Design: the hardware/software interface. San Francisco: Morgan Kaufmann Publishers. Fundamentals of Digital Logic with VHDL Design. S. D. Boston: McGraw-Hill. VRANESIC. Z. Bibliografia [BRO00] BROWN. D.