Конвейерные сумматоры

Среди традиционных многоразрядных параллельных сумматоров, построенных на основе одноразрядных комбинационных сумматоров, наиболее простым и наименее быстродействующим является сумматор с последовательным переносом, в котором значение старшего разряда выхода одноразрядного сумматора (выход М) подается на один из входов следующего одноразрядного сумматора. Время для сложения двух N-разрядных чисел, грубо говоря, в N раз превышает время работы одного одноразрядного сумматора, поскольку перенос от младшего разряда числа последовательно проходит через одноразрядные сумматоры к старшему разряду. Более быстродействующие схемы требуют добавления схем с опережающим оперированием с переносами, но и для таких сумматоров время сложения не меньше времени, пропорционального log2 N. Для сравнения на рис. 2.26, в показан конвейерный сумматор с последовательным переносом, который может складывать числа по одному за период синхронизации, независимо от числа разрядов N. Каждое сложение, разумеется, по-прежнему требует N синхроимпульсов, но как только содержимое каждого разряда вычислено, связанные с ним устройства освобождаются для использования их следующим набором чисел. Точно так же ни один их одноразрядных сумматоров не начинает работу до тех пор, пока не готовы данные для всех входов. Дополнительные фиксаторы ступени на входе с холостой логикой находятся здесь просто для того, чтобы гарантировать поступление входных данных. Аналогично, дополнительные фиксаторы на выходах осуществляют задержку передачи содержимого соответствующих разрядов до тех пор, пока не готова вся сумма. Для N-разрядного конвейерного сумматора с последовательным переносом необходимое число устройств задержки имеет порядок N в степени 2. Это может быть достаточно дорогостоящим даже при не очень больших N, если каждая задержка реализуется с помощью фиксаторов и холостой логики. Использование регистровых файлов, рассмотренных в одном из предыдущих разделов, позволяет уменьшить число устройств задержки, но не устранить их совсем.

Конвейерный умножитель

Базовая ступень сумматора может также использоваться при построении различных конвейерных устройств целочисленного умножения. На рис. 2.27 показан умножитель типа 4х4 разряда, основанный на классическом получении частичных произведений по одному разряду за один раз, за которым следует серия конвейерных сумматоров с последовательным переносом, суммирующих эти члены. Расширенные варианты приведенной схемы могут с помощью этого же метода вычислять любые произведение вида NxN разрядов со скоростью одно произведение за один период синхронизации (независимо от N), но опять-таки за счет резкого увеличения числа схем задержки, необходимых для выравнивания и запоминания промежуточных результатов. Для сравнения отметим, что наилучшее время, за которое неконвейерный умножитель способен вычислить результаты, пропорционально lgN в степени 2.

Оба эти конвейера узко однофункциональны. А как сделать хотя бы простой многофункциональный конвейер?

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

Управляющий вход Х задает: должно ли значение на входе В быть неизменным или заменяться на дополнение. на управляющем входе F задает передачу значения с А на выход S, а 1 задает сложение значения на входе А со значениями на выходе В и т.д.

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

На рисунке выше показан пример комбинации ячеек, чтобы выполнять умножение, деление, возведение в квадрат и извлечение квадратного корня:

Результат: S1S2…S6 = 0101102 = 2210

Дальнейшим развитием многофункционального конвейера будет конвейер с множественными путями (ветвящийся). Это отказ от линейности! А значит, все усложняется. Но приведем относительно легкий пример: конвейер для умножения чисел с плавающей запятой. Напомним три подфункции: умножение мантисс, сложение порядков и нормализация. Сложение чисел с плавающей запятой тоже разделяется на три подфункции: начальное выравнивание, сложение мантисс и нормализация результата.

Очевидно, что фиксированная запятая составит к вышеупомянутым примерам частный случай.

Все можно реализовать примерно на такой структуре:

Использование конвейеров:

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

Например, пусть за операцией сложения чисел с ПЗ через короткое время пойдет операция сложения чисел с ФЗ. Если не предусмотреть специально взаимную синхронизацию, то подконвейер сложения мантисс две операции попытаются использовать одновременно.

Следующий шаг в развитии конвейеров – конвейеры с обратной связью. А они могут применяться для обработки рекурсий (рекуррентных выражений). Сюда может быть отнесено много задач обработки сигналов с обобщенной формулой:

x (i) = f (a (i), x (i-1), …, x (i-m)), где, например,

a (i) – i-й раз измеренное значение входного сигнала;

x (i) – соответствующее значение результата вычислений.

Прямая реализация на конвейере возможна:

Однако такая реализация резко снижает производительность: если число ступеней для вычисления f равно d, то время от начала вычисления x(i) до завершения составит d периодов синхронизации; а поскольку x(i+1) зависит от x(i), то до завершения вычисления x(i) нельзя начать вычисления x(i+1). Вся конвейерность полетела к черту!

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

4.1.5 Временная организация и управление работой конвейеров.

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

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

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

1. время исполнения для всех ступеней является кратным некоторому базовому периоду синхронизации;

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

Второе ограничение сильнее первого, но оно достаточно «естественно»: как только данные в систему поступили, то должно быть ясно до конца, что с ними надо сделать.

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

4.2. Конвейеризация в структурах машин ОКОД.

Конвейеризация в ОКОД насчитывает несколько десятилетий. Была она, например, в БЭСМ-6. Правда, очень робкой.

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

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

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

От программиста скрывают в системе команд конвейерность по двум причинам:

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

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

Конечно, не все удается от программиста скрыть. Есть два класса эффектов, которые если и не учитываются программистом, то все же иногда видны ему:

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

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

2) обработка событий, асинхронных по отношению к нормальным операциям программы – прерывания; проблема состоит в том, что часто трудно определить

(а) где именно должен быть вставлен форсированный переход

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

Отметим еще раз, что все решения должны быть возложены на разработчика аппаратуры, который сделал конвейер. Так и происходит. Но есть прикладные задачи, в которых надо минимизировать либо аппаратные затраты, либо время. Чаще всего это возлагается на микрокомандный уровень, а значит, на специалистов-программистов, на нем работающих.

4.2.1. Архитектура конвейерных моделей ОКОД.

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

Приходится вводить абстракцию на этапе анализа и начального проектирования.

Вот базовая модель архитектуры:

• специальный регистр ЦП, именуемый счетчиком команд, отслеживает положение исполняемой команды;

• есть несколько других, доступный программисту, регистров ЦП, которые содержат данные (аккумуляторы, индексные, РОНы и проч.);

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

• полный набор команд БП;

• полный набор команд УП;

• два размера (два числа разрядов) форматов команд: короткий – для команд RR и в два раза более длинный – для большинства остальных.

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

Это разбиение типовой команды ADD.

Нечто похожее мы разбирали. Есть нюансы: например, сегмент ENDOP – в нее условно включим микрооперации установки флажков, кода состояния, увеличение содержимого СК, проверку запросов на прерывание.

Но такое разбиение далеко не единственно возможное:

• некоторые ступени (выборка операндов) могут реализовываться независимо;

• часть компонентов ENDOP можно перенести; например, изменение <СК> - в ступень IFETCH;

• разбить можно менее и более подробно; например, объединить EXEC и SAVE, разбить EAGEN.

Последнее особенно существенно, если применяются очень сложные способы адресации.

На следующем рисунке приведен пример разбиения на ступени команд одного из реально существующих процессоров (проект фирмы IBM):

А если команда не похожа на простое ADD? Тогда можно предложить:

Безусловный переход JUMP имеет еще более простое разбиение, поскольку теперь команда кончается, как только исполнительный адрес ЕА вводится в счетчик команд IC. Действия ENDOP, связанные с завершением, в еще большей степени сокращаются, поскольку здесь не надо обновлять IC.

Однако самые радикальные варианты разбиения встречаются в классе команд условного перехода BRANCH. Здесь в зависимости результата проверки условия, определенного командой, используются два совершенно различных разбиения, причем проверка служит одной из главных фаз исполнения команды. Если проверка дает отрицательный результат, то проверка завершается просто действиями ENDOP, сходными с аналогичными действиями в классе команд запоминания. Если же проверка дает положительный результат, то выбирается разбиение, подобное разбиению команд класса команды безусловного перехода JUMP. Заметим, что всюду в этой главе термины BRANCH, ADD и STORE относятся к командам модели архитектуры, тогда как сами слова – переход, сложение и запоминание – относятся к соответствующим операциям.

Наряду с приведенным описанием модели архитектуры ОКОД, необходима несколько произвольная (но реалистическая) модель производительности. Эта модель задает в общих условных единицах время исполнения каждой из ступеней основных типов разбиений, показанных на рис. 6.1 и 6.2. Оно приближенно равняется времени, затрачиваемому на исполнение этих функций процессором традиционной структуры при полном отсутствии конвейеризации или перекрытия. В последующих разделах эти времена будут нужным образом модифицированы.

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

Предполагается, что ступени IFETCH (выборка команды), OPFETCH 1 (выборка операнда 1) и STORE (запоминание) требуют обращения к памяти, которое обычно занимает больше времени, чем та или иная операция центрального процессора. Предполагается, что при генерировании исполнительного адреса EAGEN вычисления сводятся в среднем примерно к сложению смещения, находящегося в самой команде, с копией содержимого некоторого регистра центрального процессора. Аналогично, фаза исполнения для команд, подобных сложению ADD, является примерно средним между сравнительно быстрыми операциями, такими, как сложение, загрузка или логические операции, и более длинными, такими, как умножение, деление и сдвиг. Итоговые значения в таблице определяют средние времена исполнения команд каждого класса и являются суммами времен для каждой ступени.

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

Значения времен исполнения команд еще не достаточны для построения модели, которая позволяла бы обоснованно судить о потенциальной производительности вычислительной структуры. Всякая реальная программа, которую должна исполнять ЭВМ, является комбинацией, или смесью команд каждого класса. Хотя смесь зависит от структуры программы, ряд авторов разработали общие статистические распределения, на которые можно ориентироваться.

В табл. 6.2 приведена одна из таких смесей, соответствующих классам команд, определенных ранее. Большинство команд в этой таблице относится к классу команд, показанных на рисунке 6.1; за ними следуют переходы различных типов. Из табл. 6.1 и 6.2 можно найти, что на исполняемую команду в конвейерной машине при реализации рассматриваемой архитектуры ОКОД приходится в среднем 17,11 единиц времени.

Если в статистике учитывать команды с коротким форматом, то времена в модели следует уменьшить на 30 %.

4.2.2 Межкомандные зависимости и помехи.

В неконвейерной машинной структуре все операции, связанные с исполнением отдельной команды (см. рис. 6.1 и 6.2), завершаются до запуска следующей команды. Таким образом, фактическая очередность исполнения соответствует логической очевидности, заложенной программистом при написании программы. При конвейеризации это уже не всегда имеет места. Исполнения команд перекрываются, так что некоторые операции, нужные для команд i+1. i+2, …, могут зависеть от результатов i-й команды, которая еще не была завершена. Существование этих зависимостей вызывает помехи, которые должны быть обнаружены реальной вычислительной системой и разрешены ею так, чтобы фактические результаты, вырабатываемые программой, совпадали с ожидаемыми программистом. Аппаратный метод, который реализует обнаружение и разрешение помех, называется блокировкой.

Помеха возникает, когда к объекту данных, внутри ЭВМ (например, к регистру, ячейке памяти или флажку) обращаются или его модифицируют две различные команды, столь близко расположенные в программе, что конвейеризация перекрывает их исполнение. Имеются три класса таких помех, формально называемых помехой чтение после записи (RAW), помехой запись после чтения (WAR) и помехой запись после записи (WAW). Для демонстрации различий между помехами рассмотрим следующий фрагмент программы:

.

.

.

STORE X

.

.

.

ADD X

STORE X

.

.

.

STORE X

.

.

.

Помеха RAW между командами i и j (предполагается, что команда j логически следует за командой i) возникает, когда команда j пытается читать некоторый объект, модифицируемый командой i. Если та операция в команде i, которая модифицирует этот объект, не завершена до того, как команда j начинает к нему обращаться, то команда j прочитает неправильное значение этого объекта. В приведенном выше фрагменте программы помеха RAW потенциально существует между первой командой STORE (записать в ячейку Х) и командой ADD (сложить с содержимым ячейки Х). Если команда ADD читает из ячейки памяти раньше, чем первая команда STORE успела обновить ее содержимое, то к соответствующему регистру ЦП будет прибавлено неправильное значение. Команда j получила значение, которое является «слишком старым».

Помеха WAR существует, если команда j (логически следующая за командой i) хочет модифицировать некоторый объект, который читается командой i. Если j успевает модифицировать этот объект, прежде чем команда i обратилась к нему, то команда i снова получит неправильное значение, хотя это значение является теперь слишком новым, а не слишком старым. В приведенном выше фрагменте программы помеха WAR потенциально существует между командой ADD и второй командой STORE. Если вторая команда STORE перекрывается с командой ADD, то может случиться, что второе обновление содержимого ячейки Х произойдет раньше, чем к ней обратится команда ADD.

Помеха WAW существует, когда обе команды i и j пытаются обновить один и тот же объект, но i-е запоминание может наступить только после j-го. В результате после того, как обе команды завершены, в соответствующей ячейке может остаться промежуточное значение (от команды i), а не окончательное (от команды j). В нашем примере это может случиться между двумя последними командами STORE. Если вторая команда STORE завершается после третьей, то содержимое ячейки Х не будет таким, какое ожидает программист.

По симметрии является и четвертая возможность – чтение после чтения. Однако само по себе такое состояние не является помехой.

Более формальное и строгое определение помех можно найти в работе Келлера [61]. Его формулировки основаны на двух определениях.

Определение 6.1. Область определения команды i, обозначаемая D(i), - это множество всех объектов (регистров, ячеек памяти и флажков), содержимое которых влияет тем или иным способом на исполнение команды i.

Определение 6.2. Множество значений команды i, обозначаемое R(i), - это множество всех объектов (регистров, ячеек памяти и флажков), содержимое которых может быть изменено за счет исполнения команды i.

Таким образом, D(i) – это множество всех объектов, читаемых командой i, а R(i) – множество всех объектов, модифицируемых ею. Помня об этом, заметим, что возможность возникновения помехи между командой i и логически более поздней командой j имеет место тогда, когда удовлетворяется хотя бы одно из следующих условий*:

Условие 1 (RAW):

Условие 2 (WAR):

Условие 3 (WAW):

*Запись X∩Y означает пересечение множеств, т.е. элементы, общие для X и Y;

Ω означает пустое множество (не содержащее никаких элементов).

То же показано на рисунках:

Помеха «чтение после записи».

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

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

Примеры:

1. команда STORE использует содержимое некоторого индексного регистра, вычисляемое предыдущей ADD; она способна порождать помеху RAW;

2. две последовательно выполняемых команды JUMP дают помеху WAW, поскольку обе изменяю содержимое СК;

3. команда BRANCH зависит от кода состояния или значения в регистре, выработанных предыдущей ADD; она не должна зависеть от кода состояния следующей команды => помеха WAR и т.д.

Еще одна особая помеха, не показанная в последней таблице, может возникать всякий раз, когда имеет место «самомодифицируемый код», т.е. когда некоторая команда (обычно STORE) записывает в память слово, которое (внимание!!) вскоре будет исполняться как команда. Такой код может создавать помеху RAW между командой с запоминанием (и/или STORE) и фазой выборки IFETCH команды, которая будет затем исполняться.

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

Приемов много. Все сводится к одному из стандартных классов.

Два противоположных подхода к проблеме обнаружения помехи:

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

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

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

Два подхода и к устранению помех:

1. просто «остановить конвейер», если найдена помеха: обнаружена команда j в состоянии помехи с ранее инициированной командой i; тогда останавливаются все инициации команд j, j+1, j+2, … до тех пор, пока команда i не пройдет через точку конфликта;

2. (сложнее!!) останавливается команда j, но следующим (j+1, j+2,… ) разрешается двигаться по конвейеру; они обгоняют команду j, но на всех следующих ступенях для всех этих команд проверяется наличие помех не только с теми (до j), но и с j, и если здесь обнаруживается помеха, то выполнение этих команд откладывается до тех пор, пока «первая» исходная помеха для j не будет устранена и ей будет разрешено двигаться. Распадается на множество локальных методов, «изобретений», зачастую остроумных.

«Ускорение устранения помех типа RAW». Идет последовательность: …STORE, ADD, … Типичная помеха: ADD обращается к ячейке памяти, изменение содержимого которой осуществлялось STORE. Опасность! Помеха! Прямое решение: задержать ADD до окончания модификации со стороны STORE, а затем продолжать ADD.

Но есть быстрый способ, даже именуется «коротким замыканием»: копия данных, подлежащих запоминанию, передается прямо ADD! Это избавляет ADD от ожидания и затем выполнения еще одного чтения READ (хотя бы и внутри ADD):

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

1. много фиксаторов на ступенях конвейеров;

2. фиксаторы надо научить запоминать (если данных нет) индексом или тегом (указателем) за вырабатывающую их ступень;

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

4. возобновляется выполнение всех задержанных команд и движение по конвейеру.

Все это работает хорошо не только в обычных, но и в суперскалярных архитектурах (параллелизм в конвейерах выполнения команд). И даже в значительной степени под них и разрабатывалось. А примеры? Pentium! MC68060! Сигнальные процессоры!

4.3. Примеры применения конвейеров.

Самое простое – привести структурные (функциональные схемы самых распространенных процессоров в мире ПК: Pentium и MC68…

Вот они.

Структура МС68060

Структурная схема МС68060 приведена на рис. выше.

Основными узлами МС68060 являются:

• Исполнительное устройство (Execution Unit –EU);

• Устройство памяти инструкций (Instruction Memory Unit –IMU);

• Устройство памяти данных (Data Memory Unit –DMU);

• Контроллер магистрали (BUS CONTROLLER –BC).

Исполнительное устройство (EU) состоит из:

• устройства выборки инструкций (Instruction Fetch Unit – IFU);

• целочисленного устройства (Integer Unit -IU);

• устройства с плавающей точкой (Floating Point Unit –FPU).

Устройство памяти инструкций (IMU) состоит из:

• кэша адресных трансляций инструкций (Instruction ATC);

• кэша инструкций (Instruction Cache);

• контроллера кэша инструкций (Instruction Cache Controller).

Устройство памяти данных (DMU) состоит из:

• кэша адресных трансляций данных (Data ATC);

• кэша данных (Data Cache);

• контроллера кэша данных (Data Cache Controller).

Устройство памяти инструкций (IMU) и устройство памяти данных (DMU) работают по раздельным внутрикристальным магистралям с EU и BC.

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

1-й каскад – вычисление исполнительного адреса – IA CALCULATE- обеспечивает вычисление виртуального адреса инструкции.

2-й каскад – извлечение инструкции INSTRUCTION FETCH, является главным в конвейере.

3-й каскад – предварительное декодирование EARLE DECODE. В нем происходит декодирование с целью получения информации об управлении конвейером.

4-й каскад – буфер инструкций INSTRUCTION BUFFER. Представляет собой простую буферную память, где инструкция и ее управляющая информация хранятся до момента их выборки конвейером обработки целочисленного устройства.

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

Целочисленное устройство исполнительного устройства состоит из:

- двух целочисленных конвейеров обработки;

- логики для взаимодействия с FPU;

- логики управления данными.

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

Конвейеры IU структурно идентичны и именуются: первичный конвейер pOEP и вторичный конвейер sOEP.

Каждый из конвейеров включает в себя 6 каскадов:

1 – каскад полного декодирования;

2 – каскад вычисления эффективного адреса операнда EA CALCULATE;

3 – каскад извлечения данных из эффективного адреса;

4 – каскад целочисленной обработки данных INT EXECUTE;

5 – каскад доступных данных результата D.A.;

6 – каскад данных обратных записей во внутрикристальный кэш данных или во внешнюю память WRITE-BACK.

FPU является математическим процессором, отдельным от IU. Оно работает в стандарте ANSI IEEE 754 для арифметики с плавающей точкой и оптимизировано для получения высокой производительности при выполнении наиболее часто встречающихся команд и типов данных. (Может быть программно отключено для снижения энергопотребления).

IMU и DMU – два независимых устройства памяти. Каждое содержит 8-килобайтный кэш, контроллер кэша и кэш адресных трансляций (ATC). Кэш можно отключать.

ATC представляет собой 64-входовые 4-путевые установочно-ассоциативные устройства, хранящие часто используемые трансляции логического адреса в физические. После получения логического адреса из IFU контроллер устройства управления памятью инициирует поиск адресной трансляции страницы в ATC. Если требуемый дескриптор не имеется в ATC, то контроллер кэша выполняет внешний цикл поиска через контроллер магистрали. После нахождения дескриптора его содержимое загружается в ATC и адрес обращения оказывается корректно оттранслированным.

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

Все временные характеристики могут быть сконфигурированы под требования внешней памяти.