Хотите проектировать устройство, которое использует миллиард человек — решайте микроархитектурные задачки

31ab7c7017279943108fb2f379c8109c.png

Длинный извилистый путь Школы Синтеза Цифровых Схем приближается к годовой кульминации. 21–23 пройдет хакатон по процессорам в зеленоградском МИЭТ, после чего 150 слушателей из дюжины российских городов оправятся готовится к майским праздникам, приближающимся сессиям и лету.

Но для тех, кто воспринимает школу не просто как научпоп, а реально собирается стать проектировщиком микросхем, мы приготовили экзамен с задачками в духе задачек на собеседованиях в Silicon Valley. В некоторых крупных электронных компаниях для решения таких задачек соискателя заводят в комнату без интернета, и он делает это под глазами экзаменатора на компанейском компьютере. Но так ученики школы не волшебники, а только учатся, экзамен выкладывается открытым, но по его результатам школа будет давать рекомендации в электронные компании.

Все упражнения выполняются на языке описания аппаратуры System Verilog. Для проверки используется open-source симулятор Icarus Verilog и не-open-source Questa от Siemens EDA. А также бесплатная среда синтеза для ПЛИС Intel FPGA Quartus Prime Lite.

Для экзамена мы выбрали три темы в четырех упражнениях:

  1. Конечные автоматы.

  2. Контроль потока данных.

  3. Верификация.

Мы не стали вводить в экзамен ничего про процессоры, так как после Школы мы будем проводить хакатон по проектированию процессоров в МИЭТ.

Задачи экзамена находятся в репозитории valid-ready-etc, поддиректории boards/omdazz/09_exam.

Упражнение 1. exam_1_pow_5_multi_cycle_fsm

В этом упражнении нужно спроектировать еще один блок для вычисления пятой степени аргумента. Этот блок имеет тот же интерфейс, что и конвейерный блок, который мы разбирали на занятиях. Но мы хотим, чтобы вы спроектировали новый блок не с помощью конвейера из четырех умножителей, а с помощью конечного автомата, который итеративно повторяет умножение четыре раза, используя только один умножитель. Да, у блока будет более низкая пропускная способность, чем у конвейерного блока, но зато он будет гораздо меньше: как умножители, так и D-триггеры для организации конвейера занимают много места и потребляют много электроэнергии.

355d0f6225b1b0d768d9721086ba4296.png0de0af176b859d62ec4e1f30f5cd0e50.png

Более подробный список требований вы можете прочесть в файле pow_5_multi_cycle_fsm.sv. Вы также можете ориентироваться на лог golden_log.txt и скриншот временных диаграмм golden_wave.png созданных при симуляции нашего решения.

Для симуляции задания используется Icarus Verilog вместе с программой для просмотра временных диаграмм GTKWave. Для поддержки симуляции в директории упражнения есть следующие файлы:

  • 02_simulate_rtl.bash — скрипт на Bash для запуска симулятора.

  • gtkwave.tcl — скрипт на языке Tcl для добавления сигналов для отладки на временные диаграммы.

  • tb.sv — тестовое окружение.

Если у вас есть плата Omdazz/RzRd с ПЛИС Intel FPGA Cyclone IV, вы можете проверить работу вашего блока на этой плате. В директории упражнения есть следующие файлы, которые поддерживают синтез:

  • 03_synthesize_for_fpga.bash — скрипт для запуска синтеза и конфигурации ПЛИС на плате через программатор USB Blaster.

  • 04_configure_fpga.bash — скрипт для конфигурации ПЛИС без запуска синтеза.

  • fpga_top_extra.qsf — скрипт на языке Tcl для синтеза в Intel FPGA Quartus Prime Lite.

  • fpga_top.sv — верхний модуль для синтеза. Устанавливает блок, содержит соединения портов модуля с кнопками и светодиодами.

Для дополнительной информации вы можете прочитать заметку на Хабре «Третий вопрос на интервью в электронные компании». В ней описывается та же организация симуляции и синтеза, которая используется и в этом упражнении, но не для блока возведения в степень, а для очереди FIFO.

Работа схемы на плате с искуственно медленным тактовым сигналом с частотой 1 Герц (1 такт в секунду):

Упражнение 2. exam_2_gearbox_1_to_2

Упражнение 3. exam_2_gearbox_2_to_1

Упражнение 2 и 3 связаны. Упражнение 2 описано в посте на Хабре «Как подготовиться к собеседованию в Samsung Advanced Computing Lab».

59834718465391a4139326f99cfafa0a.png

Блок в этом упражнениии превращает поток данных c протоколом valid/ready в другой поток данных, тоже с протоколом valid/ready, но трансферами двойной ширины. Упражнение 3 выполняет противоположную операцию — превращает поток данных в поток половинной ширины.

Для упражнения 2 код для RTL уже написан, но вам нужно дописать код для верификации (см. TODO в tb.sv). Для упражнения 3 тестовое окружение полностью написано, но вам нужно написать RTL (см. TODO в gearbox_2_to_1.sv).

Симуляция и синтез для упражнений 2 и 3 выполняется аналогично упражнению 1.

Временная диаграмма для упражнения 2

Временная диаграмма для упражнения 2

Временная диаграмма для упражнения 3

Временная диаграмма для упражнения 3

Видео работающей схемы для упражнения 2:

Видео работающей схемы для упражнения 3:

Упражнение 4. exam_4_axi_pipelined_wr_out_of_order_rd

В этом упражнении вы реализуете пассивный монитор, важную часть Verification IP (VIP) для упрощенного протокола AXI, который мы разбирали на занятии.

IP в данном контексте означает Intellectual Property («интеллектуальная собственность»), а не Internet Protocol. Термином «Verification IP» называют пакеты, которые включают в себя функциональные модели шин (Bus Functional Model — BFM), модели слейвов (reference slaves) и мониторы шин (passive monitors).

Мониторы AXI используются для как для верификации устройств ввода-вывода, подключенных к процессору, так и для верификации процессорных ядер, соединенных с блоком кэша второго уровня или с контроллером памяти.

Вы можете прочитать про Verification IP в заметке на Хабре «Причина агонии студентов во время интервью, или популярно о моделях интерфейсов шины».

20cfa057514d9cfeedcf9882218a7761.jpeg

В отличие от моделей мастера и слейва, монитор не формирует никакие сигналы. Он следит за шиной, печатает лог проходящих транзакций и выполняет проверки данных, которые приходят со слейва во время операции чтения. Для проверки монитор использует так называемую «теневую память», структуру данных, которая моделирует работу настоящей памяти внутри слейва и для которой монитор повторяет транзакции, которые он видит на шине. Если слейв вернул не те данные, которые находятся в теневой памяти, то это повод для инженера-верификатора вместе с проектировщиком RTL кода слейва разобраться, почему это произошло.

Синтез для проверки упражнения 4 не используется, так как все компоненты в этом упражнении — поведенческие модели. При использовании Verification IP в реальной практике верификации одна или несколько из моделей заменяются верифицируемым блоком RTL. Последний часто называют Design Under Test (или Device Under Test — DUT).

Симуляция упражнения 4 выполняется с тем же скриптом 02_simulate_rtl.bash, что и для других упражнений, но при этом используется симулятор Questa Advanced Simulator от Siemens EDA. Для работы с ним в директории упражнения есть скрипт на языке Tcl — questa.tcl, который запускает компиляцию и симуляцию проекта, а также добавляет к временным диаграммам нужные для отладки сигналы.

Код монитора содержит куски кода из моделей мастера и слейва. Если вы будете смотреть на мастер, слейв и текст ожидаемого лога в файле golden_log_monitor_only.txt, реализация кода для монитора не должна вызвать у вас трудностей.

Успеха в проекте!

Приложение. TODO для упражнений 1 и 2 на русском языке (в коде они на английском)

Упражнение 1. exam_1_pow_5_multi_cycle_fsm

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

Требования:

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

  2. Если входные данные идут один за другим (back-to-back, up_vld=1) и задержка на выходе (backpressure) отсутствует (down_rdy=1), блок должен выдавать результат каждые 5 тактов.

  3. Вычисление не должно ломаться при появлении задержки на выходе (backpressure). Сигнал down_rdy может быть выставлен в 0 в любой момент, без потери результатов текущей операции.

  4. Синтезированная схема должна работать на плате ПЛИС.

  5. Модуль должен быть полностью совместим с тем же тестовым окружением, которое использовалось для верификации модулей pow_5_single_cycle и pow_5_pipelined.

  6. Дополнительное задание 1: Сравните тактовую частоту и утилизацию ресурсов ПЛИС спроектированной схемы — с pow_5_single_cycle и pow_5_pipelined. Для корректного синтеза убедитесь, что путь через умножитель начинается с D-триггера и заканчивается D-триггером.

  7. Дополнительное задание 1: Напишите утверждение темпоральной логики (continuous assertion или System Verilog Assertion — SVA), которое проверяет, что: если down_rdy=1 на протяжении всего вычисления, и мы установили up_vld=1, тогда мы получим down_vld=1 и правильное значение down_data=up_data в степени 5 в течение 5–7 тактов после того, как up_vld=1 будет подтвержден как принятый, сигналом up_rdy=1.

Про использование утверждений темпоральной логики для верификации вы можете прочитать в заметке на Хабре «Слышали ли вы про язык «e»? А ведь он был продан за $315 миллионов долларов». В ней же упоминается связаная тема — функциональное покрытие последовательностей (cover properties).

Для справки при проектировании блока вы можете использовать лог golden_log.txt, а также скриншот временных диаграмм golden_wave.png, результаты симуляции нашего решения.

Упражнение 2. exam_2_gearbox_1_to_2

Напишите код для верификации переходника gearbox_1_to_2. Для справки вы можете использовать тестовое окружение из примера boards/omdazz/06_pipelines/26_pow_5_pipelined/tb.sv

Общая идея как верифицировать переходник с valid/ready протоколом для входящего (upstream) и выходящего (downstream) потоков передач (transfers):

  1. Создайте очередь для отслеживания данных, используя соответствующую конструкцию языка SystemVerilog (queue [$]). Ширина этой очереди устанавливается параметром width.

  2. Каждый раз, когда вы наблюдаете входящую передачу на положительном фронте тактового сигнала (up_vld & up_rdy), вталкивайте up_data в хвост очереди для отслеживания данных.

  3. Каждый раз, когда вы наблюдаете выходящую передачу (down_vld и down_rdy), сначала проверьте, что очередь содержит как минимум два элемента, затем сравните два элемента в голове очереди с down_data, и, наконец, вытолкните элементы из очереди.

  4. В конце симуляции (блок final) проверьте, что очередь пуста. Если нет, выведите содержимое очереди в лог.

Все эти задачи можно решать дома, а вот хакатон по процессорам будет в Зеленограде. Вот его объявление:

4fbfce7fb8a532a55e60e8bb78f03a08.jpeg

Для тех, кто собирается возмутиться «А как же заголовок? Что там такое автор говорил про миллиард пользователей устройства?» Все честно, как в швейцарском банке. Сегодня у нас в Самсунге (автор работает в группе GPU в Самсунге) менеджер автора сообщил, что у нас открылись свежие позиции для проектировщиков именно таких устройств. Вот объявление.

8e7c15e4635420a9789dcd467564a12f.png

Правда для поступления на эту позицию нужно право на работу в США, а также соблюдение экспортных ограничений. И не все читатели, которые могут решать задачки, могут пойти на эту позицию. Но если вы не будете решать микроархитектурные задачки, то вы не сможете поступить на такую позицию даже через 10 лет, когда (я надеюсь) и в России будет возможность проектирования устройств с миллиардом потенциальных пользователей. Тем или иным способом.

© Habrahabr.ru