Enunciado do Trabalho Prático

Prof.Edson Moreno

edson.moreno [at] pucrs.br

Engenharia de Computação, FACIN/FENG, PUC-RS


Escopo do trabalho:

O Trabalho Prático (TP) consiste na exploração da arquitetura do MIPS multiciclo previamente explorada pelos alunos. O objetivo final do trabalho é projetar/implementar em VHDL comportamental em uma versão da mesma arquitetura com pipeline, explorando assim os conceitos apresentados em sala de aula.

A arquitetura implementada deverá ser capaz de executar programas descritos em assembly daquela arquitetura descritos e validados com a ferramenta MARS.

A implementação partirá de uma descrição VHDL da arquitetura MIPS trabalhada pelos alunos em disciplinas anteriores (Organização de Computadores). Ao final do trabalho, após o cumprimento de etapas detalhadas a seguir, deverá ser disponibilizada uma arquitetura do mesmo processador empregando pipeline. Esta deverá contemplar a detecção e tratamento de conflitos de dados, este último através da inserção automática de bolhas e adiantamento. A implementação da arquitetura com pipeline deve ainda incluir mecanismos de detecção e tratamento de conflitos de controle, visando a ocorrência de desvios.



Objetivos do trabalho:

Os objetivos estratégicos do trabalho a ser desenvolvido são os de (i) fazer avançar o conhecimento dos alunos em VHDL e (ii) consolidar os conceitos de arquiteturas empregando técnicas de pipeline.

Para o atendimento dos objetivos estratégicos, tem-se como objetivo específico a implementação em VHDL da arquitetura do processador MIPS com pipeline bem como a elaboração de documentação que contribua para o entendimento dos trabalhos desenvolvidos. Cabe reforçar que o resultado final do trabalho deve ser o desenvolvimento uma arquitetura com pipeline em VHDL contendo os elementos de tratamento de conflito de dados e de controle especificados nas etapas que a compõem.



Autoria dos trabalhos:

O trabalho poderá ser desenvolvido individualmente ou em duplas.


Material a ser entregue ao professor:

Cada grupo deverá preparar um documento de projeto completo descrevendo tudo o que foi realizado. O documento de projeto representa 50% da avaliação, sendo considerada em cada etapa. As etapas do trabalho são detalhadas abaixo. Trabalhos encaminhados faltando documentação ou implementação serão considerados não entregues. Implementações somente serão aceitas se a simulação estiver funcional, do contrário este não será considerado. Casos onde houver erro de sintaxe durante a apresentação (problema que pode ser avaliado pelos alunos com a opção check sintax) incorrerá em grau zero à etapa que está sendo cumprida.

O documento de projeto deverá ser claro o suficiente, de forma a ser utilizado pelo professor da disciplina como um manual (datasheet) para o desenvolvimento de programas para a arquitetura proposta. O documento deverá possuir os detalhes necessários para que todo esse fluxo seja executado sem a necessidade de consultar os projetistas (alunos) o que deve ser feito para o programa funcionar. Mais precisamente, é obrigatório o detalhamento sobre o fluxo que se inicia com a validação do código assembly no ambiente MARS até a simulação da arquitetura descrita em VHDL.

O desenvolvimento do trabalho pressupõe a descrição de programas a serem utilizados para a validação em código assembly e a simulação das descrições VHDL. Para o primeiro, assume-se aqui o emprego da ferramenta MARS, conforme citado previamente. Para as simulações empregando os arquivos VHDL, deverá ser utilizada a ferramenta ISE Simulator da xilinx. Cabe lembrar que estas ferramentas estão disponíveis nos computadores da FACIN. Apesar disto, ambas ferramentas possuem versões grátis que podem ser encontradas na internet, o MARS disponível neste link e o ISE WEBPACK no site da xilinx. A versão do MARS pode ser a 3.6 ou 4.1, já o ISE tem de ser o mesmo disponibilizado Linux em qualquer dos laboratórios da FACIN. Trabalhos apresentados em versões diferentes e que venham a apresentar problemas para a simulação não serão considerados.


Apresentação do trabalho:

Nas datas de apresentação do trabalho, serão realizadas perguntas sobre a documentação do projeto e detalhes de implementação. Um dos alunos do grupo será escolhido aleatoriamente e as respostas fornecidas por este valerão para a avaliação de todo o grupo. A escolha das ordens de apresentação será realizada sempre no início do dia da apresentação. A não apresentação do trabalho invalidará a etapa, sendo atribuído ao grupo o grau zero. Somente será atribuída nota aos alunos que estiverem presente durante a apresentação. Assim, a ausência de um elemento de um grupo durante a apresentação lhe será punida com a atribuição do grau zero naquela etapa.

Para o dia da apresentação o seguinte roteiro deve ser seguido:

1.      O download do material postado no moodle para iniciar a apresentação

2.      A apresentação do código assembly utilizado e a justificativa daquele código

3.      A “compilação” do código para dar início a simulação

4.      Apresentação e explicação das formas de onda para validação do trabalho

5.      A explicação do código vhdl

6.      A apresentação da documentação elaborada para cada etapa


Etapas e Datas Importantes:

O desenvolvimento do presente trabalho deverá ser realizado em 4 etapas. A cada uma das etapas, são atribuídos graus distintos conforme apresentado a seguir:

·         06/09/2012 - Primeira etapa --Relatório + VHDL-- (máx. 1,0 ponto)

Trabalhar sobre o MIPS multiciclo.

Para a primeira etapa, os objetivos são: (i) a definição do conjunto de instruções, (ii) a implementação da arquitetura em VHDL, bem como o testbench para validação do mesmo, e (iii) a organização que deve ser adotada para validação da implementação. Sendo assim, os seguintes recursos são esperados:

Os arquivos listados acima deverão ser encaminhados para avaliação via email em um único arquivo, compactado (.zip). O nome do arquivo compactado deverá ser composto pelo nome completo do autor, sem espaços, conforme o exemplo: NomeSobrenome(_NomeSobrenome).zip

·         09/10/2012 - Segunda etapa -- Relatório + VHDL -- (máx. 2,0 pontos)

Implementar a primeira versão do MIPS pipeline.

Para a segunda etapa, os objetivos são: (i) a entrega do relatório em pdf contendo a documentação do projeto desenvolvido da arquitetura MIPS desenvolvida com pipeline e (ii) o VHDL da versão do processador MIPS empregando pipeline de cinco estágios, tal como aquele visto em sala de aula. Esta implementação deverá ser uma evolução da versão multiciclo, explorada na fase anterior e não deverá dar qualquer suporte ao tratamento de conflitos de dados ou controle. A solução dos conflitos de dados deverá ser feita em nível de software, a partir da inserção manual de instruções nop entre instruções que tenham dependência verdadeira ou ainda através da reordenação das instruções. Solução similar deverá ser aplicada para conflito de controle, ou seja, inserindo-se instruções de nop logo após a instrução de salto para evitar que instruções incorretas sejam carregadas para o pipeline. É pressuposto que o testbench apresentado na primeira etapa do trabalho seja reutilizado aqui. Os seguintes recursos são esperados:

Os arquivos listados acima deverão ser encaminhados para avaliação via email em um único arquivo, compactado (.zip). O nome do arquivo compactado deverá ser composto pelo nome completo do autor, sem espaços, conforme o exemplo: NomeSobrenome_NomeSobrenome.zip

·         01/11/2012 - Terceira etapa --Relatório + VHDL-- (máx. 3,5 pontos)

Implementar a segunda versão do MIPS pipeline.

Para a terceira etapa, os objetivos são: (i) a entrega do relatório em pdf contendo a documentação do projeto desenvolvido da arquitetura MIPS desenvolvida com pipeline e (ii) o VHDL da versão do processador MIPS empregando pipeline com tratamento do conflito de dados e controle. No que se refere a implementação do pipeline, nesta etapa deverá estar contemplada o tratamento dos conflitos de dados e de controle da seguinte forma. Para o conflito de dados, deverá ser incluído o mecanismo de adiantamento e o pipeline deverá ter uma solução de inserção automática de bolha em situações em que o adiantamento não resolva. O tratamento de conflito de controle deve feito de forma automática através do emprego da política de que “o salto nunca ocorre”. Assim, deve-se excluir do pipeline as instruções que tenham sido inseridas incorretamente, quando um desvio ocorrer. É pressuposto que o testbench apresentado na primeira etapa do trabalho seja reutilizado aqui. Os seguintes recursos são esperados:

Os arquivos listados acima deverão ser encaminhados para avaliação via email em um único arquivo, compactado (.zip). O nome do arquivo compactado deverá ser composto pelo nome completo do autor, sem espaços, conforme o exemplo: NomeSobrenome_NomeSobrenome.zip

·         27/11/2012 - Quarta submissão --Relatório + VHDL-- (máx. 3,5 pontos)

Otimização do mecanismo de tratamento de conflito de controle.

Para a quarta etapa, os objetivos são: (i) a entrega do relatório contendo a documentação do projeto desenvolvido da arquitetura MIPS desenvolvida com pipeline e (ii) o VHDL da versão do processador MIPS empregando pipeline. Para esta etapa deverá ser implementado o tratamento dos conflitos de controle empregando-se um mecanismo de predição dinâmica, utilizando-se para tanto a predição com dois bits e partindo-se inicialmente do estado “salto não ocorre” (not taken).

Os arquivos listados acima deverão ser encaminhados para avaliação via email em um único arquivo, compactado (.zip). O nome do arquivo compactado deverá ser composto pelo nome completo do autor, sem espaços, conforme o exemplo: NomeSobrenome(_NomeSobrenome).zip