Как подготовиться к собеседованию в Samsung Advanced Computing Lab
Я работаю проектировщиком аппаратного блока графического процессора в телефонах Samsung, в рамках совместного проекта с AMD. Сейчас наш менеджмент расширяет команду и поощряет инженеров распостранять информацию о новых позициях среди своих знакомых. Я решил написать это пост для более широкой аудитории, так как множество людей, способных пройти интервью на RTL или DV позицию — больше, чем множество моих знакомых. Если вы сможете прислать мне ответ на задачку в моем посте вместе с вашим резюме, я перешлю его нанимающему менеджеру и рекрутеру нашей группы (в комментах прошу ответ не писать). Если резюме им понравится, вам нужно будет пройти стандартное собеседование на несколько часов, с несколькими инженерами, у каждого из которых свой набор задачек.
Также я покажу материалы, по которым можно готовиться к собеседованию, особенно если вы студент или у вас ограниченный опыт в электронной промышлености.
Скажу сразу что для данных позиций нужно разрешение на работу в США. Если у вас его нет, я агитировать компанию за петицию на H-1 визу для вас не могу, но вы можете решить задачку чисто для расширения кругозора или демонстрации молодецкой удали.
Для опытных инженеров задачка слишком простая, но для недавних выпускников вузов по специальности Electrical Engineering или Computer Engineering — в самый раз. Это должен уметь решать выпускник практически любого американского вуза который брал курс типа MIT 6.111 Introductory Digital Systems Laboratory, а также выпускники российких вузов МИЭТ, МИРЭА, ВШЭ МИЭМ, ИТМО, Иннополис, МГУ …, украинских КПИ, черниговского политеха, топ технических вузов Беларуси, Армении, Киргизии итд.
Ожидается, что вы владеете основами проектирования цифровых схем на уровне регистровых передач (Register Transfer Level — RTL), используя синтез с языка описания аппаратуры Verilog/SystemVerilog. Если вы напишете решение на VHDL — это тоже пойдет. Вы также можете приколоться и написать решение, используя high-level synthesis, графическую схему (schematic entry) или экзотические языки типа BlueSpec или Chisel, можете даже собрать ответ на советских микросхемах К155, транзисторах, радиолампах, реле или гидравлике — но все это я менеджменту не перешлю, хотя мне будет на это интересно посмотреть.
Итак, формулировка задачки:
Вам нужно спроектировать блок, который превращает поток данных шириной w бит в поток данных шириной w*2. Как прием узких данных в блок, так и передача широких данных из блока должна делаться с помощью valid/ready интерфейса в духе протокола AMBA AXI-Stream или каналов AXI4:
Вам также нужно написать тестовое окружение к блоку, которое обосновывает функциональную корректность и демонстрирует оптимальную пропускную способность блока. Большим плюсом будет, если вы еще и напишете код для проверки функционального покрытия, а также утверждения темпоральной логики, которые можно было бы проверить с помощью формальной верификации.
Valid/ready протокол должен следовать правилам, описанным для AXI (это все не ARM-specific и не AXI-specific, просто в армовской документации эти правила сформулированы лучше всего), в частности Valid не должен ждать Ready=1 для перехода от Valid=0 к Valid=1. Ведущий блок должен выставить Valid=1 не глядя на Ready, и потом ждать момента когда и Valid=1, и Ready=1 на положительном фронте тактового сигнала:
Ready может быть выставлен как через несколько тактов перед Valid, так и после Valid, или в том же такте что и Valid. Протокол Valid/Ready должен работать даже если Ready меняется случайно (в нашей задачке случайным может быть Downstream Ready для широкой шины). Также для оптимальной пропускной способности полезно обратить внимание на вот такое замечание в спецификации AXI (читать всю спецификацию не обязательно, я уже привел все что нужно для решения в этом после):
В отсутствие backpressure (то бишь когда downstream_rdy всегда равен 1), блок должен позволять прием данных каждый такт и выдачу данных через такт:
Полезная литература для подготовки к интервью
Вот самый лучший учебник начального уровня по вопросу, доступный сейчас на русском языке. Если вы не понимаете все, что в нем написано, то ваши шансы на трудоустройство в микроэлектронную компанию на RTL или DV (Design Verification) позицию не очень:
Вы также можете можете использовать более старый вариант учебника ниже. Главы 1-5 у учебников совпадают, но в главах 6-7 белый учебник использует модную молодежную архитектуру RISC-V, а зеленый — олдовую архитектуру MIPS. С точки зрения интервью на джуниор позицию RTL или DV инженера для проектирования или верификации GPU — это все равно.
Даже если вы будете проектировать не блок в подсистеме геометрии (как я) и не блок в pixel pipe, а шейдеры или управляющее ядро — даже в этом случае совершенно все равно, вы учились на MIPS или на RISC-V. Хотя с другой стороны, если вы учились (допустим) на микрокалькуляторе МК-54 или (допустим) на компьютерах ДВК и Радио-86, то вам нужно подучить концепцию конвейера (глава 7 и одного и другого учебника) для того, чтобы утверждать, что вы разбираетесь в основах архитектуры и микроархитектуры ЭВМ:
Подспорьем к учебнику Харрисов является вот такая книжка, которая привязывает его к упражнениям на платах с микросхемами регонфигурируемой логики ПЛИС / FPGA:
Но на одном учебнике Харрисов интервью вы не пройдете, так как в нем нет ряда тем, которые регулярно спрашивают на интервью, в частности задачки с очередями FIFO, арбитры, пересечение тактового домена, многопортовые памяти итд. Некоторые из тем, не разобранных у Харрисов, можно найти вот в такой книжке, по которой учатся в Стенфорде.
Например в ней есть про двойные буфера (skid buffers), асинхронные очереди FIFO для пересечения тактового домена (Clock Domain Crossing — CDC), работу с числами с плавающей точкой, немножко про банки памяти итд.
Но учебников недостаточно — стоит еще и читать всякие тексты из интернета, в частности статьи Клифа Каммингса (он на фото справа), особенно про пересечение тактовых доменов, синхронные и асинхронные сбросы. А также материалы сайтов rtlery.com и zipcpu.com, особенно если у вас ограниченный опыт в промышленности. Еще пять материалов про арбитры, credit-based flow control и работе с памятью, которые помогут поднять тонус перед собеседованиями:
Credit Based Flow Control. Архитектура ЭВМ, Принстонский университет
Arbiters: Design Ideas and Coding Styles by Matt Weber
Generating fast logic circuits for m-select n-port Round Robin Arbitration
Building Multiport Memories with Block RAMs
Composing Multi-Ported Memories on FPGAs
Кроме тем, связанных с проектированием, и RTL, и DV инженеру нужно четко понимать, как работает симулятор, иначе вы будете плодить баги, связанные с гонками (race conditions) и различными результатами симуляции до и после синтеза (pre- and post-synthesis simulation mismatch). Из этого понимания следует правильная методология использования блокирующих и неблокирующих присваиваний, которая вскользь упоминается у Харрисов. На тему работы симулятора есть очень полезный Appendix вот в такой книжке, которую я тоже рекомендую:
Для инженеров, которые идут на позиции по design verification, я рекомендую проштудировать следующие три книжки от начала до конца.
В первой книжке (Chris Spear) по человечески описана coverage-driven constrained random verification methodology, а также отличия SystemVerilog от Verilog-95 и Verilog-2001 (если вы их учили в вузе). Без этой книжки вам придется копаться в стандарте, который во-первых написан более мутным языком, а во вторых не объясняет зачем нужны те или иные фичи языка.
Вторая книжка (Vanessa Cooper) — это короткий тьюториал по UVM, который можно изучить быстро. UVM не так широко используется в электронных компаниях, как утверждает маркетинг компаний, которые продают тулы, поддерживающие UVM. Но что такое UVM и с чем его едят должен в 2022 году знать каждый верификатор, так как шанс нарваться на кусок UVM-а в том или ином проекте существует. Только не копируйте из этой книжки шаблон писания драйвера шины — он совершенно не подходит для более сложных шин, типа AXI с конвейерностью и внеочередным получением ответов (для них нужно поддерживать табличку «транзакций в полете» и строить конечный автомат, использующий такую табличку).
Третья книжка (Janick Bergeron) описывает философию верификации и индустриальные практики. Если вы никогда не работали в команде верификации чипа или блока, эта книжка съэкономит время вас и ваших коллег, когда вы будете задавать им вопросы.
Помимо книжек есть полезные сайты, например www.testbench.in
Если у вас нет доступа к дорогим промышленным тулам для симуляции Synopsys VCS, Cadence Xcelium и платной Mentor / Siemens EDA Questa, то я рекомендую вам получить бесплатный доступ через сайт под названием edaplayground.com . Бесплатные тулы вне этого сайта (Icarus Verilog и бесплатная версия Questa) достаточны для тренировки решения интервьюшных задач на тему RTL, но в них нет поддержки covergroups, constrained random generation и concurrent assertions, чем необходимо владеть для позиций по DV.
Кстати о concurrent assertions, утверждениях темпоральной логики. Они в последние годы становятся важным инструментом не только инженеров-верификаторов (DV), но и инженеров -проектировщиков (RTL), особенно в связи с развитием тулов формальной верификации типа Jasper Gold. Эти тулы позволяют автоматически получать ответы на вопросы типа «допустим на входе в блок у меня такие-то сигналы установлены так-то. Следует ли из этого, что потом, через много тактов, на выходе будет (или не будет) то-то?» Тул автоматически проанализирует ваш RTL и ответит «увы, вот контрпример» и покажет сценарий, когда ваше предположение нарушается, например в логике участвует сигнал, который вы забыли.
Очень полезно для анализа чужого кода. Я вообще думаю, что вузы могли бы вводить такие тулы для обучения студентов в самом начале учебной программы, чтобы они сразу правильно ставили мозг на анализ событий в конвейерах и вообще сложных последовательностных схемах.
«А как же графика?» — спросите вы, — «ведь железо, которое я буду проектировать, предназначено для быстрого вывода на экран монстров в шутерах, не так ли?» Да, вам нужно будет в конце-концов изучить графику, начиная с софтверного API, посколько все эти объекты — треугольники, матрицы преобразований координат, плоскости для отрезания и т.д. будут приходить к вам в виде данных на шинах и всяких установок извлекаемых из регистров, в которые будет писать софтверный драйвер. Но это необязательно учить сразу. Сразу нужно уметь решать микроархитектурные задачки, писать на верилоге и понимать что такое статический анализ тайминга. А монстры и шутеры — это потом, в процессе.
