Почему часы используются в компьютерах?

Часы используются в компьютерах по той простой причине, что большая часть, если не вся схема представляет собой синхронную последовательную логику .

В синхронной схеме электронный генератор, называемый тактовым генератором, генерирует последовательность повторяющихся импульсов, называемых тактовым сигналом, который распределяется по всем элементам памяти в схеме.

Теперь, когда это может показаться неудовлетворительным и само собой разумеющимся, вы могли бы разумно спросить: «Почему синхронные схемы используются в компьютерах?» но на этот вопрос тоже легко ответить :

Основным преимуществом синхронной логики является ее простота. Логическим элементам, которые выполняют операции с данными, требуется конечное количество времени, чтобы отреагировать на изменения на их входах. Это называется задержкой распространения. Интервал между тактовыми импульсами должен быть достаточно длинным, чтобы все логические элементы успели отреагировать на изменения и их выходы «установились» на стабильные логические значения до того, как произойдет следующий тактовый импульс. Пока это условие соблюдается (без учета некоторых других деталей), схема гарантированно будет стабильной и надежной. Это определяет максимальную рабочую скорость синхронной цепи.

Активной областью исследований являются асинхронные вычисления, где большая часть, если не вся схема представляет собой асинхронную последовательную логику .

Схема, подобная арифметико-логическому устройству, принимает пару чисел на вход и выдает число на выходе. Это может гарантировать, что в течение некоторого периода времени все биты вывода достигнут своих правильных конечных состояний, но фактическое количество времени, в течение которого выходные биты становятся действительными, может значительно различаться в зависимости от множества факторов.

Можно построить АЛУ с «действительными» входными данными и «действительными» выходными данными и указать, что при условии, что «действительные» входные данные являются низкими в течение достаточного времени до выполнения вычисления, а входные данные содержат желаемые значения до того, как «действительный» вход станет высоким, «действительный» выход не станет высоким, пока выходные биты не станут действительно правильными. Такая конструкция, вероятно, потребует примерно в два раза больше схем, чем обычное АЛУ [в основном ему придется отслеживать, является ли каждый бит «известным» равным нулю или «известным» равным единице; его «действительный» вывод станет истинным, как только станет известно состояние каждого выходного бита].

Что еще хуже, разрешение тем частям процессора, которые могли бы работать быстрее, делать это будет полезно только в том случае, если они не ждут все время, пока более медленные части не наверстают упущенное. Чтобы это произошло, должна быть логика, чтобы решить, какая часть машины находится «впереди» в данный момент времени, и выбрать курс действий на основе этого. К сожалению, такое решение является одним из самых сложных для надежного принятия электроникой. Надежно решить, какое из двух событий произошло первым, как правило, легко, только если можно гарантировать, что никогда не будет никаких «близких вызовов». Предположим, секвенсор памяти обрабатывает запрос от блока обработки №1, а после этого блок №1 ожидает еще один запрос. Если блок № 2 отправляет запрос до того, как первый запрос от № 1 будет завершен, блок памяти должен обработать это; в противном случае он должен обработать следующий запрос от модуля №1. Казалось бы, разумный дизайн, но в итоге он оказывается на удивление проблематичным. Проблема заключается в том, что если есть некоторый момент времени, когда запрос, полученный до этого момента, будет обработан немедленно, а запрос, полученный после этого, должен будет подождать, количество времени, необходимое для определения того, превысит ли запрос крайний срок, будет примерно обратно пропорциональна разнице между временем получения запроса и крайним сроком. Время, необходимое блоку памяти для определения того, что запрос от #2 опережает крайний срок на одну фемптосекунду, может существенно превышать количество времени, которое потребовалось бы для обслуживания второго запроса от блока #1, но блок не может обслужить любой запрос, пока он не решит, какой из них обслуживать в первую очередь.

Если все работает от общих часов, это не только устраняет необходимость в том, чтобы схема определяла, когда результат вычисления действителен, но также позволяет исключить временные «закрытые вызовы». Если все в системе работает на тактовой частоте 100 МГц, сигнал не изменяется в ответ на тактовый сигнал до 1 нс после фронта тактового сигнала, и все, что должно произойти в ответ на фронт тактового сигнала, происходит в течение 7 нс, тогда все, что должно произойти до конкретный фронт тактовых импульсов будет «выигрывать» как минимум на 3 нс, и все, что не произойдет до тех пор, пока после фронта тактовых импульсов «проиграет» как минимум на 1 нс. Определить, случается ли сигнал до или после такта, когда он гарантированно не будет «близким», намного проще, чем определить, какой из двух сигналов с произвольной синхронизацией происходит первым.

Представьте, что у вас есть 8-битное целое число, отправляемое из памяти в АЛУ для вычисления, и (по крайней мере, для этого примера) схема памяти предоставляет сигналы на 8 линиях данных до того, как они потребуются АЛУ, и в немного другое время.

Использование часов здесь гарантирует, что 8 строк данных содержат правильное значение целого числа, представляемого в течение одного тактового цикла, и что АЛУ будет «собирать» эти данные в течение одного тактового цикла.

Я понимаю, что это, вероятно, было не лучшим описанием, по сути, без часов обеспечение согласованности данных было бы намного сложнее, чем любое возможное увеличение скорости, вы бы столкнулись со многими проблемами состояния гонки.

Цифровые системы могут быть как синхронными , так и асинхронными . В асинхронных системах выходные данные могут измениться в любой момент, в отличие от синхронных систем, которые зависят от часов для изменения своих выходных данных.

Большинство цифровых систем являются синхронными (даже если они могут иметь некоторые асинхронные части), потому что проект и анализ дефектов могут быть выполнены с большей легкостью, поскольку выходные данные могут изменяться только по часам.

Я в значительной степени скопировал это изDigital Systems: Principles and Applications, 10th edition by R. J. Tocci et al.

Ну, если вы проектируете синхронную систему, у вас есть целевая тактовая частота, и вы разрабатываете логику для выполнения всех вычислений в течение цикла в течение одного тактового периода. Это также означает, что вам необходимо предусмотреть запас прочности для различных условий, таких как низкое напряжение питания, высокая температура и «медленный» чип. Синхронные микросхемы разработаны таким образом, что самый длинный логический путь (самый медленный расчет) завершается вовремя при всех этих неблагоприятных условиях. В результате, когда условия не ужасны, у вас будет намного больше времени/зазора между тем, когда логика завершит свою работу, и следующие часы зафиксируют результат. Поскольку вы (обычно) не можете изменить свою тактовую частоту, вы теряете эту скорость.

Существуют полностью асинхронные логические парадигмы, например, та, с которой я знаком, представляет собой логику соглашения NULL. Используя общие штрихи для описания того, что происходит, логическая схема может определить, когда расчет завершен, и способна эффективно создавать свои собственные «тактовые» сигналы. Это позволяет схеме работать настолько быстро, насколько это возможно, и имеет скромные преимущества по мощности и электромагнитным помехам. К сожалению, вы платите штраф за асинхронный характер с точки зрения плотности проектирования, а также максимальной производительности. Кроме того, несмотря на то, что программные инструменты для синхронного проектирования и проверки являются зрелыми, значительная часть проектирования и проверки асинхронных проектов по-прежнему выполняется вручную, что требует больших усилий для проектирования и создания асинхронного проекта.

Это также полностью игнорирует случай, когда иногда вам нужны часы для определенного приложения, чтобы быть эталоном времени. Например, ваша звуковая карта не может работать асинхронно, поскольку ей необходимо обновлять АЦП или ЦАП с определенной точной частотой дискретизации, иначе звук будет искажен.

Если бы не было встроенных часов, ворота изменялись бы так быстро, как только могли, когда бы им ни была дана команда, так почему бы это не увеличить скорость компьютеров и почему используются часы?

Проще говоря: потому что люди не являются сверхразумными существами, и им приходится идти короткими путями, чтобы сделать возможным проектирование схем из миллиардов элементов.

Когда наши машинные повелители возвысятся, они вполне могут избавиться от часов, преодолеть мелкие мелочи, такие как создание технологичной схемы без часов, несмотря на изменение процесса, и воспользоваться некоторым приростом скорости.

Немного расширим: дискретные, предсказуемые вещи легче рационально анализировать и проектировать. В качестве огромного дополнительного преимущества они самокорректируются (в данном случае синхронизация самокорректируется). Именно по этой причине мы в первую очередь используем цифровую логику. (Аналогично, в программировании мы часто используем целые числа вместо чисел с плавающей запятой, привычные управляющие структуры вместо goto-spaghetti и языки с несколькими четкими правилами вместо очень «гибких» языков, где никогда не знаешь, что произойдет. пока не запустится код)