Комментарии 7
Спасибо большое за статью! Не могу поставить плюсик по причине идиотских правил Хабра, поэтому просто утащу в закладки.
Пробежался по LinkedIn по вакансиям - зарплаты весьма вкусные.
Вопрос по "типичной команде". В реалиях Российских компаний после симуляции часто идет коррекция начальной спецификации и как следствие самого тестбенча, как подобное реализуется в "правильных" компаниях?
В подобных постах для RTL вы несколько раз затрагивали типичные требования или базовые задания для собеседований. А как обстоят дела с этим для верифитатора, о чем спрашивают, что считается порогом, ниже которого не возьмут?
В крупных электронных компаниях (и частично в некрупных) спецификация идет в два этапа: сначала архитектурная (на уровне транзакций что входит что выходит в подблоки целой большой конструкции - системы на кристалле, CPU итд), потом микроархитектурная - устройство блока - конвейеры, очереди. И еще до высокоуровневой спецификации, когда тестбенча на уровне RTL еще может не быть, делается performance modeling на основе высокоуровневой модели. Вот моя другая картинка на эту тему:
Что касается вопросов на интервью для верификаторов, то он (как и RTL инженер) должен понимать последовательностную логику, то есть решать задачки на верилоге типа "сгенерите такую-то последовательность сигналов на временной диаграмме в ответ на другую последовательность", но ему, в отличие от RTL инженера, совсем не нужно понимать статический анализ тайминга внутри такта.
Точно так же, DV инженеру (как и RTL инженеру) нужно понимать концепцию конвейера и очереди FIFO, но ему не нужно уметь их реализовывать со всеми подробностями (типа решать задачки "реализуй FIFO которое может в одном такте принимать или один, или два трансфера).
При этом DV инженеру нужно куда больше программировать, то есть писать всякие классы, потоки fork, динамические структуры данных итд, чего нет в RTL коде, а также делать интерфейс с кодом на других языках (Си, питон итд).
Юрий, добрый день.
SV+UVM это, конечно, база для верификатора. А что вы думаете про cocotb? Последние 6 месяцев ни одно собеседование на верификацию не обходится без вопросов на питон и использование cocotb.
На ощупь подход через cocotb оказался достаточно эффективным для небольших и средних RTL блоков: скорость разработки как будто бы выше + легче найти спеца по питону, чем по SV. Но есть подозрение, что на больших RTL будут сильные просадки по перфомансу.
Только минуту назад обсуждал cocotb. Это популярный вопрос в России потому что там ограниченая возможность доступа к SV и много питонистов, но в штатах такие работы встречаются реже, чем SV, например https://g.co/kgs/dPDXpT
Именно по причине, по которой вы описали: когда имеется миллион строк кода и регрессия идет ночь, никому не хочется чтобы она шла неделю.
Назвался груздем — полезай в кузов (задали вопрос о входе в Design Verification процессоров и сетевых чипов)