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

ствующие EJTAG TAP интерфейс и не требует никаких дополнительных контактов чипа.

Off-chipтрассировка осуществляется через специальный датчик трассировки и может бытьнастроен на использование 4, 8 или 16 выводов.

1.2.Тракт данных конвейерного процессора

Конвейерный тракт данных можно получить, порезав однотактный тракт данных на пять стадий, разделенных регистрами (pipelineregisters). На рис. 1.10 (a)показан однотактный тракт данных, растянутый таким образом, чтобы оставить место для регистров между стадиями.

Нарис. 1.10 (b)показан конвейерный тракт данных, поделенный на пять стадий путем вставки в него четырех регистров. Названия стадий и границы между ними показаны синим цветом. Ко всем сигналам добавлен суффикс (F, D, E, M или W), показывающий, к какой стадии они относятся.

Регистровый файл – особенный в том смысле, что процессор читает из него в стадии Decode, а пишет в стадии Writeback. Поэтому, несмотря на то, что на рисунке он находится в стадии Decode, но адрес и данные для записи приходят из стадии Writeback. Эта обратная связь будет приводить к конфликтам конвейера. В конвейерном процессоре значения записываются в регистровый файл по отрицательному фронту тактового сигнала CLK, когда значение на его входе WD3 уже стабильно.

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

36

Рис. 1.11. Однотактный (a) и конвейерный (b) тракты данных

Ошибка – в логике записи в регистровый файл, которая происходит в стадии Writeback. В регистровый файл записывается значение ResultWиз стадии Writeback, но в качестве адреса используется сигнал WriteRegEиз стадии Execute.

На рис. 1.12 показан исправленный тракт данных. Сигнал WriteRegтеперь проходит через два дополнительных регистра в стадиях Memory и Writeback, то есть остается синхронным с остальными сигналами команды. Теперь WriteRegWи

37

ResultWподаются на входы регистрового файла в стадии Writeback одновременно.

Внимательный читатель мог заметить, что в логике сигнала PC′ тоже есть проблемы, потому что этот сигнал может понадобиться изменить одновременно в стадиях Fetch и Memory (используя сигналы PCPlus4F или PCBranchM соответственно).

Рис. 1.12. Исправленный тракт данных

1.3. Устройство управления конвейерным процессором

Конвейерный процессор использует те же управляющие сигналы, что и однотактный процессор, поэтому использует такое же устройство управления. В стадии Decode оно, в зависимости от полей opcode и funct команды, формирует управляющие сигналы.

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

Полностью конвейерный процессор с устройством управления показан на рис. 1.13. Аналогично сигналу WriteRegна рис. 1.11, сигнал RegWrite, пройдя через несколько

38

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

Рис. 1.13. Конвейерный процессор с устройством управления

1.4.Конфликты и их разрешения

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

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

На рис. 1.14показан конфликт, который возникает, когда одна команда пишет в регистр ($s0), а следующая команда читает из него. Это называется конфликтом чтения после записи (readafterwrite, RAW). Команда add записывает результат в $s0 в первой части пятого такта, однако команда and читает $s0 на третьем такте, то есть получает неверное значение. Команда or читает $s0 на четвертом такте, и тоже получает неверное значение. Команда sub читает $s0 во второй половине пятого такта, то есть наконец-то получает корректное значение, которое было

39

записано в регистр в первой половине пятого такта. Все последующие команды также прочитают корректное значение из $s0. Как видно из диаграммы, конфликт в конвейере возникает то-

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

Рис. 1.14. Конфликты в конвейере.

Однако при ближайшем рассмотрении оказывается, что результат команды add вычисляется в АЛУ на третьем такте, а команде and он требуется лишь на четвертом. В принципе, мы могли бы переслать результат выполнения первой команды второй до того, как он будет записан в регистровый файл, разрешив конфликт чтения после записи без необходимости приостанавливать конвейер. Часть тракта данных, обеспечивающая такую пересылку, называется байпасом (bypass). В некоторых других случаях, которые мы рассмотрим далее, конвейервсе-таки придется приостанавливать, чтобы дать процессору время вычислить требуемый результат до того, как он понадобится последующим командам. В любом случае, чтобы программы выполнялась корректно, несмотря на конвейеризацию, мы должны что-то предпринять для разрешения конфликтов.

Конфликты можно разделить на конфликты данных

(datahazards) и конфликты управления (controlhazards). Кон-

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

40