- Главная
- Информатика
- Конвейерный процессор. Лекция №11
Содержание
- 2. 1. Принципы построения конвейерного процессора. Микропроцессоры выполняют миллионы и миллиарды команд в секунду, так что производительность
- 3. На рис. (а) приведена временная диаграмма однотактного без конвейерного процессора. По горизонтальной оси отложено время (в
- 4. В конвейерном процессоре, на рис. (b), длина самой медленной стадии определяется стадией доступа к памяти (Fetch-
- 5. 1.3. Абстрактное представление работающего конвейера Абстрактное представление работающего конвейера показывает продвижение команд по конвейеру. Каждая стадия
- 6. 2. Конвейерный тракт данных. Конвейерный тракт данных получим, разрезав однотактный тракт данных на пять стадий, разделенных
- 7. 3. Конвейерное устройство управления Конвейерный П использует те же управляющие сигналы, что и однотактный П, поэтому
- 8. 4. Конфликты и их разрешение. Процессор может читать и писать в регистровый файл RF за один
- 9. Однако, результат команды add вычисляется в АЛУ на третьем такте, а команде and он требуется лишь
- 10. Конфликты можно разделить на конфликты данных (data hazards – данные опасностей) и конфликты управления (control hazards
- 11. Пересылка данных через байпас необходима, если номер любого из регистров операндов команды, находящейся в стадии Execute,
- 12. У П появился блок обнаружения конфликтов (БОК) и два новых мультиплексора. БОК получает на свой вход
- 13. 4.2. Разрешение конфликтов данных приостановками конвейера. Например, команда lw не может прочитать данные раньше, чем в
- 14. 4.2.1. Приостановка конвейера. Конвейер приостановлен! (Для команды and повторена стадия D главная компонента RF, а для
- 15. Модифицированный процессор с приостановкой конвейера Для приостановки стадий Fetch и Decode нужно добавить вход разрешения работы
- 16. 4.3. Разрешение конфликтов управления Выполнение команды beq приводит к конфликту управления: конвейерный процессор не знает, какую
- 17. 4.3.1. Условный переход из адреса 20 по адресу 64. Вычисление условия перехода заключается в определении равенства
- 18. Конвейерный процессор с ранним вычислением условий переходов, способный разрешать конфликты управления. Вычисление условий перехода, происходит на
- 20. Скачать презентацию
1. Принципы построения конвейерного процессора.
Микропроцессоры выполняют миллионы и миллиарды команд в
1. Принципы построения конвейерного процессора.
Микропроцессоры выполняют миллионы и миллиарды команд в
Наибольшие задержки в в трактах обработки команд процессора создают Чтение и Запись в память и регистровый файл, а также Использование АЛУ..
Конвейер создадим из типовых стадий обработки команд таким образом, чтобы каждая из этих стадий включала ровно одну из операций обработки команд.
Назовем типовые стадии обработки команд следующим образом:
Fetch (F выборка), Decode (D дешифрация), Execute (E выполнение), Memory
(M доступ к памяти) и Writeback (W обратная запись результатов).
Они похожи на пять этапов выполнения команды lw в многотактном процессоре.
В стадии Fetch процессор читает команду из памяти команд.
В стадии Decode процессор читает операнды из регистрового файла и дешифрует команду, чтобы установить управляющие сигналы.
В стадии Execute процессор выполняет вычисления в АЛУ.
В стадии Memory процессор читает или пишет в память данных.
В стадии Writeback процессор записывает результат в регистровый файл
На рис. (а) приведена временная диаграмма однотактного без конвейерного процессора. По
На рис. (а) приведена временная диаграмма однотактного без конвейерного процессора. По
В однотактном процессоре, показанном на рис. (a), первая команда выбирается
из памяти в момент времени 0 рс (F I); далее процессор читает операнды из регистрового файла (D R); далее АЛУ выполняет необходимые вычисления (E ALU); происходит чтение памяти данных (M R/W); результат записывается в регистровый файл (WR).
Время исполнения одной команды составило 950 pс:
250 (F I) + 150 (D R) + 200 (E ALU)+ 250 (M R/W) + 100 (WR) = 950 рс,
Выполнение команды 2 начинается после того, как закончена команда 1.
Таким образом, однотактный без конвейерный процессор обеспечивает выполнение 2-х команд за время, равное: 2 х 950 рс = 1900 рс
1.1. Выполнение команд в однотактном процессоре.
В конвейерном процессоре, на рис. (b), длина самой медленной стадии определяется
В конвейерном процессоре, на рис. (b), длина самой медленной стадии определяется
В начальный момент времени команда1 instr1 загружается из памяти. Через 250 pс, команда 1 попадает в стадию Decode, но команда 2 instr2 загрузится из памяти только через 500 рс (столько времени теперь требуется на выборку 2-х команд), следовательно для дешифровки команды 1 можно отвести большее время или немного задержать дешифровку команды 1, пока не загрузится команда 2 и т.д.
ВЫВОДЫ:
Пропускная способность 3-х команд в конвейерном процессоре больше, чем в однотактном, потому что стадии конвейера не идеально сбалансированы, то есть не содержат абсолютно одинаковое количество логики.
Пропускная способность процессора с пяти стадийным (F,D,E,M,W) конвейером не в пять раз больше, чем у однотактного (2 команды исполняются за 1350 рс, а у без конвейерного однотактного процессора исполнялись за 1900 рс ).
Увеличение пропускной способности весьма значительно. За время 1600рс прошло 3 команды в конвейерном П, а в однотактном П потребовалось бы 3х950 рс = 2850 рс.
1.2. Выполнение команд в конвейерном процессоре.
1.3. Абстрактное представление работающего конвейера
Абстрактное представление работающего конвейера показывает продвижение команд
1.3. Абстрактное представление работающего конвейера
Абстрактное представление работающего конвейера показывает продвижение команд
Каждая стадия обозначена главным компонент стадии – память команд (instruction memory, IM, стадия Fetch), чтение регистрового файла ( register file, RF, стадия Decodre), АЛУ , (стадия Execute) память данных (DM, стадия Memory) и запись в регистровый файл ( register file, RF, стадия Writeback). Таким образом, каждая стадия привязана к ее главному копоненту.
Строки определяют на каком такте команда находится в той или иной стадии.
Например, команда sub загружается из памяти (IM) на третьем такте и выполняется на пятом (АЛУ).
Столбцы определяют чем заняты стадии конвейера на конкретном такте.
Например, на шестом такте команда or загружается из памяти команд (IM) .
Цвет главного компонента стадии закрашен серым, если он используются и белым, если не используется и простаивает. Например, память данных DM в командах add, sub, and и or не используется. Память команд RF и АЛУ используются на каждом такте. Память команд RF может использоваться в первой или во второй половине стадии: цвет серо-белый или наоборот.
Главная проблема в конвейерных системах – разрешение конфликтов (hazards-опасности ), которые возникают, когда результаты одной из команд требуются для выполнения последующей команды до того, как первая завершится.
2. Конвейерный тракт данных.
Конвейерный тракт данных получим, разрезав однотактный тракт данных
2. Конвейерный тракт данных.
Конвейерный тракт данных получим, разрезав однотактный тракт данных
На рис. (а) - схема тракта данных однотактного без конвейерного процессора, на рис. (b) показан конвейерный тракт данных, поделенный на пять стадий (F, D, E, M, W) путем вставки в него четырех регистров. Названия стадий и границы между ними показаны синим цветом.
3. Конвейерное устройство управления
Конвейерный П использует те же управляющие сигналы, что
3. Конвейерное устройство управления
Конвейерный П использует те же управляющие сигналы, что
Fetch Decode Execute Writeback
4. Конфликты и их разрешение.
Процессор может читать и писать в регистровый
4. Конфликты и их разрешение.
Процессор может читать и писать в регистровый
Запись происходит в первой части такта, а чтение – во второй, так что значение в регистр можно записать и затем прочитать обратно за один такт, и это не приведет к конфликту, что показано в компоненте RF серо-белым цветом.
Конфликт происходит, когда одна команда (add $s0,$s2,$s3) пишет в регистр ($s0), а следующая команда ( and $t0, $s0, $s1) читает из него. Это называется конфликтом чтения после записи (read after write, RAW). Команда add записывает результат в $s0 в первой части пятого такта, однако команда and читает $s0 на третьем такте, то есть получает неверное значение этого слова (его еще нет, а его уже читают). То же происходит и с командой or читает $s0 на четвертом такте. Команда sub читает $s0 во второй половине пятого такта, то есть получает корректное значение, которое было записано в регистр в первой половине пятого такта. Все последующие команды также прочитают корректное значение из $s0.
Однако, результат команды add вычисляется в АЛУ на третьем такте, а
Однако, результат команды add вычисляется в АЛУ на третьем такте, а
Конфликты можно разделить на конфликты данных (data hazards – данные опасностей)
Конфликты можно разделить на конфликты данных (data hazards – данные опасностей)
Конфликт данных происходит, когда команда пытается прочитать из регистра значение, которое еще не было записано предыдущей командой.
Конфликт управления происходит, когда процессор выбирает из памяти следующую команду раньше, чем именно эта команду потребуется.
Для разрешения конфликтов в процессор добавляется блок разрешения конфликтов (hazard unit), который будет выявлять и разрешать конфликты таким образом, чтобы процессор выполнял программы корректно.
4.1. Разрешение конфликтов пересылкой через байпас.
Конфликты данных можно разрешить путем пересылки результата через байпас (bypassing или forwarding) из стадий Memory или Writeback в ожидающую этот
результат команду, находящуюся в стадии Execute. Для организации байпаса добавим мультиплексоры перед АЛУ ( синие стрелы), что бы операнд можно было получать либо из регистрового файла RF, либо напрямую из стадий Memory или Writeback.
Пересылка данных через байпас необходима, если номер любого из регистров операндов
Пересылка данных через байпас необходима, если номер любого из регистров операндов
Модифицированный конвейерный процессор с байпасом.
Блок обнаружения конфликтов (БОК)
Fetch Decode Execute Writeback
У П появился блок обнаружения конфликтов (БОК) и два новых мультиплексора.
БОК
У П появился блок обнаружения конфликтов (БОК) и два новых мультиплексора.
БОК
Предполагается, что все линии с одинаковыми названиями сигналов соединены между собой.
БОК управляет мультиплексорами байпаса (forwarding multiplexers), которые определяют, взять ли операнды из регистрового файла или переслать их напрямую из стадии Memory или Writeback. Если в одной из этих стадий происходит запись результата в регистр и номер этого регистра совпадает с номером регистра операнда следующей команды, то используется байпас.
Регистр $0 –исключение, он всегда содержит ноль, поэтому его нельзя пересылать.
Если номера регистров результатов в стадиях Memory и Writeback одинаковы, то приоритет отдается стадии Memory, так как она содержит более новую команду.
Функция, определяющая логику пересылки данных в операнд SrcA и логику для операнда SrcB (ForwardBE) одинаковы за исключением того, что она проверяет поле rt, а не rs и имеет вид:
if ((rsE != 0) AND (rsE == WriteRegM) AND RegWriteM) then ForwardAE = 10
else if ((rsE != 0) AND (rsE == WriteRegW) AND RegWriteW) then ForwardAE = 01
else ForwardAE = 00
4.2. Разрешение конфликтов данных приостановками конвейера.
Например, команда lw не может прочитать
4.2. Разрешение конфликтов данных приостановками конвейера.
Например, команда lw не может прочитать
В этом случае будем считать, что длительность записи команды lw равна двум тактам, поэтому зависимая команда and не может использовать результат lw раньше, чем через два такта.
Команда lw получает данные из памяти в конце четвертого такта. Однако команде and эти данные требуются в качестве операнда уже в самом начале четвертого такта. Пересылка данных через байпас не поможет разрешить этот конфликт. Приостановим конвейер, задержав все операции до тех пор, пока данные не станут доступны.
Приостановим зависимую команду (and) в стадии Decode, которая попадает в эту стадию на третьем такте и оставим ее там на четвертом такте. Следующая команда (or) должна, соответственно, оставаться в стадии Fetch в течение третьего и четвертого тактов, так как стадия Decode занята командой and.
Несчастье -
4.2.1. Приостановка конвейера.
Конвейер приостановлен! (Для команды and повторена стадия D главная
4.2.1. Приостановка конвейера.
Конвейер приостановлен! (Для команды and повторена стадия D главная
Вывод. Стадию конвейера можно приостановить, если запретить обновление конвейерного регистра (стадия Decode, компонент RF команды and ), находящегося между этой и предыдущей стадиями. И все предыдущие стадии тоже должны быть приостановлены, чтобы ни одна из команд не пропала. Конвейерный Регистр, находящийся сразу после приостановленной стадии, должен быть очищен, чтобы «мусор» не попал в конвейер. Приостановки конвейера ухудшают производительность, поэтому должны использоваться только при необходимости.
Приостановка -
Модифицированный процессор с приостановкой конвейера
Для приостановки стадий Fetch и Decode нужно
Модифицированный процессор с приостановкой конвейера
Для приостановки стадий Fetch и Decode нужно
Также устанавливается сигнал FlushE, очищающий содержимое временного регистра перед стадией Execute, что приводит к появлению пузырька.
Блок обнаружения конфликтов (БОК)
Fetch Decode Execute Writeback
4.3. Разрешение конфликтов управления
Выполнение команды beq приводит к конфликту управления:
4.3. Разрешение конфликтов управления
Выполнение команды beq приводит к конфликту управления:
Способы разрешения этого конфликта:
Приостановка конвейера .
До тех пор , пока не будет вычислен адрес перехода, происходит торможение конвейера. Конвейер приостанавливается до тех пор, пока не будет принято нужное решение (т.е. до тех пор, пока не будет вычислен требуемый сигнал счетчика команд PCSrc). Решение принимается в стадии Memory, так что для каждой команды условного перехода придется приостанавливать конвейер на три такта (состояния: Fetch, Decode, Execute).
2. Предсказание перехода и начало выполнения команд перехода.
Как только условие перехода будет вычислено, процессор может прервать эти команды, если предсказание было неверны. Допустим, что условный переход не будет выполнен, и продолжили выполнять команды в порядке следования. А если окажется, что переход должен был быть выполнен, то конвейер должен быть очищен (flushed – смыть , очистить) от трех команд, идущих сразу за командой перехода, путем очистки соответствующих временных регистров конвейера. Зря потраченные в этом случае такты называются простоем из-за неправильно предсказанного перехода (branch misprediction penalty).
.
4.3.1. Условный переход из адреса 20 по адресу 64.
Вычисление условия перехода
4.3.1. Условный переход из адреса 20 по адресу 64.
Вычисление условия перехода
Конвейерный процессор с ранним вычислением условий переходов, способный разрешать конфликты управления.
Вычисление
Конвейерный процессор с ранним вычислением условий переходов, способный разрешать конфликты управления.
Вычисление
На третьем такте процессор очищает конвейер от команды and и выбирает из памяти команду slt.
ВЫВОД: простой из-за неправильно предсказанного перехода уменьшился с трех тактов до одного.