В моей жизни было четыре периода, когда я активно принимал участие в интервьировании людей на работу. В 1998 для своего стартапа в области программ для проектирования микросхем, в 2010-11 для MIPS Technologies (компания среднего размера, но престижная в свое время в узком кругу процессоростроителей), в 2019 для Wave Computing (хайповый стартап в хардверном AI) и сейчас для Samsung (на позиции дизайнеров графических процессоров телефонов). Я не собирался писать длинный текст, но пока я пью чай, набросаю несколько тезисов, первое, что приходит в голову:
Большинство текстов в интернете про поиски работы концентрируются на советах по оформлению резюме и по прохождению бихевиорального интервью. Мой персональный взгляд: настоящая борьба происходит не там. Научить правильно писать резюме можно за полчаса. А с компаниями, которые делают упор на бихевиоральное интервью, имхо лучше вообще не связываться. Главным фокусом является два умения: умение внятно рассказать, что вы делали на предыдущих работах, и умение решать задачки.
По поводу резюме: оно должно быть кратким и строго по делу. Длинные резюме на восемь страниц пишут сумасшедшие. Если вам меньше 30 лет, одна страница оптимальна, потом можно две. Под каждым местом работы должно стоять достижение. Не "программировал на Си", а "разработал и реализовал алгоритм выделения регистров в компиляторе с такого то языка, учитывающий эффекты конвейера такого-то процессора". Не нужно упоминать все компании и все умения - комбинация "RTL лид блока wireless чипа в [топ-10 электронной компании]" и "умею работать с Microsoft Word" - это маразм.
Вносить в резюме нужно только то, за что вы готовы ответить на вопросы. Один соискатель написал что он программировал на языке Jovial, думая что ему просто поверят (на этом языке американские военные писали программы в старину). Соискателю не повезло: я однажды пролистал книжку по Jovial в библиотеке Стенфорда. Выражение лица соискателя, когда я задал ему вопрос про Jovial, было бесценно.
Рассказ о том, что вы делали на предыдущей работе, должен быть хорошо структурирован. Сначала нужно описать чип или ядро, внутри которого вы разрабатывали или верифицировали блок. Потом вам нужно нарисовать на доске (реальной или виртуальной в зуме) ключевые элементы вашего блока (интерфейсы, памяти, очереди FIFO), описать ход транзакций между ними и микроархитектурные проблемы, которые при этом возникали. Упомянуть решение проблем с таймингом и энергопотреблением, а также чем это лучше других решений. Интервьюер должен почувствовать, что вы это делали, делали с пониманием, и можете передать ваше понимание окружающим.
Здесь имеется тонкий момент: вам нельзя выдавать секреты текущего или предыдущего работодателя. К счастью, блоки процессоров или сетевых чипов в разных компаниях (например TLB MMU в процессорах или там Egress Processing в роутерах) имеют похожую структуру. Также компании часто используют открытые изобретения из академической среды (пример: предсказатель переходов TAGE). Поэтому вам достаточно плясать вокруг некоего общего знания, разлитого по всей индустрии среди понимающих людей, с небольшими вариациями. А также не упоминать никакие бенчмарки, пропускные способности, особые патентуемые находки, планы и другую конкретно секретную информацию.
Уровень вопросов и задачек связан с вашим опытом в резюме. Если вы свежий интерн, у которого в резюме только курсовой проект, в котором вы писали execution unit в учебном RISC-V процессоре, готовьтесь ответить про задержки и байпасы в конвейере. Если вы упоминаете в резюме FIFO или SPI протокол, готовьтесь написать перед глазами интевьюера код для простого FIFO или SPI приемника на верилоге.
Бывают соискатели из недавних студентов, которые могут рассказать словами и картинками, но не набили руку на механике писания кода на верилоге. Это плохая комбинация. Да, я знаю, что есть мнение "он понимает сложные проблемы и выучит простое кодерство за пару месяцев". Такое мнение встречается у менеджмента, особенно если студент - отличник и позитивен. Но это плохо работает во время интервью с инженерами команды (см. примечание 1).
Вообще, для тех кто не знает: типичное интервью в крупной электронной компании состоит из нескольких этапов: 1) рекрутер; 2) технический скрининг нанимающим менеджером или одним из опытных инженеров; 3) большое интервью в котором вы за 4-6 часов говорите с 5-8 инженерами; 4) разговор с начальником на два уровня выше и 5) обсуждение предложения. Критической является часть (3).
У этой темы есть вариации: пункт (3) может быть в два приема - на два дня; инженеры могут интервьировать вас парами интервьюеров, а не поодиночке; в редких случаях бывают презентации соискателя всей инженерной команде итд.
Для старших инженеров критично знать некое общее ноу-хау индустрии, которое все применяют, но которое слабо представлено в учебниках. Например комбинация из конвейера, очереди FIFO и кредитного счетчика широко применяется в сетевых чипах для обработки потока фрагментов пакетов, и в графических чипах для обработки потоков треугольников. Но в учебниках это описано очень слабо: я видел это в контексте сетевого софтвера (не хардвера), а также в фрагменте лекции в Принстоне. Если соискатель работал в команде, которая это однозначно применяет, например в группе проектирования системы на кристалле в Apple, то его можно 1) сначала спросить "вы знаете, что такое credit based flow control"? 2) если он ответит "нет" то найти другую похожую область; 3) а если он ответит "да" то задать одну из многих задачек на эту тему.
Некоторые вещи, которые спрашивают на интервью, разобраны в статях от Cliff Cummings, идеи для тренировок на микроархитектурные задачки можно черпать из сайта RTLery итд.С задачками на интервью есть такая проблема, что любой ваш вопрос может быть передан на вебсайт типа glassdoor, где люди делятся, чему их спрашивали на интервью. Против этого есть противоядие - делать вариации задачек. Например есть широкоизвестный интервьюшный вопрос "напишите код на верилоге, который принимает числа по битам (один бит каждый такт) и определяет, делится ли это число на три (длина числа не ограничивается - оно может быть хоть миллиард бит). Так как этот вопрос стоит на таких сайтах сто лет, то в чистом виде его спрашивать нельзя: нужно делать вариацию, например 1) биты могут приходить как от старшего к младшему, так и от младшего к старшему или 2) определяете не остаток от деления на 3, а остаток от деления на 7. Итд.
В заключение добавлю, что вы можете познать все что я выше описал, на практике: если вы проектировщик микросхем на уровне регистровых передач, хотите работать в интересном проекте в GPU и (увы, это ограничение) имеете право на работу в США, то присылайте мне ваше резюме.
Примечание 1. Существует разрыв между уровнем базовых курсов в университетах и уровнем навыков, требуемых для успешной работы в компаниях. Если студент не набивал руку на учебных проектах сам, а только сдавал зачеты по картинкам из учебника и простейшим упражнениям, у него будет проблема. Столкнувшись с задачей чуть дальше учебника, студент может обнаружить, что то, что ему казалось простым (пример: gearbox, конвертор ширины шины c valid/ready интерфейсами на входе и выходе), вдруг стало сложным. Если он при этом нетвердо владеет механикой верилога типа блокирующих и неблокирующих присваиваний, параметризацией итд, то у него будут глюки и он будет биться как рыба об лед, наслаивать говнокод и заплаты, отлаживать это бесконечно, надеяться, что кто-то исправит за него итд. Этот этап нужно пройти в учебных проектах, не на производстве. Да и всякие алгоритмы замещения кэша и прочее из картинок в учебнике тогда будут выглядеть по другому.
Комментарии (43)
victor_1212
28.06.2022 20:06+3все тезисы по делу, незначительное добавление - две страницы резюме должны содержать достаточно buzz words чтобы обратить на себя внимание при первом взгляде, и иметь шанс попасть on top of the pile, в каких именно компаниях работали не менее важно чем то что сделали
Brak0del
28.06.2022 21:39иметь шанс попасть on top of the pile
Специалистов по части RTL и прочих вещей из статьи острый дефицит, некоторые вакансии висят годами, есть шанс что никакого pile нет.
victor_1212
28.06.2022 22:21> есть шанс что никакого pile нет
вполне возможно, есть шанс что некоторым читателям рекрутеры и так звонят раз в неделю, все бывает
yerbabuena
29.06.2022 16:45То,что вакансия висит годами, ещё не значит что на рынке дефицит. Вакансия может быть для вида, типа кому-то гринку делают, если речь про Штаты
Brak0del
29.06.2022 19:12Вы правы, но время висения не единственный признак.
Судя по тому, в какие дали зовут RTL-щиков из РБ, также сложилось впечатление, что совсем дефицит.
Судя по количеству участников главного русскоязычного тематического комьюнити в 2К человек, тоже похоже, что спецов очень немного. Для справки, каких-нибудь джавистов только в РБ порядка 10К человек.
mpa4b
28.06.2022 20:08+2Сдаётся мне что на вопрос про делимость на 3 двоичного числа, передающегося бит за битом может и не каждый сеньор ответить, если не знает сам признак такой делимости ("A binary number is divisible by 3 iff the sum of the odd bits is equal to the sum of the even bits"). А если знает студент -- то и он без проблем ответит. В этом проблема вопросов типа такого или 'оцените кол-во шариков, влезающее в автобус'.
YuriPanchul Автор
28.06.2022 20:13+1Ну во первых, это не единственный вопрос, а один из нескольких вопросов. Во-вторых, если человек не знает, ему можно дать подсказку: напишите конечный автомат, который в каждый момент в качестве состояния использует текущий остаток от деления. Ведь вопрос тут не о том, знает ли он признак делимости на 3, а о том, умеет ли он писать код для конечных автоматов. И потом можно смотреть как он рассуждает на доске о переходах между состояниями.
mpa4b
28.06.2022 20:20+1Я опять не понимаю как текущий остаток от деления может быть связан с этим признаком делимости на 3. Конечно если поматанить то наверное к этому признаку делимости и можно прийти, но точно не за минуту.
mpa4b
28.06.2022 20:46UPD: я тут посчитал остатки от деления степеней двойки на 3 (они или 1 или 2 и чередуются), так что если знать это (или проверить) то дальше всё предельно очевидно: сумматор по модулю 3, в который добавляется 1 или 2 каждый следующий бит (если бит=1), и когда сумма=0, то до сего момента принятое число делится на 3. Опять же, главное тут поматанить (совсем чуть-чуть), остальное предельно очевидно, даже конечный автомат в явном виде не надо расписывать.
YuriPanchul Автор
28.06.2022 20:57+1Можно без сумматора. Вот заголовок модуля, попробуйте его наполнить:
module fsm_3_bits_coming_from_right ( input clk, input rst, input new_bit, output reg [1:0] rem ); endmodule
YuriPanchul Автор
28.06.2022 20:57+1случайно запостил вам решение - прошу не показывать
mpa4b
28.06.2022 21:07Ну 1-битный признак 'чётный-нечётный бит', мигающий каждый такт, и сумматор, который от единички чётного бита делает
sum<=(sum+1)%3, а от нечётной единички соответственноsum-1(само собой, что никаких%3писать не надо, просто условиями). Он и будет тем самымrem.
Daffodil
28.06.2022 20:15Скорей всего это знание встроено в компилятор и код типа x%3==0 синтезируется в искомую схему.
mpa4b
28.06.2022 20:17Не синтезируется (нормально).
Один раз у меня прокатило деление 16 бит на 8 за 1 такт, второй раз уже в тайминги не влезло. Пришлось колхозить кастомный делитель (заодно совмещённый с операцией clip, причём бесплатно) и резать его регистрами.
Daffodil
28.06.2022 20:27Ну странно, тулы для программистов такое умеют сколько я себя помню. Видимо хардверные компиляторы сильно отстают.
mpa4b
28.06.2022 21:17+1В моем случае было полноценное деление, а не остаток, как в обсуждаемой задачке от Юрия. И с делением вообще говоря всегда проблемы: любой алгоритм деления является разновидностью того самого деления столбиком из школы, но только в двоичной (или четверичной, или восьмеричной) системе счисления, а это значит, что результат вычисляется стадиями на каждый бит (или 2 или 3 бита), и исходные данные для стадии N являются выходом стадии N-1. Как следствие -- получаются длиннющие цепочки логики, не влезающие в быстрый такт. Получается, что разработчик должен в явном виде порезать деление регистрами на конвеер или поставить блок, который неконвеерно вычисляет результат за несколько тактов, а какой именно длины или сколько тактов -- зависит от всего: от ширины векторов, от техпроцесса, от частоты. При этом от длины этого конвеера или задержки делителя зависит вся остальная логика. В этом последнем и проблема, из-за чего такая халява, как с кодом для процессоров -- не прокатывает.
IvanSTV
29.06.2022 10:31+1люди, имеющие опыт практической работы, абстрактные задачи решают обычно с большими трудностями, чем студенты. Студенты иных задач не решают.
Дай студенту задачу по расчету оптимального маршрута по складу, он сразу начнет описывать графы.
Дай мне задачу по расчету оптимального маршрута по складу, я накидаю тут же кучу дополнительных, уточняющих вопросов по процессам. И, возможно, что процессы таковы. что до графов вообще не дойдет, но задача будет решена...
Dinxor
29.06.2022 20:36+1"A binary number is divisible by 3 iff the sum of the odd bits is equal to the sum of the even bits"
Иногда даёт ложноотрицательные срабатывания. Например, 21 = 0b10101 очевидно делится на 3, но суммы бит разные.
mpa4b
29.06.2022 21:40+1На самом деле я тоже пришёл к такому выводу, что это неверный признак. Скорее его следует модифицировать, ну например если разница между этими суммами кратна 3, то и число тоже. Это определение позволяет его считать рекурсивно, точно так же, как и можно считать признак делимости на 3 в десятичной системе. Для случая прохождения числа побитно, разницу этих сумм можно считать на лету в 2-битный сумматор по модулю 3.
Daffodil
28.06.2022 20:10Является ли Samsung Tier-1 компаний в США для соискателей не корейского происхождения? Идут ли к вам люди из лидеров индустрии вроде Apple или NVidia?
YuriPanchul Автор
28.06.2022 20:54+1Конечно. Сейчас у нас в Samsung совместный проект с AMD, в котором мы взяли их RTL код который используется в игровых приставках и переделываем его для low-power и разных уровней производительности, чтобы можно было играть в трехмерные игры на телефонах и планшетах, а также показывать продвинутую графику на дисплее в автомобиле. См. https://www.anandtech.com/show/14492/samsung-amds-gpu-licensing-an-interesting-collaboration
При этом появляется куча микроархитектурных задачек ровно такого же уровня как и в Apple и NVidia, но у нас в группе бОльше возможностей to make a difference, так как в Apple все части разработки сильно разделены, а всемирные тиражи у нас поболее чем у NVidia.
mpa4b
28.06.2022 21:22Если не секрет, в чём смысл брать именно код АМД, ведь существует не один и не два вендора, предлагающих GPU именно для мобильников. Ну например vivante, imagination. Единственный вариант, который я тут вижу -- чтобы получить программную совместимость с амд карточками. Но скорее всего дело в чем-то другом, если не секрет, расскажите :)
YuriPanchul Автор
28.06.2022 21:31+1Vivante - low end, Imagination не имеет некоторых high-end features. Программная совместимость с амд - это да, важный фактор.
Daffodil
28.06.2022 21:51А AMD не возражает против того что Samsung будет конкурировать с ней на рынке ноутбуков?
YuriPanchul Автор
28.06.2022 22:02+1Там области непересекающиеся или пересекающиеся совсем по грани. Но я тут ничего не знаю - я в бизнес-негошиировании или маркетинге никак не участвую, я верилог для математических операций с треугольниками пишу, c рассовыванием их по разным буферам и памятям.
Daffodil
28.06.2022 23:25А на какой операции над треугольником специализируется ваш отдел? Вы его растеризуете или ищите точку пересечения треугольника с лучом?
YuriPanchul Автор
28.06.2022 23:30+1Я в части геометрических преобразований - перспектива, удаление лишнего из сцены - geometry engine. Растеризация (pixel pipe) - это другая группа, как и ray tracing. Еще есть группа шейдеров (процессоров для обработки специализированными программами) и группа которая это все контролирует.
IvanSTV
29.06.2022 09:14Один соискатель написал что он программировал на языке Jovial, думая что ему просто поверят (на этом языке американские военные писали программы в старину). Соискателю не повезло: я однажды пролистал книжку по Jovial в библиотеке Стенфорда. Выражение лица соискателя, когда я задал ему вопрос про Jovial, было бесценно.
-Ну вот я в свое время программировал на фортране. Но это было последний раз в 1994 году, и спектр задач был специфически- вычислительный. Задай мне сейчас конкретный вопрос по фортрану, я на нем ничего не изображу. Максимум - вспомню некотрые особенности и подходы языка, с которыми сталкивался и на которые обратил в свое время внимание. Это не значит, что я на фортране никогда ничего не писал. Аналогично 1С - я последний раз в ней ковырялся в 2005 году, и очень нерегулярно, с очень ограниченным кругом задач.
Вообще странный подход, почему если не готов с налета рассказать про что-то на собеседовании, об этом не надо писать в резюие? Такие записи демонстрируют в первую очередь софт-скиллы, в частности, способности к обучению и работе в разных средах, равно как и наличия общего представления о среде разработки.
Готовых специалистов с широкими и одновременно глубокими знаниями по каждой теме практически не существует. Существуют люди, поверхностно знакомые с многим, но в случае необходимости углубляющиеся в предмет.
YuriPanchul Автор
29.06.2022 09:26+2*** Задай мне сейчас конкретный вопрос по фортрану, я на нем ничего не изображу ***
Вам не нужно помнить детали работы например фортрановского оператора EQUIVALENCE с массивами разных типов. Ну раз уж вы внесли фортран в свое резюме, то вы должны помнить что-то общее, например чем механизм передачи параметров в фортране отличается от других языков программирования. Если вы не помните ничего, я лично рекомендую просто удалить фортран из резюме, потому что такие как я вам будут вам попадаться.
*** Такие записи демонстрируют в первую очередь софт-скиллы, в частности, способности к обучению ***
Чтобы такая запись что-то демонстрировала, она должна быть проверяемой. А если она не проверяема, то откуда интервьюер знает, что в резюме соответсвует реальным рабочим навыкам, а про что вы просто помните название?
IvanSTV
29.06.2022 10:09+1Если вы не помните ничего, я лично рекомендую просто удалить фортран из резюме, потому что такие как я вам будут вам попадаться.
Как раз про EQUIVALENCE и массивы я что-то помню, ибо нам...хался с этим в свое время, будучи сопливым школьником :) Такое трудно забыть....
Я еще раз повторяю, что такие как вы, некорректно оцениваете резюме и делаете неверные выводы. Если вам кандидат указал язык, но не смог на языке ничего изобразить, то надо просто уточнить объем и конкретный опыт работы, а не отсеивать как совравшенго.
Чтобы такая запись что-то демонстрировала, она должна быть проверяемой. А если она не проверяема, то откуда интервьюер знает, что в резюме соответсвует реальным рабочим навыкам, а про что вы просто помните название?
Достаточно спросить. какие именно задачи решал или дать кусок кода комментировать, а не пытаться попасть вопросом в знакомую интервьюируемому область. Вы можете просто не попасть и сделать неверные выводы.
К вопросу, буквально на днях пытался мужику объяснить кусочек объектной модели языка, и шло туго. Потом выяснил, что человек практически умеет писать код, и делает это на неплохом уровне. но банально не имеет теоретической подготовки и не понимает терминологии. Может оказаться, что человек просто можетне понять фразу "механизм передачи параметров ". Например, я фортран изучал по Мак-Кракену, там не было этого термина. Если бы вы спросили меня, "какой механизм передачи параметров в фортране" в 1995 году, то я бы тупо не понял вопрос.
YuriPanchul Автор
29.06.2022 23:20*** Достаточно спросить. какие именно задачи решал ***
Так именно для этого предназначено резюме - написать, какие он задачи решал. А то подход "напишу все, а потому уточню на словах" напоминает мне работу аэропорта Абу-Даби, где оказывается, недостаточно смотреть на табло с объявлениями о регистрации, но нужно еще и спросить у стоящего неподалеку служителя, в какое время точно начинатся и заканчивается регистрация (я так пропустил самолет, так как на табло была неверная информация).
Я данной рекомендацией хочу людям помочь, снизить их риски, потому что то, что вы назвали "странным подходом", на самом деле достаточно распостранено.
*** а не отсеивать как совравшенго. ***
Я не отсеиваю только на основе одного вопроса. В случае с кандидатом с Jovial (дело было в 2010 году), у него все резюме состояло из каких-то забытых вещей - я вначале спросил его про SystemVerilog, он сказал что больше использовал Verilog-2001/95, я задал ему вопрос про Verilog, он сказал что он больше использовал VHDL, я спросил про VHDL, он тоже плавал, потом он зачем-то упомянул Аду, я задал вопрос про механизм рандеву в параллельных процессах на Аде, и вот потом настал черед Jovial-а. То есть он просто прыгал с темы на тему, пытаясь найти что-то, по чему я не смогу ему задать вопрос и махну рукой. А я его преследовал прыжками, как гепард антелопу, и довел до Джовиала.
Лучше просто найти несколько областей, которые человек знает твердо и составить резюме из них. А то, что он обучаем, это будет и так видно, по тому как он решает задачи (я всегда помогаю если человек пытается решить что-то для него новое).
*** Может оказаться, что человек просто можетне понять фразу "механизм передачи параметров ". Например, я фортран изучал по Мак-Кракену, там не было этого термина. Если бы вы спросили меня, "какой механизм передачи параметров в фортране" в 1995 году, то я бы тупо не понял вопрос. ***
С терминологией вопрос тонкий, это да. Если скажем у человека стоит в резюме Фортран еще с чем-нибудь, скажем с Паскалем или Си, можно спросить "в фортране передача параметров по ссылке или по значению?" А если не поймет, то написать код с вызовом сабрутины и спросить, какое число будет в переменной после выполнения.
te3s
29.06.2022 13:45+3Довольно олдовый и скучный подход к собесам. В резюме достаточно просто напихать buzzwords (за которые надо бы уметь пояснить), чтобы триггернуть hr-а. Лучший собес для обеих сторон это беседа про то, какие задачи удалось решить, какие не удалось, какими способами. Фрешградам можно дать порешать какие-то задачки, потому что опыта у них еще нет. Требование выдать околорабочий код за 5-10 минут на собесе для решения задачки из учебника (которая в реальной разработке никогда и не встретится) довольно бесполезное требование. Такого формата собеседования ничего по сути и не проверяют. Только вгоняют в стресс соискателя, да и самому интервьюеру надо тратить время и готовиться к таким собесам. Очень неэффективный формат. Почему?
Да потому что можно уметь решать такие задачки за время собеса и быть очень хорошим разработчик, а можно и не уметь, и тоже быть очень хорошим разработчиком. Т.е. такой формат хороших разработчиков не отбирает, а отбирает людей, умеющих решать "необычные" задачки в реальном времени. После такого процесса найма часто оказывается, что все в команде умеют очень эффективно "обрабатывать треугольники", но никто не умеет писать понятный поддерживаемый код, вести внятную документацию и работать именно с процессом разработки.Вообще в HW (да и в embedded) есть определенный пул вопросов, который надо знать на разных уровнях профессионализма. Вот их и можно обсуждать, да и то +/- в общем виде. Специфика работа такова, что можно за 20 лет опыта ни разу не столкнуться с реализацией и внедрением методик оптимизации по мощности, например. Или с интерфейсами, или с арифметикой. Да, надо знать все эти вопросы в общем виде, но вот набить руку на практике может и не получится. А если методика найма подразумевает, что все эти вопросы опыт соискателя должен покрывать, причем с примерами из практики, то воронка найма очень сильно сужается.
Ни одного вопроса про разработку и процессы в статье не заметил. А в HW с этим все очень и очень плохо. В больших компаниях не все до сих пор перешли на git, не говоря уже о CI/CD и прочих полезных практиках. И ведь ничего этому не мешает, кроме отсталости и ретроградства самих разработчиков. Документация пишется кое-как после проекта, причем часто в вордовских файлах, распространяющихся через шейрпоинт какой-нибудь. Хороший тулинг тоже отсутсвует, чаще всего это кривые скрипты на каком-нибудь tcl (благо, ситуация вроде меняется и молодые разработчики хотя бы интересуются тем же питоном). Зато все умеют делить в RTL на 3. Почему-то считается, что надо обладать каким-то особым экспертным знанием, "ноу-хау". Но дело в том, что как только это ноу-хау попало в хорошо управляемую и версированную кодовую базу, то это больше не ноу-хау. Гораздо важнее умение выстроить процесс разработки. Увы, но лет через 10 HLS вытеснит RTL и HW разработка (для большинства задач) станет очень и очень похожа на разработку софта. Поэтому не стоит уже сейчас цепляться за решение "необычных" задачек, а стоит все больше обращать внимание на то, насколько способны люди поддерживать общий большой проект без превращения его в дремучее легаси. Как-то так.
YuriPanchul Автор
29.06.2022 21:52+1*** Довольно олдовый и скучный подход к собесам. ***
Может он и олдовый и скучный, но это текущий процесс на RTL (Register Transfer Level) и DV (Design Verification) позиции в крупных электронных компаниях в Калифорнии - Apple, NVidia, Intel, AMD, Juniper, Samsung, Xilinx итд.
*** В резюме достаточно просто напихать buzzwords (за которые надо бы уметь пояснить), чтобы триггернуть hr-а. ***
HR в данных коллективах включается только в конце, при обсуждении оффера. Или вы имеете в виду компанейского рекрутера? Но я же написал, что пройти рекрутера - это небольшой шаг, не то, где главная битва.
*** Требование выдать околорабочий код за 5-10 минут на собесе для решения задачки из учебника (которая в реальной разработке никогда и не встретится) довольно бесполезное требование. Такого формата собеседования ничего по сути и не проверяют. Только вгоняют в стресс соискателя, да и самому интервьюеру надо тратить время и готовиться к таким собесам. Очень неэффективный формат. Почему? ***
Вы возможно невнимательно прочитали мой текст. Я нигде не предлагал давать задачки прямо из учебника. Наоборот, я написал "Столкнувшись с задачей чуть дальше учебника".
Вообще я предлагаю задачки двух классов: отсекающие и жизненные.
Отсекающая: Если человек не может написать простой конечный автомат на языке описания аппаратуры Verilog, то как он сможет работать с блоком на 200 тысяч строк?
Жизненная: Я вообще предлагаю задачки типа тех, которые решаются у нас на производстве - соединить какие-нибудь очереди FIFO или там расшерить память между читающими-пишущими блоками. Или оптимизировать на энергопотребление с помощью enables. На таких задачках можно увидеть, как человек рассуждает и что он будет делать с таким на рабочем месте.
*** Т.е. такой формат хороших разработчиков не отбирает, а отбирает людей, умеющих решать "необычные" задачки в реальном времени. ***
В реальном времени можно посмотреть как человек думает, что он делает на автомате (например определение глубины очереди FIFO для достаточной пропускной способности блока - необходимый навык отделяющий опытных инженеров от неопытных).
Как я писал выше, я часто даю и "домашнюю работу" в виде "давайте посмотрим что вы напишете сейчас за полчаса, чтобы понять как вы начинаете, потом обсудим что у вас получилось и потом вы сделаете окончательно работающее решение дома". (Хотя такое практикуется в компаниях редко - кроме меня это еще делала менеджерка в Juniper).
*** но никто не умеет писать понятный поддерживаемый код, вести внятную документацию и работать именно с процессом разработки. ***
Хаос в коде можно частично словить и за полчаса. Как и аккуратность в рисовании микроархитектурных диаграмм и понятность в объяснении. Я об этом написал: "Рассказ о том, что вы делали на предыдущей работе, должен быть хорошо структурирован. Сначала нужно описать чип или ядро, внутри которого вы разрабатывали или верифицировали блок. Потом вам нужно нарисовать на доске (реальной или виртуальной в зуме) ключевые элементы вашего блока (интерфейсы, памяти, очереди FIFO), описать ход транзакций между ними и микроархитектурные проблемы, которые при этом возникали"
*** Специфика работа такова, что можно за 20 лет опыта ни разу не столкнуться с реализацией и внедрением методик оптимизации по мощности, например. ***
Вы о каких типах дизайна говорите? И в моем блоке чипа для GPU телефона энергопотребление важно (иначе у телефона сядет батарейка), и в предыдущем проекте чипа для магистрального роутера (иначе там нужер вводить более суровую систему охлаждения), поэтому каждый разработчик однозначно должен владеть clock-gating-ом и на микроуровне (с enable), и на уровне подблоков как минимум в теории (пользованию конкретными тулами типа Atrenta SpyGlass Power или Mentor Power Artist или Synopsys PTPX или Cadence Joules - компании учат на внутренних трейнингах).
*** Или с интерфейсами ***
Если человек не может закодировать простой valid/ready интерфейс, то у него вообще нет опыта и он за чтение базовых учебников никогда не вылезал. А старшие инженеры как правило понимают credit based flow control, так как во всех конторах от Apple до Juniper его используют для внутренних интерфейсов между подблоками, и если он его не знает, встает вопрос что он там делал.
*** , или с арифметикой ***
Я про арифметику не писал. Задачка про остаток от деления на 3 - это на самом деле не задачка на арифметику, а завуалированная задачка на конструирование простого (из трех состояний) конечного автомата.
Про арифметику достаточно общего понимания какие операции являются дорогими в смысле тайминга в пикосекундах внутри такта (умножение), а какие требуют конвейерного блока для работы на высокой частоте (floating point например). Это автоматически приходит с опытом оптимизации на основе static timing analysis report, и это можно не спрашивать на интервью помимо общих вопростов типа "что вы делаете с setup violations / negative slack".
** Да, надо знать все эти вопросы в общем виде, но вот набить руку на практике может и не получится. ***
Если у человек скажем три года опыта как RTL designer, то у него должно присутствовать понимание какие операции тяжелые в смысле тайминга, а какие нет. Если он никогда не анализировал static timing analysis report, то это какой-то странный проектировщик, типа программиста, который умеет писать только if и вызовы функций, но не умеет писать циклы.
*** Ни одного вопроса про разработку и процессы в статье не заметил. А в HW с этим все очень и очень плохо. В больших компаниях не все до сих пор перешли на git, не говоря уже о CI/CD и прочих полезных практиках. ***
Многие электронные компании еще лет 20 назад подсели на Perforce и используют Git поверх перфорса. Ничего принципиального в этом скилле нет - дать человеку шпаргалку на страницу, чтобы он умел использовать perforce или git в данной организации - это просто. А вот научить его микроархитектуре, как строить конвейер, разделять память и скрывать латентность - это гораздо более сложный скилл.
Насчет CI/CD - многие электронные компании сейчас используют Jenkins, в этом тоже ничего особого нет, трейнинг за полчаса.
*** Документация пишется кое-как после проекта, причем часто в вордовских файлах, распространяющихся через шейрпоинт какой-нибудь. ***
Я не знаю, о каких компаниях вы говорите, в компаниях в которых я был, имеется процесс - сначала архитект чипа пищет архитектурную спецификацию на блок, потом микроархитект блока пишет микроархитектурную спецификацию с деталями конвейера и очередей, и только потом пишется RTL код.
*** Хороший тулинг тоже отсутсвует, чаще всего это кривые скрипты на каком-нибудь tcl (благо, ситуация вроде меняется и молодые разработчики хотя бы интересуются тем же питоном). ***
Это не то, что я вижу. В компаниях имеется смесь из Tcl, Perl, Python, Ruby, Bash, Make и проприетарных языков типа SystemRDL, и сдвиг в сторону питона уже лет 10 минимум.
*** Зато все умеют делить в RTL на 3. Почему-то считается, что надо обладать каким-то особым экспертным знанием, "ноу-хау". Но дело в том, что как только это ноу-хау попало в хорошо управляемую и версированную кодовую базу, то это больше не ноу-хау. ***
А вы точно читали мою заметку - или только комментарии к ней? Я наоборот, пишу, что популярный вопрос про остаток от деления на 3 стоит на всех интервьюшных сайтах уже 100 лет (точнее 20 лет точно) и поэтому в чистом виде неактуален. И он вообще не про деление.
*** Увы, но лет через 10 HLS вытеснит RTL и HW разработка (для большинства задач) станет очень и очень похожа на разработку софта. ***
Аааааааааа, вы сторонник HLS. Ой, зачем же я это все написал выше. Я же основатель стартапа в HLS еще в 1996-2001 годах ( https://en.wikipedia.org/wiki/C_Level_Design ). Я речь "лет через 10 HLS вытеснит RTL" впервые услышал от Synopsys на Design Automation Conferece в 1996 году, причем именно этими словами. И потом сам говорил такие речи и слушал их от пары десятков компаний.
Реальность такова: все крупные компании попробовали HLS в каких-то нишевых задачах, и плюнули на это дело. Потому что надежнее написать конвейер в явной форме, а не массажировать Си код прагмами.
*** Поэтому не стоит уже сейчас цепляться за решение "необычных" задачек, а стоит все больше обращать внимание на то, насколько способны люди поддерживать общий большой проект без превращения его в дремучее легаси. Как-то так. ***
Задачки у меня самые обычные, я как-раз остаток от деления на 3 не даю, а даю например написать gearbox, которые в реальных дизайнах встречаются часто. Поддержка большого проекта - вы про аккуратность в параметризации, чистые интерфейсы и вменяемую модульную иерархию? Аккуратность необходима, но ею нельзя заменить способность решать микроархитектурные задачки - кому нужет аккуратный человек, дизайн которого вставляет пустые такты в потом обработки данных, отчего производительность блока падает вдвое.
te3s
30.06.2022 01:44Может он и олдовый и скучный, но это текущий процесс на RTL (Register Transfer Level) и DV (Design Verification) позиции в крупных электронных компаниях в Калифорнии - Apple, NVidia, Intel, AMD, Juniper, Samsung, Xilinx итд.
Крупные не значит хорошие. Как раз таки крупные и страдают больше всего от плохих и отсталых процессов. Если что-то используется крупной компанией, это не означает автоматически, что это какая-то хорошая практика. Вполне вероятно, что это просто тяжелое наследие, продолжающее существовать из-за ригидности больших компаний.
Вы возможно невнимательно прочитали мой текст. Я нигде не предлагал давать задачки прямо из учебника. Наоборот, я написал "Столкнувшись с задачей чуть дальше учебника".
Из учебника или нет, на валидность моего тезиса и дальнейшее рассуждение это никак не влияет.
Если человек не может написать простой конечный автомат на языке описания аппаратуры Verilog, то как он сможет работать с блоком на 200 тысяч строк?
Серьезно? Блок на 200 тысяч строк? Какой же ужас творится в "крупных электронных компаниях в Калифорнии".
В реальном времени можно посмотреть как человек думает, что он делает на автомате (например определение глубины очереди FIFO для достаточной пропускной способности блока - необходимый навык отделяющий опытных инженеров от неопытных).
Каким образом определение глубины очереди FIFO "на автомате", а не за полчаса, например, отделяет опытного разработчика от неопытного? Это очень смахивает на какое-то когнитивное искажение. Если я очень часто или в данный момент времени часто сталкиваюсь с какой-то задачкой, то мне тоже начинает казаться, что остальные должны это понимать и делать "на автомате", но это неправда.
Вы о каких типах дизайна говорите? И в моем блоке чипа для GPU телефона энергопотребление важно (иначе у телефона сядет батарейка), и в предыдущем проекте чипа для магистрального роутера (иначе там нужер вводить более суровую систему охлаждения), поэтому каждый разработчик однозначно должен владеть clock-gating-ом и на микроуровне (с enable), и на уровне подблоков как минимум в теории (пользованию конкретными тулами типа Atrenta SpyGlass Power или Mentor Power Artist или Synopsys PTPX или Cadence Joules - компании учат на внутренних трейнингах).
Частенько бывает так, что в самом начале новенькое ядро не вызывает проблем с мощностью, да и даже с таймингами на чипе. И только потом, когда появляются новые фичи, ядро растет, такие проблемы могут себя проявить. Да, мощность это важно, но можно и не столкнуться с такой проблемой, если ты просто дизайнер. Clock gating это базовая техника, о ней все должны знать и применять автоматически. Все остальное, ну такое. Да, есть специальные тулы, каждый ли дизайнер должен ими владеть? Нет, не каждый. Достаточно просто написать нормальный дженкинсовский пайплайн, который сам все сделает и вернет отчет дизайнеру. Это больше что-то на уровне архитекторов, которые должны решить, какие техники мы применяем и раздать гайдлайны дизайнерам. А лучше опять же построить нормальный CI пайплайн.
Если человек не может закодировать простой valid/ready интерфейс, то у него вообще нет опыта и он за чтение базовых учебников никогда не вылезал. А старшие инженеры как правило понимают credit based flow control, так как во всех конторах от Apple до Juniper его используют для внутренних интерфейсов между подблоками, и если он его не знает, встает вопрос что он там делал.
Вот это очень интересный момент. Да, с одной стороны это правда, что если не может закодировать простой valid/ready интерфейс, претендуя на реальный опыт, это странно. Но с другой стороны, а нужно ли кодировать valid/ready интерфейс? Я понимаю, что в HW зоопарк технологий и подходов. Но вроде бы обычно используется axi/apb, для этого доступны генераторы кода. Т.е. как бы нет никакой нужды писать это руками. Даже если у вас свой кастомный интерфейс между блоками, так напишите для него генератор один раз и используйте, зачем каждый раз писать один и тот же credit based flow control? Старшие инженеры понимают его как раз потому, что пишут его каждый раз руками, вместо того, чтобы написать (или лучше взять опенсорсный) питоновский генератор, что отнюдь не добавляет им плюсов как хорошим разработчикам. Господи, даже если я не знаю, как писать этот ваш credit based flow control. Покажите мне один раз реализацию, и я пойму, как это написано, очень быстро. Т.е. это не какой-то супер важный скилл, по которому можно отсекать людей на собесах.
Я про арифметику не писал. Задачка про остаток от деления на 3 - это на самом деле не задачка на арифметику, а завуалированная задачка на конструирование простого (из трех состояний) конечного автомата.
Да какая разница, какая задачка? Опять же, это не какие-то супер знания, на освоение которых уходят годы. Вы просто нормальные гайдлайны на проекте напишите, где будет сказано, как вы работаете с автоматами или с арифметикой, какие техники для оптимизации по мощности применяете, и все. Линтер натяните, чтобы эти правила соблюдались. Это не надо запоминать, все, о чем вы говорите, легко решается процессами и разумной автоматизацией (jenkins пайплайны, код чекинг и т.д.).
Многие электронные компании еще лет 20 назад подсели на Perforce и используют Git поверх перфорса. Ничего принципиального в этом скилле нет - дать человеку шпаргалку на страницу, чтобы он умел использовать perforce или git в данной организации - это просто. А вот научить его микроархитектуре, как строить конвейер, разделять память и скрывать латентность - это гораздо более сложный скилл.
Так вы дайте ему шпаргалку по микроархитектуре на страницу, чтобы он строил конвейер, как вы договорились, разделял память и скрывал латентность. Об этом и речь, что большинство вопросов покрывается нормальными процессами и гайдлайнами. Сложности разработки возникают совершенно в других местах.
Насчет CI/CD - многие электронные компании сейчас используют Jenkins, в этом тоже ничего особого нет, трейнинг за полчаса.
Многие используют, многие нет. Речь о том, что проникновение хороших практик из SW в HW довольно слабое. Опять же, кто и как пишет вам пайплайны, автотесты? Вот очень интересно, как решается эта проблема в HW компаниях Калирофнии. Это входит в набор скиллов верификатора? Разработчик должен предоставить автотест (хотя бы sanity) для своего блока?
типа программиста, который умеет писать только if и вызовы функций, но не умеет писать циклы.
Здесь я пошучу, но можно вообще не писать циклы, если это функциональщина :)
Я не знаю, о каких компаниях вы говорите, в компаниях в которых я был, имеется процесс - сначала архитект чипа пищет архитектурную спецификацию на блок, потом микроархитект блока пишет микроархитектурную спецификацию с деталями конвейера и очередей, и только потом пишется RTL код.
Ну, процесс-то имеется, вопрос в том, работает ли? То же SW уже прошло этот этап и признало такой подход медленным и просто неадекватным реальности. Очень часто приходится видеть на практике, как вносится множество правок в такого рода документы уже после реализации. Ну не работает то, что вы здесь описываете. Опять же это очень архаично, когда-то, может быть, работало для простых систем, но для чего-то +/- сложного не работает это. Да и вы здесь умолчали о том, в каком формате пишутся файлы и как хранятся. Признайтесь, это ворд и шейрпоинт, да?)
Это не то, что я вижу. В компаниях имеется смесь из Tcl, Perl, Python, Ruby, Bash, Make и проприетарных языков типа SystemRDL, и сдвиг в сторону питона уже лет 10 минимум.
Надо просто сжечь скрипты на tcl (ну если это не фронтенд проприетарных тулов) и perl. Да и с bash и make уже надо завязывать. Ну не поддерживаемо все это. Сдвигаются лет 10 все никак сдвинуться не могут, потому что практики, что в разработке, что в менеджменте отсталые и неэффективные, что особенно поражает, когда рядом есть SW, из которого просто можно воровать все хорошее и получать лайки. Не уверен насчет проприетарности SystemRDL (точнее, это как посмотреть), вроде стандарт открытый и есть открытый же компилятор. Ну и вы представьте, какую-нибудь SW компанию, которая говорит, что у них есть какие-то скрипты на perl, который до сих пор используются для автоматизации рутинных задач. Смешно же, ну. А вот HW этим гордится. Хотя гордится нечем.
А вы точно читали мою заметку - или только комментарии к ней? Я наоборот, пишу, что популярный вопрос про остаток от деления на 3 стоит на всех интервьюшных сайтах уже 100 лет (точнее 20 лет точно) и поэтому в чистом виде неактуален. И он вообще не про деление.
Да какая разница какая задача опять же. Я вот вас спрошу на собесе про что-то, что вам не встречалось, а потом скажу, что мол вы нам не подходите, потому что за оптимальную реализацию CIC фильтра сходу не пояснили. А то, что вы отличный разработчик и, если надо, в этом за пару дней разберетесь, ничего не значит. Нет, значит нет.
Реальность такова: все крупные компании попробовали HLS в каких-то нишевых задачах, и плюнули на это дело. Потому что надежнее написать конвейер в явной форме, а не массажировать Си код прагмами.
10 лет или не 10, не знаю. Но все рано или поздно придет к этому. Ну никому не нравится писать на HDL, давайте будем честны. Те, кто говорят, что им нравится, страдают от стокгольмского синдрома. Мне кажется, что было много разработчиков (да и сейчас встречаются), которые утверждали, что ассемблер надежнее и они всегда напишут лучше, чем копилятор. Увы, компиляторы победили. Это вопрос времени.
Задачки у меня самые обычные, я как-раз остаток от деления на 3 не даю, а даю например написать gearbox, которые в реальных дизайнах встречаются часто.
Так если часто, вы вынесите в либу и не паритесь, зачем людей мучать?)
кому нужет аккуратный человек, дизайн которого вставляет пустые такты в потом обработки данных, отчего производительность блока падает вдвое.
Есть такая практика, как код ревью. Вы один раз человеку покажите, что он делает не так и как надо, и вопрос решен.
Мое личное мнение. Вы супер опытный и крутой человек из HW и без сомнения с крутыми скиллами, сделавший очень многое для популяризации этой области среди российских студентов и школьников. Здесь вам можно только поаплодировать стоя. Но у HW разработки есть очевидная проблема. Это ее отсталость. SW гораздо более конкурентная и многочисленная область, поэтому прогресс там произошел значительно быстрее. Многие вещи, которые вы считаете важными, в SW уже давно отмели, как незначительные. Этот путь, который только предстоит пройти HW уже пройден в SW. Не надо наступать на те же грабли. Большинству компаний в SW, на подавляющее большинство позицией в SW не нужно жесткое алгоритмическое интервью, не нужно уметь на доске в режиме реального времени писать рабочий код для переворачивания бинарных деревьев. Важны, по-настоящему важны, совершенно другие вещи. HW еще видимо не совсем освоилось с идеей открытых доступных либ, версирования и прочего, иначе как объяснить эту странную страсть к подсчетам остатков от деления числа, приходящего бит за битом? Зачем это знать всем, если Панчул может написать оптимальную реализацю, которую мы все можем просто использовать в своих проектах? Это же трата времени и денег, разве не так?
YuriPanchul Автор
30.06.2022 02:50+1*** Серьезно? Блок на 200 тысяч строк? Какой же ужас творится в "крупных электронных компаниях в Калифорнии". ***
Под словом "блок" я разумеется имею в виду не Verilog module / VHDL entity, а подсистему в которой может быть 200 modules
*** Каким образом определение глубины очереди FIFO "на автомате", а не за полчаса, например, отделяет опытного разработчика от неопытного? Это очень смахивает на какое-то когнитивное искажение. Если я очень часто или в данный момент времени часто сталкиваюсь с какой-то задачкой, то мне тоже начинает казаться, что остальные должны это понимать и делать "на автомате", но это неправда. ***
Если у человека стоит в резюме что он работал скажем в Cisco или Juniper дизайнером блока (как я), то там такое встречается на каждом шагу и без этого в будет агония в отладке. Там ничего сложного нет на самом деле - нужно складывать латентности конвейера и длины промежуточных FIFO, следя за размерами кусков данных. Если этого навыка нет, то человек такой блок или не дизайнил, или делал вспомогательную работу.
*** Достаточно просто написать нормальный дженкинсовский пайплайн, который сам все сделает и вернет отчет дизайнеру. Это больше что-то на уровне архитекторов, которые должны решить, какие техники мы применяем и раздать гайдлайны дизайнерам. А лучше опять же построить нормальный CI пайплайн. ***
Прекрасно, вот вам дженкинс дал отчет, что вот в таком подблоке у вас высокое энергопотребление. Что вы с этим делаете?
module shift_reg # ( parameter width = 256, depth = 10 ) ( input clk, input [width - 1:0] in_data, output [width - 1:0] out_data ); reg [width - 1:0] data [0: depth - 1]; always @ (posedge clk) begin data [0] <= in_data; for (int i = 1; i < depth; i ++) data [i] <= data [i - 1]; end assign out_data = data [depth - 1]; endmodule*** Но вроде бы обычно используется axi/apb, для этого доступны генераторы кода. Т.е. как бы нет никакой нужды писать это руками. ***
Внутри обычного AXI пять valid/ready интерфейсов, по одному на каждый канал - AWVALID/AWREADY, то же для AW, W, R и B. Внутри AXI Stream один.
С помощью AXI связываются крупные блоки, причем как правило (если мы не говорим про stream) блоки, у которых есть адрес или register ID - процессорные ядра, кластеры, DMA итд. Связывать с помощью AXI все мелкие блочки в иерархии - это вычурно (в нем много лищнего) и негибко (иногда можно обойтись только valid, иногда нужен интерфейс с кредитами).
*** Старшие инженеры понимают его как раз потому, что пишут его каждый раз руками, вместо того, чтобы написать (или лучше взять опенсорсный) питоновский генератор, что отнюдь не добавляет им плюсов как хорошим разработчикам. ***
Для этих целей в компаниях есть своя библиотека модулей и генераторов, но проще писать свои макросы. Насчет опенсорсного - а вы можете дать ссылку?
*** Господи, даже если я не знаю, как писать этот ваш credit based flow control. Покажите мне один раз реализацию, и я пойму, как это написано, очень быстро. Т.е. это не какой-то супер важный скилл, по которому можно отсекать людей на собесах. ***
Это не то что rocket science, но просто некий индикатор его истории проектов.
*** Да какая разница, какая задачка? Опять же, это не какие-то супер знания, на освоение которых уходят годы. ***
Ну если человек будет с нуля тренироваться на новой работе как писать конечные автоматы, то он будет отбирать время у своих старших коллег.
*** Так вы дайте ему шпаргалку по микроархитектуре на страницу, чтобы он строил конвейер, как вы договорились, разделял память и скрывал латентность. ***
А тут нет простой шпаргалки, тут чтобы выучиться, нужно решать задачи и сидеть с коллегами их разбирать. Такое можно делать, если человек интерн. Но если он написал в резюме "5 лет опыта", то "назвался груздем - полезай в кузов".
*** Многие используют, многие нет. Речь о том, что проникновение хороших практик из SW в HW довольно слабое. Опять же, кто и как пишет вам пайплайны, автотесты? Вот очень интересно, как решается эта проблема в HW компаниях Калирофнии. Это входит в набор скиллов верификатора? Разработчик должен предоставить автотест (хотя бы sanity) для своего блока? ***
По искусству верификации хардвер сильно впереди софтвера. Verification plan, formal proof, functional coverage, constrained-random, temporal logic expressions и прочая кухня - это тема отдельного поста.
*** Здесь я пошучу, но можно вообще не писать циклы, если это функциональщина :) ***
Шутку понял :-)
*** Да и вы здесь умолчали о том, в каком формате пишутся файлы и как хранятся. Признайтесь, это ворд и шейрпоинт, да?) ***
Ворд и перфорс, иногда git, да (ворд меня тоже бесит, я предпочитаю писать тексты в HTML).
*** Надо просто сжечь скрипты на tcl (ну если это не фронтенд проприетарных тулов) и perl. ***
Perl отвратительный как язык, но с ним есть интересная комбинация встроенного перла внутри верилога, и питоновского аналога этого я не видел.
Tcl язык конечно неудобный, но он настолько прочно встал как внутренний язык тулов в Synopsys/Cadence/Mentor/Xilinx/Altera итд в начале 1990-х, что его так никто не смог оттуда вычистить.
*** Да и с bash и make уже надо завязывать. ***
Вам сейчас станет страшно, но это не шутка. Во многих электронных компаниях до сих пор shell по умолчанию - это csh. Да, С-shell, и на нем есть скрипты для конфигурации.
*** Не уверен насчет проприетарности SystemRDL (точнее, это как посмотреть), вроде стандарт открытый и есть открытый же компилятор. ***
У RDL есть несколько вариантов в разных компаниях.
*** 10 лет или не 10, не знаю. Но все рано или поздно придет к этому. Ну никому не нравится писать на HDL, давайте будем честны. Те, кто говорят, что им нравится, страдают от стокгольмского синдрома. Мне кажется, что было много разработчиков (да и сейчас встречаются), которые утверждали, что ассемблер надежнее и они всегда напишут лучше, чем копилятор. Увы, компиляторы победили. Это вопрос времени. ***
Компиляторы - это хорошо поставленная задача, а вот HLS - нет, там угадать намерение дизайнера из кода на Си трудно. Например, вы пробовали написать на HLS конвейерное процессорное ядро с байпасами?
*** Задачки у меня самые обычные, я как-раз остаток от деления на 3 не даю, а даю например написать gearbox, которые в реальных дизайнах встречаются часто.
Так если часто, вы вынесите в либу и не паритесь, зачем людей мучать?) ***
Это хорошая задача на понимание что происходит в каждом такте (комбинационная и последовательностная логика, блокирующие и неблокирующие присваивания).
*** кому нужет аккуратный человек, дизайн которого вставляет пустые такты в потом обработки данных, отчего производительность блока падает вдвое.
Есть такая практика, как код ревью. Вы один раз человеку покажите, что он делает не так и как надо, и вопрос решен. ***
Одно дело - делать код ревью с интерном. Но код ревью с человеком, у которого в резюме опыт по каждому мелкому поводу - это безблагодатно.
*** Большинству компаний в SW, на подавляющее большинство позицией в SW не нужно жесткое алгоритмическое интервью, не нужно уметь на доске в режиме реального времени писать рабочий код для переворачивания бинарных деревьев. ***
Даже на позиции в команде писания компиляторов, где сплошные преобразования деревьев?
*** эту странную страсть к подсчетам остатков от деления числа, приходящего бит за битом? Зачем это знать всем, если Панчул может написать оптимальную реализацю ***
Опять же - это не мой вопрос, я спрашиваю другое, я его привел как пример популярного вопроса.
te3s
30.06.2022 13:55Под словом "блок" я разумеется имею в виду не Verilog module / VHDL entity, а подсистему в которой может быть 200 modules
И все это хозяйство должен поддерживать один разработчик? Ужас.
Там ничего сложного нет на самом деле - нужно складывать латентности конвейера и длины промежуточных FIFO, следя за размерами кусков данных. Если этого навыка нет, то человек такой блок или не дизайнил, или делал вспомогательную работу.
Ну вот смотрите, я такие блоки не дизайнил. Но вы весь "навык" сформулировали в одном предложении, теперь он у меня тоже есть. На каком основании вы тогда делаете выводы о качестве разработчика? На основании обладания знанием, которое передается за 30 секунд? Какие-то странные критерии.
Прекрасно, вот вам дженкинс дал отчет, что вот в таком подблоке у вас высокое энергопотребление. Что вы с этим делаете?
Напишу в чатик коллегам "ребят, кто сталкивался, подкиньте идейку". Мне напишут, что "можно двигать не данные, а пойнтеры на данные". Я такой "окей, понял, сейчас будет". Т.е. опять же это не какой-то супер навык отличающий хорошего разраба от плохого.
Для этих целей в компаниях есть своя библиотека модулей и генераторов, но проще писать свои макросы. Насчет опенсорсного - а вы можете дать ссылку?
Ну если есть, так зачем из этого делать критерий отбора на собесе? Вы же уже написали это, зачем вам человек, который будет знать и мочь написать то, что уже написано? Мб про что-нибудь другое лучше поспрашивать? Опенсорсного мало и оно плохое, если честно. В любом случае здесь просто нужно написать генератор (200-300 строк на питоне). А еще лучше выложить его в опенсорс потом и больше не мучать людей вопросами "как написать уже написанное".
Ну если человек будет с нуля тренироваться на новой работе как писать конечные автоматы, то он будет отбирать время у своих старших коллег.
Knowledge sharing и менторство наше все вообще-то, как иначе передавать знания? С такой логикой это очередной замкнутый круг по типу "на стартовую вакансию нужны люди с опытом". Ну и что вы заладили с этими автоматами. Там опять же шаблон меньше, чем на страницу. Любой человек с техническим образованием идею за 5 минут ухватит. И время отбирать у коллег не надо, когда у вас есть внятные гайдлайны, проблема в том, что часто их нет, потому что HW разрабы очень кичатся своими "знаниями" и упорно не шерят их, а все "знания" состоят из двух половиной концепций, схватывающихся на лету.
А тут нет простой шпаргалки, тут чтобы выучиться, нужно решать задачи и сидеть с коллегами их разбирать. Такое можно делать, если человек интерн. Но если он написал в резюме "5 лет опыта", то "назвался груздем - полезай в кузов".
Здесь согласен. Действительно, лучший способ научиться что-то делать, просто пытаться делать это.
По искусству верификации хардвер сильно впереди софтвера. Verification plan, formal proof, functional coverage, constrained-random, temporal logic expressions и прочая кухня - это тема отдельного поста.
Да, с концептуальной точки зрения это так. Но инструменты очень плохие в HW и UVM очень вычурная и усложненная (больше, чем обычно нужно) методология. Хотелось бы упрощения и улучшения инструментов.
Вам сейчас станет страшно, но это не шутка. Во многих электронных компаниях до сих пор shell по умолчанию - это csh. Да, С-shell, и на нем есть скрипты для конфигурации.
Сам в такой работаю, знаю)
Ворд и перфорс, иногда git, да (ворд меня тоже бесит, я предпочитаю писать тексты в HTML).
Ну вот об этом и речь, когда я говорю про отсталость и слабую осведомленность HW о том, что происходит вокруг. Вордовские файлы в гите никто не хранит, их невозможно мерджить и сравнить версии. Вообще никто доки в ворде не пишет. Про "писать тексты в HTML" тоже не понял. Вы на HTML доку пишете?
Обычно дока пишется в markdown (или что-то похожее) и хранится в одном репозитории с кодом. Дальше есть генераторы и паблишеры, которые вам хоть HTML, хоть PDF отрендерят или на корпоративном конфлюенсе запостят, если надо.Даже на позиции в команде писания компиляторов, где сплошные преобразования деревьев?
Вы намеренно утрируете сказанное. Мы же с вами прекрасно понимаем, что 99% SW это не написание компиляторов. То же самое с HW. Есть множество проектов, компаний, устройств, где нет тех или иных проблем, связанных с дизайном. Я все-таки настаиваю на том, что важнее как человек мыслит, может ли понятно изложить свои идеи, думает ли о том, как в будущем будет "жить" его код, кто с ним будет работать, тяжело или легко это поддерживать, масштабировать. Это сейчас важнее, потому что это пока что сложно формализовать и передать в виде знания. А особенности предметной области, будь это оптимизация по мощности или алгоритмические "фишки" передаются в виде пары слайдов и гайдов.
vvzvlad
30.06.2022 23:44+1*** Большинству компаний в SW, на подавляющее большинство позицией в SW не нужно жесткое алгоритмическое интервью, не нужно уметь на доске в режиме реального времени писать рабочий код для переворачивания бинарных деревьев. ***
Даже на позиции в команде писания компиляторов, где сплошные преобразования деревьев?
Цитаты собеседника лучше оформлять с помощью blockquote-тега (кавычки в панели кнопок редактора комментарий)
vconst
29.06.2022 14:51+2с компаниями, которые делают упор на бихевиоральное интервью, имхо лучше вообще не связываться
Так вот что это было…
Ну, значит я все правильно сделал ))
Daffodil
Даете ли вы тестовое задание соискателю на дом? В software компаниях часто просят написать небольшой проект на пару тысяч строк кода чтобы оценить знание современных паттернов и стандартов кодирования.
YuriPanchul Автор
Да, иногда даю, но не в пару тысяч, а в пару сотен. Обычно в форме: давайте посмотрим что вы напишете сейчас за полчаса, чтобы понять как вы начинаете, потом обсудим что у вас получилось и потом вы сделаете окончательно работающее решение дома. Для таких целей удобно использовать площадку http://edaplayground.com/
Домашнее задание в пару тысяч строк на верилоге для игрушечного роутера с складированием кусков пакетов в память как список я видел в другой компании.