Устройство обмена с оперативной памятью системы на кристалле "Эльбрус-S"

1. Устройство обмена с оперативной памятью системы на кристалле "Эльбрус-S"

2. Core Core L2 L2 MAU MAU “Эльбрус” 0.13 um 300 MHz Chipset 100 MHz 1.6/3.2 GB/s Memory

3. Core Core L2 L2 MAU MAU Chipset Chipset Chipset Chipset MAU MAU L2 L2 Core Core “Эльбрус-S” 0.09 um 500 MHz Memory Memory 8 GB/s 2 GB/s Memory Memory

4. Задача: • Разработка MAU для новой системы с обеспечением максимально возможной эффективности доступа к памяти Требования: • Поддержка когерентности • Максимальная пропускная способность • Минимальное время доступа

5. Структурная схема i/o Link A Link B Link C MC#1 Chipset MC#2 MAU KM LD Data ST Data LD Buff ST Buff CPU

6. Core Core L2 L2 MAU MAU Chipset Chipset Chipset Chipset MAU MAU L2 L2 Core Core Операция Load Memory Memory Memory Memory

7. Буфер приёма данных и сбора когерентных ответов Для завершения LD необходимо: • Собрать когерентные ответы • Принять данные • Взять из LDB сопровождающую информацию и отдать с ней данные в процессор Требования к буферу: • Параллельный асинхронный приём данных и когерентных ответов со всех направлений • Приоритет данных из кэшей над данными из памяти • Максимально быстрая выдача данных в процессор на основе собранной информации

8. Буфер приёма данных и сбора когерентных ответов(принятая схема) ack code 4xDW mem coh rq wait ready release 69 69 69 69 24 48 in_regs приоритет когерентные ответы ответ о завершении num c p tag data[63:0] 6 1 4x 1 4 64 mc0 mc1 link0 link1 link2

9. Пропускная способность Запросы по чтению – 32 или 64 байт за такт (16 или 32 ГБ/с) Приём данных процессором – 32 байт за такт (16 ГБ/с) Приём данных MAU: • из памяти – 8 ГБ/с • из линков – по 2 ГБ/с • из ввода-вывода – 1 ГБ/с на практике - в сумме не более ~12 ГБ/с Лишние запросы  нехватка ПСП + доп. задержки в линках  Необходимаоптимизация работы LDB

10. LDB CPU MRQ LDB Addr dst03 dst47 LD Data 24 Chipset

11. Оптимизация работы LDB «Эльбрус»: Возможность подклеивания заявок: • не требующих нового обращения в память (за 4xDW) • не требующих тех же DW LDB + = Задача – добавить возможность подклеивания заявок, запрашивающих пересекающиеся группы DW

12. Решение – буфер виртуальных заявок Типы входящих в LDB заявок: • обычная – заведение новой строки, запрос в память за 4xDW или 8xDW • подклеиваемая – добавление значимостей DW и соотв. DST в имеющуюся строку • вторичная – новый тип, заведение новой строки без запроса в память Аппаратная реализация: • введение в LDB битов вторичности запросов (для блокирования ухода таких заявок в память)и сигналов заведения вторичных строк • буфер вторичных заявок - ссылок на исходные строки LDB для вторичных строк LDB • поддержка буфером приёма данных удержания данных на своём выходе по сигналу из буфера вторичных заявок

13. Схема взаимодействия LDB, буфера приёма данных и буфера вторичных заявок destination data_out Буфер вторичных заявок LDB номер текущей вторичной строки информация о заведении hold номер первичной строки Буфер данных

14. Задержки в LDB, STB– примерно 3 такта (физические) + ожидание в очереди Буфер приема данных (до оптимизаций): • задержка данных на входных регистрах -1-2 для MC, 1-7 для линков, 1-8 для I/O • задержка на принятие решения – 1 такт (физическая) • ожидание выдачи из-за одновременного возникновения готовности нескольких строк - 0-?

15. Задержка на входных регистрах Приоритетная схема необходима для избежания переполнения, либо требуется более сложный механизм увеличение задержки и площади Однако не учитывает ни время ожидания, ни готовность по когерентным ответам  доп. задержка при интенсивном приходе данных (0-7 тактов) in_regs приоритет mc0 mc1 link0 link1 link2 I/O

16. Решение • Байпас значимостей готовностей по данным • Внеочередная запись в массив данных • Запись «приоритетных» данных на регистр «внеочередного» источника Результат: + Динамика заполнения регистров не меняется + Задержка на регистрах на итоговую задержку не влияет - Данные из массива можно получить только через 3 такта после принятия решения

17. Временная диаграмма работы буфера приёма данных и сбора когерентных ответов нельзя! р е г и с т р ы и в х о д ы готовность по данным номер строки для выдачи Внеочередная запись в массив Чтение из массива чёт Данные в ЦП готовность по ответам адреса назначения из LDB Адреса назначения в ЦП hold и вторичные строки hold и вторичные строки такты ЦП Потребовался ещё 1 такт задержки данных на выходе буфера. Но ЦП всё равно принимает данные только через 2 такта после адресов.  Общая задержка не увеличилась

18. Проблема выбора строки из множества готовых Готовность по данным – до 6 строк одновременно Готовность по ответам – до 6 строк одновременно Итого 12 + накопленные ранее. Неадекватный выбор  разброс времени доступа Приоритет по номеру: + простота, минимальные задержки и площадь - возможность «зависания» некоторых строк Решение #1 – приоритет по номеру, смещающийся по счётчику (простое). Решение #2 – приоритет по очерёдности поступления запроса (сложное). Оба оказались реализуемыми, тема для отдельного исследования.

19. Результаты • Разработано verilog-описание MAU, удовлетворяющее поставленным требованиям и решающее поставленные задачи • Начата отладка и физдизайн