Комментарии 75
Спасибо за статью! Проблема действительно острая! Но хочу обратить внимание что опять даже в разработке физических чипов присутствует тяга к программированию. Как в анекдоте про студента который выучил на экзамене только про блох, а его спросили про рыб. Он и говорит что рыбы живут в воде и у них нет шерсти, но если бы была, то там водились блохи и давай про блох дальше... Кто сейчас лидеры в производстве чипов - те у кого лучший техпроцесс, как все эти среды разработки позволят улучшить техпроцесс? Есть такой чудесный предмет в ВУЗах - называется ФОЭ (Физические основы электроники) Вот расспросите современных программистов - что они знают про p-n переход. А ведь именно с ним в конечном счете связано все их программирование.
Как я описал выше, все эти вещи должны хорошо представлять process engineer на фабе, разработчик ASIC library и немного physical design engineer.
Для разработчика микроархитектуры и проектировщика на уровне регистровых передач вся физика - задержки в пикосекундах, статическое и динамическое энергопотребление и размеры - изолированы в ячейках standard cell library и алгоритмах EDA. То есть от него требуется анализировать static timing analysis report, в которых конечно есть пикосекунды, но от ФОЭ это далеко.
А для функциональной верификации это еще меньше нужно, так как в ней пикосекунды и нановатты появляются очень косвенно - для верификатора стоит знать про clock gating и стадии конвейера, которые непрямым образом связаны с той физикой.
Так что в этом деле есть место для специализаций разной степени удаленности от физики.
*** Кто сейчас лидеры в производстве чипов ***
Является ли скажем Apple лидером в производстве чипов? Нет, не является, он использует фабы других компаний. При этом является ли Apple лидером в проектировании чипов? Конечно является - Apple M1 пример. Что является фокусом Apple M1 ? Микроархитектура. Связана ли микроархитектура с техпроцессом? Косвенно.
Вот если бы на apple сейчас наложили санкции как на нас, то они бы уже обанкротились наверно). В наших условиях, я считаю, важно именно осваивать полный цикл и выходить в лидеры начиная с физики, а использование готовых физических решений обрекает нас всегда быть догоняющими.
Но в посте же я обсуждаю совсем другую проблему - не проблему России, которой производители оборудования для фабов не хотят продавать степперы, а проблему Кыргызстана, где нет даже российкого уровня понимания полупроводникового производства, поэтому заходить с этой стороны менее эффективно, чем с других, в частности функциональной верификации. Это подход, который оправдал себя например c аутсорсом верификации от японской Seiko Epson филиппинским аутсорсерам.
Ну в принципе Американскому Университету в Центральной Азии и Siemens Electronic Design Automation GmbH только того и надо - сделать группу разработчиков "без понимания" и в полной зависимости от внешних ресурсов...
А есть альтернатива для первого шага? Или вы предлагаете начать с изобретения оборудования для производства микросхем уровня начала 1970-х и за каких-нибудь двести лет изобрести все степперы итд до 3 нм?
Думаю многие были бы не против если бы их высосала международная корпорация, чем если это сделают российские чинуши.
Мир это глобальная конкуренция. Может цель корпорации не помочь маленькой стране развиться и конкурировать, а высосать потенциальные таланты?
Я думал цель корпорации — заработать денег, для чего можно и талантов нанять в другой стране и бизнес туда перенести, если налогов меньше придётся платить.
Есть такой чудесный предмет в ВУЗах — называется ФОЭ (Физические основы электроники) Вот расспросите современных программистов — что они знают про p-n переход. А ведь именно с ним в конечном счете связано все их программирование.
А электронщиков, видимо, надо начинать учить добыче лития?
Если завтра все схемы волшебным образом заменятся на оптические или биологические без p-n переходов (но с такой же скоростью и процентом ошибок) — программирование не изменится совсем.
Было бы неплохо если бы у электронщиков было понимание об этом процессе. Они бы лучше понимали что может повлиять на поставку электронных компонентов.
биологические есть. каждый человек обладает как минимум одним. программирование ребенка довольно отличается от ЭВМ
p-n переход?
Серьезно?
Микропроцессорная техника давным давно ушла в КМОП, а может и дальше.
Как выр
оастить
Начать с правописания?
Я, когда был в Индонезии, открыл для себя со слов своих друзей, что электроника там изучается как школьный предмет — пусть и необязательный, но который многие выбирают по желанию. Думаю, нам этого не хватает. С другой стороны, в период моей юности я видел вокруг гораздо больше интереса к электронике, нежели сейчас, хотя возможностей сейчас несоизмеримо больше. Парадокс.
Да, в Индонезии еще в 1970-е годы собирался каждый четвертый в мире телевизор, да и рядом Малайзия с фабами и Сингапур, так что вовлеченность в школьной программе понятна.
С другой стороны, в период моей юности я видел вокруг гораздо больше интереса к электронике, нежели сейчас, хотя возможностей сейчас несоизмеримо больше. Парадокс.
Если ваша юность приходилась на СССР, то тогда многим приходилось делать электронные устройства самостоятельно из-за дефицита. Теперь же можно без проблем купить какую угодно электронику.
Нет, на 1990-е, но ни мной, ни моими знакомыми двигало явно не это, просто был банальный интерес к творчеству, создать что-то своими руками ощущалось «круто». Мы делали порой нелепые и странные вещи (например напаивали светодиоды на спицы советского велосипеда — до сих пор помню, как на удивление легко они лудились) и переключали их примитивным мультивибратором на 2 транзисторах. И сколько эмоций потом приносила езда на таком — не описать!
Да, велосипед широко использовался как способ демонстрации своих наработок :)
Ещё одна конструкция, которая иногда встречалась — на руле крепился калькулятор, к контактам «=» был подпаян геркон, закреплённый на раме, а где-то на спицах крепился магнит. На калькуляторе вводилась длина окружности колеса (к примеру 1.16), затем «+ 1.16» — и дальше можно было просто ехать и на экране отображалось пройденное расстояние.
У кого скиллов побольше — собирали оптический аналог, вроде в одном из номеров журнала «в помощь радиолюбителю» была схема цифрового спидометра (измерял скорость по частоте «мелькания» спиц) между источником и приёмником.
Когда я менял специализацию, выбирал между микроэлектроникой (дизайн, проектирование) и web-программированием. Анализ предложений на рынке труда сделал выбор за меня в пользу последнего. Какой смысл идти в направление, где зарплаты в 2 раза ниже при одинаковом уровне квалификации?
О рынке какой страны вы говорите? Можете назвать конкретные цифры?
В момент выбора речь шла о РФ, конечно.
Под моим постом Хабр показал следующие текущие российcкие вакансии. Это для России много или мало? По сравнению с веб-программированием в России же
Верно, это уровень сеньора. Обратите внимание на сеньорские позиции в разработке. Хотел отметить ещё один важный момент, начинаем мы с джунов и далее растём. Временная кривая профессионального роста на девелоперских позициях, особенно на "галерах", выглядит существенно круче. 3 года до миддла вполне реально. В инженерии микроконтроллеров это лет 5-6 в силу различных особенностей физических систем.
Она может создать группу по аутсорсу так называемой функциональной верификации
А какой смысл растить UVMщиков, ведь всем известно что в функциональную верификацию идут только те, кого не взяли в нормальные программисты? Уровень computer science подготовки в РФ пока выше чем в Индии или Филиппинах, зачем нам отбирать хлеб у самых бедных стран? Лучше сфокусироваться на разработке архитектур и компиляторов, а группу по верификации создавать в дружественных странах, например в Иране, Венесуэле или Центральной Африканской Республике.
Вы похоже не дочитали до третьего абзаца и начали комментировать
Также насчет функциональной верификации вы неправы. Есть люди, которые занимаются интересным задачами в этой области, скажем верификацией многоядерных кластеров с когерентными кэшами. Или скажем формальной верификацией конвейера в процессоре.
И сводить верификаторов к UVMщикам - это вы просто не очень знаете реальную ситуацию в большом количестве компаний. Хотя про UVM говорили "все индустрия выстраивается вокруг UVM" еще в 2010 году, но реально в больших компаниях UVM используют достаточно ограниченно и часто выдумывают свои наборы примитивов, так как в UVM трудно делать многие вещи (скажем гибкие sequences) и UVMщики часто заняты борьбой с вычурностью UVM вместо реальной работы по верификации.
UVM можно использовать скажем для некоторых блоков сетевых чипов, но для верификации CPU она слабо применима.
Бишкек говорите... Киргизия... интересный тренд намечается :)
корейская компания SK Hynix создала такую компанию в Беларуси
Скорее купила:
In 2014, SK Hynix acquired the embedded software division of the Softeq Development Company in Minsk.
еще одна полезная статья,
> Инженер по моделированию пишет программу, которая имитирует, как ведет себя блок, но без погружения в детали на уровне тактов
если возможноj чуть подробнее, желательно с примерами, как определяется уровень детализации/абстракции, и использьзуемое для моделирования sw, не совсем понятно что можно сделать полезного "без погружения в детали на уровне тактов", точнее понятно что это возможно далеко не всегда
Например есть шина AXI через которую процессор общается с памятью и периферийными устройствами. Общение можно рассматривать на уровне транзакций типа "записать слово (адрес, данные)" или "прочитать строку кэша (адрес, & данные, & статус)" - или на уровне сигналов (clock, reset, awaddr, awvalid, awready, wdata ...).
На уровне транзакций их поведение можно рассматривать без деталей протокола valid/ready на пяти каналах. Только рассматривать порядок выполнения транзакций. Они могут при этом перекрываться (скажем передача адреса для новой транзакции может начаться до окончания передачи данных предыдущей транзакции). Также данные для чтения могут возвращаться не в том порядке, в котором были посланы адреса для чтения.
Так вот. Инженер-верификатор может написать так называемую bus functional model (BFM) - программу, которая является мостом между транзакциями и последовательностью изменений выходных сигналов на шине. Которая принимает последовательности read, write, fetch_cache_line, atomic_read_write, запускает последовательности изменений сигналов, получает ответы, складирует полученные данные и статусы обратно в транзакции и отдает обратно тесту, который запустил последовательности транзакций.
При этом тестовое окружение может специфицировать разные параметры BFM драйвера - скажем сколько тактов должно быть между началом одной и другой транзакции (min и max) - чтобы проверить, что устройство под тестом (Device Under Test - DUT) обрабатывает все интересные сценарии. Также в тестововм окружении может быть reference slave (модель тестируемого устройства для проверки поведения проектируемого RTL кода). Также в тестовом окружении может быть монитор, который превращает сигналы на шине в транзакции, паралельно работе драйвера и ведомого устройства, и фиксирует нарушения протокола, если они имеются.
Фиксировать ошибки на уровне тактов сложно, так как верификатору не известно, в каком такте что решил делать проектировщик RTL, но вот проверить очередность (что некая запись не переписыват данное по адресу, и последующее чтение почитает именно то, что надо) - это можно и без знания потактового поведения.
очень интересно, какое sw используется для моделирования (looks like event driven)?
достаточно знаком с многоуровневым моделированием в том числе в сетях, но в другом контексте, поэтому относительно хорошо понимаю, о чем идет речь,
пожалуй еще более интересно - как и кто решает на каком уровне абстракции необходимо моделирование по данному изделию (IC) т.е. описывает функциональную модель исходную для моделирования ?
*** очень интересно, какое sw используется для моделирования (looks like event driven)? ***
Коммерческие симуляторы Synopsys VCS, Cadence Xcelium, Siemens EDA (Mentor) QuestaSim, из бесплатных Icarus Verilog (правда он не поддерживает SystemVerilog полностью). Отладка в Synopsys Verdi, Cadence SimVision. Siemens EDA Questa.
В 1990-е годы использовали как правило смесь из кода на Verilog и VHDL с кодом на С/С++ через интерфейс PLI, также язык "e" с тулом Specman. С 2000 года интерфейс DPI, язык SystemVerilog, библиотеку на C++ SystemC. Затем с 2010 года в основном язык SystemVerilog для верификации и язык Verilog 2001/2005 для дизайна, а также библиотеку UVM (до этого была RVM, OVM, VMM). Местами остался язык VHDL - коммерческие тулы (Synopsys/Cadence/Mentor ( Siemens EDA)) умеют симулировать одновременно SystemVerilog и VHDL с вызовами кода на Си. Есть также бесплатный симулятор GVHDL, но в целом VHDL остался в legacy проектах. SystemC тоже не особенно расширяется, то есть достаточно концентрироваться на SystemVerilog на коммерческих тулах и для образования - Icarus Verilog и бесплатная версия QuestaSim (с ограниченной скоростью симуляции по сравнению с платной).
Чем обосновано использования чистого Verilog, а не синтезируемой части SV?
В больших компаниях - инерцией, хотя они постепенно переходят. У поставщиков semiconductor IP - необходимостью совместимости c клиентами и всеми EDA тулами. Пример несовместимости - тул для анализа динамического энергопотребления Synopsys PTPX глючит, если использовать многомерные порты "input [10:0][7:0] abc" которые есть в SV, но нет в Verilog-2001/2005.
Да, инерция есть, но двигаясь вперёд улучшаешь результаты работы.
А Synopsys что по этому поводу говорит, или вы используете старую версию.
Если обьявить тип 8 бит и сделать 1D массив из этих элементов или заменить 2D порт на 11×8 и применить вектор как индекс?
Меня больше раздражает проблемы дамп в fsdb и Verdi для нескольких вызовов функции в одном модуле (он их не распознает и показывает зачения только для одной функции), а также невозможность посмотреть значения для automatic function.
*** пожалуй еще более интересно - как и кто решает на каком уровне абстракции необходимо моделирование по данному изделию (IC) т.е. описывает функциональную модель исходную для моделирования ? ***
Verification architect - он на основе опыта решает стратегию проверки. Например в Интеле, где много инженеров, делают избыточно точные модели процессорных ядер на С++ со всеми деталями конвейера, но в большинстве других компаний как правило RTL описание на Verilog проверяют против модели процессоров (написанных на Си) на уровне инструкций (без моделирования конвейера, например с помощью симулятора Imperas) . И баги ловят, сравнивая результаты записи в видимые программисту регистры в конце конвейера в RTL.
Статья очень грамотная. Единственное, что многие инженеры, как только получат минимальный опыт в России - мгновенно уедут. Во всяком случае я (и многие-многие другие, гораздо большие акулы) буду со своей стороны следить за этим очень внимательно и пытаться привлекать их из-за рубежа, способствуя этому тренду "уезда". Хотя я, конечно, больше по пункту 4: физическое моделирование.
Интересная мысль, верификатор-то как раз может быть индивидуальным предпринимателем и работать удаленно, ему по сути нужен только доступ к софту. Другое дело что это подсознательно воспринимается как работа "второго сорта", всё-таки не сам придумываешь...
Зависит от типа верификатора. Он может продавать скажем Verification IP (Intellectual Property) - параметризуемый код на SystemVerilog для генерации транзакций для стандартных шин (AXI например) и мониторингу шины с экстрагированием транзакций из сигналов (правда это уже хорошо заезженная область). Если речь идет о verification IP для чего-нибудь сложного (например кластере процессорных ядер с когерентными кэшами), то такая работа может быть творческой.
Единственное, что многие инженеры, как только получат минимальный опыт в России - мгновенно уедут.
Статья всё же не про РФ. Многих может удержать возможность заниматься клёвыми вещами за хорошие деньги по месту жительства с сохранением друзей, родственников, связей и прочих активов.
Уехать не так и просто, нужно конкурировать с другими за визы, конкурировать за места с 'говорливыми' индусами. Потом одно дело позиция senior и уже другое staff и выше.
@YuriPanchul, а что вы думаете по поводу вот этих вещей?
Там вроде как красной нитью (особенно у google) проходит мысль о том, что HW разработка должна стать очень похожей на SW. Реалистично ли ожидать на горизонте 10 лет создания открытого тулчейна и новых инструментов для облегчения входа SW инженеров в HW?
Про открытые тулчейны и Google + Skywater я хочу написать отдельный пост. Отношусь я к этому положительно, но каким образом это делает HW разработку более похожей на SW разработку, чем сейчас? C открытым тулчейном OpenLane / Yosys итд проектировщик использует ровно тот же Verilog, и static timing report в OpenLane приниципиально не отличается от такого же отчета от коммерческго Synopsys PrimeTime сейчас. OpenLane пытается сделать с помощью скриптов итеративный процесс синтеза, чтобы можно было нажать кнопку как с софтверной компиляцией, и оно бы само синтезировалось с оптимальным таймингом, используя темплейт Caravel. Но такие же скрипты можно написать для коммерческих тулов. То есть тут вносится открытость, бесплатность и косметически лучшая автоматизация, но суть не меняется.
Или вы хотите сказать про high-level synthesis (HLS)? Ну про HLS уже 30 лет на моей памяти говорят "через 10 лет всё будет HLS", и 30 лет компании берут его, ковыряются и откладывют со словами "лучше по старинке написать нормальный RTL, чем массажировать Си-код прагмами".
Тот случай, когда комментарии читать не менее интересно, чем саму статью)
И статья и комментарии просто удивительны! Всем спасибо!
Панчул все пытается что-то вырастить в стране, где процветает оголтелая радуловщина.
Как вырастить культуру чиподелов в стране, где есть только программисты?