Por que os microcontroladores precisam de um relógio

Por que as instruções precisam ser processadas em intervalos de tempo definidos (ou seja, com o uso de um relógio)? Eles não podem ser executados sequencialmente - imediatamente após a conclusão da instrução anterior?

Uma analogia para a necessidade de relógios em microcontroladores seria particularmente útil.

Um ou dois exemplos ilustrativos podem ajudar aqui. Dê uma olhada no seguinte circuito hipotético:

^{simular este circuito - esquemático criado usando o CircuitLab}

Suponha que o início de A e B seja alto (1). A saída do AND é, portanto, 1 e, como as duas entradas para o XOR são 1, a saída é 0.

Os elementos lógicos não mudam de estado instantaneamente - há um atraso de propagação pequeno, mas significativo, à medida que a alteração na entrada é tratada. Suponha que B fique baixo (0). O XOR vê o novo estado em sua segunda entrada instantaneamente, mas a primeira entrada ainda vê o 'obsoleto' 1 da porta AND. Como resultado, a saída aumenta brevemente - mas apenas até o sinal se propagar através da porta AND, tornando as duas entradas para o XOR baixas e fazendo com que a saída diminua novamente.

A falha não é uma parte desejada da operação do circuito, mas falhas como essa acontecerão sempre que houver uma diferença na velocidade de propagação através de diferentes partes do circuito, devido à quantidade de lógica ou mesmo apenas ao comprimento dos fios. .

Uma maneira realmente fácil de lidar com isso é colocar um flip-flop acionado por borda na saída de sua lógica combinatória, desta forma:

^{simule este circuito}

Agora, quaisquer falhas que ocorram são ocultas do resto do circuito pelo flip-flop, que somente atualiza seu estado quando o relógio passa de 0 a 1. Desde que o intervalo entre as bordas crescentes do relógio seja longo o suficiente para que os sinais se propaguem. No caminho através das cadeias lógicas combinatórias, os resultados serão determinísticos e isentos de falhas.

Sinto que muitas dessas respostas não estão exatamente acertando a questão central. O microcontrolador possui um relógio simplesmente porque executa (e é impulsionado por) lógica seqüencial .

Na teoria dos circuitos digitais, a lógica seqüencial é um tipo de circuito lógico cuja saída depende não apenas do valor presente de seus sinais de entrada, mas também da sequência de entradas passadas, o histórico de entradas. Isso contrasta com a lógica combinacional, cuja saída é uma função apenas da entrada atual. Ou seja, a lógica sequencial tem estado (memória) enquanto a lógica combinacional não. Ou, em outras palavras, a lógica seqüencial é lógica combinacional com memória.

Também:

A principal vantagem da lógica síncrona é sua simplicidade. As portas lógicas que executam as operações nos dados requerem uma quantidade finita de tempo para responder às alterações em suas entradas. Isso é chamado atraso de propagação. O intervalo entre os pulsos do relógio deve ser longo o suficiente para que todos os portões lógicos tenham tempo para responder às mudanças e suas saídas "se ajustem" a valores lógicos estáveis, antes que ocorra o próximo pulso do relógio. Desde que essa condição seja atendida (ignorando outros detalhes), é garantido que o circuito seja estável e confiável. Isso determina a velocidade máxima de operação de um circuito síncrono.

Resposta curta: os gerentes desejam uma PROVA de função simples e testável antes de comprometer milhões (ou mais) com um projeto. As ferramentas atuais, simplesmente não fornecem respostas assíncronas aos designs.

Microcomputadores e microcontroladores normalmente utilizam um esquema de relógio para garantir o controle de tempo. Todos os cantos do processo precisam manter o tempo em todos os efeitos de tensão, temperatura, processo, etc. nas velocidades de propagação do sinal. Não há portas lógicas de corrente que mudam instantaneamente: cada porta muda de acordo com a tensão fornecida, a unidade que recebe, a carga que dirige e o tamanho dos dispositivos usados ​​para fazê-la (e, é claro, o nó do processo (tamanho do dispositivo) em que é fabricado e com que rapidez esse processo está realmente realizando --- ISSO passa pela fábrica). Para obter a comutação "instantânea", você teria que usar a lógica quântica, e isso pressupõe que os dispositivos quânticos possam mudar instantaneamente; (Não tenho certeza).

A lógica cronometrada faz PROVING que o tempo em todo o processador funcione nas variáveis ​​esperadas de tensão, temperatura e processamento. Existem muitas ferramentas de software disponíveis que ajudam a medir esse tempo, e o processo líquido é chamado de "fechamento de tempo". Overclock pode (e, na minha experiência, não ) tomar em algum lugar entre 1/3 a 1/2 da energia usada em um microprocessador.

Então, por que não design assíncrono? Existem poucas, se houver, ferramentas de fechamento de tempo para suportar esse estilo de design. Existem poucas, se houver, ferramentas automatizadas de local e rota que podem lidar e gerenciar um grande design assíncrono. Se nada mais, os gerentes NÃO aprovam nada que não tenha uma PROVA de funcionalidade direta e gerada por computador.

O comentário de que o design assíncrono requer "uma tonelada de" sinais de sincronização, que requeriam "muito mais transistores", ignora os custos de roteamento e sincronização de um relógio global e o custo de todos os chinelos que o sistema de clock exige. Os projetos assíncronos são (ou deveriam ser) menores e mais rápidos do que seus equivalentes com clock. (Um simplesmente pega o caminho de sinal mais lento do ONE e o usa para alimentar um sinal de "pronto" para a lógica anterior).

A lógica assíncrona é mais rápida, porque nunca precisa esperar por um relógio que precisava ser estendido para outro bloco em outro lugar. Isso é especialmente verdadeiro nas funções de registro em lógica para registro. A lógica assíncrona não possui vários problemas de "configuração" e "retenção", pois apenas as estruturas de coletor final (registradores) têm esses problemas, em oposição a um conjunto de lógica em pipeline com flip-flops intercalados para espaçar os atrasos de propagação lógica no relógio limites.

Isso pode ser feito? Certamente, mesmo em um bilhão de transistores. É mais difícil? Sim, mas apenas porque provar que ele funciona em um chip inteiro (ou mesmo no sistema) está muito mais envolvido. Obter o tempo no papel é razoavelmente direto para qualquer bloco ou subsistema. Controlar esse tempo em um sistema automatizado de local e rota é muito mais difícil, porque as ferramentas NÃO são configuradas para lidar com um conjunto potencial muito maior de restrições de tempo.

Os microcontroladores também têm um conjunto potencialmente grande de outros blocos que fazem interface com sinais externos (relativamente) lentos, adicionados a toda a complexidade de um microprocessador. Isso torna o tempo um pouco mais envolvido, mas não muito.

Conseguir um mecanismo de sinal de "bloqueio" do "primeiro a chegar" é um problema de projeto de circuito e existem maneiras conhecidas de lidar com isso. As condições da corrida são um sinal de 1). má prática de projeto; ou 2). sinais externos entrando no processador. O relógio realmente introduz uma condição de corrida sinal-contra-relógio, que está relacionada às violações de "configuração" e "espera".

Eu, pessoalmente, não entendo como um design assíncrono pode entrar em um estado parado ou em qualquer outra condição de corrida. Essa pode ser a minha limitação, mas, a menos que isso aconteça na entrada de dados no processador, NUNCA deve ser possível em um sistema lógico bem projetado e, mesmo assim, como pode ocorrer à medida que os sinais entram, você planeja lidar com isso.

(Eu espero que isso ajude).

Tudo isso dito, se você tiver o dinheiro ...

Os microcontroladores precisam usar um relógio porque precisam ser capazes de responder a eventos que podem ocorrer a qualquer momento, inclusive quase simultaneamente com outros eventos externos ou gerados pelos próprios controladores, e geralmente têm vários circuitos que precisam saber se um evento X precede outro evento Y. Pode não interessar se todos esses circuitos decidem que X precedeu Y, ou todos esses circuitos decidem que X não precede Y, mas geralmente será crítico que, se algum dos circuitos decidir que X precedeu Sim, todos devem fazê-lo. Infelizmente, é difícil garantir que os circuitos cheguem a um consenso garantido quanto a X preceder Y ou mesmo a um consenso sobre se chegaram ou não a um consenso. A lógica síncrona pode ajudar enormemente com isso.

A adição de um relógio a um circuito torna possível garantir que um subsistema não sofra condições de corrida, a menos que uma entrada para o sistema seja alterada em uma janela muito pequena em relação ao relógio e também garantir que a saída de um dispositivo seja alimentada em outro , a saída do primeiro dispositivo não será alterada na janela crítica do segundo dispositivo, a menos que a entrada do primeiro dispositivo seja alterada dentro de uma janela crítica ainda menor. A adição de outro dispositivo antes desse primeiro dispositivo garantirá que a entrada para o primeiro dispositivo não seja alterada nessa pequena janela, a menos que a entrada para o novo dispositivo seja alterada dentro de uma janela realmente muito pequena. De uma perspectiva prática, a menos que se tente deliberadamente causar uma falha de consenso,

Certamente é possível projetar sistemas totalmente assíncronos que executam "o mais rápido possível", mas, a menos que um sistema seja extremamente simples, será difícil evitar que um projeto seja atropelado por uma condição de corrida. Embora existam maneiras de resolver as condições da corrida sem a necessidade de relógios, as condições da corrida podem ser resolvidas com muito mais rapidez e facilidade usando relógios do que seria o caso sem eles. Embora a lógica assíncrona frequentemente consiga resolver as condições de corrida mais rapidamente do que a lógica cronometrada, as ocasiões em que não pode fazê-lo representam um grande problema, especialmente devido à dificuldade de fazer com que partes de um sistema cheguem a um consenso sobre se chegaram ou não a um consenso.. Um sistema que possa executar consistentemente um milhão de instruções por seção geralmente será mais útil do que um que às vezes pode executar quatro milhões de instruções por segundo, mas pode ficar parado por milésimos de segundo (ou mais) por vez, devido às condições da corrida.

As MCUs são apenas um exemplo muito complexo de um circuito lógico sequencial síncrono. A forma mais simples é provavelmente o D-flip-flop com clock (D-FF), ou seja, um elemento de memória síncrona de 1 bit.

Existem elementos de memória que são assíncronos, por exemplo, a trava D, que é (de certa forma) o equivalente assíncrono do D-FF. Um MCU nada mais é do que um monte de milhões de elementos básicos de memória (D-FF) colados com toneladas de portas lógicas (eu estou simplificando demais).

Agora vamos ao que interessa: por que os MCUs usam D-FFs em vez de trincos D como elementos de memória internamente? É essencialmente para confiabilidade e facilidade de design: as travas D reagem assim que as entradas mudam e as saídas são atualizadas o mais rápido possível. Isso permite interações indesejadas desagradáveis ​​entre diferentes partes de um circuito lógico (loops e raças de feedback não intencionais). Projetar um circuito seqüencial complexo usando blocos de construção assíncronos é inerentemente mais difícil e propenso a erros. Os circuitos síncronos evitam essas armadilhas restringindo a operação dos blocos de construção aos instantes de tempo em que as bordas do relógio são detectadas. Quando a borda chega, um circuito lógico síncrono adquire os dados em suas entradas, mas ainda não atualiza suas saídas. Assim que as entradas são adquiridas, as saídas são atualizadas. Isso evita o risco de que um sinal de saída seja retornado a uma entrada que não tenha sido completamente adquirida e estrague tudo (dito simplesmente).

Essa estratégia de "dissociar" a aquisição de dados de entrada da atualização de saídas permite técnicas de design mais simples, que se traduzem em sistemas mais complexos para um determinado esforço de design.

O que você está descrevendo é chamado de lógica assíncrona . Ele pode funcionar e, quando o faz, geralmente é mais rápido e usa menos energia do que a lógica síncrona (com clock). Infelizmente, a lógica assíncrona tem alguns problemas que impedem que ela seja amplamente usada. O principal que vejo é que são necessários muito mais transistores para implementar, pois você precisa de uma tonelada de sinais de sincronização independentes. (Os microcontroladores trabalham muito em paralelo, assim como as CPUs.) Isso aumentará os custos. A falta de boas ferramentas de design é um grande obstáculo inicial.

Os microcontroladores provavelmente sempre precisarão de relógios, pois seus periféricos geralmente precisam medir o tempo. Temporizadores e PWMs funcionam em intervalos de tempo fixos, as taxas de amostragem ADC afetam sua largura de banda e protocolos de comunicação assíncronos como CAN e USB precisam de relógios de referência para recuperação do relógio. Normalmente, queremos que as CPUs funcionem o mais rápido possível, mas esse nem sempre é o caso de outros sistemas digitais.

Na verdade, você está vendo o MCU como uma unidade completa, mas a verdade é que ele é feito de portas diferentes e lógicas TTL e RTL, geralmente matriz FF, todos precisam do sinal do relógio individualmente.

Para ser mais específico, pense em simplesmente acessar um endereço a partir da memória, essa tarefa simples pode envolver várias operações, como disponibilizar o BUS para as linhas de dados e as linhas de endereço.
A melhor maneira de dizer é, a instrução si ocorrem em pequenas unidades de operação que requerem ciclos de relógio, estes combinados para ciclos de máquina , que representam várias propriedades MCU como velocidade (FLOPS ** em complicado MCU), tubo de revestimento etc.

Response to Comentário do OP

Para ser mais preciso, dou um exemplo: existe um chip chamado ALE(Ativação da trava de endereço) geralmente com o objetivo de multiplexar o barramento de endereço inferior para transmitir endereço e dados nos mesmos pinos, usamos osciladores (o intel 8051 usa oscilador local de 11.059MHz como relógio) para buscar o endereço e os dados.

Como você deve saber que partes básicas do MCU são CPU, ALU e registro interno e assim por diante, a CPU (controlando s / g) envia o endereço para todos os pinos de endereço 16 no caso de 8051, isso ocorre no momento instantâneo T1 e depois o endereço é a matriz correspondente de armazenamento do capacitor (carga como sinal) ( * mapeamento de memória * ) é ativado e selecionado.

Após a seleção, o sinal ALE é ativado, ou seja, o pino ALE é aumentado no próximo relógio, digamos T2 ( geralmente um sinal Alto, mas muda conforme o design da unidade de processamento ); depois disso, os barramentos de endereço inferior agem como linhas de dados e os dados são gravados ou lidos. (dependendo da saída no pino RD / WR do MCU).
Você pode ver claramente que todos os eventos são seqüenciais oportunos

O que aconteceria se não usarmos o clock Então teremos que usar o método de sincronização assíncrona ASQC, que tornaria cada porta dependente da outra e pode resultar em falhas de hardware. hora de concluir a tarefa.
Então é algo indesejável

O problema fundamental que um relógio resolve é que os transistores não são realmente dispositivos digitais: eles usam níveis de tensão analógicos nas entradas para determinar a saída e levam um tempo finito para mudar de estado. A menos que, como mencionado em outra resposta, você entre em dispositivos quânticos, haverá um período de tempo em que a entrada fará a transição de um estado para outro. O tempo que isso leva é afetado pelo carregamento capacitivo, que será diferente de um dispositivo para o outro. Isso significa que os diferentes tranisistores que compõem cada porta lógica responderão em momentos ligeiramente diferentes. O relógio é usado para 'travar' as saídas dos dispositivos componentes, depois que todos estiverem estabilizados.

Como analogia, considere a camada de transporte de comunicações SPI (Serial Peripheral Interface). Uma implementação típica disso usará três linhas: Entrada de dados, Saída de dados e Relógio. Para enviar um byte sobre essa camada de transporte, o mestre definirá sua linha de saída de dados e afirmará a linha do relógio para indicar que a linha de saída de dados tem um valor válido. O dispositivo escravo irá amostrar sua linha Data In somente quando instruído a fazê-lo pelo sinal do relógio. Se não houvesse sinal de relógio, como o escravo saberia quando amostrar a linha Data In? Ele poderia amostrá-lo antes que a linha fosse definida pelo mestre ou durante a transição entre estados. Protocolos assíncronos, como CAN, RS485, RS422, RS232, etc. resolvem isso usando um tempo de amostragem predefinido, taxa de bits fixa e bits de enquadramento (aéreos).

Em outras palavras, é necessário algum tipo de conhecimento comum para determinar quando todos os transistores em um conjunto de portas atingiram seu estado final e a instrução está concluída. No quebra-cabeça (100 olhos azuis) indicado no link acima e explicado com alguns detalhes nesta pergunta no Maths Stack Exchange, o 'oráculo' atua como o relógio para as pessoas na ilha.