Коротко — как детектировать конфликты и какие методы применять, с оценкой затрат и рекомендацией для встраиваемой системы.
1) Детектирование конфликтов
- Data (RAW): на стадии $ID$ сравнивают исходные регистры с целевыми в более поздних стадиях:
- если $\text{ID.rs}=\text{EX.rd}$ и $\text{EX.regWrite}=1$ → конфликт;
- аналогично для $\text{MEM.rd}$ и $\text{WB.rd}$.
- Load-use (специальный случай): если $\text{EX.memRead}=1$ и $(\text{ID.rs}=\text{EX.rd}\text{или}\text{ID.rt}=\text{EX.rd})$ — данные будут готовы только после стадии $MEM$ → нужен stall или специальный forward из $MEM$.
- Control (ветвления): пока ветвление не разрешено (обычно в $EX$ в простом конвейере), инструкции после ветви являются потенциально неверными. Детектирование: на стадии $ID$ распознают инструкцию ветвления; сравнение/вычисление целевого адреса проводится в $EX$.
2) Методы устранения
- Forwarding (bypass):
- Описание: добавление путей данных и мультиплексоров, которые подают результат из стадий $EX/MEM/WB$ прямо на вход ALU в $EX$.
- Плюсы: минимальные или нулевые вставки пузырей для большинства ALU-зависимостей; хорошая производительность.
- Минусы: дополнительные мультиплексоры, логика сравнения регистров и согласования сигналов.
- Stalling (pipeline interlock, вставка bubbles):
- Описание: блокировка продвижения инструкций (вставка «NOP») до тех пор, пока данные не готовы.
- Плюсы: простая аппаратная реализация.
- Минусы: снижает IPC; особенно дорого для часто встречающегося load-use.
- Speculative execution:
- Описание: выполнять инструкции после ветви до разрешения ветви; при ошибке — откат (flush) результатов.
- Плюсы: потенциально значительное повышение производительности при хороших предсказателях.
- Минусы: высокая аппаратная сложность (ренейминг, буферы, механизмы восстановления), увеличенное энергопотребление.
- Branch prediction:
- Описание: предсказывать направление/адрес ветви и продолжать выборку. Стратегии: static (направление по константам), dynamic (одно- или двухбитные счетчики), BTB, RAS для возвратов.
- Плюсы: при малом аппаратном бюджете (малые динамические предикторы) даёт существенное улучшение переходной производительности.
- Минусы: дополнительная память (BTB), логика обновления и энергии; при сложных схемах — большая сложность.
3) Сравнение по трём показателям (оценочно)
- Forwarding:
- Аппаратная стоимость: низкая–средняя (мультиплексоры + сравнители).
- Влияние на производительность: большое положительное (убирает большинство зависимостей).
- Энергопотребление: небольшое увеличение (доп. коммутируемые пути).
- Stalling:
- Аппаратная стоимость: очень низкая.
- Влияние на производительность: сильное снижение при частых зависимостях (особенно load-use).
- Энергопотребление: снижается за счёт меньшей активности, но эффективность падает из‑за длительного времени выполнения.
- Branch prediction (простая динамическая, $2$-бит):
- Аппаратная стоимость: низкая–средняя (BTB + $2$-бит counters).
- Влияние на производительность: заметное (меньше промахов → меньше flush).
- Энергопотребление: умеренное (доступы к BTB/таблицам).
- Speculative execution (широкая, глубока):
- Аппаратная стоимость: высокая.
- Влияние на производительность: высокая при хороших предсказателях.
- Энергопотребление: значительное увеличение (выполнение и отбрасывание инструкций).
4) Рекомендация для ресурсо‑ограниченной встраиваемой системы
- Обязательное: реализовать forwarding для ALU-результатов и логику детектирования hazard-ов (сравнения $\text{ID.rs/rt}$ с $\text{EX/MEM/WB.rd}$).
- Load-use: реализовать простую детекцию и позволить максимум один цикл задержки (one-cycle stall) в случае $\text{EX.memRead}$ → это дешевле и проще, чем более сложные схемы.
- Branch handling: использовать лёгкий динамический предиктор:
- $2$-битные счетчики и BTB размером порядка $64$–$128$ записей (встроенные ядра часто используют такой диапазон);
- небольшой RAS глубиной $8$ для возвратов функций.
- Не рекомендовать: полноценную speculative execution с переименованием регистров и большими буферами — слишком дорого и энергозатратно для ограниченного устройства.
- Дополнительно: для кода с предсказуемыми ветвлениями (например, циклы) можно добавить статические эвристики (backward-taken), которые почти не требуют аппаратуры.
5) Примерный итог настроек (компромисс производительность/стоимость/энергия)
- Forwarding + one-cycle load-use stall + $2$-bit BTB ($64$–$128$ entries) + RAS depth $8$ → хорошая производительность при умеренной аппаратной стоимости и приемлемом энергопотреблении для встраиваемых систем.
Если нужно, могу предложить конкретные размеры BTB/таблиц и оценку экономии цикла на наборе целевых приложений.