Re: Feedback Lab. 6 Turma A (Turma B também deve ler)

0 views
Skip to first unread message

Thiago Borges Abdnur

unread,
Jun 15, 2010, 9:32:21 PM6/15/10
to mc613_duvi...@googlegroups.com
Atenção pessoal da Turma B. 

Diversos erros apontados no documento enviado pelo Rafael também apareceram de forma similar nos trabalhos que corrigi, portanto leiam esse documento que pode ser  bem esclarecedor para o projeto final.

Até.

2010/6/12 Henrique Baggio <hnrqb...@gmail.com>
Rafael,

Gostei da idéia do feedback. Como conversamos com vc na última aula, essa prática ajuda muito a corrigir os erros nos labs.

Por exemplo, ao ver seu comentário sobre o erro no exercício 4 do meu grupo (10), que inferia muitos latches por não usar um clock'event, foi que percebi que isso atrapalhou bastante.

Alguns labs atrás, tive o problema de tentar controlar um processo usando dois sinais e pegar eventos nos dois, exatamente o que acontece no caso do datapath do exercício, no meu caso, eu tenho dois sinais, KEY(0) e KEY(1), que são o clock e o reset assincrono do circuito. Meu processo ficou assim:

process(KEY(0), KEY(1))
begin
    if (KEY(1) = '0') then         -- reset assincrono
        ...
    elsif (KEY(0) = '0') then      -- processa instrucao
        ...
    end if;
end process;

Tanto no if como no elsif os mesmos sinais são alterados. Só não coloquei aqui para simplificar.

Como vc disse, essa lógica infere uma tonelada de latches. Só que ao tentar usar a sua dica, e colocar no if um 'event para cada sinal,  o quartus informa uma série de erros como esse:
Error (10820): Netlist error at datapath.vhd(36): can't infer register for LEDG[0] because its behavior depends on the edges of multiple distinct clocks

Foi por isso que não coloquei os events no if. Entendi que sem eles a lógica fica errada e gera latches, mas não consegui resolver. Separar o if em dois processos, um para cada sinal KEY, também não funcionou.

Já estava quase mandando esse e-mail pedindo para que vc explicasse como fazer, quando resolvi buscar nos slides das aulas algum exemplo (que eu sabia ter visto) de um caso parecido. E achei mesmo: um contador de 4 bits com reset assincrono. Ai percebi que o certo era ter feito um event em apenas um dos sinais. Teste no meu projeto e não tem um latch sequer! \o/

Enfim, agora já estamos caminhando pra parte final da disciplina. Mas fica a dica que que esse tipo de retorno sobre a correção dos labs ajuda muito. Obviamente, cada grupo poderia entrar em contato e pedir para explicar o que deu errado, mas acho que ambos os caminhos são bons. =)



--
Thiago 'bolaum' Borges Abdnur
----------------------------------
"Querer o mal é querer a morte. Uma vontade perversa é o começo do suicídio."
- Eliphas Levi (Axioma II - A Chave dos Grandes Mistérios)

mario cortes

unread,
Jun 16, 2010, 7:52:33 AM6/16/10
to mc613_duvi...@googlegroups.com
Pessoal

Gostaria de enfatizar alguns pontos que eu tenho falado em aula, e que coincidem com os oportunos comentários do Rafael.

Estamos em um laboratório de projeto de Hardware. O uso de VHDL deve ser considerado apenas como uma ferramenta para facilitar o projeto de HARDWARE.

O projeto de hardware, seja ele convencional ou com o auxílio de linguagens, vai resultar na combinação e interconexão de estruturas conhecidas e compreendidas: portas lógicas, multiplexadores, decodificadores, ULAs, FFs, latches, contadores, deslocadores, máquinas de estado, memórias, barramentos, etc. Nós vimos em aula as maneiras corretas, robustas e seguras de implementar essas funções com VHDL. Ao se afastarem desses estilos de programação, vocês estão entrando em território desconhecido. Vimos casos de FSM que não foram identificadas pelo Quartus como tal. Isso porque o aluno se afastou totalmente dos estilos recomendados. Uma FSM é uma FSM e ponto. Não há o que inventar.

Ao enfrentar um projeto mais complexo, concebam o sistema de forma top-down, tentando construir módulos funcionais mais ou menos desacoplados (e preferencialmente síncronos) que, após alguns desdobramentos hierárquicos, acabam em estruturas básicas conhecidas de HW. Depurem o funcionamento dos módulos. Utilizem sempre os estilos de programação apresentados.

Isolem e tratem separadamente funções mais atípicas e estranhas, como por exemplo a entrada dos zeros e uns no detector de sequencia do lab06. Não misturem essas funções com a implementação de FSM ou outra coisa.

Se seguirem essas recomendações, isso não garante que não terão alguns problemas. Mas com certeza eles terão solução muito mais fácil do que se vocês mergulharem direto no código de forma não planejada.

Bom trabalho a todos



2010/6/15 Thiago Borges Abdnur <bol...@gmail.com>



--
Mario Côrtes
Institute of Computing        P.O.Box 6176
University of Campinas, Brazil             13084-971, Campinas, Sao Paulo
Reply all
Reply to author
Forward
0 new messages