EEL-7020 – Sistemas Digitais

Definicao do Trabalho Pratico – 2012/1

“Projeto, implementacao e simulacao em VHDL/FPGA de uma versao reduzida do jogo Batalha Naval”


Departamento de Engenharia Eletrica,
CTC,
UFSC,
Florianopolis, SC, Brasil

Prof. Eduardo Augusto Bezerra

Prof. Joni da Silva Fraga

Prof. Djones Vinicius Lettnin

 


Visao geral
O objetivo geral do trabalho pratico e’ o projeto e implementacao em VHDL/FPGA de uma versao eletronica e reduzida do jogo Batalha Naval.


Batalha naval eletronica
A Figura 1 apresenta o tabuleiro classico do jogo batalha naval, e a Figura 2 apresenta os componentes das plataformas de desenvolvimento utilizados para a implementacao eletronica do jogo.
Dicas e detalhes sobre a plataforma de desenvolvimento da Figura 2 estao disponiveis na pagina do projeto “FPGA para todos”: http://fpgaparatodos.com.br/

tabuleiro
Figura 1. Tabuleiro da versao classica do jogo Batalha Naval.
conexoes-kits
Figura 2. Hardware para a implementacao fisica do jogo.


Especificacao

  • A Figura 3 apresenta o diagrama de blocos do sistema digital a ser implementado em VHDL, com a maquina de estados utilizada para o controle das operacıes a serem realizadas pelos diversos componentes do sistema. Notar que nessa figura sao apresentados os dois circuitos, a serem utilizados nas duas placas, e que os circuitos sao identicos.
  • Na versao reduzida a ser implementada, serao considerados apenas 3 submarinos (3 quadrados da Figura 1).
  • A sequencia de acıes realizadas em cada plataforma de desenvolvimento, que devera ser controlada pelo circuito descrito em VHDL e a seguinte:
    1. Selecionar as 8 chaves (conjunto azul na Figura 2) para posicionar os 3 submarinos. Chaves em ON (ligadas) informam para o circuito que um submarino devera
      ser colocado naquela posicao do tabuleiro. Os LEDs indicam as posicıes do tabuleiro. Por exemplo, se as chaves 1, 4 e 5 estiverem ligadas (ON), os submarinos
      serao colocados nas posicıes LED 1, LED 4 e LED 5.
    2. Apos selecionadas as posicıes dos 3 submarinos, devera ser pressionado um dos 8 botıes pretos apresentados na parte inferior da Figura 2. Esse botao representara
      um “Enter”, informando ao circuito implementado em VHDL que a informacao selecionada nas chaves (3 bits, ou 3 submarinos) devera ser armazenada para utilizacao
      durante o jogo.
      Os tres LEDs correspondentes deverao acender, quando o botao Enter for
      pressionado.
    3. Apos a etapa de posicionamento dos submarinos (etapa de configuracao), o jogo inicia com cada oponente selecionando apenas uma chave por vez (apenas uma chave ficara em ON),
      e pressionando outro botao preto para realizar o disparo na posicao indicada, porem na esquadra do oponente.
    4. Apos pressionado o botao de disparo, a informacao sobre a posicao do submarino do oponente sera enviada para o circuito VHDL implementado na outra plataforma de desenvolvimento.
    5. O circuito VHDL destino devera realizar a recepcao da informacao do disparo, e verificar se na posicao indicada no byte recebido existe algum submarino.
    6. Se existir algum submarino na posicao recebida, o LED correspondente onde se encontra o submarino na esquadra atacada devera permanecer aceso ate o final do jogo, indicando
      que um submarino foi descoberto e destruido.
    7. Se nao existir um submarino na posicao informada, o LED correspondente devera apenas acender e apagar em seguida informando que o disparo foi na agua.
    8. Os disparos serao intercalados, ou seja, mesmo que um jogador acerte um disparo, o proximo disparo sempre sera realizado pelo adversario. Um jogador nao podera
      realizar mais de um disparo sucessivamente.
    9. O jogo termina quando um dos oponentes conseguir descobrir (e afundar) os 3 submarinos do adversario.
  • A transferencia de dados entre as plataformas de desenvolvimento utilizadas pelos dois jogadores podera ser realizada por intermedio de comunicacao paralela ou serial, de acordo com decisao de projeto dos desenvolvedores.
  • Descricao dos modulos da Figura 3:
    • FSM de controle – Responsavel por controlar todo o fluxo de operacıes do sistema. Controla, entre outros, a escrita e leitura de registradores, contadores, entradas e saidas. Controla as operacıes de transferencia de dados (comunicacao) entre as duas placas. Notar que deve ser selecionado o relogio e um botao para reset em uma das placas, para utilizacao em ambas. Isso ira garantir que ambas FSMs estao em sincronia em relacao ao sinal de relogio e ao Reset.
    • Chaves SW(7..0) – Dispositivo de entrada utilizado no inicio do jogo, para a montagem da esquadra (apenas 3 chaves devem estar em 1), e durante o jogo para realizar os disparos (apenas uma chave deve estar em 1).
    • Botıes KEY(7..0) – Dispositivo de entrada utilizado para informar a ocorrencia de eventos para a FSM. Um botao de uma das placas deve ser utilizado para o Reset das duas placas. Um botao em cada placa deve ser usado como “Enter” no termino da montagem, para a FSM realizar o armazenamento da esquadra no respectivo registrador. Um outro botao “Enter” e utilizado durante o jogo para informar os “disparos” do jogador para a FSM.
    • Registrador “Esquadra” – No inicio do jogo, no momento da montagem da esquadra, e utilizado para armazenar as posicıes dos tres submarinos. Durante o jogo, o conteudo desse registrador (esquadra) e utilizado como entrada pelo Comparador, para identificar se algum submarino foi atingido por um disparo do adversario.
    • Registrador “Disparos recebidos” – … utilizado durante o jogo para armazenar os disparos realizados pelo adversario. Cada novo disparo recebido (cada bit) deve ser armazenado nesse registrador, sem apagar os bits (disparos) recebidos anteriormente. Pode ser realizada uma operacao de OR (“OU” bit-a-bit) entre o disparo recebido (que deve ser de 8 bits) e o conteudo anterior desse registrador. A entrada desse registrador e fornecida pelo modulo de comunicacao. A saida do registrador e utilizada como entrada pelo Comparador.
    • Comparador – Realiza a comparacao entre os 8 bits (3 sao submarinos) armazenados no Registrador “Esquadra”, e os 8 bits armazenados no Registrador “Disparos recebidos”. Esse comparador podera realizar uma operacao logica entre as entradas, resultando no total de bits diferentes entre as duas entradas. O byte resultante dessa comparacao devera ser fornecido ao Contador, que ira contar o numero de bits em nivel logico 1 nesse byte. Quando o contador apresentar uma contagem igual a 3 (tres bits estao em 1), logo os 3 submarinos foram descobertos, e o jogo e finalizado.
    • Contador – Contagem do numero de bits em nivel logico 1 existentes no byte recebido. Esse componente realiza a contagem de naufragios ocorridos (acertos do adversario). A entrada do contador e a saida do comparador. Quando o total de naufragios for 3, o jogo acaba, e os submarinos (LEDs) descobertos da esquadra devem ser apresentados.
    • Comunicacao – Esse componente e responsavel pelo envio da palavra (byte) com o “disparo” para a placa do adversario, e pela recepcao de uma palavra (byte) com um “disparo” do adversario. Apos a etapa de montagem das esquadras, as duas FSMs podem permanecer aguardando em um estado de Espera. Assim que for recebido um sinal da placa do adversario ou de um botao da mesma placa, a FSM sabera se trata-se de um disparo a ser enviado para o adversario, ou de um disparo sendo recebido do adversario. Nesse instante, o modulo de comunicacao de uma das placas entrara em modo de recepcao de dados, e o da outra placa em modo de transmissao de dados. Os dados podem ser transferidos entre as placas por intermedio de comunicacao serial (registradores de deslocamento contidos no modulo de Comunicacao da Figura 3), ou diretamente por intermedio de 8 fios caracterizando uma comunicacao paralela. Apos recebido o byte com o disparo do adversario, o modulo de comunicacao disponibiliza esse dado em sua saida, e a FSM realiza o armazenamento no Registrador “Disparos recebidos”.
    • LEDs – Utilizados para indicar: o posicionamento da esquadra na etapa de configuracao; disparos recebidos e submarinos afundados durante o jogo; e para indicacao de esquadra descoberta no fim do jogo.

    batalha_naval
    Figura 3. Diagrama de blocos.

Documentacao do projeto (relatorio final)

  • A documentacao devera ser completa e clara o suficiente para possibilitar
    alteracıes e atualizacıes na implementacao do projeto, sem a necessidade de consultar os
    projetistas
    . Durante a correcao da documentacao o professor da disciplina ira realizar uma
    alteracao no codigo VHDL, sem consultar os autores, com informacıes obtidas apenas a partir
    da documentacao. Na avaliacao final da documentacao sera considerado o grau de facilidade
    para realizar a alteracao no VHDL.
  • A documentacao do projeto devera conter uma descricao detalhada de todos os modulos desenvolvidos.
  • O texto devera DESCREVER o projeto, sem incluir a listagem completa do codigo VHDL implementado.
    Alguns trechos do codigo VHDL poderao ser incluidos na documentacao, apenas quando necessario
    para alguma explicacao de modulos implementados.
  • Devera ser incluido o fluxo completo do projeto, detalhando as ferramentas utilizadas e as
    etapas de projeto. A descricao do fluxo deve ser suficientemente detalhada de forma a
    facilitar a repeticao de todas as etapas realizadas. No momento da correcao do trabalho
    sera consultada e seguida a descricao do fluxo de projeto existente na documentacao. Dessa
    forma, descricıes incompletas do fluxo de projeto poderao prejudicar a avaliacao do trabalho.
  • Preparar e incluir na documentacao um diagrama de blocos completo com todos os modulos implementados.
    O diagrama de blocos devera ser detalhado de forma a incluir todos os sinais de entrada e saida,
    e todos os modulos implementados.
  • Devera ser fornecida tambem a representacao grafica das maquinas de estados, tabelas de estados e
    explicacıes sobre estados e transicıes.
  • Sugestao de organizacao para o documento do projeto:
    • Folha de rosto contendo dados do autor, da instituicao, local, data;
    • Objetivos do trabalho;
    • Especificacao do problema proposto – visao/entendimento do autor sobre essa especificacao;
    • Projeto dos componentes do sistema com uma breve descricao do objetivo de cada componente.
      Incluir nessa descricao uma explicacao (com diagrama de blocos e textual) dos componentes
      estudados na teoria e sua utilizacao na pratica (ex. multiplexadores, decodificadores, circuitos
      aritmeticos, …);
    • Descricao das ferramentas utilizadas e fluxo de projeto;
    • Descricao da simulacao realizada, com diagramas de forma de ondas extraidos diretamente do Quartus II ou ModelSim;
    • Consideracıes e conclusıes sobre o trabalho realizado.
  • … importante cuidar a coerencia e a coesao da documentacao, pois o documento entregue sera
    essencial para o entendimento e correcao do trabalho realizado.
  • A documentacao devera ser entregue no Moodle,
    obedecendo RIGOROSAMENTE o prazo estipulado.

Codigo fonte VHDL e arquivo de projeto do Quartus II

  • O codigo fonte VHDL deve estar adequadamente comentado – incluir um comentario explicativo em cada
    bloco de codigo e, sempre que necessario, em linhas individuais.
  • Incluir um bloco de comentario no inicio do arquivo com o fonte VHDL contendo
    dados dos alunos e demais dados de identificacao do projeto (ex. utilidade, ferramentas, FPGA alvo, …).
  • O codigo fonte precisa estar com a indentacao adequada.
  • Escolher nomes adequados para os simbolos utilizados no programa (entities, architectures, signals, …).
  • Os fontes VHDL deverao ser entregues no Moodle, obedecendo RIGOROSAMENTE o prazo estipulado.
  • Gerar um arquivo compactado, contendo APENAS os fontes VHDL do projeto desenvolvido no Quartus II, e submeter apenas esse arquivo. O sistema de submissao de trabalhos disponivel no Moodle aceitara a submissao de um unico arquivo por grupo.

Etapas do projeto e dicas uteis
1. Dividir o problema em partes menores – abordagem “dividir para conquistar”:

  • Desenvolver circuitos em VHDL para acesso aos perifericos da placa com o FPGA. Durante o semestre,
    alguns desses circuitos foram desenvolvidos nas aulas teoricas e praticas como, por exemplo, registradores e maquinas de estados.
  • Desenvolver circuitos combinacionais em VHDL para as operacıes logicas e aritmeticas a serem executadas.
  • Seguir as dicas para implementacao de circuitos controladores fornecidas
    nas aulas teoricas e praticas. Uma boa dica de descricao em VHDL de uma FSM de controlador
    e desenvolvida no Laboratorio 8.
  • Apos ter certeza que todos os circuitos possuem o comportamento desejado, realizar a integracao dos
    componentes desenvolvidos, formando gradualmente sistemas digitais mais completos que atendam aos
    requisitos fornecidos. A integracao de componentes e discutida no Lab 9 e no Lab 10 (port map).
  • Seguindo essa filosofia de projeto, poderia ser desenvolvida uma versao inicial do projeto com apenas uma
    funcionalidade, por exemplo, e apos devidamente validada, as demais funcionalidades poderiam
    ser incluidas (todos os novos componentes sendo validados individualmente, antes de serem
    anexados ao projeto).
  • ATENCAO!! Mesmo projetistas de sistemas digitais experientes, ja atuando na
    industria, nao desenvolvem sistemas por inteiro sem antes simular e validar os componentes
    individualmente. Essa regra e seguida por projetistas experientes ate para sistemas digitais
    considerados simples como, por exemplo, o projeto em questao.

2. Simulacao do projeto:

  • Utilizar ferramentas de simulacao com formas de ondas, tais como, o ModelSim ou o Quartus II para simular os circuitos
    desenvolvidos individualmente.
  • Realizar a simulacao com os diagramas de formas de ondas dos diversos componentes desenvolvidos e,
    gradualmente, dos novos componentes compostos pela integracao dos componentes menores, ate chegar
    na implementacao final do projeto.

3. Prototipacao na plataforma de desenvolvimento:

  • Identificar os perifericos disponiveis no kit de desenvolvimento e pinos de entrada/saida, que poderao ser uteis
    no desenvolvimento do sistema digital solicitado. Informacıes sobre pinos e perifericos poderao ser
    encontradas no site do projeto “FPGA para todos“. Esse site possui informacıes detalhadas sobre o modulo principal a ser utilizado para
    a prototipacao do circuito descrito em VHDL (Modulo CPLD_7064), e
    sobre os perifericos disponiveis para esse modulo (Modulos Perifericos).
  • Testar na plataforma de desenvolvimento os diversos componentes conforme forem sendo desenvolvidos, assim como os componentes
    resultantes da integracao dos modulos. Realizar os testes na plataforma de desenvolvimento, apenas apos a simulacao indicar
    que o sistema esta funcionando de acordo com o esperado.
  • As plataformas de desenvolvimento do laboratorio nao poderao ser emprestadas para os alunos, que deverao compartilhar as mesmas apenas no
    laboratorio. Os alunos interessados em adquirir os componentes para montar suas proprias plataformas de desenvolvimento, poderao
    entrar em contato diretamente com a equipe do projeto “FPGA para todos“.

4. Ajuda:

  • Procurar o monitor da disciplina para duvidas sobre o projeto dos circuitos a serem utilizados.
  • Verificar a agenda semanal do Prof. Eduardo Bezerra para agendar horarios de atendimento e, tambem,
    para agendar a data/hora da apresentacao do trabalho que devera ser realizada na semana que inicia no dia 2 de julho de 2012:
    (selecionar week view)

Avaliacao

  • O trabalho podera ser desenvolvido individualmente ou em grupos com, no maximo, tres integrantes.
  • A documentacao do projeto e o fonte VHDL deverao ser entregues no Moodle:
    • O prazo maximo para entrega e dia 29 de junho de 2012.
    • O sistema estara aceitando submissıes no dia 29 de junho ate as 23:55 horas.
    • Nao serao aceitos envios atrasados (apos as 23:55 do dia 29 de junho).
    • Em semestres anteriores, alunos que perderam o prazo para envio ficaram com nota zero no trabalho final.
    • O sistema aceita varios envios (desde que dentro do prazo de entrega). Assim, e fortemente recomendado que todas as versıes parciais do trabalho sejam enviadas no moodle (tanto o VHDL quanto o relatorio).
    • Uma nova submissao sobreescreve a anterior. Todos os alunos devem submeter pelo menos uma versao dos seus trabalhos por dia, garantindo que tera um trabalho para ser avaliado no final do semestre.
    • O tamanho maximo do arquivo contendo o relatorio e de 10 M bytes. Devera ser submetido APENAS um arquivo, e esse arquivo devera estar no formato PDF.
    • O tamanho maximo do arquivo contendo o fonte VHDL e de 100 K bytes. Devera ser submetido APENAS um arquivo compactado contendo todos os fontes VHDL.
    • Nao deverao ser incluidos arquivos de projeto do Quartus II no arquivo compactado – INCLUIR APENAS OS FONTES VHDL (.vhd).
    • O nome do arquivo compactado com os fontes VHDL devera ser o nome completo do aluno, sem espacamento. Por exemplo, o aluno “Eduardo Augusto Bezerra” devera gerar o seguinte arquivo compactado com seus fontes VHDL: “eduardoaugustobezerra.zip”
    • TODOS OS ALUNOS DEVERAO SUBMETER OS SEUS RELATORIOS E FONTES VHDL, MESMO QUE TENHAM DESENVOLVIDO OS TRABALHOS EM GRUPOS.
    • O sistema de submissıes de arquivos do Moodle e a ferramenta oficial para entrega de trabalhos da disciplina. NAO SERAO ACEITOS TRABALHOS ENVIADOS POR EMAIL, TRABALHOS IMPRESSOS, OU QUALQUER OUTRA FORMA DE ENTREGA A NAO SER O SISTEMA DO MOODLE.
  • A apresentacao da simulacao e a demonstracao do funcionamento por intermedio de simulacao sera realizada
    na semana de 2 a 6 de julho 2011. Os alunos deverao agendar
    a data e hora para apresentacao do trabalho durante essa semana.
  • Durante a apresentacao, os alunos deverao estar aptos a responder quaisquer perguntas. Respostas
    insatisfatorias ou a ausencia do aluno podera acarretar em anulacao da nota final.
  • Na apresentacao serao realizados questionamentos sobre decisıes de projeto e estrategias
    de implementacao VHDL utilizadas. Sera verificada tambem a familiaridade dos alunos com
    as ferramentas de desenvolvimento utilizadas durante o semestre. Todos os alunos do grupo
    devem estar aptos a responder todas as questıes.
  • As explicacıes durante a apresentacao da documentacao do projeto, e na demonstracao do projeto
    funcionando por intermedio da simulacao e dos diagramas de formas de onda, sao fundamentais
    para a avaliacao.
  • Trabalhos copiados, inclusive entre turmas, resultarao em nota zero para todos os alunos envolvidos.
    Sera utilizado o MOSS como ferramenta auxiliar
    na identificacao de situacıes de plagio.
  • Os dois itens a serem avaliados possuem os seguintes pesos na nota final do trabalho pratico:
    • Documentacao do projeto: 50%
    • Demonstracao do funcionamento por intermedio de simulacao no Quartus II ou ModelSim: 50%
  • OBSERVACAO IMPORTANTE!! O trabalho podera ser realizado em grupo, porem A AVALIACAO … INDIVIDUAL. Cada integrante do grupo SERA’ QUESTIONADO
    INDIVIDUALMENTE, e devera estar apto A UTILIZAR A FERRAMENTA de desenvolvimento, e mostrar CONHECIMENTO DE TODO O VHDL desenvolvido, assim como da SIMULACAO REALIZADA.