Por que os relógios são usados ​​em computadores?

Como eu sei, um relógio controla todas as operações lógicas, mas também limita a velocidade de um computador porque os portões precisam esperar o relógio mudar de baixo para alto ou alto para baixo, dependendo do componente. Se nenhum relógio fosse incorporado, os portões mudariam o mais rápido possível, sempre que recebessem o comando, por que isso não aumentaria a velocidade dos computadores e por que os relógios são usados?

Os relógios são usados ​​em computadores pela simples razão de que a maioria, senão toda a circuidade, é lógica sequencial síncrona .

Em um circuito síncrono, um oscilador eletrônico chamado relógio gera uma sequência de pulsos repetitivos chamados sinal de relógio, que é distribuído a todos os elementos de memória no circuito.

Agora, isso pode não parecer satisfatório e concedido, você perguntaria razoavelmente "por que os circuitos síncronos são usados ​​em computadores?" mas também é uma pergunta fácil de responder :

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.

Uma área ativa de pesquisa é a computação assíncrona, na qual a maioria, senão todo o circuito, é lógica sequencial assíncrona .

Imagine que você tenha um número inteiro de 8 bits enviado da memória para uma ALU para um cálculo e (pelo menos para este exemplo) que o circuito de memória fornece os sinais nas 8 linhas de dados antes que a ALU os exija e em momentos ligeiramente diferentes.

O uso de um relógio aqui garantiria que as 8 linhas de dados mantivessem o valor correto para o número inteiro representado por um ciclo de relógio e que a ALU "coletaria" esses dados dentro do mesmo ciclo de relógio.

Percebo que essa provavelmente não era a melhor descrição, essencialmente sem um relógio, garantindo que a consistência dos dados seria muito mais difícil do que qualquer possível aumento na velocidade valeria a pena; você enfrentaria muitos problemas de condição de corrida.

Um circuito como uma unidade lógica aritmética terá alguns números como entradas e produzirá um número como saída. Pode garantir que, dentro de um período de tempo, todos os bits da saída tenham atingido seus estados finais corretos, mas a quantidade real de tempo para a validação dos bits de saída poderá variar consideravelmente com base em vários fatores.

Seria possível construir uma ALU com uma entrada "válida" e uma saída "válida" e especificar que, desde que a entrada "válida" seja baixa por um período de tempo suficiente antes de uma computação ser realizada, e as entradas de dados contenham o valores desejados antes que a entrada "válida" seja alta, a saída "válida" não será alta até que os bits de saída estejam de fato corretos. Esse projeto provavelmente exigiria cerca de duas vezes mais circuitos que uma ULA convencional [basicamente teria que controlar se cada bit era "conhecido" como zero ou "conhecido" como um; sua saída "válida" se tornaria verdadeira assim que o estado de cada bit de saída fosse conhecido].

Para piorar as coisas, permitir que as partes de uma CPU capazes de rodar mais rapidamente o faça apenas será útil se não estiverem esperando o tempo todo que as peças mais lentas sejam atualizadas. Para que isso aconteça, deve haver lógica para decidir qual parte da máquina está "à frente" em um determinado momento e selecionar um curso de ação com base nisso. Infelizmente, esse tipo de decisão é uma das mais difíceis para os eletrônicos tomarem com segurança. Decidir com segurança qual dos dois eventos ocorreu primeiro é geralmente fácil apenas se for possível garantir que nunca haverá "fechamentos". Suponha que um seqüenciador de memória esteja manipulando uma solicitação da unidade de processamento nº 1 e a unidade nº 1 tenha outra solicitação pendente depois disso. Se a unidade nº 2 enviar uma solicitação antes da conclusão da primeira solicitação nº 1, a unidade de memória deve lidar com isso; caso contrário, ele deve atender à próxima solicitação da unidade nº 1. Parece um design razoável, mas acaba surpreendentemente problemático. O problema é que, se houver algum momento no tempo em que uma solicitação recebida antes desse momento seja processada imediatamente e uma solicitação recebida depois disso tenha que esperar, a quantidade de tempo necessária para determinar se uma solicitação ultrapassará o prazo final. aproximadamente inversamente proporcional à diferença entre a hora em que a solicitação foi recebida e o prazo. O tempo necessário para a unidade de memória determinar que uma solicitação do nº 2 ultrapassa o prazo de um femptossegundo pode exceder substancialmente a quantidade de tempo necessária para atender a uma segunda solicitação da unidade nº 1, mas a unidade não pode atender solicite até que decida qual atender primeiro.

Tendo tudo funcionando em um relógio comum, não apenas elimina a necessidade de o circuito determinar quando a saída de um cálculo é válida, mas também permite que as "chamadas fechadas" sejam eliminadas. Se tudo no sistema executar um relógio de 100Mhz, nenhum sinal será alterado em resposta a um relógio até 1ns após a borda do relógio e tudo o que acontecerá em resposta a uma borda do relógio ocorrerá dentro de 7ns, tudo o que acontecerá antes de um uma determinada borda do relógio "vencerá" em pelo menos 3ns e tudo o que não acontecerá até depois de uma borda do relógio "perderá" em pelo menos 1ns. Determinar se um sinal de chances antes ou depois do relógio, quando é garantido que não esteja "próximo", é muito mais fácil do que determinar qual dos dois sinais de tempo arbitrário ocorre primeiro.

Os sistemas digitais podem ser síncronos ou assíncronos . Em sistemas assíncronos, a saída pode mudar a qualquer momento, diferente dos sistemas síncronos, que dependem do relógio para alterar suas saídas.

A maioria dos sistemas digitais é síncrona (embora possa ter algumas partes assíncronas) porque o projeto e a análise de defeitos podem ser feitos com mais facilidade, pois as saídas podem mudar apenas com o relógio.

Eu praticamente copiei isso de Digital Systems: Principles and Applications, 10th edition by R. J. Tocci et al.

Bem, se você estiver projetando um sistema síncrono, possui uma taxa de clock alvo e projeta a lógica para concluir todos os cálculos durante um ciclo dentro de um período de clock. Isso também significa que você precisa incorporar uma margem de segurança para permitir várias condições, como baixa tensão de alimentação, alta temperatura e um chip "lento". Os chips síncronos são projetados para que o caminho lógico mais longo (cálculo mais lento) termine no tempo em todas essas condições adversas. Como resultado, quando as condições não são terríveis, você terá muito mais tempo / margem entre quando a lógica concluir sua operação e o próximo relógio trancar o resultado. Como você (geralmente) não pode alterar a frequência do relógio, você perde essa velocidade.

Não são completamente paradigmas lógicos assíncronos que existem, por exemplo, um que eu estou familiarizado com a lógica convenção NULL. Usando traços largos para descrever o que está acontecendo, o circuito lógico é capaz de identificar quando um cálculo é concluído e é capaz de criar efetivamente seus próprios sinais de "relógio". Isso permite que o circuito funcione o mais rápido possível e possui alguns benefícios modestos de energia e EMI. Infelizmente, você paga uma multa pela natureza assíncrona em termos de densidade do projeto e desempenho superior. Além disso, embora as ferramentas de software para design e validação síncrona estejam maduras, muito do design e validação para projetos assíncronos ainda são manuais, resultando em um maior esforço necessário para projetar e criar um design assíncrono.

Isso também negligencia completamente o fato de que, às vezes, você precisa de um relógio para que um aplicativo específico seja uma referência de tempo. Por exemplo, sua placa de som não pode operar de forma assíncrona porque precisa atualizar o ADC ou DAC a uma taxa de amostragem específica e precisa ou o áudio será distorcido.

Se nenhum relógio fosse incorporado, os portões mudariam o mais rápido possível, sempre que recebessem o comando, por que isso não aumentaria a velocidade dos computadores e por que os relógios são usados?

Simplificando: porque os humanos não são seres superinteligentes e precisam tomar atalhos para tornar possível o projeto de circuitos de bilhões de elementos.

Quando os overlords de nossas máquinas sobem, eles podem muito bem se livrar do relógio, superar minúcias incertas, como tornar um circuito sem relógio fabricável, apesar da variação do processo, e tirar proveito de alguns ganhos de velocidade.

Para expandir um pouco: coisas discretas e previsíveis são mais fáceis de analisar e projetar racionalmente. Como um grande benefício adicional, eles se auto-corrigem (neste caso, o tempo se auto-corrige). Esta é a razão pela qual usamos a lógica digital em primeiro lugar. (Da mesma forma, na programação, geralmente usamos números inteiros em vez de ponto flutuante, estruturas de controle familiares em vez de goto-spaghetti e linguagens com algumas regras claras em vez de linguagens muito "flexíveis", onde você nunca sabe ao certo o que acontecerá até que o código seja executado.)