Материал: Архитектура и программирование MIPS-процессоров. Разинкин К.А

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

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

Разрешение конфликтов пересылкой через байпас

Некоторые конфликты данных можно разрешить путем

пересылки результата через байпас (bypassing, также использу-

ется термин forwarding) из стадий Memory или Writeback в ожидающую этот результат команду, находящуюся в стадии Execute. Чтобы организовать байпас, понадобится добавить мультиплексоры перед АЛУ. Теперь операнд можно получить либо из регистрового файла, либо напрямую из стадий Memory или Writeback, как показано на рис. 1.15. Таким образом, на четвертом такте $s0 пересылается через байпас из стадии Memory, где находится команда add, в стадию Execute, где находится команда and, которой нужен результат выполнения add. На пятом такте $s0 пересылается из стадии Writeback, где теперь находится команда add, в стадию Execute, где находится ожидающая ее результата команда or.

Рис. 1.15. Пересылка данных через байпас

Пересылка данных через байпас необходима, если номер любого из регистров операндов команды, находящейся в стадии Execute, равен номеру регистра результата команды, находящейся в стадии Memory или Writeback. На рис.

41

1.16 показан модифицированный конвейерный процессор с байпасом.

Рис. 1.16. Разрешение конфликтов в конвейере при помощи байпаса

У него есть блок обнаружения конфликтов и два новых мультиплексора. Блок обнаружения конфликтов получает на свой вход номера регистров, хранящих операнды команды, находящейся в стадии Execute, а также номера регистров результатов команд, находящихся в стадиях Memory и Writeback. Также ему необходимы сигналы RegWriteиз стадий Memory и Writeback. Эти сигналы показывают, нужно ли на самом деле писать результат в регистр или нет (например, команды sw и beq не записывают свои результаты в регистровый файл, поэтому их результаты пересылать не нужно). Заметьте, что на рисунке сигналы RegWrite, подключенные к блоку обнаружения конфликтов, изображены как короткие линии с названиями сигналов, как бы висящие в воздухе. Это сделано для того, чтобы не засорять рисунок длинными линиями, соединяющими управляющие сигналы вверху и блок обнаружения конфликтов внизу.

42

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

Блок обнаружения конфликтов управляет мультиплексорами байпаса (forwardingmultiplexers), которые определяют, взять ли операнды из регистрового файла или переслать их напрямую из стадии Memory или Writeback. Если в одной из этих стадий происходит запись результата в регистр и номер этого регистра совпадает с номером регистра операнда следующей команды, то используется байпас. Регистр $0 – исключение, он всегда содержит ноль, поэтому его нельзя пересылать.

Если номера регистров результатов в стадиях Memory и Writebackодинаковы, то приоритет отдается стадии Memory, так как она содержит более новую команду. Ниже приведена функция, определяющая логику пересылки данных в операнд SrcA. Логика для операнда SrcB(ForwardBE) точно такая же, за ис-

ключением того, что она проверяет поле rt, а не rs.

 

If(rsE != 0) AND (rsE == WriteRegM)

AND

Reg-

WriteM) then ForwardAE= 10

 

 

else if ((rsE != 0) AND (rsE == WriteRegW)

 

AND RegWriteW) then ForwardAE= 01

 

 

ElseForwardAE

= 00

 

 

Разрешение конфликтов данных приостановками конвейера

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

В этом случае мы будем говорить, что латентность команды lw равна двум тактам, потому что зависимая команда не может использовать результат lw раньше, чем через два такта. Эта проблема показанана рис.1.17. Команда lw получает

43

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

Рис.1.17. Проблема при пересылке результата команды lw через байпас

Альтернативное решение – приостановить конвейер, задержав все операции до тех пор, пока данные не станут доступны. Нарис. 1.18показана приостановка зависимой команды (and) в стадии Decode. Команда and попадает в эту стадию на третьем

такте и остается там на четвертом такте.

Следующая

команда

(or) должна, соответственно, оставаться

в стадии Fetch

в тече-

ние третьего и четвертого тактов, так как стадия Decode занята.

Рис. 1.18. Разрешение конфликта приостановкой конвейера

44

На пятом такте результат команды lw можно через байпас переслать из стадии Writeback в стадию Execute, где будет находиться команда and. На этом же такте операнд $s0 команды or может быть прочитан прямо из регистрового файла, без какой-либо пересылки данных.

Заметьте, что теперь стадия Execute на четвертом такте не используется. Аналогично, стадия Memory не используется на пятом такте, а Writeback – на шестом. Эта неиспользуемая стадия, проходящая по конвейеру, называется пузырьком (bubble), и ведет себя так же, как команда nop. Пузырек получается путем обнуления всех управляющих сигналов стадии Execute на время приостановки стадии Decode, так что он не приводит ни к каким изменениям архитектурного состояния.

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

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

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

На рис. 1.19 показан модифицированный процессор, который умеет приостанавливать конвейер для разрешения конфликтов данных, возникающих при выполнении команды lw. Блок управления конфликтами смотрит, какая команда находится в стадии Execute. Если это lw, а номер регистра результата (rtE) совпадает с номером любого из регистров операндов команды, находящейся в стадии Decode (rsD или rtD), то стадия Decode должна быть приостановлена до тех пор, пока операнд не будет прочитан из памяти.

45

Источник: https://studfile.net/preview/16568788/