EEL-7020 – Sistemas Digitais

Definicao do Trabalho Pratico – 2011/1

“Projeto e implementacao em VHDL/FPGA de um sistema de comunicacao de dados com deteccao e correcao de erros usando codigo de Hamming”


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

Prof. Eduardo Augusto Bezerra

Prof. Joni da Silva Fraga

Prof. Raimes Moraes

 

Visao geral

O objetivo geral do trabalho pratico e o projeto de um sistema digital para implementacao de sistema de comunicacao de dados com deteccao e correcao de erros usando codigo de Hamming.

Especificacao

  • Considerar um sistema de comunicacao de dados que utiliza codigo de Hamming para geracao de paridade (protecao dos dados a serem transmitidos) e posterior deteccao e correcao de possÌveis erros.
  • Dicas sobre codigos de Hamming: pagina da USP
    (copia local) e universidade na Florida
    (copia local).
  • Deverao ser implementados dois circuitos, um “Transmissor” e um “Receptor”, conforme apresentado no diagrama de blocos a seguir.
  • No circuito transmissor, as mensagens de dados a serem enviadas sao compostas por palavras de 57 bits, e estao armazenadas em um elemento de memoria.
  • Considerando os 57 bits de uma mensagem, devem ser gerados bits de paridade utilizando o codigo de Hamming. Esses bits de
    paridade deverao ser concatenados aos 57 bits de dados, formando a informacao a ser transmitida (mensagem + bits de paridade).
  • Alem dos bits gerados com o uso do codigo de Hamming, a mensagem a ser transmitida devera possuir um bit adicional para
    melhorar ainda mais a capacidade de deteccao de erros do sistema. Trata-se de um bit de checksum, que e obtido por intermedio de um ou-exclusivo
    entre todos os demais 63 bits da mensagem (57 bits de dados + 6 bits de Hamming).
  • Dessa forma, o tamanho total da mensagem a ser transmitida sera de 64 bits (57 bits de dados + 6 bits de Hamming + 1 bit de checksum).
    Com isso teremos uma mensagem a ser transmitida com 64 bits, onde 57 bits representam informacao ˙til (dados), e 7 bits representam a redund‚ncia
    (bits de paridade) necessaria para melhoria da confiabilidade do sistema.
  • Ainda no lado do transmissor, devera ser desenvolvido um circuito para injecao de falhas. As falhas se resumirao a alterar apenas um dos 64 bits da mensagem a ser transmitida,
    que e composta por 57 bits de dados + 7 bits de paridade.
    Esse circuito ira simular a ocorrencia de ruÌdos em uma linha de transmissao. O ruÌdo pode ser considerado o principal responsavel pelas falhas na comunicacao de dados.
  • Apos ter sido injetada a falha, sera necessario adicionar quatro bytes de sincronismo no inÌcio da mensagem a ser transmitida. Esses quatro bytes representam uma
    “marca de sincronismo” (SYNCH) a ser utilizada pelo circuito receptor para identificar o inÌcio de uma nova mensagem. Enquanto o circuito receptor nao identificar
    uma sequencia de bits formada por esses quatro bytes, a recepcao dos 64 bits da mensagem nao devera iniciar. Sempre que for detectado um bit em erro na sequencia de
    sincronismo esperada, entao o detector de sequencia devera retornar ao ao estado inicial de espera pelo primeiro bit da sequencia. Ao ser identificada a sequencia
    completa de bits de sincronismo, entao o proximo bit recebido sera o primeiro bit da mensagem.
  • Os circuitos usados na conversao paralelo/serie e serie/paralelo, que realizam a transmissao dos dados efetivamente, serao registradores de deslocamento (comunicacao serial).
  • A sequencia de sincronismo (SYNCH) e composta por 1ACFFC1D (hexadecimal), ou 0001 1010 1100 1111 1111 1100 0001 1101 (binario). O primeiro bit da sequencia a ser
    transmitido devera ser o bit mais a esquerda (0), seguido dos demais bits (0, 0, 1, 1, 0, 1, 0, 1, 1, 0, 0, 1, …).
  • Ao receber uma sequencia de sincronismo (SYNCH) completa, o circuito receptor ira aguardar por 10 mensagens de 64 bits. Isso representa um total de 640 bits
    de mensagens (incluindo a informacao util e os bits de paridade), para cada 32 bits de SYNCH. Apos receber as 10 mensagens, o
    receptor devera retornar ao modo “aguardando sequencia de SYNCH”. Esse modo de operacao
    devera ser garantido pelo circuito transmissor.
  • No lado do receptor um circuito decodificador e responsavel por processar os bits de paridade contidos na mensagem recebida, e informar a posicao em que se
    encontra o bit com a falha injetada pelo circuito do transmissor.
  • Um circuito combinacional de correcao automatica devera recuperar o dado original de 57 bits, que foi obtido da memoria do transmissor antes da falha ter sido injetada.
  • Um sinal de relogio gerado a partir de um dos clocks disponÌveis na placa devera ser utilizado para garantir o sincronismo a
    nÌvel de bit. Esse sinal de relogio gerado devera ser enviado pelo transmissor para o receptor em uma linha separada da linha de dados.
    Dessa forma, um ˙nico sinal de relogio sera utilizado nos dois circuitos, em todos os componentes que precisarem de um clock.
  • Deverao ser implementadas duas maquinas de estados, uma para controlar as atividades do transmissor, e outra para controlar as atividades do receptor.
    Ambas maquinas de estado deverao utilizar o mesmo sinal de relogio, que e enviado do transmissor para o receptor.
  • O sistema devera ser desenvolvido inteiramente em VHDL, e de forma hierarquica, conforme estrategias apresentadas nas aulas praticas. Dessa forma, deverao
    ser implementados os diversos componentes do sistema, que poderao ser compostos por outros componentes, e devera existir uma descricao VHDL que sera o
    “topo” dessa hierarquia. Nessa descricao VHDL deverao ser criadas todas as inst‚ncias de componentes que se fizer necessario, e deverao ser realizadas
    todas as conexıes, usando component e port map. Uma vez que na entrega do trabalho serao consideradas apenas solucıes em VHDL, logo nao serao
    aceitas solucıes onde os diversos componentes do sistema venham a ser conectados por intermedio, por exemplo, de um diagrama de blocos.
  • Um botao (push-button) devera ser utilizado para dar a partida nas maquinas de estado iniciando a transmissao das mensagens.
  • OBS 1. Os bytes recebidos nas mensagens deverao ser analisados e, caso representem caracteres imprimÌveis da tabela ASCII entao, OPCIONALMENTE, poderao ser
    apresentados no LCD disponÌvel no kit de desenvolvimento.
  • OBS 2. Visando simplificar a depuracao (simulacao) do sistema, assim como a possÌvel escrita dos bytes das mensagens no
    LCD, serao aceitas implementacıes com palavras de 16 bits de dados e 5 bits de paridade, totalizando 21 bits por mensagem codificada (dados + paridade).
    A sincronizacao entre transmissor e receptor se dara da mesma forma, ou seja, por intermedio da sequencia de SYNCH especificada anteriormente.


fig1

Figura 1. Diagrama de blocos funcional do sistemas digital a ser implementado.

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 incluÌdos na documentacao, apenas quando necessario
    para alguma explicacao de modulos implementados.
  • Devera ser incluÌdo 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 saÌda,
    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 extraÌdos diretamente do Quartus II;
    • Consideracoes e conclusoes 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 inÌcio 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 sÌmbolos utilizados no programa (entities, architectures, signals, …).
  • O arquivo de projeto completo, incluindo pelo menos um diagrama de formas de onda (vector waveform file) e o fonte VHDL deverao ser entregues no Moodle,
    obedecendo RIGOROSAMENTE o prazo estipulado. O diagrama de formas de onda devera mostrar claramente a simulacao de uma transferencia de mensagens entre o transmissor e o receptor, com a injecao de falhas, seguida da devida correcao.
  • Gerar um arquivo compactado, contendo todo o diretorio do projeto desenvolvido no Quartus II, e submeter apenas esse arquivo. O sistema de submissao de trabalhos disponÌvel no Moodle aceitara a submissao de um ˙nico 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
    (ex. XOR utilizado no gerador de paridades).
  • 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 9.
  • 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 6 (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 incluÌdas (todos os novos componentes sendo validados individualmente, antes de serem
    anexados ao projeto).
  • ATENCAO!! Mesmo projetistas de sistemas digitais experientes, ja atuando na
    ind˙stria, 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 a ferramenta de simulacao com formas de ondas do 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 no FPGA da placa DE2 da Altera:

  • Identificar os perifericos disponÌveis na DE2 e pinos de entrada/saÌda do FPGA, que poderao ser ˙teis
    no desenvolvimento do sistema digital solicitado. Informacıes sobre pinos e perifericos poderao ser
    encontradas no Manual do Usuario da Placa DE2.
  • Testar no FPGA os diversos componentes conforme forem sendo desenvolvidos, assim como os componentes
    resultantes da integracao dos modulos. Realizar os testes na placa, apenas apos a simulacao indicar
    que o sistema esta funcionando de acordo com o esperado.
  • Os kits DE2 estao disponÌveis no laboratorio de sistemas digitais e microprocessadores, e poderao ser
    utilizados fora dos horarios de aulas desse laboratorio.
  • Os kits DE2 nao poderao ser emprestados para os alunos, que deverao compartilhar os mesmos apenas no
    laboratorio.

4. Ajuda:

  • Slides utilizados pelos alunos em estagio docencia na aula de explicacao sobre o trabalho – ComunSincronaHamming.pdf.
  • Procurar o monitor da disciplina para d˙vidas sobre o projeto dos circuitos a serem utilizados.
  • Verificar as agendas semanais dos professores da disciplina 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 27 de junho:

Avaliacao

  • O trabalho podera ser desenvolvido individualmente ou em grupos com, no maximo, tres integrantes.
  • Conforme colocado anteriormente, a documentacao do projeto e o fonte VHDL deverao ser entregues no
    Moodle, obedecendo RIGOROSAMENTE o prazo estipulado.
  • A apresentacao da simulacao e a demonstracao do funcionamento por intermedio de simulacao sera realizada
    na semana de 27 de junho a 01 de julho 2011. O grupo devera combinar com o professor da disciplina
    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 dos alunos 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: 50%
  • OBSERVACAO IMPORTANTE!! O trabalho podera ser realizado em grupo, porem A AVALIACAO E’ INDIVIDUAL. Cada integrante do grupo SER¡ 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.