Um design de FPGA pode ser principalmente (ou completamente) assíncrono?

Tivemos um curso FPGA / Verilog muito curto na universidade (há 5 anos) e sempre usamos relógios em todos os lugares.

Agora estou começando com FPGAs novamente como um hobby, e não posso deixar de me perguntar sobre esses relógios. Eles são absolutamente necessários ou um projeto baseado em FPGA pode ser completamente assíncrono? Pode-se construir um monte complexo de lógica e fazer com que as coisas se espalhem o mais rápido possível?

Percebo que há muitas dicas com isso, como saber quando o sinal se propagou por todas as partes do circuito e a saída se estabilizou. Isso não vem ao caso. Não é que eu queira realmente criar um design totalmente assíncrono, mas apenas para melhorar minha compreensão dos recursos.

Para meus olhos iniciantes, parece que a única construção que exige absolutamente um relógio é a reg, e meu entendimento é que um FPGA típico (por exemplo, um Cyclone II) terá seus chinelos pré-conectados a sinais específicos de relógio. Isso está correto? Existem outros relógios implícitos como este e eles geralmente podem ser acionados manualmente pelo design?

Uma resposta curta seria: sim; uma resposta mais longa seria: não vale o seu tempo.

Um FPGA em si pode executar um design completamente assíncrono sem problemas. O resultado é o problema, já que o tempo em qualquer FPGA não é muito previsível. O maior problema é o fato de que o tempo e o design resultante variam quase que definitivamente entre as diferentes sessões de local e rota. Você pode restringir os caminhos assíncronos individuais, certificando-se de que eles não demorem muito, mas não tenho certeza de que você possa especificar um atraso mínimo.

No final, isso significa que seu design será imprevisível e potencialmente completamente variável, mesmo com uma ligeira alteração no design. Você precisaria examinar todo o relatório de tempo toda vez que alterar alguma coisa, apenas para garantir que ainda funcione. Por outro lado, se o design for síncrono, basta procurar uma aprovação ou falha no final do local e da rota (assumindo que suas restrições estão configuradas corretamente, o que não leva muito tempo).

Na prática, as pessoas buscam projetos completamente síncronos, mas se você precisar simplesmente amortecer ou inverter um sinal, não precisará passar por um flip-flop desde que o restrinja adequadamente.

Espero que isso esclareça um pouco.

"Pode-se construir um monte complexo de lógica e fazer com que as coisas o percorram o mais rápido possível?" Sim. CPUs inteiras foram construídas completamente assíncronas - pelo menos uma delas foi a CPU mais rápida do mundo. http://en.wikipedia.org/wiki/Asynchronous_circuit#Asynchronous_CPU

Me incomoda que as pessoas rejeitem as técnicas de design assíncronas, embora teoricamente tenham várias vantagens sobre as técnicas de design síncrono, apenas porque (como outros aqui disseram) os projetos assíncronos não são tão bem suportados pelas ferramentas disponíveis.

Para mim, é como recomendar que todas as pontes sejam feitas de madeira, porque mais pessoas têm ferramentas para trabalhar madeira do que ferramentas para trabalhar aço.

Felizmente, algumas das vantagens do design assíncrono podem ser obtidas enquanto ainda se utiliza principalmente técnicas de design síncrono, usando um design global síncrono local assíncrono (GALS) .

Um fator ainda não mencionado é a metaestabilidade. Se um circuito de trava for atingido com uma sequência de entradas / transições, de modo que o estado resultante dependa de atrasos de propagação ou outros fatores imprevisíveis, não há garantia de que o estado resultante seja limpo "alto" ou "baixo". Considere, por exemplo, um flip-flop acionado por uma borda que está atualmente emitindo um "baixo" e cuja entrada é alterada de baixa para alta quase ao mesmo tempo em que a borda do relógio chega. Se a borda do relógio ocorrer o tempo suficiente antes da alteração da entrada, a saída simplesmente ficará baixa até a próxima borda do relógio. Se a borda do relógio ocorrer o tempo suficiente após a alteração da entrada, a saída mudará rapidamente uma vez de baixa para alta e permanecerá até a próxima borda do relógio. Se nenhuma dessas condições se aplicar,. Pode permanecer baixo ou alternar rapidamente uma vez e permanecer alto, mas pode permanecer baixo por algum tempo e depois alternar ou alternar e, depois de algum tempo, voltar ou alternar algumas vezes, etc.

Se um projeto é totalmente síncrono e todas as entradas são sincronizadas duas vezes, é muito improvável que um pulso de tempo atinja a primeira trava de um sincronizador de forma a fazer com que ele alterne no momento perfeito para confundir o segundo robusto. Em geral, é seguro considerar coisas como "simplesmente não acontecerá". Em um design assíncrono, no entanto, muitas vezes é muito mais difícil argumentar sobre essas coisas. Se uma restrição de tempo em um circuito de trava (não apenas chinelos, mas qualquer combinação de lógica que funcionaria como trava) for violada, não há como dizer o que a saída fará até a próxima vez que houver uma condição de entrada válida que force a trava para um estado conhecido. É perfeitamente possível que saídas atrasadas causem violações das restrições de tempo das entradas a jusante, levando a situações inesperadas,

A maneira mais segura de modelar um circuito assíncrono seria fazer com que quase todos os circuitos de saída produzam uma saída "X" por um tempo sempre que alternar entre "0" e "1". Infelizmente, essa abordagem geralmente resulta em quase todos os nós exibindo "X", mesmo em casos que, na realidade, quase certamente resultariam em comportamento estável. Se um sistema puder funcionar quando simulado, com todas as saídas se tornarem "X" imediatamente após uma entrada mudar, e permanecer "X" até que as entradas estejam estáveis, é um bom sinal de que o circuito funcionará, mas fazendo com que os circuitos assíncronos funcionem sob essas restrições. é frequentemente difícil.

Obviamente, se seus requisitos de design são lentos o suficiente para que muitos atrasos internos ainda sejam ordens de magnitude maiores que os tempos com que você se importa, isso não é um problema, e você pode olhar o relatório de cronograma para ficar de olho nisso, mas há um limite para o que você pode fazer de maneira útil sem informações internas sobre o estado. Se você quiser fazer algo como um multiplexador de 100 entradas, então lembre-se de que cada entrada terá um atraso de propagação diferente. De fato, você pode obter alguns efeitos interessantes e caóticos com um grande número de loops de feedback oscilantes com atraso imprevisível - talvez um sintetizador totalmente assíncrono baseado em FPGA possa ser o próximo 'analógico' ..

Sim você pode. Você pode ignorar os flip-flops completamente e criar tudo com LUTs. E / ou você pode usar os elementos de estado da maioria dos FPGAs Xilinx como travas (acionadas por nível) em vez de flip-flops (acionados por borda).

Como @Andrey apontou, não vale o seu tempo. Especificamente, as ferramentas não fazem isso, então você estará completamente sozinho. Além disso, como eles têm registros embutidos, você não salvaria nada se não os usasse.

Realmente existem três tipos de projetos.

1. Combinatória. Não há relógios nem caminhos de feedback e o sistema não tem "memória". Quando uma ou mais entradas são alteradas, as alterações se propagam pela lógica. Após algum tempo, a saída entra em um novo estado, onde permanece até que as entradas mudem novamente.
2. Sequencial síncrono. Um sistema é construído a partir de registradores e blocos de lógica combinatória; os registradores são cronometrados por um pequeno número (geralmente 1) de relógios. Se houver vários relógios, podem ser necessárias precuações especiais nos sinais que passam de um domínio do relógio para outro.
3. Sequencial assíncrono. Existem caminhos de feedback, travas, registros ou outros elementos que fornecem a memória de design de eventos passados ​​e que não são monitorados por linhas de relógio analisadas facilmente.

Em geral, ao sintetizar / otimizar a lógica combinatória, as ferramentas assumem que tudo o que importa é qual é o resultado final e o tempo máximo necessário para resolver esse resultado.

Você pode criar um design puramente combinatório e que obtenha o resultado certo. As saídas podem mudar em qualquer ordem e várias vezes antes de atingir seus valores finais. Tais projetos desperdiçam muito recursos lógicos. A maioria dos elementos lógicos passa a maior parte do tempo ociosa, enquanto em um sistema seqüencial você pode ter reutilizado esses elementos para processar vários itens de dados.

Em um sistema síncrono seqüencial, tudo o que importa é que as saídas do bloco combinatório tenham se estabelecido em seu estado correto quando são registradas no próximo flip-flop. Não importa em que ordem eles mudam ou se são falhas ao longo do caminho. Novamente, as ferramentas podem facilmente transformar isso em lógica, desde que o relógio seja lento o suficiente para dar a resposta certa (e eles podem dizer se o relógio que você deseja usar é lento o suficiente).

Em um sistema seqüencial assíncrono, essas suposições desaparecem da janela. Falhas podem importar, a ordem das alterações na saída pode importar. As ferramentas e os próprios FPGAs foram projetados para projetos síncronos. Houve muita discussão (design de FPGA assíncrono no Google, se você quiser saber mais) sobre a possibilidade de implementar sistemas assíncronos em FPGAs padrão ou em projetos especialmente projetados, mas ele ainda está fora da prática de design aceita pelo mainstream

Sim. Se você não possui construções de tipo de processo, não deve fazer coisas como deduzir registros. Haverá coisas como memória interna que requerem relógios, embora, se você realmente quiser, provavelmente possa gerá-las de forma assíncrona.

FWIW, pensei em acrescentar que um objetivo óbvio em soluções lógicas assíncronas seria a redução global no consumo de energia.

Esses buffers de clock / PLL / global queimam muitos Joules.

À medida que as soluções FPGA penetram nas arenas alimentadas por bateria (por exemplo, Lattice Icestick), esse aspecto ganha muito mais atenção.