Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 265
Моя гипотеза как такие граждане выживают
Всё просто: они работают, вывозят сложнейшие проблемы.
А в викторинах на собесах "чем A отличается от B" процветают энциклопедические эрудиты. За них потом и приходится всё вывозить первым.
Вот я, например, недавно провалил техническое собеседование по языку C#. Один из вопросов, на который я не смог ответить: "Какой номер версии C#, с которым вы работали на последнем проекте?"
Номер версии - это действительно моветон, но если (предположим) вы писали на C# компилятор, причем указали что писали именно парсер, у вас не должно быть проблемы ответить на вопрос типа "какая была структура parsed tee в вашем парсере"? Если человек на такой вопрос ответить не может , то он парсера в компиляторе не писал. Или вы не согласны?
ответить на вопрос типа "какая была структура parsed tee в вашем парсере"
это прям единственно правильное название? А lexical tree, token tree, ... и даже комбинация из этих tree нельзя? Без названия parsed tee распарсить не возможно?
мне все равно как он это называет. Пусть опишет структуру, типы узлов, какая информация в них содержится. Если не может - он этого не делал. А это кстати не lexical tree. Лексический анализ в компиляторе и синтаксический анализ - это фундаментально разные вещи.
А это кстати не lexical tree
названия очень часто не соответствуют сути, но их уже никто не меняет, поэтому при определенных особенностях эмоционального восприятия ваш вопрос может быть очень не верно интерпретирован, я бы сначала спросил какого типа структура формируется (tree - это часть ответа все таки, наверно). А то что структуру должен как то рассказать это я согласен. А на какие единицы они разбирают мне было бы даже интересно, я могу делать только предположения, компиляторы не писал, только проверял на соответствие стандарту.
набирал впопыхах, описка - parse tree
parsed tee
Аж загуглил, не отстал ли от шарпа. Parse tree. Не пугайте так :)
Просмотрел кучу реализаций разных языков (в основном, конечно, не мейнстримовых, но и мейнстримовые тоже смотрел), и вот ни разу не встретил, чтобы использовали именно parse tree, обычно это ast, возможно с элементами синтаксиса для вспомогательных целей (типа как в Go, когда хранят токен с его позицией для диагностических сообщений и определении типа операций).
А вот какой-нибудь ANTLR генерирует parse tree, да, но по-другому и быть не может, генераторы парсеров не знают семантику языка.
А для ручных парсеров это просто лишний слой.
Я не разделяю AST и parse tree, употребляю это как синонимы. Я это дело выучил в конце 1980-х на примере portable C compiler (PCC) 1977-го года от Стивена Джонсона, с которым я кстати потом встретился вживую и даже работал в одном офисе. У него в компиляторе было дерево ориентированное на абстрактный синтаксис, то есть AST, которое потом преобразовалось в дерево для генерации кода.
Я не разделяю AST и parse tree, употребляю это как синонимы.
Ну вот опять и снова недопонимание уже на уровне терминологии. Вы задаёте вопрос, собеседуемый по-своему его понимает, и выдаёт ответ который вы тоже понимаете по-своему. Итого вердикт типа "некомпенентный, ничего не понимает", хотя на самом деле разговор в сути об одном и том же.
Так, а как с этим вопросом можно провалиться?
Я начал работать с шарпом лет 10 назад, тогда основными версиями были 4.0 и 4.5
С тех пор шарп у нас перешел на неткор, и там любую лтс версию можно называть и не ошибиться (6-8-10).
Если же вопрос внезапно про версии языка как такового, то я бы тоже завалился на вопросе, потому что языковые изменения незначительные и специфику новых конструкций редко использую, так что 5 версия наверно достаточна мне в 99% случаев, а актуальная где то на 12-14 версиях.
Я вот тоже провалил, но потому что ответил. Версия оказалась на 0.5 ниже той, которую они хотели. Зачем хотели, объяснять не стали %)
Подождите-ка, но он должен хоть что-то знать хорошо, для вывезения сложнейших проблем. Я не смог найти такой темы в его резюме. Если человек скажем пишет RTOS, он должен регулярно использовать Си и ассемблер и он воленс-неволенс его знает и может ответить на базовые вопросы. Если вы чего-то не знаете, не надо включать это в резюме и нарываться на вопросы.
Почему попадание темы в горячий кэш мясной памяти упорно путается со способностью манипулировать инструментом?
После очередного языка программирования и очередного фреймворка лично я скорее не буду доверять своей памяти и начну перепроверять всеми средствами, от справочников до контроля типов через подсветку в IDE.
Я просто пытался дать ему простой вопрос то тому что он сказал что знает, прежде чем копать глубоко вопросами типа "как бы вы организовали такую-то программу или проверку блока под тестом". Но он на каждый вопрос не отвечал, а перескакивал "я не идельно знаю А, знаю лучше Б". Я сам не люблю эрудитов и викторины, просто он не давал с этого режима выскочить.
Подождите-ка, но он должен хоть что-то знать хорошо
Знать != уметь вербализировать свои знания.
Из ваших вопросов правильный только про “A = B + C”. Человек который знает, действительно просто возьмёт да сделает. И не сразу идеально и набело. Т.е. если чел сходу не спросил про знаковость, это ещё не значит что он некомпетентный. Реальная разработка не ведётся сразу набело, а проходит через множество итераций, в ходе которых и вспоминаются всякие ньюансы, и решения доводится до идеального.
Вопрос про race condition тоже валидный. Это одна из типичных проблем отладки, особенно у людей с опытом менее 2 лет и не следующих определенному темплейту писания кода. Если он на это не нарывался - возникает вопрос сколько у него опыта. Если он сразу переводит стрелку на vhdl - возникает вопрос есть ли опыт вообще. После этого естественно переключиться в режим проверки валидности резюме.
race condition это не проблема отладки, это проблема работы всего параллельного. Вон у нас уже тут недопонимание в терминологии.
Если он сразу переводит стрелку на vhdl - возникает вопрос есть ли опыт вообще.
Не хочу защищать данного персонажа, возможно он и правда не тот за кого себя выдаёт. Но проведение собесов в стиле викторины - это тоже очень плохая практика.
В верилоге есть специфическая форма race condition, которая по сути баг языка (блокирующие присваивания в always @ (posedge clock) a = b; always @ (posedge clock) c = a;) что дает разный результат в разных симуляторах и может дать даже разный разультат до синтеза и после него).Это другое чем эквиваленты в софтверных языках. Против этого придумали делать неблокирующие присваивания <=, но глючный вариант оставили в языке.
Насчет vhdl - если бы он ответил на a = b+c, я бы спросил что-нибудь по делу, например как организовать testbench для какого-нибудь моста из протоколов которые есть в резюме (скажем apb в axi)
Насчет vhdl - если бы он ответил на a = b+c, я бы спросил что-нибудь по делу, например как организовать testbench для какого-нибудь моста из протоколов которые есть в резюме (скажем apb в axi)
Вот правильно. Пример конкретной проблемы - бери да решай. А все эти абстрактные академические вопросы с потолка - люди реального дела плохи в таких вещах.
Я написал ввше: Я просто пытался дать ему простой вопрос то тому что он сказал что знает, прежде чем копать глубоко вопросами типа "как бы вы организовали такую-то программу или проверку блока под тестом". Но он на каждый вопрос не отвечал, а перескакивал "я не идельно знаю А, знаю лучше Б". Я сам не люблю эрудитов и викторины, просто он не давал с этого режима выскочить
Ну он мог предложить объяснить на примере, кто ему мешал?
На вопрос про отличие он меня вынудил сам, посколько довел до необходимости проверить, валидная ли информация у него в резюме. Если человек не знает про рандеву в Аде, то он языка не знает. Это как не знать struct в языке Си. Ада сделана для параллельных процессов.
Более точная аналогия - это как не знать указатели в языке Си. Его главная фишка языка и если человек ее не знает это как использовать Си как Бейсик.
Но при этом человек много лет как-то работал и ему платили за это живые деньги.
Это не человек не знает про указатели в Си. Это задаваемые ему вопросы про указатели в Си требуют от него непонятно какого ответа. Зачастую на собесах получается так.
Но при этом человек много лет как-то работал и ему платили за это живые деньги.
Полезна ли для работодателя такая как-то работа, большой вопрос. А при найме оценивается потенциальный профит от кандидата.
Т.е. предыдущим работодателям была бесполезна, но они всё равно за неё исправно платили много лет?
Может быть только резюме подделано и никакой работы на самом деле не было.
Т.е. предыдущим работодателям была бесполезна, но они всё равно за неё исправно платили много лет?
Bullshit jobs, например.
Т.е. предыдущим работодателям была бесполезна, но они всё равно за неё исправно платили много лет?
Добро пожаловать в реальный мир.
А это разве новость, что довольно большая часть айтишников ничего не делают работе (реально, ничего) и им за это годами платят деньги? :)
Процентов 80 людей, которые пишут на С++ не понимают, что такое указатели.
Ну наверное в GUI с фреймворками это не критично, но если скажем писать компилятор или place-and-route продукт для проектирования микросхем, то там без такого знания трудно - аллокацию памяти нужно хорошо представлять под сложные структуры. А если драйвер или ядро ОС - тем более
Но при этом всё у них исправно работает? Мне бы такое не понимание!
Очень смелое заявление. Я слышал, что 80% сеньоров не могу за пять минут написать работающий FizzBuzz и это может и гиперболизированная, но похожая на правду вещь. А тут... хочешь - не хочешь при изучении C++ с указателями ты столкнешься, и если мы про raw pointers, а не про более новомодные штуки как weak_ptr, то каких-то тонких, но рядовых особенностей, которые можно не понимать или как-то неправильно интерпретировать в них просто нет. Ошибаться легко, но не по причине непонимания, а по причине их неудобства и не безопасности.
Пипец, первый раз увидел std::launder ! Думаю в aerospace code если такое увижу - будет интересная беседа с “применителем сего” :)
В рабочем цикле память не выделяется с использованиeм custom allocators. Точнее не выделяется вообще. Стараемся использовать разумный баланс по когнитивной нагрузке. Возможно в каком то месте и придется использовать когда то… но точно будет 10 строк комментария - зачем это делается…
std::launder is rarely needed in typical application code, but it is critical for low-level library development, such as custom allocators or implementing containers like std::vector or std::optional
Подготовка есть, нормальные new/malloc, часть памяти в специальных BRAM блоках “выделяется/организуется”, с помощью статических темплайтов с проверкой в compile time.
Про HFT:
Если все пишет один или два супер профи то подход оправдан, правда я думал там (HFT) уже все на уровне железа, FPGA и даже hard-copy ASIC.
И смотря насколько глубоко понимать. О Pointer Provenance как по мне любой недавний джун имеет представление, когда по ручкам настучали за reinterpret_cast везде где хочется и нельзя. std::launder на фоне этого вообще не должен никаких проблем вызывать (только решать), но есть тонкость, что его в C++17 ввели и есть прекрасный шанс ни в одном проекте его не увидеть. Я, пожалуй, чаще видел людей, которые про Strict Aliasing не слышали. Сложно ли это? Да не особо, было бы желание.
не знаю, как надо относиться к работе и к своему профессиональному развитию <...>
Так мир программистов на C++ он очень разный, чуть ли не полярный. Куча проектов еще живут, которые стартовали на c++03 из соображений производительности, но не той, где наносекунды считают, а где джава рантайм таскать с собой никто не будет а дотнет тогда еле шевелился. Всякий десктоп, локальный энтерпрайз, какие-то модули-числомолотилки, в которых аллокаций вообще нет, специализированная техника, и так далее. Там сидят люди и во всем этом варятся и никакой необходимости в новых компиляторах у них нет, а уж тем более и в новых стандартах. Все равно целиком проект переписать никто не даст, а исправлять по частям смысла мало. Ну и железо все время становилось быстрее, так что если не используешь квадрат, там где n log n хватает - уже большой молодец, а даже если используешь, ну когда (скорее если вдруг) тесно станет, то кто-нибудь починит.
Я как-то на таком работал, например, так вот на работе только палки в колеса ставили, а дома... а дома я выучил C#, меня этот язык реально радует. А часть бывших коллег вообще на эту ерунду еще и дома время не тратили.
Я вот уверен, что >80% людей, считающих, что они понимают указатели, не понимают provenance, например.
Не преувеличивайте. Возможно кто-то до поры до времени не знал, но не понимать когда уже столкнулся с проблемой - это уж совсем эрудитом надо быть.
на собесах […] процветают энциклопедические эрудиты
Удивительно, но под любой статьёй, обличающей незнание базы, появляются такие комментарии. Мол, это всё душные мелочи, которые не нужны в настоящей работе. И обычно дальше дискуссия развивается в сторону, что для настоящей работы вообще не нужны никакие “книжные” знания и поэтому на собеседованиях нельзя спрашивать вообще ничего.
они работают, вывозят сложнейшие проблемы
Я не совсем понимаю, зачем вы заочно защищаете людей, не знающих базы своего технологического стека? Каким образом из неспособности ответить на простейшие вопросы по языку следует успех в решении “сложнейших проблем”?
Race conditions в Верилоге — это базовое знание для работающих с Верилогом, этому учат студентов сразу же после введения в синтаксис. Это примерно так же обязательно, как для разработчика на C знать, что порядок вычисления аргументов функции не предписан стандартом и на него нельзя полагаться.
И если вы когда-нибудь хотя бы эпизодически писали на VHDL, то должны знать, что в этом прекрасном языке:
есть несколько разных типов для целых чисел/битовых шин (
signed,unsigned,std_logic_vectorи др.),они не приводятся неявно друг к другу.
Поэтому приведённая в статье портянка с resize буквально обязательна и до боли знакома любому VHDL-практику просто потому, что без неё код не скомпилируется.
Удивительно, но под любой статьёй, обличающей незнание базы, появляются такие комментарии. Мол, это всё душные мелочи, которые не нужны в настоящей работе. И обычно дальше дискуссия развивается в сторону, что для настоящей работы вообще не нужны никакие “книжные” знания и поэтому на собеседованиях нельзя спрашивать вообще ничего.
Это обычный защитный психологический механизм, из базовых.
Челвоек видит описание сложного собеседования, понимает, что он бы, возможно, тоже его не прошёл, дальше включается защита от этой неприятной мысли через инвалидацию самого собеседования. «Это не я чего-то не знаю, это собеседования у вас .удацкие, да и сами вы рожей не вышли».
Под любой статьёй про сайты знакомств комментарии точно такие же. Более того, вообще под любым материалом, описывающим процесс отбора, который потенциальный читатель имеет шансы не пройти.
Если специалист, успешено решавший задачи в промышленных масштабах, не проходит собес, то может потому что проблема не в специалисте, а в собесе?
успешено решавший задачи в промышленных масштабах
О чём мы абсолютно достоверно знаем с его собственных слов.
У человека может быть свидетельство о регистрации программы(там указан язык программирования) и это может быть известный в узких кругах продукт.
Всё ещё будете гонять его после этого на собесе по языку?
За недостаточную глубину знаний он получит отказ?
Всё ещё будете гонять его после этого на собесе по языку?
Да.
За недостаточную глубину знаний он получит отказ?
Да.
У человека может быть свидетельство о регистрации программы(там указан язык программирования) и это может быть известный в узких кругах продукт.
Ещё у него может быть диплом о высшем образовании, в котором указаны часы изучения языка программирования и итоговая оценка. «Вы ещё будете гонять его после этого на собесе по языку?».
Я чисто из опыта знаю что все дипломы можно спокойно игнорировать. У меня на интервью был студент из Стенфорда который 10 раз переписывал дизайн то ди gearbox то ли сумматора с контролем потока данных:
https://github.com/chipdesignschool/systemverilog-homework/blob/main/08_flow_control/08_05_gearbox_1_to_2_fc/08_05_gearbox_1_to_2_fc.sv
https://github.com/chipdesignschool/systemverilog-homework/blob/main/08_flow_control/08_07_a_plus_b_using_fifos_and_double_buffer/a_plus_b_using_fifos_and_double_buffer.sv
А еще была девочка из <опустим название университета> образование в котором стоит 90 тысяч долларов в год, которая на вот такой вопрос (как добавить в однотактовый процессор команду умножения используя блок умножения с латентностью два):
https://github.com/chipdesignschool/systemverilog-homework/tree/main/09_single_cycle_cpu/09_02_cpu_mul_with_latency
написала:
sr_cpu cpu ( .clk ( clk * 0.5 ),
Я тут подумал "бедные родители, потратили полмиллиона долларов на обучение чадо, а выхлоп вот такой"
О чём мы абсолютно достоверно знаем с его собственных слов.
Для проверки его слов есть СБ, есть официальные документы типа трудовой и договоров ГПХ, рекомендации профессиональных сообществ которым мы можем доверять.
Незачем бродить вокруг да около и оценивать "знания". Факты завершенных проектов, схожих с нашими, обладает куда лучшей предиктивностью что кандидат и у нас справится.
Вы сейчас великолепно описываете замену 3-4 часов живого общения (считаем несколько этапов интервью) на примерно впятеро больший объём бюрократии.
При этом, что характерно для бюрократии, результат она даёт частичный и сугубо формальный. Про характер кандидата и его устремления бюрократия вам скажет ровно ничего, в трудовой книжке будет написано нейтральное «инженер-программист», СБ с удовольствием проверит, являлся ли он учредителем юридических лиц, в сообществах человека могут просто не знать (давайте, вот мы с вами сейчас в сообществе, получите тут актуальную характеристику на меня — хотя бы на уровне «чем конкретно я занимаюсь и чего в этом достиг»).
На менее официальном языке вся эта деятельность называется ЖПБ, жопоприкрывающие бумажки. Реальная эффективность никакая, но если потом что-то пойдёт не так — ваша жопа прикрыта бумажками: вот договор, вот трудовая, вот заключение СБ, проверили всё что могли, не извольте ругать.
У меня был случай, когда я сам отговорил кандидата устраиваться к нам.
Формально по резюме у него всё отлично, всё соответствует, этапы до меня он прошёл без замечаний — но я с ним разговариваю и вижу, что по любому вопросу он начинает с удовольствием уходить в ту область, которой у нас в работе ну процентов 20 времени проекта, а иногда и вообще нет. То есть вопрос не в том, справится ли он, а в том, что непонятно, вовлечётся ли он в оставшиеся 80 % — или начнёт умирать от скуки на рабочем месте.
Всё просто: они работают, вывозят сложнейшие проблемы.
Как это следует из неспособности ответить на простейшие вопросы по стеку?
Вот так. Знания в голове в абстракциях, а не в словах. И привести эти абстракции к словам, для аутиста-интроверта далеко не такая тривиальная задача как может показаться.
Верно и обратное. Эрудит с хорошей памятью и подвешенным языком, часами будет заливаться соловьём, но реальных знаний у него нет, только слова.
Дык именно по этой причине у меня после первого вопроса всегда идет упражнение с написанием кода (см. пример ниже с квази-конвейерным делением). Потому что действительно есть куча эрудитов с хорошей памятью которые могут рассуждать про алгоритм Томасуло и многоядерные процессоры, но ничего не могут реализовать.
Впрочем к обсуждаемому кандидату это не относится, так как он соскочил с первого вопроса на другой язык, после чего это повторял.
А эрудитов со знаниями и аутистов без таковых не бывает, поэтому эти случаи рассматривать не будем. Аутистов берем, эрудиты – на выход!
Эрудиция не равно навык, но если человек открыто врет в резюме про пять языков, то и в работе он будет сказочником
ок, вот только как это объяснить типичному каргокульту айти
Внушает, да...
Для полноты картины не хватает успешных кейсов: как кандидаты, прошедшие подобные фильтры-отборы-интервью, круто изменили компанию к лучшему именно своей работой 🥲
Круто менять необязательно. Если человек добавляет фичи в скажем десятки миллионов новых телефонов или встроенный компьютер для автомобиля (driver's assistance) - это уже круто. А вот если ничего не может сделать самостоятельно, а только копипастити потом пристает к коллегам с вопросами почему не работает, то это просто отрицательная ценность для команды.
Вот тут и приходим к тому что главное от кандидата это наличие мяса на попе уметь брать проблему и самостоятельно её решить, чего бы это ни стоило, а не знания. Знания дело наживное. В пределах разумного, конечно. А на собесах что проверяется? Совсем не то проверяется.
Но, без каких то знаний, решение проблемы может затянуться на непрогнозируемый срок, но в целом я с Вашим посылом согласен.
Пройти собес – тоже задача, почему бы и ее не решить. Мама до старости сопли подтирать не будет, надо брать ответственность за свою жизнь на себя.
Вполне нормально отсеивать кандидатов, которые слова сказать не могут, и вполне нормально, что среди них будет 0,1% немых гениев. Жизнь несправедлива.
Пройти собес – тоже задача, почему бы и ее не решить.
Конечно. Можно даже потом не работать, а дальше проходить собесы с повышением грейда и зепки.
Но мне бы хотелось нанять специалиста работать таким какой он есть, а не нарваться на специалиста проходить собесы.
В вашем случае всё предельно просто, нанимайте людей без собеседований. Такой вариант наиболее полно отвечает на указанный вами запрос.
А у других людей идут быть другие требования, например, найти хорошего специалиста.
В вашем случае всё предельно просто, нанимайте людей без собеседований.
Так и делаем. Если кандидат успешно решал схожие задачи, то оказывается никакие ритуалы его оценки и не нужны. Поэтому лучше сфокусироваться на "пробиве" кандидата. А ещё лучше брать по знакомству.
А у других людей идут быть другие требования, например, найти хорошего специалиста.
Проблема в том что хорошо проходящий собес не тождественен хорошему специалисту. Нынче даже скорее обратная корреляция сложилась.
А, как потом растаётесь с сотрудниками, если что то пошло не так? (и как и на кого списываются издержки при этом))
хорошо проходящий собес не тождественен хорошему специалисту
Это такая же проблема, как то, что работнику неуклонно платить зарплату. Неприятно, но терпимо.
И что, пробив оказывается дешевле собеседований?
Вот и в моей Тиме был такой опыт. Взяли сеньора блестяще прошедшего интервью. На все вопросы он дал вполне правильные ответы. Уже потом оказалось что программировать он не умеет и мне, тогдашнему начинающему мидлу, пришлось за ним бегать и допиливать фичи 🤷
А вот я собеседования проходить не умею. Стрессую и не могу вспомнить базовые вещи. Зато в команде самые сложные таски решаю обычно я
Я сейчас в основном делаю задачки на навыки которые у кандидата должны быть автоматически, из повседневной работы, но с неким нетривиальным и при этом жизненным поворотом - см. напр. https://habr.com/en/articles/1033360/comments/#comment_29958312
Прикольно бы было, если бы затронут Форт (Forth) язык. :) На медни пообщался с ИИ поисковика по этому вопросу https://search.brave.com/ (в целом интересно), за исключением некоторых ньюансов по незнанию затронутых в диалоге Форт реалий, Но, на вопрос - Были ли Форт контроллеры у Atmel - говорил “Нет такой информации” , пока напрямую ему не назвал слово Marc4 (т.е. замкнул сам напрямую два или более ключевых слов в его векторной базе данных)
Да уж, если бы он вздумал соскочить на Форт, я бы его тут же зажарил живьем предложением расписать как бы он реализовывал форт-процессор на верилоге. Это шикарный интервьюшный вопрос, если у кандидата в резюме одновременно Форт и Verilog или VHDL. Очень развесистый вопрос с ответвлением про кеширование стека.
А, Форт процессоров в железе “нет”, Зачем тогда “бесполезные” вопросы? :)
Инженерный снобизм в чистом виде. Ну вот зачем вы его спрашиваете про аду, форт или jovial если в вашей компании это не используется. Вместо того что бы выдти на конструктивный диалог по конкретным задачам которые человеку предстоит решать, вы тратите время оплаченное компанией на экзамен кандидата по сферическим знаниям которые не используется в вашей компании. 😩
Если вы чего-то не знаете, не надо включать это в резюме и нарываться на вопросы.
И да в моём резюме тоже есть vhdl и verilog и когда то на нём я писал корреляторы и Фурье процессор для быстрой свертки (занимался навигацией и даже есть патенты) но это было в 2011 году и после этого я переквалифицировался сначала в DSP программиста а потом в менеджера. И что я теперь должен по вашему удалить весь этот опыт из резюме если я сейчас на RTL языках и пары строк из головы не напишу (правда чужой код прочитаю и даже скажу примерно во что синтезнется)? 😀
начало статьи: в интервьировании на позицию по моделированию и верификации процессорных ядер
если вы будете "подаваться" на дизайнера микросхем - то да, просят про RTL языки. Не потому, что они были упомянуты, а потому что вы обещаете владение ими пробуясь на такую вакансию.
На вакансии менеджера художественной галереи их, действительно, спрашивать не надо, но там спросят другое.
Вместо того что бы выдти на конструктивный диалог по конкретным задачам
Думаю, там уже после ответа на вопрос про сложение стало понятно, что кандидата решать конкретные задачи решать не возьмут. А всё остальное уже просто из любопытства, узнать как долго можно менять тему, не отвечая на вопрос.
в моём резюме тоже есть vhdl и verilog и когда то на нём я писал корреляторы и Фурье процессор для быстрой свертки
Вы смогли ответить на вопросы про race condition и сложение?
Про race conditions врядли, просто потому что так бы не написал, может скажу ересь но как помню было синхронное(<=)и асинхронное(=) присваиваивание, и просто знаю что под клоком использовать асинхронное нельзя.
Про сложение тоже бы ответил частично, я помню что есть знаковые и безнаковые типы в vhdl что нужно делать расширение шины и подключать для работы библиотеки, но вот написать код не смог бы, просто потому что последний раз его писал в 2010 ещё в Active-hdl которая на тот момент уже умирала. Больше с написанием кода я дел не имел.
Это как в универе я посчитал кучу перемножений и определителей матрицы но вот сейчас без matlab мой мозг очень сильно заскрипит что бы это сделать, да посидев и погуглив я быстро вспомню и освежу навык но вот на собесе могу и не сделать. Тоже самое и с RTL, я могу спокойно рассказать зачем используются коды грея в FIFO работающего с разными клоковомыми доменами, но вот из головы даже этот счётчик грея не напишу. 😀
Получается, что вы, не работая с HDL-кодом 15 лет, уже ответили лучше, чем тот кандидат.
просто знаю что под клоком использовать асинхронное нельзя
Оно обычно называется блокирующим присваиванием, но да — чтобы лишний раз не задумываться о гонках, в синтезируемом коде просто следуют эмпирическим правилам:
комбинационную логику пишут блокирующими присваиваниями,
синхронную логику (“под клоком”) — неблокирующими,
переменные не модифицируют более чем в одном процессе.
Если весь код написан с соблюдением этих соглашений, гонкам просто неоткуда взяться.
Нет никакого снобизма. Кандидат вынудил меня идти по этому пути, когда соскочил с вопросов про 1) SystemVerilog -> на Verilog-95 2) потом на VHDL 3) потом на Аду.
Мой типичный план интервью:
1) описание последнего проекта для разогрева;
2) простой вопрос;
3) задачки по существу - в его случае например спросить как бы он организовал testbench или bus functional model с транзакциями, то есть конкретная задача, которую ему предстоит решать.
Но он увильнул от (2) причем три раза. После этого мне просто стало интересно что будет если продолжить идти по этому пути дальше.
*** И что я теперь должен по вашему удалить весь этот опыт из резюме если я сейчас на RTL языках и пары строк из головы не напишу ***
Лучше всего это удалить. Или как минимум делать два абзаца: текущие технологии (за которые вы можете ответить) и то что вы использовали в прошлом (про что сразу говорить что вы ничего не помните). Я в конце 1990-х ставил себе в резюме Tcl, который потом не удалил и меня про это спросили через 10 лет. Это очень глупая ситуация. Идеально иметь в резюме только текущие навыки, за которые вы можете ответить.
Сейчас ИИ всем студентам автоматически добавляет в резюме SVA (SystemVerilog Assertions), и я когда вижу это SVA, тут же первым делом прошу их написать простейшее SVA. 95%+ не пишут. Сразу начинают мычать, что он де отлаживал результат SVA, а SVA писали другие инженеры. Задаю вопрос "но вы указали что отладили в проекте 120 багов. Сколько из них было найдено с помощью SVA? Ах 20-30. То есть вы видели кучу SVA и не запомнили их синтаксис?"
Самая большая хохма что еще перед AI первая выдача гугла на мой вопрос про SVA был неправильный ответ - таким образом я во время онлайн интервью определял кто сейчас смотрит на второй экран с выдачей гугла или суфлером.
Лучше всего это удалить. Или как минимум делать два абзаца: текущие технологии (за которые вы можете ответить) и то что вы использовали в прошлом (про что сразу говорить что вы ничего не помните).
Ну не знаю, я уже где то 7 лет менеджер и мне кажется именно мой опыт и то что я работал с FPGA/ASIC, DSP, MCU baremetal, RTOS, Embedded Linux и делает его уникальным. Вы же мне предлагаете отказаться от позиционирования себя как T-shaped менеджера и стать в один ряд с управенцами без технических знаний практически анулировав предыдущий опыт и оставив в резюме только первый технический диплом 😀, хотя я помимо менеджмента разбираюсь в проектировании любого embedded устройства от схемотехники до прошивки, да сейчас уже не так глубоко как раньше и уровень реализации уже где то выпадает но концептуально всё ещё помню многие вещи.
Инженерный снобизм в чистом виде. Ну вот зачем вы его спрашиваете про аду, форт или jovial если в вашей компании это не используется
Затем, что кандидат врёт про наличие опыта работы с ними.
Ну то есть буквально — сознательно врёт с корыстной целью.
Я, конечно, допускаю, что в мире АА (абстрактных аутистов) человека нанимают примерно как новую плашку памяти в ноутбук выбирают, по соответствию параметров из таблички характеристик, но в реальном коллективе нанять человека, который активно использует навык лжи с корыстными целями — очень плохая идея.
Почему врёт, если человек может прочитать код на этом языке и написать пару строк он им владеет. То что он не знает тонкостей какого-то языка это совершенно другое. Как в английском есть классификация от А1 до С2 и если я владею им на уровне А2-B1 то я считаю что я его знаю и в резюме запишу что знаю без указания уровня(для моих задач прочитать текст или написать комент или спросить где тут ресторан этого хватает с лихвой), вы собеседуете и знаете какой уровень вам необходим для работы вот и выясняйте это ваша работа, может вас устроит тот что у меня, но если я напишу конкретный уровень то во многих компаниях на собес попасть без шансов просто из за дурацкий автофильтров и глупых hr которые поставят как знание языка b2-c1. То же самое с языками я знаю СИ и в резюме пишу просто СИ но вот какой нужен вам и знаю ли я его это уже выяснять вам если не указали в вакансии (может вам нужна мисра из соображений безопасности, а может быть и нет). Здесь же человека указавшего аду пытают по адовой многопоточке а он может просто писал на ней какие то простые вещи тут как с bash и git все пишут что знают но у большинства знания как с английским на уровне А1 но для работы этого хватает. 😀
Что за чушь вы несёте?
Человек уже сидит на интервью. Он уже прошёл фильтры. Он общается с профессиональным интервьюером по своей основной специальности, которому прямо и однозначно говорит, что у него есть опыт в N, не имея такого опыта.
То есть — врёт.
Но вы можете продолжать оправдывать его (на самом деле — себя).
Но вы можете продолжать оправдывать его (на самом деле — себя).
Да без вопросов я спокойно могу сказать про себя что я дурак хоть и имею 2 диплома и за 18+ лет имея за плечами патенты и серьёзные продукты на рынке знаю только лишь то что практически ничего не знаю так как понимаю сколько различных предметных областей в embedded. А вот что я могу сказать конкретно по собесу
Спросили vhdl и verilog по первым вопросам не смогли выдти на конструктив избавляемся от кандидата по не соответствию hard/soft scils. Дальше время тратить нет это дорого для компании. Если через вас слишком большой поток неликвида нужно задуматься где проблема (плохой фильтр у hr или у вас завышенные требования к кандидатам).
Копания в аде и глубже если не нужно компании это именно снобизм и тут я приводил пример с питоном, я понимаю свои ограничения и на бэкенд не пойду но если бэк програмист прийдет ко мне я его буду спрашивать по необходимой мне предметной области и мы быстро расстанемся если он её не знает. При этом как я и писал в резюме мы оба знаем питон просто каждый в меру своей необходимости.
Теперь про знания языков зная python без многопоточки мне гораздо легче будет её освоить и написать чем тому кто вообще питон не знает(ии сейчас мне в помощь) Для меня как менеджера при найме такого человека это плюс ему в карму если его простой навык использования языка встраивается в мою предметную область (тут уже был пример с bash, git, тем же английским). И я не буду пытать его по каким то тонкостям.
Как бы вы назвали более глубокие уровни знания языка, когда человек может не только написать пару строк, но и знаком с крайними случаями, тонкостями и неочевидными подводными камнями?
Мне нравится аналогия принятая у лингвистов если взять английский - c1 advanced, c2 proficiency. При этом владении английским языком признается на уровне b1 intermediate и только почему то программисты засчитывают владение языком программирования когда вы знаете всё нюансы то есть если сравнивать с английским то это минимум advanced.
При этом во многих прикладных областях знать язык на уровне advanced не требуется достаточно intermediate, к тому же бывает так что архитектура проца просто не ложится на язык и часть нюансов не работает (моя любимая архитектура DSP от ti c54-c55 есть компилятор на си и даже си++ правда сильно урезанный но вот прикол байта в архитектуре нет, минимально адресуется 16 бит ещё и bigendian а вам надо rndis драйвер для USB написать ещё и eth стек на нём запустить 😀).
а язык, по которому собеседуют — вроде основной
А мне казалось что начиная с Ады там уже были вспомогательные или не используемые в компании языки просто интервьювер их знал очень хорошо а тот кого собеседовали нет потому и привёл аналогию с баш.
А если бы вы знали нюансы языка, то вы знали бы, что плюсовый байт не обязан быть восьмибитным, он может быть и больше
Ну знаю я это как это мне поможет работать с байтов ым потоком,собирать его и извлекать из него инфу на процессоре который это не позволяет.
другая сторона в случае английского языка [человек] обладает несколько большим интеллектом и способностью к коррекции ошибок, чем другая сторона в случае ЯП [компилятор]
Вопрос решается на уровне корп стандарта компании типа undefined behavior не писать или общего стандарта безопасности типа мисры. Выше уже приводили пример race conditions в верилог что следуя паре простых правил вы на них никогда не нарветесь и знать о них для вас становится не обязательно чем на аналогия с intermediate и advanced.
Весело наблюдать обычно как один синьер другого собеседует, тут кто первый халат надел тот царь и бог, а второй если не наступал на те же грабли тот дурак .
А ещё веселее когда в маленьком городе миллионнике они потом встречаются и меняются местами и товарищ заваливший собеседование прошлый раз отрывается в ответ по полной. 😂
Это я к тому что один мог писать системные скрипты другой многопоточку используя один и тот же язык и в резюме указать что язык знают но при этом запросто завалить друг друга на собесе.
Embedded очень большой и областей огромное множество, и практики как и набор используемых инструментов везде разный. Надо просто смотреть понимает человек физику процессов которыми управляет через код или нет(так называемую предметную область в которой ему предстоит работать), остальное лишнее так как оно слишком часто меняется.
У меня так с python для цифровой обработки сигналов, и в резюме у меня указано что я знаю python, но при этом у меня нет знания ооп, многопоточки или Django, и любой backend программист меня просто разнесёт на собесе. Вот только если он попадётся мне то на той же фильтрации я его порву как тузик грелку. 😂
Вот только если он попадётся мне то на той же фильтрации я его порву как тузик грелку
Это если встретятся два одиночества, ни одно из которых не умеет произносить фразу «да, я с этим работал, но вот в такой конкретной предметной области, в ней спрашивайте, всё расскажу».
Вопрос, стоит ли нанимать таких людей на работу — дискуссионный.
Ну, допустим, наймут вас. А на поставленную руководителем задачу, в которой надо многопоточку фигачить, вы тоже постесняетесь сказать, что не умеете, предпочтя задачу молча завалить?
Нет я прекрасно ориентируюсь в своей области знаний а ещё я экстраверт так что сразу легко донесу до руководства свои слабые стороны подсветив что мне решение подобной задачи будет стоить больше. Это базовый навык в модели общения доверие-прозрачночть с руководством и понимание этого позволяет легко двигаться по карьерной лестнице. 😀
как бы он реализовывал форт-процессор на верилоге
И он бы тут же соскочил на лисп-машины.
Ну если он к этом моменту ещё не понял, что Юра в жизни прочитал очень много странных книжек, то это тоже не в пользу кандидата говорит ;)
Да, с лиспом его можно было бы заставить написать на верилоге linked list controller который бы вытягивал лисповские списки из памяти (car и cdr). Вопрос про списки на верилоге у меня тоже есть:
https://github.com/yuri-panchul/2019_2021_eda_playground/blob/main/linked_list_1/design.sv
Плюс похожие вопросы спрашивают на интервью в Apple и Juniper (сейчас HP).
Я занимался реализацией Forth процессора на VHDL. В моей реализации сейчас 3 стека (процессор заточен под DSP). А что не так с кешированием стека? В смысле зачем оно?
Да, тоже интересно. Если взять, какую то реализацию Форт процессора например с Github, то будет ли оно там для решения задач стоящих перед автором проекта, или как автор обсуждаемой статьи нацелен на получение Hi-End результата в своих результатах в сравнении с …
P.S. А, можете по следу своей разработки опубликовать статью?
Да, я думал про статью, но как-то все руки не доходят. Я как обычный программист - мне проще писать код чем его документировать (;
А, зря, пока, к примеру, Форт сообщество окукливается в своих индивидуальных подходах к “снаряду” Мир не стоит на месте и занимает и его исторические ниши сводя на минимум его понимание и применение в перспективных разработках.
P.S. В проекте двух стекового учебного “Форт” процессора Брус-16 (статья на Хабре https://habr.com/ru/companies/yadro/articles/1023972/ ), “любители” сразу дополнили его Форт-системой в этом топике http://fforum.winglion.ru/viewtopic.php?f=3&t=3402&p=52064&
Для снижения латентности, если стек хранится в памяти. Она из проблем стековых процессоров (например транспьютеров) по сравнению с risc-процессорами с большим регистровым файлом - заключалась в том, что для вычисления простого выражения, скажем a*b+c*d (в обратной польской записи ab*cd*+) требовалось делать много транзакций к памяти, что медленнее чем к регистровому файлу. Также это труднее было параллелить.
А что, форт сейчас где-то используется?
Интересный и не простой вопрос к ответу при анализе реалий его.
В каких изделиях, программах или закрытых применён информации мало, возможно что решения на/с нём конкурируют на “сложных” задачах под NDA. На Западе есть исторические предпосылки по использованию Форт (Forth), в России их исчезающе мало и в силу того, что студентшкольники с ним не сталкиваются, а встретив “страшилки” про него проходят мимо.
Р.S. Но, проще не пытаться вникнуть в суть разных сильных сторон языка и парадигм на которых он и его “разновидности” спроектированы, а приклеить к нему ярлык “Неуловимого. Джо” :) Моё, к примеру, резюме с акцентом на работу с Форт направлением на hh.ru вероятно так и останется в оценках “курьёзным” случаем от какого олдфага (ретрограда) не проходящее фильтры HR по возрасту и ключевым словам. А, спрашивать об опыте даже не относящегося к вакансии, как минимум имеет смысл для оценки кандидата и возможности применения его для наиболее полезного усиления созданного проекта-продукта.
У forth есть одна большая проблема — сложность командной разработки. Очень трудно договориться в проекте о реализации базового словаря. По итогу — либо соглашения занимают непропорционально большое время, либо — кто в лес, кто по дрова. Каждый сам себе художник в форте.
Можно пойти путём заимствования используемог лексикона слов из подходящего языка, к тому же Форт подходит и для надсторойки над или интеграции с взятым и уже отлаженным кодом ядра стороннего языка или софта, а реализаций идей как это сделать уже напридумывали.
P.S. Сложность найти и/или, вероятно, привлечь программистов для развёртывания проекта с пониманием использования Форт “мышления” в реалиях в сложившихся и рекомендуемых подходов в создании массового ПО и учёта, что какие то вещи с Форт придётся продумывать и делать “иначе” в силу специфики и “метафоричности” Форт . :)
Я и говорю — полёт фантазии художника здесь неограничен ничем. Особенно мощью реализации этих фантазий. А команда художников слепит монстра. И — да. Форту нет смысла заимствовать из других языков. Он, в первую очередь, создан для создания нового, проблемно ориентированного языка. Под каждую имеющуюся задачу. А вот тут уже проблемы исполнения. И глубокие проблемы с перепрограммированием (особенно командным, когда каждый реализуя общее, лепит что-то уникально своё). Проблема в договорённостях.
Форт — это язык гениальных одиночек. Каких сейчас, наверное, уже и не осталось.
Ну например loader во FreeBSD использует Forth
Или ранее использовался, а сейчас. Lua?
P.S. Пробовал находить ссылки встречаемости Форт в каких то компаниях, ПО и проектах, для cозданного топика на http://fforum.winglion.ru но их нeмного находилось, хотя по слову Forth на github много чего выдаётся в результат поиска.
Насчет использования loader_4th уже не знаю - давно в FreeBSD не работал, возможно и правда что-то изменилось. Я возлагал опеределеные надежды на использование "аппаратного" Forth процессора в FPGA для "ленивой" разработки в плане DSP. Пока не очень обнадеживает. Регистровый RISC-V вроде как проще и все таки производительней показался.
Для “ленивой” разработки DSP есть GA144, но это уж для очень “ленивых”, но без появления на рынке массовых Форт-контроллеров ничего не изменится и Форт так и будут “насиловать” в нерадной для него регистровой архитектуре разных контроллеров.
P.S. И На RISC-V уже много какие Форт-системы добавили/запустили/портировали
В не совсем стандартном виде он есть внутри PostScript и в фонтах TTF.
В близком к стандарту – OpenBoot. Про загрузчик FreeBSD (где он был лет 20) уже говорили.
Этого мало, конечно, но не ноль.
Ну, как бы — "стандартный вид", это не про Форт. Некие соглашения внутри команды, вокруг стековой парадигмы и — соглашения по словарю. Даже имеющиеся стандарты — никого ни к чему не обязывают. Да и не могут. Увы.
Форт вполне успешен в использовании во встраиваемом оборудовании чему есть достаточно фактов и свидетельств.
P.S. При поиске и, к примеру, его “упаминания” в базе диссертаций находится некоторое количество материала связанного с Форт в них. Какое то и современное ПО есть. сделанное на нём или с ним (данных немного). Часто можно и не знать об этом т.к. даже используя продаваемую Форт систему клиенты её, в основном, не аффишируют сей факт.
Наблюдал другое - спрашивают соискателя про опыт, какие последние проекты: ну там микроконтроллеры какие, IDE, как прошивали/отладка велась, как совместная работа организована - "мне нельзя говорить, NDA" 🤷♂️
И вот тоже не понятно, зачем тогда на собеседование пришёл.
Вполне нормальный ответ, вы спрашиваете про то как были построены процессы разработки в компании если компания с именем то это попадает под NDA. Переформулируйте просто вопрос и всё
Ты работал с конкретной ide или процом
Вот устройство как бы ты организовал процессы фабричной прошивки и обновления в процессе эксплуатации
Как бы ты отлаживал и собирал инфу на подобном устройстве
Если бы я назначил тебя лидом как бы ты организовал работу в команде
В этом случае человек поделится своим реальным опытом ну или может слегка пофантазировать если его нет, но при этом нет нарушения NDA, потому что он не расказывает конкретно про процессы в предыдущей компании.
Такая проблема есть, но можно задавать вопросы, которые не зависят от конкретного микроконтроллера. Например спрашивать про обработку прерывания в RTOS в такой форме, чтобы это было общее что для STM32, что для ESP32, что для PIC32.
"мне нельзя говорить, NDA"
Обычно человек, имеющий хоть какой-то жизненный опыт (но то есть возраст 30+ уже точно в эту категорию должен попадать), умеет в таких случаях составлять конструкции вида «я не могу ответить про конкретный проект и внутрянку компании, но лично я много работал с ...».
Потому что он понимает, что собеседование — компромиссный процесс, в котором ему тоже выгодно удовлетворить интервьюера. И как любой подобный процесс, он имеет компромиссную природу результата.
Ну либо он пришёл к вам от скуки, послушать чо спрашивать будете и чо предложите по бонусам, поэтому ему пять слов лишних сказать лень, но в таком случае будет логичным завершить интервью с ним после третьего «мне нельзя говорить», поставить в отзыве «не нанимать» и заняться более полезными делами.
> через несколько лет трудоустроенным в другой компании
Ну это не обязательно связано. В конце концов вы не знаете, на какую именно позицию он там устроился, могла быть совсем не про топологии.
А сама "стратегия собеседования" звучит как-то странно. Кажется, что он не хотел оффера, а просто развлекался. Потому что эта стратегия просто обнуляет его шансы.
Байка-то великолепная, но остаётся байкой. Это даже не анекдот про "если бы у рыбы была шерсть, в ней бы водились блохи" - там студент ответил на все вопросы (хотя и криво). А этот ваш соискатель - ни на один.
То есть да, счётчик запоротых вопросов нулевой. Но и счётчик отвеченных - тоже нулевой. В результате техническую часть он просто не проходит. Если конечно у него нет волосатой лапы. Но если есть - все эти хитрости ему просто не нужны.
но остаётся байкой
Вы хотите сказать, не бывает странных кандидатов, а причины поступков и поведения человека всегда легко понять и объяснить, потому все это – неправдоподобно и байка?
В данном случае интервьюер непонятно зачем тратит свое время на человека, который на вопрос чему равен 2+2 (в выбранной области) отвечает, что он занимался только умножением
интервьюер непонятно зачем тратит свое время
это как раз понятно, он эмоциональный джекпот сорвал
его странные юношеские хобби вдруг все сыграли
все книжки, о которых "нормальные девятиклассники" даже не слышали, потискивая девятиклассниц, вдруг одна за другой "раскрылись на нужной странице"
тут в самом деле будешь затаив дыхание, чтобы не спугнуть этакое чудо, ждать каждого следующего вопроса :-D
не бывает странных
если бы статья называлась "вчера я видел городского сумасшедшего" - то никаких вопросов, я тоже их видел
но статья называется "тактика прохождения интервью", то есть рациональный и объективно работающий метод...
...который просто не может работать при минимально адекватном интервьере
Та кто его знает, некоторые теряются при живом общении, но в состоянии потока работают и решают сложные задачи, решают успешно.
У нас как-то один эксперт был на собеседовании, так он сразу отрезал - нет, на такие вопросы я отвечать не буду - унижение мне не нужно, у меня есть чувство собственного достоинства. Все офонарели.
Т.е. если чел. эксперт, может быть он что-то и напутает от стресса в простейших вещах. Как-то возьми выпускника по математической специальности - возможно он не вспомнит все аксиомы планиметрии, которые дети в школе изучают. Из этого можно сделать вывод что ему нужно в школу.
возьми выпускника по математической специальности - возможно он не вспомнит все аксиомы планиметрии, которые дети в школе изучают
Нет, это так не работает, тем более в математике. У математики нет внешних объектов исследования, аксиома есть основной объект исследования математики. Я ещё могу допустить, чтобы, скажем, химик забыл какие-то элементы школьной химии (тем более что изрядная часть школьной химии - это устаревшая или ложная информация). Но математик, забывший аксиомы - это не математик.
Забывший аксиомы своей области.
Но вот те же аксиомы планиметрии из школы - по идее то все должны помнить? И можно ими унижать человека, как бы если не вспомнил на уровне таблицы умножения - можно сказать, да вам, батенька, нужно школу закончить для начала.
Унижать так-то можно любым достаточно известным, но мало полезным знанием, было бы желание (и хоть какой-то смысл).
Но аналогия с таблицей умножения неверная, пусть у человека "от зубов и не отскакивает", сколько будет шестью восемь, но он сможет дать правильный ответ спустя какое-то время, а значит считать все же умеет.
Аксиомы планиметрии... а почему тогда не список персонажей "Войны и Мира"? Примерные размеры планет солнечной системы? Правила игры в шахматы?
Мне, несмотря на оконченный математический ВУЗ, аксиомы планиметрии пригодились ровно чтобы сдать экзамен в школе по аксиомам планиметрии, не больше не меньше. Это не матан, который сплошь и рядом всплывает, и не теория вероятности, без которой вообще сложно себя считать человеком рассудительным.
И, казалось бы это несложное знание, но я изначально не склоняюсь считать простым то, что кажется лишь интуитивно просто; вот про аксиому принадлежности я не только не вспомнил без википедии, но и не вспомнил бы ее вообще, если бы мне нужно было самому создать аксиоматику. Меняет ли это хоть что-то в мире? Да вообще ничего. Это даже в геймдеве не нужно, и когда дачу строишь тоже как-то безразлично на то, что каждый отрезок имеет длину, большую нуля, потому что нулевыми отрезками как-то даже в голову не приходит крышу крепить.
Вот те же аксиомы Пеано еще попробуй забудь, если узнал. Но их почему-то даже обычно не проходят в школе. Но раз уж без этого жить можно, то что уж говорить.
Ну мне кажется, шансов начать не с определений в логике второго порядка маловато. Даже интересно, где бы могли так преподавать.
В FOL уже буквально с диагональным методом Кантора возникнут такие проблемы, которые младшекурсникам не по зубам, а ведь надо как-то пределы вводить. Непрерывность определить. Ну да, выше Вы писали про ZFC, но пока уже другие будут спокойно интегралы по контуру считать, придется сидеть на парадоксе Банаха-Тарского. Мне не кажется, что это может быть проще.
Да ведь вкусовщина. На первом не сыграет, да, а на втором-третьем, если с головой на плечах - сыграет и проиграет наверняка. Было бы интересно, правда, посмотреть, где с FOL начинают. Все-таки относительно SOL + топологии это редукция, что несомненно полезно для формализации, но дает свои минусы для познания. А вот реально качественные формализации всем (без малого) студентам по жизни никак не пригодятся.
И тот же диагональный метод вполне описывается прозой и на интуитивном уровне понимания ∀ и ∃.
Тут на хабре, в среднем пару раз в год пишут "статьи" вот такие вот интуитивно понимающие, о том, что вообще континуума не существует и они могут это доказать.
Ну и продолжая вкусовщину, я благодарен за то как меня учили и с чего начинали, потому что матан я, кажется, даже в припадке не забуду. Во многом базовый, конечно, но, главное, для меня все предельно просто, и все что забыл легко выводится.
Но математик, забывший аксиомы - это не математик.
Но на практике так происходит - спрашивал людей, имеющих мат. направленность, которые не так давно закончили (может несколько лет) - далеко не все смогли вспомнить аксиомы планиметрии. По идее сразу нужно отправлять в школу, т.к. если ты не знаешь аксиомы - то ты не имеешь базы. Но мозг человека работает иначе, не как компьютер. Когда ему нужно будет - вспомнит.
В ютюбе тоже попадались прикольные ролики на эту тему, когда спрашивают именно бывших выпускников рейтинговых вузов (особенно спустя 2-3 года после обучения).
Я как-то помогал с технической частью собеседования на один проект, где нужен был миддл со знанием Qt. Ну и вот, кидают мне резюме кандидата, который выглядит как очень твердый миддл с богатым и разнообразным опытом…
Я на собесах начинаю с достаточно лёгких но нестандартных вопросов, просто чтобы кандидат расслабился и не стрессовал. Спросил: в чём отличие указателя от ссылки в си++. И кандидат завис. Начал оправдываться что в кутэ всё на указателях, своя модель управления памятью и тп. В целом говорил правильно, неплохо объяснил тот же mvc в контексте кутэ, но прямо чувствовалось отсутствие фундаментальных знаний по си++. И я не знал что делать. С одной стороны выглядело так, что человек повидал всякое энтерпрайз г**но, владеет фреймворком и с задачами мидла должен справляться, но с другой я ну никак не мог порекомендовать его именно как си++ программиста.
Или был другой случай, тоже искали си++ мидла на бэкэнд, но с виду неплохой кандидат очень плавал в многопоточности и raii. Он почувствовал это, попытался сказать, мол я программировал в основном с кутэ. И тут, я как в статье, почувствовал почву для отрыва :)
*** Спросил: в чём отличие указателя от ссылки в си++. И кандидат завис. ***
Ну в этом случае если бы он сказал что все делал без ссылок но с указателями, я бы написал что-нибудь в таком роде:
A & f (A b, A & c)
{
static A s;
if (b.a != c.a)
s = c;
c = b;
return s;
}и попросил бы его переписать это с помощью указателей, чтобы не было references. Причем проследил бы что A b передается по значению и в переписанной версии.
Если перепишет корректно - я бы списал зависание на стресс во время интервью.
Да ни в чем, и то и другое работает с адресом, чисто синтаксический сахар, еще и не понятно что лучше, особенно если делать хорошо оптимизированные templates, a использование references может подложить жабу если человек вписал имя переменной а функция эту переменную поменяла. Если prototype описан с указателем, то приходится явно указывать &var при вызове - и облегчает понимание того что туда уехал адрес а не копия значения, иначе частенько приходится лезть в прототипы или доки.
Это понятно, что это syntactic sugar, просто товарищ выше по ветке захотел от кандидата этого знания и я предложил способ как это проверить с помощью кода.
Ссылка даёт гарантию, что объект существует. И без сишных хаков это выполняется. И позволяет делать разные оптимизации. Не говоря уже о возможности делать нормальный синтаксис. Это как бы основы си++ 03. Их надо знать, если вы не собираетесь писать на си с классами вместо си++.
А с си++11 появился целый зоопарк новых типов ссылок которые значительно облегчают эффективное программирование. И если человек не считает уместным использовать возможности языка и хочет писать по старинке на сишечке, то это отказ. Как минимум чтобы не портить кодовую базу и не создавать конфликты на код ревью.
А в современном си++ указатели вообще не нужны в пользовательском коде.
Ну я бы тоже подзавис. Кто-то ждет ответа, ну это просто "syntactic sugar", а кто-то будет ждать, что "указатель это отдельная переменная, сама имеющая адрес в памяти". Такой вопрос гарантированно попадает в "вопросы с ожидаемым подвохом". Отличий, как по мне, больше чем сходства. Больше в сторону, чем std::string отличается от int.
Впрочем, да, это не повод молчать и чего-то ждать.
Пишу на Go 7 лет, до этого немного php видел, в других языках правда может быть такое, что разработчик не знает на какой версии языка написан его проект? Мне правда любопытно.
По идее на версии компилятора же завязаны многие вещи и вот совсем не ответить на собеседование на твой вопрос это норма?
На счёт «не знать базу, но решать сложнейшие проблемы» - сталкивался с такими людьми, но там обычно нерешаемость проблема. для других обусловлена тем, что изначально модуль годами писался годами одним человеком без документации и со своим видением прекрасного, а так же применением всевозможных паттернов ради их применения.
Я бы наверное мог понять почему условный джун который вошел через нейронки не напишет с руки базовую вещь типа отправки хттп запроса, но сеньор который не «помнит» как писать базовы код который в любом случае пишешь - это очень подозрительно и, возможно, опасно для компании.
В лучшем случае можно рассмотреть его менеджером для обширной экспертизы, но. вопрос опять же уже в софт скиллах будет
Делаю сложные системы на ФПГА уже 30 лет (500mhz sampling 86 GB DDR addressing, MAC/IP/UDP, DDCS, FSK/QPSK modulation/demodulation, senseless FOC), но ваше интервью точно не пройду, вопросы об ошибках, которые в нормальном подходе не встречаются, классика советской школы где учили на академию а не на решение практических задач
Вы про race condition? Ну если вы пишете на VHDL, то у вас этой ошибки не возникнет.
И если вы пишете на верилоге, и при этом строго используете блокирующие присваивания в always_comb/always @* и неблокирующие в always_ff @ (posedge clk) то тоже.
Я его об этом спрашивал только потому что у него такое может встретится в тестбенчах, типа
@ (posedge clk)
dut_in = 5'd12;
@ (posedge clk)
В принципе это простой вопрос, и если бы он сказал "не знаю", я был ему задал что-то другое.
А вот вас я бы спросил микроархитектурный вопрос. Например. Допустим у вас есть черный ящик - блок с вычислением операции деления чисел с плавающей точкой за переменное количество тактов до N:
Вот с такой диаграммой:
Используйте его чтобы сделать блок умножения, который может принимать данные каждый такт бесконечно (то есть не ждать окончания деления) и давать поток результатов с фиксированной латентность, вот с такой диаграммой (латентность может быть больше чем на диаграмме):
От вас требуется:
Идея как это сделать.
Код на верилоге на доске.
Если справитесь быстро (то есть менее чем за 30 минут), дополнительный вопрос: добавьте к дизайну сигнал ready и на входе и на выходе:
Если и на это ответите быстро, дополнительное условие: данные на A и B могут приходить в разных тактах:
Диаграмма valid/ready следует правилам AXI-Stream:
При этом:
Менять исходный блок нельзя, можно только строить логику вокруг него.
Делать свои арифметические блоки нельзя.
Заводить FIFO на миллиард элементов чтобы поглотить все данные в тесте нельзя.
Ограничивать пропускную способность при отсутствие backpressure нельзя (нужно принимать A и B каждый такт).
В ИИ смотреть нельзя и гуглить тоже - все у доски.
Можете попробовать.
Это не академический вопрос - это все от сохи.
Может это и отличная задача, но без контекста - абсолютно непонятно что делать.
А какой вам нужен контекст? Интерфейс приведен. Требуемая фнкциональность приведена. Описание блоков которые можно использовать приведены. Я этот вопрос протестировал на больше десятка человек - для свежих студентов трудный, но для людей с 2-3 летним опытом приектирования блоков на Verilog или VHDL - в самый раз. Для людей с 5-10 летним опытом легкий, если опыт реален.
Первое - нафига такие сложности. Зачем из блока деления делать умножение. Вобщем, задача напоминает "копать канаву отсюда и до обеда" - некое бессмысленное действие. Именно поэтому я упомянул контекст - чтобы задача обрела смысл.
Зачем из блока деления делать умножение
Я очень извиняюсь, там я описался. Не умножение, а все-таки деление. Из неконвейерного блока деления делать блок деления, коорый может принимать данные в каждом такте. Как-бы квази-конвейерный.
Контекст: Я работаю в группе фиксированных функций GPU. Мой блок работает между геометрическим шейдером и растеризатором и делает преобразования перспективы и подобные. Для этого нужно строить много специализованных FPU rоторые умеют вычислять всякие формулы для потока треугольников с координатами. Некоторые подблоки для формул конвейерные, но некоторые вычисления делать конвейерными дорого, поэтому они делаются конечными автоматами с большой латентностью.
При этом нельзя допускать, чтобы такие вычисления образовывали заторы в потоке, чтобы из-за них все останавливалось на много тактов и снижалась пропускная способность.
Задачка выше - проверка что кандидат может сообразить как строить такие структуры.
UPD: Тут ниже написали, что задачка решается и в формулировке с опиской. Это ценная идея для будущих интервью!
https://habr.com/en/articles/1033360/comments/#comment_29954996
Вроде и в исходной постановке ("блок умножения, который может принимать данные каждый такт") она решаема, только блоков деления надо будет 2N и кода раза в два больше. На первой стадии вычислять res1=1/B, на второй вычислять А/res1.
Код на доске это какой-то каменный век, уже у многих атрофировались нейронные связи что бы просто код писать ведь давным-давно все пишут с автокомплитом а щас ещё и с нейронкой. Ну тут хозяин барин, особенно если у вас нет kpi на количество часов которое Вы потратили на поиск подходящего кандидата. 😀
Согласен. А 30 минут (и это еще быстро?) кода на доске это вообще какая-то пытка, так или иначе. Доска для архитектуры (совсем простенькой) и, ну максимум, FizzBuzz, если любите немного поиздеваться (но зачем?).
У нас в Самсунге вернули интервью у доски, то же сделали в Гугле и в Cisco. Иначе народ повально использует ИИ-суфлеры и это раздражает.
Отличная задача, SpinalHDL Flow и Stream классы эту проблему давно решили и тратить нейроны в проектах не требуется :) Именно решив 5-10 раз такие штуки и исправив ошибки в чужом коде, на 90% переехал на Spinal
Проблема в том, что в большинстве электронных компаний ответ на SpinalHDL не примут или примут с большим скрипом, только если вы продемонстрируете что-то еще что команду интервьюеров впечатлит. Потому что встанет вопрос "как такого человека вписать в команду, если он будет вместо работы над миллионом строк верилога всех агитировать все переписать на SpinalHDL".
Решения задачи в вашем контексте не существует. Потому я не в Самсунге :)) Но есть же Efinix и SiFive и VexRiscV… И куча задач где мы заменяем команду из 30 человек
В смысле микроархитектурное решение не сушествует? Существует.
Или вы настаиваете что должен быть SpinalHDL?
Ну если SpinalHDL принимают в Efinix и VexRiscV - good for you.
Но насчет SiFive - у них же свой Chisel есть. Вы хотите сказать что SpinalHDL и Chisel однозначно отображаются друг на друга и команда в SiFive готова принять решения на SpinalHDL? У меня есть там несколько знакомых, могу спросить.
Я не упертый на Spinal, он кстаки очень хорошо сожительствует с уже существующим verilog. Один проект 25 летней давности недавно завернул в Spinal только из за возможности более удобной симуляции, были заодно выловлены вредные баги и добавлена уже Spinal периферия.
Efinix вообще имеет hard ядра VexRisc-like, создатель Spinal Charles P у них даже работал (не знаю как сейчас). SiFive ядра мы использовали в одном из ASIC проектов, к нему периферию писали на Spinal. Chisel уж слишком академичен для многих, но идея Spinal была поддержана, возможно даже скоро будет Rev2 АСИКА
Так “блок умножения” или деления ??? Как можно вытащить из одного? блока результат быстрее чем его latency или вы подразумеваете что поставим up to N блоков и планировщик ?
Ну или пару фифошек на входе и выходе для исключения мета стабильности и pll разгоняющую в N раз клок для делителя.
Про запрещение перехода в другой клоковый домен в задаче ведь ничего не сказано. 😀
Ой, ошибся. Деления конечно. N блоков и планировщик - то есть на пункт 1 вы ответили. После этого ответа я прошу изобразить код на верилоге на доске. Качественный кандидат минут за 15 пишет. После чего вопрос - как к этому добавить backpressure
Если выходная латентность больше или равна N то задача решается FIFO и сдвиговым регистром на N позиций и процессом который начинает тащщить результаты из FIFO при появлении 1 на выходе из регистра, заталкиваем 1 в сдвиговый каждый раз как arg_valid для делителя/“умножителя”.
Тут уже воспользовался корреляционным помошником:
import spinal.core._
import spinal.lib._
/** Выравнивание выхода конвейерного оператора (делителя/умножителя) с
* латентностью L >= N.
*
* arg_valid ──► shift_reg[N] ──┐
* │ token через N тактов
* op_result ──► FIFO ──────────┴──► result_out
*/
class OperatorLatencyAligner[T <: Data](
payloadType : HardType[T],
n : Int,
fifoDepth : Int
) extends Component {
require(n >= 1)
require(fifoDepth >= 1)
val io = new Bundle {
val argValid = in Bool() // импульс arg_valid оператора
val operatorOut = slave Stream(payloadType) // поток результатов с оператора → в FIFO
val resultOut = master Stream(payloadType) // выровненный по латентности выход
}
// ── N-tap сдвиговый регистр ────────────────────────────────────────
val shiftReg = Reg(Bits(n bits)) init(0)
shiftReg := shiftReg(n - 2 downto 0) ## io.argValid
val tokenAvail = shiftReg.msb // arg_valid, задержанный на N тактов
// ── FIFO результатов ───────────────────────────────────────────────
val fifo = StreamFifo(payloadType, fifoDepth)
fifo.io.push << io.operatorOut
// ── счётчик «висящих» токенов ──────────────────────────────────────
// Если L > N или потребитель backpressure'ит, токены не теряются.
val pending = Reg(UInt(log2Up(fifoDepth + n + 1) bits)) init(0)
val pushTok = tokenAvail
val popTok = io.resultOut.fire
when( pushTok && !popTok) { pending := pending + 1 }
when(!pushTok && popTok) { pending := pending - 1 }
val haveToken = pushTok || pending =/= 0 // bypass на 0 латентность
io.resultOut.valid := haveToken && fifo.io.pop.valid
io.resultOut.payload := fifo.io.pop.payload
fifo.io.pop.ready := haveToken && io.resultOut.ready
}
object OperatorLatencyAlignerVerilog extends App {
SpinalVerilog(new OperatorLatencyAligner(UInt(32 bits), n = 8, fifoDepth = 16))
}Я спиналом не владею, не понимаю что это. Это все решение или только часть? Суть задачи в том, что исходный делитель - не конвейерный. А результирующий модуль должен вести себя будто делитель конвейерный. То есть принимать аргументы в каждом такте и выдавать результат каждый такт с фиксированной латентностью если нет backpressure.
Если это только часть и если цель - выровнять выход неконвейерного делителя до фиксированной латентности, то FIFO не нужно.
То есть вот для такого преобразования FIFO не нужно:
Но это только часть задачи. Нужно еще и чтобы могло принимать каждый такт.
Вариант задачи без ready или с ready? Без ready FIFO не нужно.
Умножителя нет, только делители. Про умножитель я выше описался.
Вообще вы несколько мутно написали. В какой момент происходит вталкивание в FIFO? При появлении res_valid от делителя? А если второй делитель сработает на несколько тактов раньше чем первый, то есть arg1 появился в такте 1, res1 возник в такте 10, а arg2 пришел в такте 2, но res2 возник в такте 8? Будет ли тогда res2 втолкнут в FIFO раньше чем res1?
Вы вообще можете нарисовать все делители, сдвиговый регистр и FIFO на картинке и написать код или псевдокод?
Я честно запутался что реально требуется :) Я решил задачу для одного блока (limited resources - XC2S15 :)) ), когда мы фиксируем latency на время большее чем N. Часто нужно если управляем NCO, но если вам нужно N-1 итд (c много-блоками), то будет немного по другому. Вечером подумаю, сейчас нас ждут самолеты…
Да, с много-много блоками. И вы не торопитесь и даже можете показать решение на SpinalHDL - мне самому любопытно посмотреть как SpinalHDL экономит код на решении таких задач.
Вот на Spinal, идея примерно та же, набор свободных блоков, индех свободного блока может быть в списке типа сдвигового массива FIR filter. Но в нашем случае можно просто round robin. Комментарий причесан LLM т.к у меня нет русской клавиатуры для больших писем :)
import spinal.core._
import spinal.lib._
/** ============================================================================
* FixedLatencyBlockPool
* ----------------------------------------------------------------------------
* Обёртка над пулом из N независимых вычислительных блоков, каждый из которых
* может тратить от 1 до N тактов на одну операцию и завершаться вне порядка
* поступления задач (out-of-order completion).
*
* Снаружи компонент выглядит как конвейер с ФИКСИРОВАННОЙ латентностью ровно
* N тактов: подал arg на такте T → получил result на такте T+N.
* Пропускная способность — 1 операция за такт (non-blocking, без backpressure).
*
* Принцип работы:
* 1. Round-robin распределяет входные задачи по блокам 0,1,...,N-1,0,1,...
* Так как блок переиспользуется ровно через N тактов, а максимальная
* латентность блока тоже N — он гарантированно успевает освободиться.
* Явный free-list не нужен.
*
* 2. Каждый блок имеет персональный регистр-защёлку (latch). Если блок
* завершился раньше N тактов — результат сохраняется и ждёт своей очереди
* на выход.
*
* 3. Сдвиговый регистр глубиной N тащит пару (valid, idx) — он определяет,
* результат КАКОГО блока будет выдан на текущем такте. Именно он
* обеспечивает выдачу В ПОРЯДКЕ поступления задач, несмотря на то что
* блоки могут завершаться вне порядка.
*
* 4. На выходе стоит мультиплексор-байпас: если выбранный блок отдаёт
* результат ИМЕННО НА ЭТОМ такте (т.е. блок отработал ровно N тактов и
* латч ещё не успел обновиться) — берём значение напрямую с шины блока,
* минуя регистр.
*
* Параметры:
* - argType : тип входного операнда (HardType, чтобы можно было передавать
* и Bundle, и UInt, и т.п.)
* - resType : тип результата
* - n : количество блоков И одновременно глубина выходной латентности
* ==========================================================================*/
class FixedLatencyBlockPool[A <: Data, R <: Data](
argType : HardType[A],
resType : HardType[R],
n : Int
) extends Component {
require(n >= 1, "Нужен хотя бы один вычислительный блок")
val io = new Bundle {
// ── Вход компонента (от источника задач) ─────────────────────────────────
// Источник может подавать одну задачу за такт, без права на отказ
// (non-blocking). Backpressure наружу не выводится.
val argValid = in Bool()
val arg = in (argType)
// ── Интерфейс к N внешним вычислительным блокам ──────────────────────────
// На каждый блок идёт свой строб argValid и общий (по значению) arg.
// От блока ждём асинхронный по латентности (1..N тактов) ответ через
// resultValid + result.
val blkArgValid = out Vec(Bool(), n)
val blkArg = out Vec(argType, n)
val blkResultValid = in Vec(Bool(), n)
val blkResult = in Vec(resType, n)
// ── Выход компонента (потребителю) ───────────────────────────────────────
// resultValid поднимается ровно через N тактов после соответствующего
// argValid. Если на входе был «пузырь» — на выходе он тоже будет пузырём.
val resultValid = out Bool()
val result = out(resType)
}
// ─────────────────────────────────────────────────────────────────────────
// 1. Round-robin выбор блока для текущей задачи
// ─────────────────────────────────────────────────────────────────────────
// Указатель rr хранит номер блока, в который УЙДЁТ следующая задача.
// Инкрементируется ТОЛЬКО на тактах с argValid=1 — пузыри (gap-такты) не
// должны сбивать раскладку, иначе сломается соответствие idx ↔ блок в
// выходном сдвиговом регистре.
//
// Почему этого достаточно вместо явной очереди свободных блоков:
// блок i получает задачу на такте T, и СЛЕДУЮЩУЮ задачу — на такте T+N
// (так как rr делает полный круг ровно за N инкрементов).
// Максимальная латентность блока тоже N, значит к моменту T+N он точно
// свободен. Free-list тут вырождается до счётчика по модулю N.
val rr = Counter(n)
when(io.argValid) { rr.increment() }
// Дешифратор «one-hot» строба: argValid идёт только на тот блок,
// на который сейчас указывает rr. На все остальные подаётся 0.
// Операнд arg раздаётся всем блокам одинаково — лишний фанаут безвреден,
// блок всё равно работает только когда у него взведён argValid.
for (i <- 0 until n) {
io.blkArgValid(i) := io.argValid && (rr.value === i)
io.blkArg(i) := io.arg
}
// ─────────────────────────────────────────────────────────────────────────
// 2. Персональные защёлки результатов
// ─────────────────────────────────────────────────────────────────────────
// Поскольку блоки могут завершаться вне порядка (например, блок 2 закончил
// за 1 такт, а блок 0 — за 3), нельзя просто взять результат с шины блока в
// момент выдачи. Нужно где-то его подержать до своей очереди.
//
// Решение: на каждый блок свой регистр. Когда у блока поднимается
// resultValid — защёлкиваем result. Дальше он будет ждать своего такта
// выдачи на финальном выходе компонента.
//
// Гонок здесь не возникает: rr-расписание гарантирует, что между двумя
// захватами защёлки блока i проходит ровно N тактов, а к этому моменту
// старое значение уже было прочитано на выходе.
val blkLatched = Vec.fill(n)(Reg(resType()))
for (i <- 0 until n) {
when(io.blkResultValid(i)) {
blkLatched(i) := io.blkResult(i)
}
}
// ─────────────────────────────────────────────────────────────────────────
// 3. Сдвиговый регистр глубиной N — линия задержки тегов
// ─────────────────────────────────────────────────────────────────────────
// Тащит пару (valid, idx) от входа к выходу.
// - valid : был ли реальный argValid в соответствующем такте (отличает
// полезные слоты от пузырей);
// - idx : номер блока, в который эта задача была отправлена.
//
// На выходе сдвигового регистра (pipe(n-1)) мы получаем тег задачи, которая
// поступила ровно N тактов назад — её результат и нужно выдать СЕЙЧАС.
// Именно эта линия задержки превращает out-of-order завершение блоков
// обратно в in-order выдачу наружу.
case class Tag() extends Bundle {
val valid = Bool()
val idx = UInt(log2Up(n) bits)
}
val pipe = Vec.fill(n)(Reg(Tag()))
pipe.foreach(_.valid init False) // важно: idx можно не инициализировать,
// он читается только если valid=1
// Загружаем первую ступень текущим тегом и сдвигаем остальные.
pipe(0).valid := io.argValid
pipe(0).idx := rr.value
for (i <- 1 until n) pipe(i) := pipe(i - 1)
// ─────────────────────────────────────────────────────────────────────────
// 4. Финальная выдача результата
// ─────────────────────────────────────────────────────────────────────────
// resultValid просто следует за valid-битом, доехавшим до конца линии
// задержки. result — это содержимое защёлки блока, на который указывает
// выехавший тег.
io.resultValid := pipe(n - 1).valid
io.result := blkLatched(pipe(n - 1).idx)
// ── ВНИМАНИЕ: пограничный случай ──
// Если блок реально использует ВЕСЬ свой бюджет в N тактов, его
// resultValid поднимется ИМЕННО на том такте, когда тег уже стоит на выходе
// линии задержки. К концу этого такта защёлка обновится — но мы читаем её
// комбинаторно В ТЕЧЕНИЕ этого же такта, т.е. видим ещё СТАРОЕ значение.
//
// Решение — комбинаторный байпас: если блок отдаёт resultValid на этом такте,
// брать результат прямо с шины блока, минуя защёлку. В этом варианте
// компонента байпас НЕ установлен — его стоит добавить, если блоки реально
// могут тратить ровно N тактов (а не строго меньше):
//
// val outIdx = pipe(n - 1).idx
// io.result := Mux(io.blkResultValid(outIdx),
// io.blkResult(outIdx),
// blkLatched(outIdx))
}Вот так выглядит пример и тест где я сделал умножитель который выдает результат через T тактов где Т зависит от нижних битов операнда
// ── Phantom multiplier: latency derived from b's low bits, 1..N ──────
class PhantomMultiplier(width: Int, n: Int) extends Component {
val io = new Bundle {
val argValid = in Bool()
val arg = in (MulArg(width))
val resultValid = out Bool()
val result = out UInt(2 * width bits)
}
val cw = log2Up(n + 1)
val nLat = U(n, cw bits)
val bMod = (io.arg.b % nLat).resize(cw bits)
val latency = (bMod === 0) ? nLat | bMod // 1..n
val counter = Reg(UInt(cw bits)) init 0
val resultReg = Reg(UInt(2 * width bits)) init 0
when(io.argValid) {
resultReg := io.arg.a * io.arg.b
counter := latency
} elsewhen(counter =/= 0) {
counter := counter - 1
}
io.resultValid := counter === 1
io.result := resultReg
}
// ── Testbench: pool + N phantom blocks, signals exposed for sim ──────
class PoolTestBench(width: Int, n: Int) extends Component {
val io = new Bundle {
val argValid = in Bool()
val arg = in (MulArg(width))
val resultValid = out Bool()
val result = out UInt(2 * width bits)
val blkFire = out Vec(Bool(), n)
val blkIssue = out Vec(Bool(), n)
}
val pool = new FixedLatencyBlockPool(MulArg(width),
HardType(UInt(2 * width bits)), n)
val blocks = List.fill(n)(new PhantomMultiplier(width, n))
pool.io.argValid := io.argValid
pool.io.arg := io.arg
for (i <- 0 until n) {
blocks(i).io.argValid := pool.io.blkArgValid(i)
blocks(i).io.arg := pool.io.blkArg(i)
pool.io.blkResultValid(i) := blocks(i).io.resultValid
pool.io.blkResult(i) := blocks(i).io.result
io.blkFire(i) := blocks(i).io.resultValid
io.blkIssue(i) := pool.io.blkArgValid(i)
}
io.resultValid := pool.io.resultValid
io.result := pool.io.result
}Результаты теста:
[Progress] IVerilog compilation started
[Progress] IVerilog compilation done in 60.751 ms
[Progress] Start PoolTestBench test simulation with seed 1340115538
[t= 2] issue # 0 a=13725 b=63370 blk_lat=2
[t= 3] issue # 1 a=57787 b=10432 blk_lat=4
[t= 4] issue # 2 a=58428 b=19387 blk_lat=3
[t= 5] issue # 3 a=33693 b=28037 blk_lat=1
[t= 5] block 0 fired
[t= 6] issue # 4 a=48746 b=39436 blk_lat=4
[t= 7] result # 0 = 869753250 ok
[t= 7] issue # 5 a=48487 b=56471 blk_lat=3
[t= 7] block 3 fired
[t= 8] result # 1 = 602833984 ok
[t= 8] block 1 fired
[t= 8] block 2 fired
[t= 8] issue # 6 a=39310 b=34908 blk_lat=4
[t= 9] result # 2 = 1132743636 ok
[t= 9] issue # 7 a=63596 b= 8382 blk_lat=2
[t= 10] result # 3 = 944650641 ok
[t= 10] issue # 8 a= 4352 b=21591 blk_lat=3
[t= 11] result # 4 = 1922347256 ok
[t= 11] issue # 9 a= 3904 b=58273 blk_lat=1
[t= 11] block 0 fired
[t= 11] block 1 fired
[t= 12] result # 5 = 2738109377 ok
[t= 12] block 3 fired
[t= 12] issue #10 a=61712 b=28604 blk_lat=4
[t= 13] result # 6 = 1372233480 ok
[t= 13] issue #11 a=21983 b=33720 blk_lat=4
[t= 13] block 1 fired
[t= 13] block 2 fired
[t= 14] result # 7 = 533061672 ok
[t= 14] block 0 fired
[t= 14] issue #12 a=55001 b=21208 blk_lat=4
[t= 15] result # 8 = 93964032 ok
[t= 15] issue #13 a=56331 b= 1411 blk_lat=3
[t= 16] result # 9 = 227497792 ok
[t= 16] issue #14 a= 5805 b=35911 blk_lat=3
[t= 17] result #10 = 1765210048 ok
[t= 17] issue #15 a=62544 b=18777 blk_lat=1
[t= 17] block 2 fired
[t= 18] result #11 = 741266760 ok
[t= 18] block 3 fired
[t= 19] result #12 = 1166461208 ok
[t= 19] block 0 fired
[t= 19] block 1 fired
[t= 19] block 3 fired
[t= 20] result #13 = 79483041 ok
[t= 20] block 2 fired
[t= 21] result #14 = 208463355 ok
[t= 22] result #15 = 1174388688 ok
All 16 results in order. Wrapper latency = 4 cycles.Хм, интересно. А если с backpressure?
С backpressure, переходим на stream, но тесты уже лень писать.
import spinal.core._
import spinal.lib._
class FixedLatencyBlockPool[A <: Data, R <: Data](
argType : HardType[A],
resType : HardType[R],
n : Int
) extends Component {
require(n >= 1)
val io = new Bundle {
val arg = slave Stream(argType) // upstream, may stall
val blkArgValid = out Vec(Bool(), n)
val blkArg = out Vec(argType, n)
val blkResultValid = in Vec(Bool(), n)
val blkResult = in Vec(resType, n)
val result = master Stream(resType) // downstream, may stall
}
// ── pipe advance condition ──────────────────────────────────────────
// The tag pipe is rigid — all stages shift together or none. It can
// shift iff the output slot will be free this cycle: either it already
// holds a bubble, or the consumer is taking the result.
case class Tag() extends Bundle {
val valid = Bool()
val idx = UInt(log2Up(n) bits)
}
val pipe = Vec.fill(n)(Reg(Tag()))
pipe.foreach(_.valid init False)
val advance = !pipe(n - 1).valid || io.result.ready
// ── upstream handshake ──────────────────────────────────────────────
// We can accept iff the pipe will shift this cycle (otherwise pipe(0)
// would clobber a still-needed tag).
io.arg.ready := advance
val argFire = io.arg.fire // == io.arg.valid && advance
// ── round-robin, gated by argFire ───────────────────────────────────
val rr = Counter(n)
when(argFire) { rr.increment() }
for (i <- 0 until n) {
io.blkArgValid(i) := argFire && (rr.value === i)
io.blkArg(i) := io.arg.payload
}
// ── per-block result latches (out-of-order completion absorber) ─────
// Blocks keep running during stalls; their results land here and wait.
val blkLatched = Vec.fill(n)(Reg(resType()))
for (i <- 0 until n) {
when(io.blkResultValid(i)) { blkLatched(i) := io.blkResult(i) }
}
// ── tag pipe, frozen when !advance ──────────────────────────────────
when(advance) {
pipe(0).valid := argFire
pipe(0).idx := rr.value
for (i <- 1 until n) pipe(i) := pipe(i - 1)
}
// ── output mux with same-cycle bypass (for blocks finishing at lat=N)
val outIdx = pipe(n - 1).idx
io.result.valid := pipe(n - 1).valid
io.result.payload := Mux(io.blkResultValid(outIdx),
io.blkResult(outIdx),
blkLatched(outIdx))
}Должен сказать, я не верю что вместе с написанием это 30и минутная задача. 1 - 1.5 часа будет хорошо. Хотя товарищ который писал Лексикон (Веселов) - кодировал новые features co страшной скоростью - но он гений.
Один из супер важных моментов со Spinal - это использование IDE (IntelliJ IDEA) подсказки и проверки многих косяков возникают прямо по мере написания… это очень значительно облегчает работу.
Вы останавливаете весь процесс, когда когда на выходе read=0? Я не въезжаю в spinal, но не вижу у вас FIFO, в которое сливаются результаты если на downstream произошел останов.
Я про:
The tag pipe is rigid — all stages shift together or none. It can // shift iff the output slot will be free this cycle: either it already // holds a bubble, or the consumer is taking the result.
Веселова встречал вживую еще в 1987 году в Москве и потом снова в 1993 уже в Калифорнии. В последние годы он меня правда ругал на фейсбуке.
Насчет времени - ну там три компоненты: 1) инстанциировать N делителей и указатель следующего с assumption что у неконвейерного делителя фиксированная латентность. Хороший кандидат это делает за 30 минут - это я уже видел у трех или четырех кандидатов
2) Превратить неконвейерный с переменной латентностью в неконвейрный с фиксированной латентностью - ну на это еще какое-то время и
3) добавить FIFO и кредитные счетчики для backpressure:
Инженеры с опытом в Самсунге, AMD, Apple, Juniper/HP делают (3) на автомате.
Так что да, в сумме час, если расслабленно - полтора.
Отличная задачка на подумать. Сначала прикинул с N блоками А/В, потом решил обойтись одним. За 10-15 минут надумалась схема подсчитывающая время выдачи результата из А/В и в зависимости от этого мультиплексирующая выход A/B с его сигналом VDo на один из N сдвиговых 9-битных регистров (в случае 8-битного слова С), имеющих фиксированную нарастающую задержку от 1 до N (первый регистр = 1 такт, второй = 2... последний = N). Выходы регистров тупо мультиплексируются по ИЛИ - старший бит будет выходом VDo блока, остальные - шина результата блока. Схема контроля содержит N счётчиков, которые разрешаются/сбрасываются сигналами VDi/VDo от А/В. На каждые новые данные запускается свой индивидуальный счётчик, после задействования последнего возвращаемся к первому. Конвейерная задержка блока будет равна то ли N, то ли N+1 - выясняется на этапе разработки.
Разнотактовые входы роли никакой особо тут не сыграют. Введение RDY тоже вроде бы особых проблем не должно составить, так как этот сигнал может управлять EN сдвиговых регистров и разрешением приёма по входу. Если в момент падения RDY А/В будет работать, то вроде бы ничего страшного - схема контроля направит результат на вход нужного регистра. Тут нужно будет подумать при наличии этого сигнала защитить логику - вдруг по входу кто-то VDi выставит - это нужно будет игнорировать и, в идеале, Error выставить.
С возрастом всё самое интересное оказывается в содержании пункта 1. Идея и архитектура под неё, рисуемая квадратиками карандашиком на бумажке. Код писать - это уже рутина и работа. Тем более на доске я синтаксис точно завалю))
Сначала прикинул с N блоками А/В, потом решил обойтись одним.
С одним неконвейерным блоком A/B у вас не получится пропускная способность 1 транзакция/такт неограниченное время, это физически невозможно. А вот с N получится.
Если в момент падения RDY А/В будет работать, то вроде бы ничего страшного - схема контроля направит результат на вход нужного регистра.
Не будет ли здесь возможности потери данных?
Тут нужно будет подумать при наличии этого сигнала защитить логику - вдруг по входу кто-то VDi выставит - это нужно будет игнорировать и, в идеале, Error выставить.
Error с потерей данных? Нет, в условии что блок должен работать без потерь данных при любых паттернах ready
Я почему-то думал, что он конвейерный. Он такой большой и красный, что кажется чем-то фундаментальным. И вообще - а где написано, что он неконвейерный? ) Родство ИИ и ЕИ в том, что это довольно галлюцинирующие штуки - поставишь задачу с чуть неполными условиями и они наделают такого, что не надо.
Потери данных при изменении RDY не будет, если в этом режиме работы выход с А/В защелкивать в начале сдвигового регистра. Но это как-то некрасиво, поэтому в вышеизложенную реализацию такой защелкивающий регистр лучше сделать на выходе А/В - при нормальной работе он будет конвейерным, а при торможении просто сохраняющим. Но в любом случае, если блок А/В не конвейерный, то это всё неважно.
Error должен выставляться в случае запрета приёма данных по входу, но в случае их всё же появления. В этом случае будет потеря данных - я запретил их мне передавать, но они пришли. Возможно у меня профдеформация по обработке нештатных ситуаций, которая потом здорово помогает при отладке.
Реальные проблемы с таймингами никто не спросил, зато устроили экзамен по истории информатики)
О, если бы знали как тяжело внедрялся язык Си в 80-х годах прошлого столетия в нашей стране
Спустя годы, в начале 2000-х только один человек при встрече со мной сказал искреннее спасибо за то, что тогда в 80-х настаивал на изучении и внедрении Юникса и Си.
Вы смысле "если бы"? Я читал книжку Кернигана-Ричи и "ОС Инмос" (советский Unix) все в том же 9 классе в 1986 году. Я потом летом 1986 года программировал на Си - см. https://habr.com/en/posts/1028712/
Насколько я помню народ перешел с Паскаля на Си в 1985-1987. Си был внедрен в ВЦ АН в Москве, в новосибирском акдемгородке. В Курчатнике и еще одном месте возникла группа которая потом стала кооперативом Демос.
А еще была МОС ЕС на ЕС ЭВМ, тоже Unix-система:
И там где был Unix, естественно, был и Си. Но в эти годы доминировал, конечно, PL/1. И никакие доводы не могли переломить эту ситуацию. Чтобы приучить к Си, мы сначала внедрили Паскаль, а затем и Си. Книги, про которые вы пишите, были настольными книгами у меня. Но в нашем институте за Си пришлось повоевать. ВЦ АН СССР, Новосибирский академгородок, это все же не рядовые НИИ, вам повезло.
Да, ваша хаброзаметка познавательная
Риторический вопрос.
А, Форт у себя не рассматривали, т.к. по книге Баранова, Ноздрунова “Форт и его реализации” он много где отметился в НИИ СССР, не считая DSSP (Диалоговая Система Структурного Программирования) происхождением из МГУ?
Нет, не рассматривался.Тогда уже было ясно, что так или иначе будущее за ОС типа Unix (винды еще не было, да и она выйдет из Xenix-а), а это всё же Си. Реалии сегодняшнего дня подтверждаю это (тот же Linux)
Гонки в верилоге - это реально база, но гонять деда по синтаксису мертвых языков чисто ради эго - такое себе удовольствие)
Ну а что с ним делать, если он соскочил с первого же вопроса на другой язык, а потом это повторил снова и снова?
Я студентов перед экзаменом честно предупреждаю, что язык их — враг их, а валить я умею единственным вопросом: «почему?».
если именно соскочил, возможно продолжать смысла нет, это все же не экзамен на отметку в школе, у меня несколько другой стиль интервью был, вообще вопросы на которые за 2 минуты есть ответ в сети не видел смысла спрашивать, задачи по программированию тоже, тем более терминологию, просто спрашивал "как работает" типа своими словами про то, что сделано лично по резюме, не помню случая, чтобы не стало более-менее понятно, следующий уровень вопросов - начиная с краткого введения в новый проект, типа что надо делать по мнению кандидата, как и что он может contribute, плюс будет ли это для кандидата интересно, кроме оценки кандидата цель интервью также установление определенной степени доверия, типа никто его здесь не кинет, проведенных интервью было реально много
Я, кажется, понял: деда кто-то проталкивал на это место и посадить в лужу надо было показательно
Ну да, выживают за счет подвешенного языка и солидного вида. Продают себя дорого, сидят на легаси тестах, а когда пахнет жареным - просто меняют контору
Постоянно эта путаница происходит. В таких статьях работа - собеседование, не программирование. А поэтому методы могут быть любыми как его проводить и как его проходить. Можно даже скакать наперегонки.
Сам метод мне кажется сомнительным. Если уж ищут кандидата на Go, то вряд ли поможет переход на Ada.
При таком подходе я бы наверное тоже не прошел собеседование (; Хотя у меня опыт больше 40 лет. Я просто честно отвечаю - я этим занимался, но подробностей не помню, зато у меня есть опыт, я знаю где это посмотреть, что лучше применять архитектурно. Вы можеете взять студента который ответит лучше меня на вашу "викторину" - но навряд ли он сможет лучше решить конкретную задачу. Потому что если я чего-то не знаю, я умею это узнавать (;
Да, времена и нравы изменились и мало смысла пытаться поучавствовать в “тараканьих” бегах, Всё нужное Мы уже прошли и что хотели доказали себе, и на “Слабо” не имеет смысла провацировать, бумеранг прилетит обратно. :)
Так он сам попал в такой путь, когда начал перескакивать на другие языки. У каждого человека должна быть технология, которую он знает хорошо. У одного это C в embedded контексте, у другого SystemVerilog с микроархитектурой, у третьего еще что-то. Вот про это и должно быть интервью. Если такой точки нет, то первой что нужно сделать - что-то хорошо выучить, даже если это займет скажем год или два. Иначе может получиться вот такое. А что делать интервьюеру? Сказать "хорошо, мы верим, вы все выучите?" Но для такой веры нужно обоснование - пример того, что человек уже знает хорошо.
Вот полностью с вами согласен. Особенно поражают такие деятели, которые на собеседовании хотят от кандидата по памяти собрать звездолет, а в реальности все их рабочие задачи это разгребать дикое легаси или перекладывать json’ы между разными API. Я за почти 30 лет в профессии успел работать и яндексе, и в скайпе и в microsoft, плюс имею знакомых в гугле и прочем FAANG’е и везде собеседование обычно дико оторвано от повседневной рабочей реальности. В этом смысле наиболее нормальное место работы от небольшой стартап. Но найти успешный это всегда лотерея.
Но в эту игру можно играть вдвоем - у таких деятелей в ответ можно спросить - а как у вас принимаются решения и сколько времени занимает довести фичу до прода? Есть ли в компании стеклянный потолок, если ты не кореец? (это мой небольшой инсайд про самсунг). Обычно чем больше компания, тем большее болото она из себя представляет.
Вы просто не дочитали мою заметку до конца. Я начал с ним прыгать по кочкам, когда он отфутболил три вопроса по релевантным языкам (SystemVerilog, Verilog и VHDL) и перескочил на нерелевантные (которые компании конечно и нафиг не были нужны):
Тут я начал подозревать, что кандидат просто прыгает с языка на язык, чтобы завести меня в область, в которой я ничего не знаю, чтобы я его отпустил (его ждали интервьировать еще три человека в компании).
Все это было до Самсунга. При этом на моих текущих собеседованиях в Самсунге я использую задачи которые возникают прямо от сохи (то есть сегодня возникла проблема в работе, завтра она уже на интервью).
Один пример - выше:
https://habr.com/en/articles/1033360/comments/#comment_29951404
Или вот такой. Она выглядит простой, типа первый простой вопрос на интервью, но если студента вуз не тренировал упражнениями на последовательностую логику, то он на ней зависает:
Превратите последовательности с битом first в последовательности с битом last. Полная формулировка: на вход цифрового блока приходят последовательности из трансферов данных. Каждый трансфер считывается на положительном фронте тактового сигнала clock, на котором сигнал valid=1. Первый трансфер в каждой последовательности обозначен сигналом first. Блок должен выдавать на выходе такую же последовательность, но маркировать не первый трансфер, а последний сигналом last. Напишите код на языке описания аппаратуры Verilog который это делает".
D-триггер в цепочке данных?
Не совсем, т.к непонятно что делать после ресета, и в больших перерывах valid “first@data1…data_N_________” Надо задерживать данные и valid и видимо игнорировать первый first after reset.
По сути да, нужно просто аккуратно это написать и спросить правильный вопрос:
https://habr.com/en/articles/1033360/comments/#comment_29976070
Интересен сам факт того что он весь этот стек знает даже на уровне названий (вместе с автором, что еще интереснее). Любопытный персонаж, я бы его попробовал разговорить за жизнь и по задачам, которые он решал
В надежде, что персонаж, врущий на собеседовании, вдруг раскроет душу и расскажет, как он дошёл до такой жизни?..
Скорее всего во всём этом он либо просто стоял рядом, либо через такое же собеседование устраивался на синьористую позицию, на которой сначала «надо погрузиться в проект», а дальше в соответствии с анекдотом про три конверта. В целом умение беззастенчиво врать в таком режиме года по три-четыре позволит на каждом месте продержаться.
Что я могу сказать? У вас феноменальная память
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Перепрыгивание с языка на язык как тактика прохождения интервью