Maquiavélicas ferramentas

Maquiavélicas ferramentas

Fazer algo simples é, talvez, um dos mais complexos desafios de engenharia. Atingir uma solução elegante, ou seja, simples, eficiente e, por sua vez, robusta para um problema exige estudo, esforço e experiência. Parte do problema está, infelizmente, mascarado por trás das nossas ferramentas. Se aprendermos a colocar parafusos com um martelo possivelmente não usaremos chaves de fenda, pois é mais rápido usando um martelo.

 

As ferramentas têm uma incidência maquiavélica em nosso raciocínio e, com isso, no resultado do nosso trabalho. Quem costuma pensar de uma forma, rapidamente esquece de correr atrás de outras soluções.

 

O projetista de circuitos digitais não é a exceção. Infelizmente o mercado puxa para soluções rápidas e geralmente não geridas pela engenharia, mas pelos prazos, que paradoxalmente atrasam o projeto, resultando em mais projetos de baixa qualidade.

 

O padrão de fato para projeto de lógica programável vem sendo há algum tempo a descrição formal das funcionalidades. A linguagem, nossa ferramenta, usada na descrição do hardware deveria acompanhar nossa metodologia de projeto e conduzir-nos por sendeiros seguros, desalentando-nos de usar construções potencialmente inseguras, perigosas ou desnecessariamente complexas. A ferramenta haveria de alentar o desenvolvedor sobre o uso de boas práticas de projeto, evitando a generalizada e, infelizmente, usual prática: codificar rápido e contornar na verificação.

 

Para apresentar um exemplo de raciocínio vamos implementar em lógica programável um componente bem conhecido, uma porta de comunicação serial, com somente Tx para simplificar. A funcionalidade de uma porta de comunicação serial do tipo encontrado nos antigos ACIAs ou atuais UARTs é essencialmente simples. Um bloco com entrada em paralelo e saída em serial. A cada escrita na entrada paralelo os dados são encaminhados para a saída serial numa taxa de bits pré-determinada.

 

fig1
Figura 1 - Saída serial

 

 

Se adotarmos o padrão semelhante das portas RS232, é encaminhado um bit de início (start), em seguida oito bits de dados e, para finalizar, dois bits de parada (stop).

 

Alguns sinais são implícitos na descrição, um sinal para marcar as escritas e um outro para marcar o passo da taxa de bits. A mais temos que contar os bits para inserir o início e a parada no momento correto. Aliás, por metodologia, faremos apenas projetos síncronos, e para tanto adicionaremos um relógio (clock). Do ponto de vista de um sistema, o UART não funcionará isolado, tendo que se comunicar com outros blocos e esses blocos precisam saber se o UART estará disponível. Vamos adicionar mais um sinal, um flag, para indicar se ele estiver ocupado. Se estiver ocupado não poderemos inserir mais dados nele.

 

Assim que a descrição de funcionalidade ficar pronta, vamos traduzi-la para uma linguagem que possa ser processada facilmente pelas ferramentas de verificação e implementação, que no nosso caso será VHDL.

 

Vamos iniciar com o bloco entrada paralelo e saída serial: 

 

A seguir vamos adicionar os sinas implícitos já comentados:

 

Para fazermos síncrono, vamos adicionar o relógio:

 

Para conversar com o resto do sistema, vamos adicionar o flag de ocupado:

 

Feita a interconexão, vamos transladar a funcionalidade do bloco. Lembrando, a cada ordem de escrita por o WR os dados colocados no DI são encaminhados para a porta serial na taxa de bits marcada por TICK. Enquanto o Tx está encaminhando dados, o BUSY ficará válido, com o valor lógico 1.

 

Para encaminharmos os dados, vamos carregá-los no registro data, carregar o número de bits no contador de bit e encaminhar bit a bit até o contador zerar.

 

Portanto, necessitaremos de um registro para os dados (data) e outro para contar os bits (bitCnt).

 

Mas o projeto tem que ser síncrono, tem que ter relógio e detecção da borda do relógio.

 

Para criarmos o sinal de estado, o bloco estaria ocupado até encaminharmos todos os bits. Dito de outra forma, o bloco estaria ocupado se o contador de bits for diferente de zero.

 

E finalmente vamos ligar o sinal de saída para o registro de dados, transmitindo o bit menos significativo primeiro, ligando para o bit 0 do registro.

 

Vamos montar os segmentos do código e adicionar as estruturas requeridas do VHDL a mais da biblioteca IEEE, os pacotes IEEE.STD_LOGIC_1164 e IEEE.NUMERIC_STD.

 

Vamos verificar o funcionamento.

 

fig2
Figura 2: Funcionamento

 

 

Aparentemente funcionaria, a cada escrita de dados o BUSY passa para valor lógico 1 iniciando o tráfego dos bits, finalizando o BUSY retorna para valor lógico 0 e o Tx espera até próximo WR. Porém olhando para as formas de onda em detalhe temos um problema.

 

O bit de início está errado. O banco de teste tenta simular um sistema real; a escrita de dados no bloco não está sincronizada com o marcador de taxa se saída (tick). Isso faz que o tempo do bit de início dependa da diferença da fase entre o sinal de escrita e o sinal de taxa de bit.

 

fig3
Figura 3: Funcionamento

 

 

A correção é simples, após a escrita temos que esperar até tick antes de encaminhar os dados. Vamos precisar mais um sinal para o flag de espera, sinc.

 

O código corrigido ficaria:

 

Simulando mais uma vez:

fig4
Figura 4: Simulação

 

 

O flag sinc fica em um desde a escrita no registro de dados até o primeiro tick a seguir da escrita. Isso atrasa o início do trafego no barramento série sincronizando os bits com o tick, conseguindo assim todos os bit da mesma duração.

 

A captura a seguir apresenta um dos eventos de sincronização, como esperado o evento inicia com a escrita no registro de dados e finaliza na chegada do primeiro TICK após da escrita.

 

fig5
Figura 5: Simulação

 

 

A seguir o código completo do transmissor da UART na versão funcional, para conseguir suportar 1 ou 2 bits de parada foi adicionado um parâmetro genérico k para alterar o número de bits encaminhados 10 ou 11.

 

A solução que adotamos para um problema está diretamente influenciada por nosso conhecimento e experiência. Nessa experiência as ferramentas que usarmos têm uma participação colateral, maquiavélica, as vezes não valorada, não apenas pelo que conseguimos fazer com elas mas como elas conseguem influenciar em nosso raciocinio.

 

Aplicando uma metodologia de projeto correta com ferramentas que reforcem nosso raciocinio, usando linguagens estritas por exemplo, fazemos projetos simples, robustos e eficientes no uso dos recursos.

 

Esse artigo é propriedade intelectual da Walter D. Gallegos, e pode ser utiilizado e publicado indicando o autor Walter Gallegos e o seguinte link: www.waltergallegos.com

 

NEWSLETTER

Receba os melhores conteúdos sobre sistemas eletrônicos embarcados, dicas, tutoriais e promoções.

Obrigado! Sua inscrição foi um sucesso.

Ops, algo deu errado. Por favor tente novamente.

1
Deixe um comentário

avatar
 
1 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
1 Comment authors
Juscilan Moreto Recent comment authors
  Notificações  
recentes antigos mais votados
Notificar
Juscilan Moreto
Visitante
Juscilan Moreto

"Se aprendermos a colocar parafusos com um martelo possivelmente não usaremos chaves de fenda" - (Embarcados) - Perfeita Colocação!