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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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