Тезисы, сформулированные во время распития чая, о процессе интервью, с позиции интервьирующего

Вы правы, но время висения не единственный признак.

Судя по тому, в какие дали зовут RTL-щиков из РБ, также сложилось впечатление, что совсем дефицит.

Судя по количеству участников главного русскоязычного тематического комьюнити в 2К человек, тоже похоже, что спецов очень немного. Для справки, каких-нибудь джавистов только в РБ порядка 10К человек.

UPD: я тут посчитал остатки от деления степеней двойки на 3 (они или 1 или 2 и чередуются), так что если знать это (или проверить) то дальше всё предельно очевидно: сумматор по модулю 3, в который добавляется 1 или 2 каждый следующий бит (если бит=1), и когда сумма=0, то до сего момента принятое число делится на 3. Опять же, главное тут поматанить (совсем чуть-чуть), остальное предельно очевидно, даже конечный автомат в явном виде не надо расписывать.

Приходит в голову по сбросу сделать текущий остаток нулём, а потом апгрейдить его по каждому следующему принимаемому биту. Но на собеседовании я вряд ли такое напишу. Только в спокойной обстановке. Вообще-то я за домашние задания на день - три.

Ну странно, тулы для программистов такое умеют сколько я себя помню. Видимо хардверные компиляторы сильно отстают.

Формально миллиард бит можно просуммировать в 30-битные аккумуляторы :)

Не прочитал задачу внимательно.

3 это же 11. А признак деления на 11 как раз такой.

Vivante - low end, Imagination не имеет некоторых high-end features. Программная совместимость с амд - это да, важный фактор.

*** Достаточно спросить. какие именно задачи решал  ***

Так именно для этого предназначено резюме - написать, какие он задачи решал. А то подход "напишу все, а потому уточню на словах" напоминает мне работу аэропорта Абу-Даби, где оказывается, недостаточно смотреть на табло с объявлениями о регистрации, но нужно еще и спросить у стоящего неподалеку служителя, в какое время точно начинатся и заканчивается регистрация (я так пропустил самолет, так как на табло была неверная информация).

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

*** а не отсеивать как совравшенго. ***

Я не отсеиваю только на основе одного вопроса. В случае с кандидатом с Jovial (дело было в 2010 году), у него все резюме состояло из каких-то забытых вещей - я вначале спросил его про SystemVerilog, он сказал что больше использовал Verilog-2001/95, я задал ему вопрос про Verilog, он сказал что он больше использовал VHDL, я спросил про VHDL, он тоже плавал, потом он зачем-то упомянул Аду, я задал вопрос про механизм рандеву в параллельных процессах на Аде, и вот потом настал черед Jovial-а. То есть он просто прыгал с темы на тему, пытаясь найти что-то, по чему я не смогу ему задать вопрос и махну рукой. А я его преследовал прыжками, как гепард антелопу, и довел до Джовиала.

Лучше просто найти несколько областей, которые человек знает твердо и составить резюме из них. А то, что он обучаем, это будет и так видно, по тому как он решает задачи (я всегда помогаю если человек пытается решить что-то для него новое).

*** Может оказаться, что человек просто можетне понять фразу "механизм передачи параметров ". Например, я фортран изучал по Мак-Кракену, там не было этого термина. Если бы вы спросили меня, "какой механизм передачи параметров в фортране" в 1995 году, то я бы тупо не понял вопрос. ***

С терминологией вопрос тонкий, это да. Если скажем у человека стоит в резюме Фортран еще с чем-нибудь, скажем с Паскалем или Си, можно спросить "в фортране передача параметров по ссылке или по значению?" А если не поймет, то написать код с вызовом сабрутины и спросить, какое число будет в переменной после выполнения.

*** Серьезно? Блок на 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, для этого доступны генераторы кода. Т.е. как бы нет никакой нужды писать это руками. ***

1. Внутри обычного AXI пять valid/ready интерфейсов, по одному на каждый канал - AWVALID/AWREADY, то же для AW, W, R и B. Внутри AXI Stream один.

2. С помощью 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 не нужно жесткое алгоритмическое интервью, не нужно уметь на доске в режиме реального времени писать рабочий код для переворачивания бинарных деревьев. ***

Даже на позиции в команде писания компиляторов, где сплошные преобразования деревьев?

*** эту странную страсть к подсчетам остатков от деления числа, приходящего бит за битом? Зачем это знать всем, если Панчул может написать оптимальную реализацю ***

Опять же - это не мой вопрос, я спрашиваю другое, я его привел как пример популярного вопроса.

*** то непонятно почему конвейер будет "двигаться или останавливаться целиком"? ***

Я сказал "конвейер будет либо весь двигаться, либо весь останавливаться целиком" применительно к первой картинке, которую вы привели. На этой картинке как только FIFO становится full, оно останавливает все движение в конвейере, но до этого движение происходит чисто по valid.

На вашей первой картинке full идет прямо на все ready всех стадий конвейера без какой-либо дополнительной комбинационной логики:

*** Книга интересная но достаточно быстро погружает в сложные детали. ***

Книгу выше я привел только чтобы почеркнуть, что нужно рассматривать случаи, когда может быть комбинационная логика на ready в разных стадиях.

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

*** как же не видя всех деталей схемы конвейера с кредитными счетчиками (в частности без понимания того, что происходит с сигналами valid/ready внутри конвейера достаточно сложно понять преимущества. ***

Ниже я сравню две картинки и покажу разницу в сигналах.

*** Если взять "старый подход" к проектированию конвейера то есть абстрагироваться и представить что каждая стадия конвейера это маленький IP-core с AXI-stream на входе и AXI-stream на выходе то непонятно почему конвейер будет "двигаться или останавливаться целиком"? ***

Не будет, но на вашей первой картинке было не так. Вообще конечно построить весь конвейер как кучу стадий с AXI Stream на входе и AXI Stream можно, но с кредитами будет 1) проще логика (ниже я покажу где); 2) вместо кучи промежуточных флопов на то, что вы называете "удалитель пузырей" (я думаю это функционально эквивалентно skid buffer / double buffer / "pipeline stomach" и FIFO глубиной два) можно просто поставить после всего конвейера большое SRAM-based FIFO, которое примет в себя все что шло по конвейеру; 3) с кредитами можно делать всякие трюки сначала брать максимальный кредит, а потом возвращать его частично после некоторой стадии если выясняется что больше не нужно (это полезно если одна транзакция может породить несколько).

*** Предположим что некоторые стадии конвейера могут останавливаться (то есть сами генерировать сигналы valid/ready, а не транслировать их). Таким образом остановившиеся стадии слева будут пораждать "пузыри" (сигнал valid=0) для стадий справа. Мы уже видим асинхронное движение, разве нет? ***

Согласен, но это не было на вашей первой картинке.

*** Так же между стадиями конвейера мы всегда можем поставить "удалитель пузырей". А в случае с проблем с таймингами (особенно если комбинаторная логика по сигналу ready очень длинная) можем поставить FIFO (неглубокий) который "прервет" цепочку комбинаторной логики не только по линии "valid" но и по обратной линии "ready". ***

Согласен, но это не было на вашей первой картинки, поэтому я сразу стал говорить о тайминге.

*** Взяв к примеру схему асинхронного FIFO от Clifford Cummings и убрав оттуда логику для "clock-domain-crossing" можем получить синхронный FIFO на любую глубину - комбинаторные линии "valid" и "ready" прерваны, так как в FIFO они генерируются на основе значений счетчиков "write_counter" и "read_counter". ***

Я знаю эту проблему, но это нечто отдельно от кредитных счетчиков.

*** То есть смотрите в итоге, мы ведь можем спроектировать отдельные стадии конвейера так что они сами будут генерировать сигналы "valid/ready", так же можем использовать "удалители пузырей" и FIFO для буферизации и решения проблем с таймингами? ***

Да

*** Правильно ли мое понимание что "старый подход" может быть превращен в "новый" если мы дополним старую схему кредитным счетчиком который будет инкрементировать значение счетчика при входе новой транзакции в конвейер при условии (valid=1 && ready=1), и дикрементировать значение при выходе транзакции с конвейера при том же условии (valid=1 && ready=1)? Как я понимаю это нужно для того что бы сообщить другим блокам на upstream'е насколько занят конвейер. ***

А вот теперь нет. Давайте поставим рядом вашу и мою картинку, я проведу вас по разницам, и из разниц будет проще понять преимущества:

Вот ваша картинка:

Вот моя картинка:

Итак, разницы:

1. Главная: на вашей картинке изменение счетчика происходит в начала конвейера и в конце конвейера (но до FIFO). А на моей картинке изменение счетчика происходит в начала конвейера и после выталкивания из FIFO. В FIFO стекает то, что накопилось в конвейере.

2. Другая крупная: в моей картинке сигнал full от FIFO вообще не используется, а в вашей картинке он используется как ~ready для последней стадии конвейера. By design моя схема построена так, что upstream логика никогда не запустит в конвейер транзакции, которые могут переполнить FIFO. Так что количество "транзакций сейчас находящихся в конвейере" + "количество транзакций в выходном FIFO ждущих pop" всегда меньше или равно глубины FIFO.

3. На вашей картинке в счетчике оказывается количество транзакций, которые сейчас идут по FIFO. В моей картинке происходит другое: мы сразу устанавливаем счетчик равным максимальному количеству кредитов. Это число соотвествует глубине FIFO после конвейера. Перед тем, как запустить в конвейер транзакцию, мы проверяем не равен ли счетчик нулю. Если не равен, то мы его уменьшаем на один и запускаем транзакцию.

4. В более сложном конвейере, когда мы можем запускать за один такт несколько транзакций, или если одна транзакция может породить в N-й стадии M транзакций, или если выясниться, что на P-той стадии R транзакций оказались убиты, мы можем обновить кредитный счетчик с этим знанием - так как выяснилось, что что-то не дойдет до конца. Эти сложные случаи реализовать без кредитов - это большая головная боль, и если реализовывать из без кредитов, то в выходную FIFO нужно закладывать бОльшую глубину.

Понятна разница?

То есть выгоды по сравнению с вашим подходом две:

1. Не нужно использовать сигнал full как ~ready и не нужно протаскивать его наверх через стадии, так как верх заведомо не пришлет данных столько, чтобы FIFO переполнилось и

2. Сложные случаи (см. выше). Помимо перечисленных, еще и случаи с несколькими upstream-ми.

Также есть выгода по сравнению с (не вашим и не моим, а третьим) подходом, когда мы запускаем транзакции в начале на основе учеьа пустого места в FIFO в конце. В этом подходе проще логика, чем в вашем подходе, но нужно более глубокое FIFO, чтобы вместить все данные в случае back-to-back транзакций и чтобы конвейер на простаивал слишком много, когда транзакции идут с пропусками.

По этой причине у нескольких компаний внутренние шины между подблоками - не AXI-подобные, а шины с кредитами, то есть вместо пары valid / ready имеется пара valid / credit_return (с дополнительным сигналом max-creadits).

(Вообще конечно тут было бы круто приводить конкретные примеры с кластерами CPU и обработчиками пакетов, но вы наверное увидите разницу и с общей идеей)