Ну последняя М в названии как раз и говорит, что это мультиплексирование. :) Только это не мультиплексирование пользователей, а поднесущих.
Все-таки, обычно, OFDM считают одной из схем модуляции, только это MCM - multicarrier modulation. Как правило, в цифровой части, модуляцией часто называют процесс формирования модуляционного символа из входного потока битов. Т.е. для QAM-4, например, процесс формирования модуляционного символа это просто мэппинг группы битов в точку сигнального созвездия. Но это все равно принято называть модуляцией, даже несмотря на то, что переноса на несущую частоту еще не произошло, так как мы работаем только в цифровой части. С OFDM схема чуть сложнее, но смысл тот же - из входного потока битов формируются OFDM-символы.
Тогда не очень понятно. Например в LTE расстояние между поднесущими 15кГц. Имеется в виду, что эти 15 кГц - это защитный интервал?
15 кГц это расстояние между поднесущими, что дает нам длительность одного OFDM символа в 1/T = 1/(15 кГц) = 66 мкс или один сабфрейм длительностью в 1 мс, образованный 14-ю OFDM символами. Это никак не связано с защитным интервалом. Защитный интервал в OFDM - это циклический префикс.
Расстояние между поднесущими это интервал в частотной области, который определяет такую длительность OFDM символа, что поднесущие оказываются ортогональны (при любом порядке модуляции на каждой из поднесущих, между прочим, но это так, заметка на полях). Можно определить длительность OFDM символа, которая, в свою очередь, будет определять расстояние между поднесущими, необходимое для их ортогональности. Проще говоря, условие ортогональности поднесущих:
А вот циклический префикс помогает справиться с межсимвольной (в смысле между OFDM символами) интерференцией во временной области.
Таким образом, расстояние между поднесущими и защитный интервал, это два разных параметра, не имеющих никакой особой связи между собой.
Отличная идея для серии статей, буду следить за вами)
По теме SEFDM. Идея прикольная, но приемник уж больно сложный получается. Впрочем, это верно для многих альтернативных методов мультиплексирования, такой простоты как в OFDM нет нигде. Еще ложку дегтя добавляет пик-фактор SEFDM сигналов, по-моему, он выше, чем у OFDM, что тоже будет критически важно для усилитилей передатчиков в ТГц диапазоне. Так что передатчик тоже получится сложным из-за сложного DPD.
Там вроде как красной нитью (особенно у google) проходит мысль о том, что HW разработка должна стать очень похожей на SW. Реалистично ли ожидать на горизонте 10 лет создания открытого тулчейна и новых инструментов для облегчения входа SW инженеров в HW?
Под словом "блок" я разумеется имею в виду не Verilog module / VHDL entity, а подсистему в которой может быть 200 modules
И все это хозяйство должен поддерживать один разработчик? Ужас.
Там ничего сложного нет на самом деле - нужно складывать латентности конвейера и длины промежуточных FIFO, следя за размерами кусков данных. Если этого навыка нет, то человек такой блок или не дизайнил, или делал вспомогательную работу.
Ну вот смотрите, я такие блоки не дизайнил. Но вы весь "навык" сформулировали в одном предложении, теперь он у меня тоже есть. На каком основании вы тогда делаете выводы о качестве разработчика? На основании обладания знанием, которое передается за 30 секунд? Какие-то странные критерии.
Прекрасно, вот вам дженкинс дал отчет, что вот в таком подблоке у вас высокое энергопотребление. Что вы с этим делаете?
Напишу в чатик коллегам "ребят, кто сталкивался, подкиньте идейку". Мне напишут, что "можно двигать не данные, а пойнтеры на данные". Я такой "окей, понял, сейчас будет". Т.е. опять же это не какой-то супер навык отличающий хорошего разраба от плохого.
Для этих целей в компаниях есть своя библиотека модулей и генераторов, но проще писать свои макросы. Насчет опенсорсного - а вы можете дать ссылку?
Ну если есть, так зачем из этого делать критерий отбора на собесе? Вы же уже написали это, зачем вам человек, который будет знать и мочь написать то, что уже написано? Мб про что-нибудь другое лучше поспрашивать? Опенсорсного мало и оно плохое, если честно. В любом случае здесь просто нужно написать генератор (200-300 строк на питоне). А еще лучше выложить его в опенсорс потом и больше не мучать людей вопросами "как написать уже написанное".
Ну если человек будет с нуля тренироваться на новой работе как писать конечные автоматы, то он будет отбирать время у своих старших коллег.
Knowledge sharing и менторство наше все вообще-то, как иначе передавать знания? С такой логикой это очередной замкнутый круг по типу "на стартовую вакансию нужны люди с опытом". Ну и что вы заладили с этими автоматами. Там опять же шаблон меньше, чем на страницу. Любой человек с техническим образованием идею за 5 минут ухватит. И время отбирать у коллег не надо, когда у вас есть внятные гайдлайны, проблема в том, что часто их нет, потому что HW разрабы очень кичатся своими "знаниями" и упорно не шерят их, а все "знания" состоят из двух половиной концепций, схватывающихся на лету.
А тут нет простой шпаргалки, тут чтобы выучиться, нужно решать задачи и сидеть с коллегами их разбирать. Такое можно делать, если человек интерн. Но если он написал в резюме "5 лет опыта", то "назвался груздем - полезай в кузов".
Здесь согласен. Действительно, лучший способ научиться что-то делать, просто пытаться делать это.
По искусству верификации хардвер сильно впереди софтвера. Verification plan, formal proof, functional coverage, constrained-random, temporal logic expressions и прочая кухня - это тема отдельного поста.
Да, с концептуальной точки зрения это так. Но инструменты очень плохие в HW и UVM очень вычурная и усложненная (больше, чем обычно нужно) методология. Хотелось бы упрощения и улучшения инструментов.
Вам сейчас станет страшно, но это не шутка. Во многих электронных компаниях до сих пор shell по умолчанию - это csh. Да, С-shell, и на нем есть скрипты для конфигурации.
Сам в такой работаю, знаю)
Ворд и перфорс, иногда git, да (ворд меня тоже бесит, я предпочитаю писать тексты в HTML).
Ну вот об этом и речь, когда я говорю про отсталость и слабую осведомленность HW о том, что происходит вокруг. Вордовские файлы в гите никто не хранит, их невозможно мерджить и сравнить версии. Вообще никто доки в ворде не пишет. Про "писать тексты в HTML" тоже не понял. Вы на HTML доку пишете? Обычно дока пишется в markdown (или что-то похожее) и хранится в одном репозитории с кодом. Дальше есть генераторы и паблишеры, которые вам хоть HTML, хоть PDF отрендерят или на корпоративном конфлюенсе запостят, если надо.
Даже на позиции в команде писания компиляторов, где сплошные преобразования деревьев?
Вы намеренно утрируете сказанное. Мы же с вами прекрасно понимаем, что 99% SW это не написание компиляторов. То же самое с HW. Есть множество проектов, компаний, устройств, где нет тех или иных проблем, связанных с дизайном. Я все-таки настаиваю на том, что важнее как человек мыслит, может ли понятно изложить свои идеи, думает ли о том, как в будущем будет "жить" его код, кто с ним будет работать, тяжело или легко это поддерживать, масштабировать. Это сейчас важнее, потому что это пока что сложно формализовать и передать в виде знания. А особенности предметной области, будь это оптимизация по мощности или алгоритмические "фишки" передаются в виде пары слайдов и гайдов.
Может он и олдовый и скучный, но это текущий процесс на RTL (Register Transfer Level) и DV (Design Verification) позиции в крупных электронных компаниях в Калифорнии - Apple, NVidia, Intel, AMD, Juniper, Samsung, Xilinx итд.
Крупные не значит хорошие. Как раз таки крупные и страдают больше всего от плохих и отсталых процессов. Если что-то используется крупной компанией, это не означает автоматически, что это какая-то хорошая практика. Вполне вероятно, что это просто тяжелое наследие, продолжающее существовать из-за ригидности больших компаний.
Вы возможно невнимательно прочитали мой текст. Я нигде не предлагал давать задачки прямо из учебника. Наоборот, я написал "Столкнувшись с задачей чуть дальше учебника".
Из учебника или нет, на валидность моего тезиса и дальнейшее рассуждение это никак не влияет.
Если человек не может написать простой конечный автомат на языке описания аппаратуры Verilog, то как он сможет работать с блоком на 200 тысяч строк?
Серьезно? Блок на 200 тысяч строк? Какой же ужас творится в "крупных электронных компаниях в Калифорнии".
В реальном времени можно посмотреть как человек думает, что он делает на автомате (например определение глубины очереди FIFO для достаточной пропускной способности блока - необходимый навык отделяющий опытных инженеров от неопытных).
Каким образом определение глубины очереди FIFO "на автомате", а не за полчаса, например, отделяет опытного разработчика от неопытного? Это очень смахивает на какое-то когнитивное искажение. Если я очень часто или в данный момент времени часто сталкиваюсь с какой-то задачкой, то мне тоже начинает казаться, что остальные должны это понимать и делать "на автомате", но это неправда.
Вы о каких типах дизайна говорите? И в моем блоке чипа для GPU телефона энергопотребление важно (иначе у телефона сядет батарейка), и в предыдущем проекте чипа для магистрального роутера (иначе там нужер вводить более суровую систему охлаждения), поэтому каждый разработчик однозначно должен владеть clock-gating-ом и на микроуровне (с enable), и на уровне подблоков как минимум в теории (пользованию конкретными тулами типа Atrenta SpyGlass Power или Mentor Power Artist или Synopsys PTPX или Cadence Joules - компании учат на внутренних трейнингах).
Частенько бывает так, что в самом начале новенькое ядро не вызывает проблем с мощностью, да и даже с таймингами на чипе. И только потом, когда появляются новые фичи, ядро растет, такие проблемы могут себя проявить. Да, мощность это важно, но можно и не столкнуться с такой проблемой, если ты просто дизайнер. Clock gating это базовая техника, о ней все должны знать и применять автоматически. Все остальное, ну такое. Да, есть специальные тулы, каждый ли дизайнер должен ими владеть? Нет, не каждый. Достаточно просто написать нормальный дженкинсовский пайплайн, который сам все сделает и вернет отчет дизайнеру. Это больше что-то на уровне архитекторов, которые должны решить, какие техники мы применяем и раздать гайдлайны дизайнерам. А лучше опять же построить нормальный CI пайплайн.
Если человек не может закодировать простой valid/ready интерфейс, то у него вообще нет опыта и он за чтение базовых учебников никогда не вылезал. А старшие инженеры как правило понимают credit based flow control, так как во всех конторах от Apple до Juniper его используют для внутренних интерфейсов между подблоками, и если он его не знает, встает вопрос что он там делал.
Вот это очень интересный момент. Да, с одной стороны это правда, что если не может закодировать простой valid/ready интерфейс, претендуя на реальный опыт, это странно. Но с другой стороны, а нужно ли кодировать valid/ready интерфейс? Я понимаю, что в HW зоопарк технологий и подходов. Но вроде бы обычно используется axi/apb, для этого доступны генераторы кода. Т.е. как бы нет никакой нужды писать это руками. Даже если у вас свой кастомный интерфейс между блоками, так напишите для него генератор один раз и используйте, зачем каждый раз писать один и тот же credit based flow control? Старшие инженеры понимают его как раз потому, что пишут его каждый раз руками, вместо того, чтобы написать (или лучше взять опенсорсный) питоновский генератор, что отнюдь не добавляет им плюсов как хорошим разработчикам. Господи, даже если я не знаю, как писать этот ваш credit based flow control. Покажите мне один раз реализацию, и я пойму, как это написано, очень быстро. Т.е. это не какой-то супер важный скилл, по которому можно отсекать людей на собесах.
Я про арифметику не писал. Задачка про остаток от деления на 3 - это на самом деле не задачка на арифметику, а завуалированная задачка на конструирование простого (из трех состояний) конечного автомата.
Да какая разница, какая задачка? Опять же, это не какие-то супер знания, на освоение которых уходят годы. Вы просто нормальные гайдлайны на проекте напишите, где будет сказано, как вы работаете с автоматами или с арифметикой, какие техники для оптимизации по мощности применяете, и все. Линтер натяните, чтобы эти правила соблюдались. Это не надо запоминать, все, о чем вы говорите, легко решается процессами и разумной автоматизацией (jenkins пайплайны, код чекинг и т.д.).
Многие электронные компании еще лет 20 назад подсели на Perforce и используют Git поверх перфорса. Ничего принципиального в этом скилле нет - дать человеку шпаргалку на страницу, чтобы он умел использовать perforce или git в данной организации - это просто. А вот научить его микроархитектуре, как строить конвейер, разделять память и скрывать латентность - это гораздо более сложный скилл.
Так вы дайте ему шпаргалку по микроархитектуре на страницу, чтобы он строил конвейер, как вы договорились, разделял память и скрывал латентность. Об этом и речь, что большинство вопросов покрывается нормальными процессами и гайдлайнами. Сложности разработки возникают совершенно в других местах.
Насчет CI/CD - многие электронные компании сейчас используют Jenkins, в этом тоже ничего особого нет, трейнинг за полчаса.
Многие используют, многие нет. Речь о том, что проникновение хороших практик из SW в HW довольно слабое. Опять же, кто и как пишет вам пайплайны, автотесты? Вот очень интересно, как решается эта проблема в HW компаниях Калирофнии. Это входит в набор скиллов верификатора? Разработчик должен предоставить автотест (хотя бы sanity) для своего блока?
типа программиста, который умеет писать только if и вызовы функций, но не умеет писать циклы.
Здесь я пошучу, но можно вообще не писать циклы, если это функциональщина :)
Я не знаю, о каких компаниях вы говорите, в компаниях в которых я был, имеется процесс - сначала архитект чипа пищет архитектурную спецификацию на блок, потом микроархитект блока пишет микроархитектурную спецификацию с деталями конвейера и очередей, и только потом пишется RTL код.
Ну, процесс-то имеется, вопрос в том, работает ли? То же SW уже прошло этот этап и признало такой подход медленным и просто неадекватным реальности. Очень часто приходится видеть на практике, как вносится множество правок в такого рода документы уже после реализации. Ну не работает то, что вы здесь описываете. Опять же это очень архаично, когда-то, может быть, работало для простых систем, но для чего-то +/- сложного не работает это. Да и вы здесь умолчали о том, в каком формате пишутся файлы и как хранятся. Признайтесь, это ворд и шейрпоинт, да?)
Это не то, что я вижу. В компаниях имеется смесь из Tcl, Perl, Python, Ruby, Bash, Make и проприетарных языков типа SystemRDL, и сдвиг в сторону питона уже лет 10 минимум.
Надо просто сжечь скрипты на tcl (ну если это не фронтенд проприетарных тулов) и perl. Да и с bash и make уже надо завязывать. Ну не поддерживаемо все это. Сдвигаются лет 10 все никак сдвинуться не могут, потому что практики, что в разработке, что в менеджменте отсталые и неэффективные, что особенно поражает, когда рядом есть SW, из которого просто можно воровать все хорошее и получать лайки. Не уверен насчет проприетарности SystemRDL (точнее, это как посмотреть), вроде стандарт открытый и есть открытый же компилятор. Ну и вы представьте, какую-нибудь SW компанию, которая говорит, что у них есть какие-то скрипты на perl, который до сих пор используются для автоматизации рутинных задач. Смешно же, ну. А вот HW этим гордится. Хотя гордится нечем.
А вы точно читали мою заметку - или только комментарии к ней? Я наоборот, пишу, что популярный вопрос про остаток от деления на 3 стоит на всех интервьюшных сайтах уже 100 лет (точнее 20 лет точно) и поэтому в чистом виде неактуален. И он вообще не про деление.
Да какая разница какая задача опять же. Я вот вас спрошу на собесе про что-то, что вам не встречалось, а потом скажу, что мол вы нам не подходите, потому что за оптимальную реализацию CIC фильтра сходу не пояснили. А то, что вы отличный разработчик и, если надо, в этом за пару дней разберетесь, ничего не значит. Нет, значит нет.
Реальность такова: все крупные компании попробовали HLS в каких-то нишевых задачах, и плюнули на это дело. Потому что надежнее написать конвейер в явной форме, а не массажировать Си код прагмами.
10 лет или не 10, не знаю. Но все рано или поздно придет к этому. Ну никому не нравится писать на HDL, давайте будем честны. Те, кто говорят, что им нравится, страдают от стокгольмского синдрома. Мне кажется, что было много разработчиков (да и сейчас встречаются), которые утверждали, что ассемблер надежнее и они всегда напишут лучше, чем копилятор. Увы, компиляторы победили. Это вопрос времени.
Задачки у меня самые обычные, я как-раз остаток от деления на 3 не даю, а даю например написать gearbox, которые в реальных дизайнах встречаются часто.
Так если часто, вы вынесите в либу и не паритесь, зачем людей мучать?)
кому нужет аккуратный человек, дизайн которого вставляет пустые такты в потом обработки данных, отчего производительность блока падает вдвое.
Есть такая практика, как код ревью. Вы один раз человеку покажите, что он делает не так и как надо, и вопрос решен.
Мое личное мнение. Вы супер опытный и крутой человек из HW и без сомнения с крутыми скиллами, сделавший очень многое для популяризации этой области среди российских студентов и школьников. Здесь вам можно только поаплодировать стоя. Но у HW разработки есть очевидная проблема. Это ее отсталость. SW гораздо более конкурентная и многочисленная область, поэтому прогресс там произошел значительно быстрее. Многие вещи, которые вы считаете важными, в SW уже давно отмели, как незначительные. Этот путь, который только предстоит пройти HW уже пройден в SW. Не надо наступать на те же грабли. Большинству компаний в SW, на подавляющее большинство позицией в SW не нужно жесткое алгоритмическое интервью, не нужно уметь на доске в режиме реального времени писать рабочий код для переворачивания бинарных деревьев. Важны, по-настоящему важны, совершенно другие вещи. HW еще видимо не совсем освоилось с идеей открытых доступных либ, версирования и прочего, иначе как объяснить эту странную страсть к подсчетам остатков от деления числа, приходящего бит за битом? Зачем это знать всем, если Панчул может написать оптимальную реализацю, которую мы все можем просто использовать в своих проектах? Это же трата времени и денег, разве не так?
Довольно олдовый и скучный подход к собесам. В резюме достаточно просто напихать buzzwords (за которые надо бы уметь пояснить), чтобы триггернуть hr-а. Лучший собес для обеих сторон это беседа про то, какие задачи удалось решить, какие не удалось, какими способами. Фрешградам можно дать порешать какие-то задачки, потому что опыта у них еще нет. Требование выдать околорабочий код за 5-10 минут на собесе для решения задачки из учебника (которая в реальной разработке никогда и не встретится) довольно бесполезное требование. Такого формата собеседования ничего по сути и не проверяют. Только вгоняют в стресс соискателя, да и самому интервьюеру надо тратить время и готовиться к таким собесам. Очень неэффективный формат. Почему?
Да потому что можно уметь решать такие задачки за время собеса и быть очень хорошим разработчик, а можно и не уметь, и тоже быть очень хорошим разработчиком. Т.е. такой формат хороших разработчиков не отбирает, а отбирает людей, умеющих решать "необычные" задачки в реальном времени. После такого процесса найма часто оказывается, что все в команде умеют очень эффективно "обрабатывать треугольники", но никто не умеет писать понятный поддерживаемый код, вести внятную документацию и работать именно с процессом разработки.
Вообще в HW (да и в embedded) есть определенный пул вопросов, который надо знать на разных уровнях профессионализма. Вот их и можно обсуждать, да и то +/- в общем виде. Специфика работа такова, что можно за 20 лет опыта ни разу не столкнуться с реализацией и внедрением методик оптимизации по мощности, например. Или с интерфейсами, или с арифметикой. Да, надо знать все эти вопросы в общем виде, но вот набить руку на практике может и не получится. А если методика найма подразумевает, что все эти вопросы опыт соискателя должен покрывать, причем с примерами из практики, то воронка найма очень сильно сужается.
Ни одного вопроса про разработку и процессы в статье не заметил. А в HW с этим все очень и очень плохо. В больших компаниях не все до сих пор перешли на git, не говоря уже о CI/CD и прочих полезных практиках. И ведь ничего этому не мешает, кроме отсталости и ретроградства самих разработчиков. Документация пишется кое-как после проекта, причем часто в вордовских файлах, распространяющихся через шейрпоинт какой-нибудь. Хороший тулинг тоже отсутсвует, чаще всего это кривые скрипты на каком-нибудь tcl (благо, ситуация вроде меняется и молодые разработчики хотя бы интересуются тем же питоном). Зато все умеют делить в RTL на 3. Почему-то считается, что надо обладать каким-то особым экспертным знанием, "ноу-хау". Но дело в том, что как только это ноу-хау попало в хорошо управляемую и версированную кодовую базу, то это больше не ноу-хау. Гораздо важнее умение выстроить процесс разработки. Увы, но лет через 10 HLS вытеснит RTL и HW разработка (для большинства задач) станет очень и очень похожа на разработку софта. Поэтому не стоит уже сейчас цепляться за решение "необычных" задачек, а стоит все больше обращать внимание на то, насколько способны люди поддерживать общий большой проект без превращения его в дремучее легаси. Как-то так.
Статья неплохая, но слишком все пропитано шведской традицией сглаживать или не замечать острые углы и проблемы. У меня есть личный опыт с такими компаниями как Klarna, Ericsson, ABB, Tieto. Это условный Big Tech. Со стартапами сталкиваться пока что не приходилось, поэтому про них ничего не могу сказать. Забавно, что та же Klarna до сих пор считает себя стартапом, но это ладно, так многие делают. Про Klarna верно отмечено, что там есть хоть какая-то культура работы, поощеряющая эффективность. Остальные же компании максимально неэффективны в плане труда. Очень часто за плоской структурой скрывается импотенция менеджмента и отсутствие даже намека на какие-то процессы внутри компании.
Что плохо:
Система FILO. Тебя не могут сократить, если после тебя еще кого-то наняли. Впервую очередь должны уволить тех, кого наняли позже. Если работаешь в компании много лет, то тебя практически невозможно уволить сколь бы неэффективным и бесполезным ты ни был. Все это приводит к засилью "специалистов" 50+. Среди них есть отличные спецы, но большинство вяло занимается "кодированием", а не разработкой, всеми силами препятствуя всему новому. Мотивации развиваться у возрастных специалистов нет, потому что все равно не уволят, а зп можно только повышать, понижать нельзя. Такую ригидность и стагнацию стимулируют шведские профсоюзы, из-за которых становится крайне сложно уволить объективно бездарного и ленивого сотрудника.
Как это ни странно профсоюзы это плохо. По крайней мере в шведском их варианте. Единственный бонус, который они могут дать, это страхование дохода на случай увольнения. Несложное сравнение ежемесячных взносов и обещаемой страховки показывает, что в профсоюзах нет никакого смысла, если работник проработал хотя бы 10 лет в шведской системе. К тому же обещаемые профсоюзом дополнительные выплаты при безработице на практике получить очень сложно, так как профсоюз оставляет за собой право отказать в выплате, если профсоюз усмотрел, что ситуация не такая однозначная, как кажется уволенному сотруднику.
А вот вреда от них много. Профсоюз продвигает уравниловку в самом плохом ее варианте. Например, выравнивание зарплат. Если Паша и Света закончили университет 3 года назад, но Паша эффективно работает, тратит личное время на обучение, решает сложные рабочие задачи, берет на себя ответственность и лидерскую роль в некоторых проектах, а Света просто ходит на работу что-нибудь поделать, то зарплата у Паши и Светы все равно будет примерно одинаковая. Пашу нельзя поощерить зарплатой, потому что против этого восстанет профсоюз. С точки зрения профсоюза Паша и Света работают одинаково, потому что у обоих одинаковое образование и опыт работы, а значит и зарплата не может быть разной. Поэтому зарплата Паши, должна быть как у Светы. А еще Света девочка. К тому же, вы что, гендерное неравенство тут продвигаете? Нехорошо-с.
Вот вам недавний пример из жизни, насколько профсоюзы на все влияют. Из-за профсоюзов шведы много лет сидели без складов Amazon на своей территории, который очень хотел открыться в Швеции. Камнем преткновения был тот факт, что надо обязательно договриться с профсоюзом по поводу минимальной зарплаты. У Amazon и шведских профсоюзов были очень разные оценки минимальной оплаты труда работников складов, поэтому много лет шведы сидели без быстрой доставки и кучи рабочих мест.
Маятник гендерного неравенство улетел в другую сторону. В Klarna за референс девушки дают в 2 раза большее вознаграждение, чем за референс мужчины. При найме предпочтение отдается женщинам, если соотношение мужчин и женщин в вашей компании страдает, даже если ваша компания работает в отрасли, где в высшем образовании тот же перекос в сторону студентов мужского пола.
Отсутствует рынок жилья, назревает ипотечный пузырь, снижаются инвестиции в инфраструктуру, разваленное школьное и высшее образование до такой степени, что выпускник местной образовательной системы на шведском же рынке труда не может конкурировать с выходцами из Китая, восточной Европы, Индии, Пакистана, Бангладеша и т.д. Все это итог 50-летнего засилья шведских социалистов у власти.
Корень всех этих бед один - шведское понимание равенства, где под равенством понимается не равенство возможностей, а равенство результата. Звучит абсурдно, но для шведов это абсолютная истина, постулат, внушенный социалистами у власти, который даже нет смысла обсуждать, а уж тем более крамольно выражать сомнение в верности этого утверждения.
Что хорошо:
На работе можно придумывать свои проекты и работать над ними. По большей части это из-за бездарного, слабого, а зачастую еще и старого и немощного менеджмента, но для активного автономного разработчика это можно обернуть в плюс.
В целом жизнь в Швеции довольно спокойная. Есть, конечно, много "приколов", которые людям из СНГ понять сложно, как например магазины, закрывающиеся в 8 вечера и аптеки, которые не работают по воскресеньям. Но это ничего. Зато есть хорошая транспортная доступность, чистые улицы и т.д.
Я пробежал глазами и ссылку на самую главную статью так и не увидел, о чем и написал и попросил поправить меня, если это не так. Статья, действительно, очень важная, а самое главное, что находится в открытом доступе, в отличие от платного американского семинара. Про российский семинар просто еще раз отмечу, что странно построить практически весь семинар на чужой статье, выдрав даже картинки, не упоминая ту самую статью в открытом доступе. Надеюсь, что Александр Силантьев ссылку добавит.
Вообще поразительно просто. Что в этой статье у Панчула нет ссылки на первоисточник, что в видео, думаю, ни одной ссылки тоже нет (поправьте меня, если это не так). Хотя нагло украдено все, даже картинки свои поленились нарисовать, а просто выдрали из статьи. Пиарить свои семинары, используя чужой материал, причем из 2008 года, без упоминания авторства, ну-ну, хороший подход.
И всерьез обсуждают, что надо там оставить Паскаль как язык программирования.
Здесь я несогласен. Аргумент, что учителя знают Паскаль, в принципе, нормальный. Цель информатики в школе это познакомить детей с информатикой как с областью знания вообще. В паскале есть все необходимые концепции (явные указатели, ООП и т.д.), с которыми надо познакомиться на базовом уровне. Язык сам по себе простой и понятный, что очень хорошо для обучения. Алгоритмы и структуры данных довольно наглядно реализуются на паскале. Единственный минус это невостребованность языка бизнесами. Но школа и академия это не прислужка бизнеса, как бы бизнесу этого не хотелось, и не обязана штамповать готовых python/java/c++ интернов для очередного владельца очередного мобильного приложения. Простота и наглядность основные принципы, наверное, для обучения программированию, особенно школьников, и паскаль полностью удовлетворяет этим требованиям.
Да блин, потому что в тебя еще вкачивать и вкачивать знания. Ты не специалист. Ты заготовка специалиста. Если повезет.
Меньшего от корпоративного блога и не ожидал. Действительно, это же не человек, не инженер, а заготовка, просто единица ресурса для бизнеса. Ведь все вокруг просто обязаны со школьной скамьи знать стек вашей компании, ведь это очень удобно и экономно. Давайте в школе на информатике изучать сразу PHP, Angular, Android и iOS, ведь скайенгу так нужна армия рабов, да и потом всегда можно сказать «Вот ты пару лет поработай, ума наберись, заготовка ты эдакая, а потом и до джуна может быть дорастешь».
Зачем изучать информатику как область знания? Надо сразу с python начинать, потому что всем нужен
Бизнес-результат. Всем нужен результат.
Больше всего он нужен Александру Ларьяновскому, ведь это прямо конвертируется в его личный карман. Да, в РАО сидят одни идиоты, а идиоты они потому, что хотят учить детей программированию на простом и понятном паскале, а бедный Александр от этого очень страдает, ибо не хочет вкладываться в обучение и развитие своих же молодых специалистов, поэтому РАН и РАО такие идиоты, не хотят обслуживать бизнес-интересы скайенга. В академии вообще одни некомпетентные люди сидят, как вы сказали. Хотят там информатику изучать, дискретную математику, алгебру там, а БИЗНЕС-РЕЗУЛЬТАТ кто показывать будет?
Мда, прошу прощения за столь едкий пост, но эти телеги бизнесов про то, что все вокруг идиоты и государственная система образования должна штамповать для них готовых рабов за бюджетные деньги вместо развития науки (извините, ни мобайл, ни веб-разработка никакого отношения ни к какой науке и развитию не имеют) уже просто задолбали.
Опять не соглашусь с вами. Львиная часть тулчейна уже лет 5 отлично работает на линуксах. Ни в одной большой и серьезной компании ни fpga, ни asic разработка не ведутся под виндой, из того что я видел, это всегда линукс.
наверчивает и усугубляет методы шифрования битстрима и дерет в тридорога за лиценции на свой софт.
Шифрование битстрима это хорошо. Фишка fpga в том, что это reprogrammable устройство. Поэтому многие используют fpga в конечном продукте, чтобы если что, можно было выкатить «патч». Дешевле и эффективнее, чем отзывать продукцию и делать респин, если у вас asic. Но в этом случае вашим продуктом становится сам дизайн. Дело в том, что по битстриму вполне себе без проблем реверсится netlist, ну и в итоге, сам дизайн. Поэтому шифрование битстрима это нормально и хорошо.
Про «дерет в тридорога за лицензии на свой софт». Xilinx коммерческая компания (стоявшая у истоков fpga, между прочим). Она заинтересована в извлечении прибыли, извините, коммунизм еще не настал. Зарабатывать с продажи fpga нереально, на чем же тогда зарабатывать? На лицензиях к своему тулчейну. Это же довольно сложный софт, специфический. Там свои специфические алгоритмы. Это результат 40-летнего труда многих хороших инженеров и разработчиков. С чего бы им отказываться от извлечения прибыли и конкурентного преимущества?
Сделать из hw open-source странная идея. Не то чтобы это плохо, мне, как инженеру и пользователю, это скорее выгодно. Просто непонятно как это должно происходить и кто будет этим заниматься. В sw open-source возможен отчасти потому, что разработчиков, способных его развивать и поддерживать условно много. В части fpga, найдется довольно мало инженеров, способных и готовых пилить открытые тулчейны. Там очень специфические алгоритмы. В целом разработчиков, специализирующихся на этом довольно мало. Не понимаю, как это должно происходить и развиваться, если честно.
Очень странный рассказ. Сам несколько лет живу и работаю в Швеции. Страну можно за многое покритиковать, но никак не за то, что расписывает здесь автор. При чтении возникло чувство, что автор совсем не разобрался в стране, в их системе, жилищном вопросе и в том, что такое социальная страна.
Первым квестом было получение местного налогового номера, без которого невозможно открыть банковский счет. И здесь шведская бюрократия показала себя в полной мере.
Если у вас было легальное разрешение на работу, то вы должны были получить personnummer, а не налоговый номер, это во-первых. Наверное вы про personnummer и говорите. Обычно получить personnummer и открыть банковский счет занимает около месяца, но, может, в Стокгольме очереди какие-то большие?
Не очень понятны перипетии с жильем. Вы тратили 20000 крон. В Стокгольме, самом дорогом городе Швеции, очень хорошая двушка стоит 15000 крон, а просто хорошая от 11000 крон. Хорошая трешка стоит 15-18 тысяч, да, но обычно в таких домах, с такими ценами, галдящие арабы не живут. Да и квартиры в том панельном гетто, в которым вы жили, стоят намного дешевле и за те же деньги можно найти жилье намного лучше. Не совсем понял ваши претензии к арендодателям. В Швеции права квартиросъемщика защищены лучше, чем права арендодателя, и все всегда происходит по контракту. В стандартном контракте 2-3 месяца notification period — т.е. вы должно предупредить о своем желании съехать за 2-3 месяца, точно так же арендодатель должен за 2-3 предупредить о своем намерении вас выселить. Мне кажется, вас очень сильно обманывали с жильем.
Жилищный фонд лучше, чем в СНГ. Даже в старых домах хорошая инфраструктура, нет каких-то во все стороны торчащих сантехнических труб, нет кривых стыков плит. Новые дома строятся по заветам современных урбанистов — малоэтажное жилье с хорошим благоустройством. Отличные планировки в квартирах и площади. Может на Украине жилищный фонд гораздо лучше, чем в Швеции, и уж тем более лучше, чем в России, это объяснило бы ваш наброс на жилье.
Почему так сложно и дорого снять жилье? Ну, читайте про first-hand, second-hand contract в Швеции. Если вкратце, то государство выдает гражданам жилье в дешевую аренду, а большинство жилья на рынка это субаренда жилья, выданного государством. Построить новое жилье сложно и дорого, слишком большая зарегулированность строительства. Хорошая ли это система? Для кого как, лично меня она сильно пугает и сильно мне не нравится.
Вторая, и, наверное главная, причина — материальная. Что бы ни говорили про социальность страны, но в результате доходы шведских айтишников небольшие.
Из социальности страны как раз-таки следует то, что это flat country, и доходы выравниваются. Да, по всем специальностям зарплатная вилка довольно узкая, это 18000 — 40000 крон после налогов. Да, айтишник в Европе это не барин, как вы привыкли в СНГ, а обычный представитель среднего класса. Как вы думаете, если каждая маникюрщица и парикмахерша получает около 2000 евро после налогов, то может ли стрижка стоить столько же, сколько на Украине? Если вас это не устраивает, то так и заявите, что вам нравится в СНГ, когда соотечественники, чей труд не продашь заграницу, зарабатывают намного меньше вас, и у вас появляется возможность потреблять кучу дешевых услуг. Увы, в стране, где у каждого есть право на достойную жизнь, айтишник не будет барином, а будет обычным средним классом, как и должно быть.
Но даже здесь не все так просто. После 7-10 лет хорошего опыта многие начинают работать subcontractor, т.е. становятся ИП, предоставляющим услуги какой-то большой компании. Там уже меньше налогов, гораздо выше зарплата, сложнее проекты, но в то же время меньше безопасности, больше рисков. Spotify таким по 70-90 тысяч крон платит, но не всем такой путь подойдет, да это и не надо.
Про природу тоже странно. Страна довольно небольшая и вытянутая, какое природное разнообразие вы ожидаете увидеть? Про одинаковые кафе и магазины в городах тоже не понял. В Швеции фишка в том, что в любом маленьком городе, будет набор современных кафешек и магазинов, в этом смысле жизнь в Стокгольме мало отличается от жизни в какой-нибудь Эскилстуне. Как по мне это наоборот плюс, а не минус. Децентрализация, развитие регионов и все такое.
Про медленные поезда вранье. Да, настоящих скоростных поездов со скоростями 300км/ч нет, но все остальные ездят со скоростью 100 км/ч. Вся страна на поезде пересекается за 4-5 часов. Также они довольно удобные внутри. Дорогие ли они? Да, дороговато, но это от времени зависит.
Каждое предложение это неточность, вранье или глупость. Понимаю, скорее всего непреднамеренная, но тем не менее. Вам не понравилось, что переехав, вы перестали быть барином среди нищих холопов, а оказались обычным гастарбайтером. Да, вам надо зарабатывать на дорогое жилье. Местному шведу хорошую квартиру купят родители, у которых тоже свой дом в предместье Стокгольма, доставшейся по наследству. Жизнь местных шведов намного проще вашей, но это цена, штраф, за переезд в чужую страну.
Очень глупо бежать в Европу за деньгами и роскошной жизнью. Люди переезжают в поисках стабильности и уверенности в завтрашнем дне. В Швеции у меня гораздо больше шансов сохранить сбережения, накопить капитал, нежели в России, где раз в 20 лет случается полный ребут всего. И как это ни странно, на покупку своего жилья в Швеции уйдет примерно столько же времени, сколько на покупку своего жилье в том же Питере. Вот только качество шведского жилье будет намного выше.
И да, в скандинавских странах принято, что работают все, а не так, что работает один, а тратят двое. Может тогда что-нибудь даже и накопили.
SDR пророчат большое будущее и основным достоинством считается снятие ограничений в реализации радиопротоколов. Примером является метод модуляции OFDM (Orthogonal frequency-division multiplexing), которая стала возможна только методом SDR.
Все-таки, обычно, OFDM считают одной из схем модуляции, только это MCM - multicarrier modulation. Как правило, в цифровой части, модуляцией часто называют процесс формирования модуляционного символа из входного потока битов. Т.е. для QAM-4, например, процесс формирования модуляционного символа это просто мэппинг группы битов в точку сигнального созвездия. Но это все равно принято называть модуляцией, даже несмотря на то, что переноса на несущую частоту еще не произошло, так как мы работаем только в цифровой части. С OFDM схема чуть сложнее, но смысл тот же - из входного потока битов формируются OFDM-символы.
15 кГц это расстояние между поднесущими, что дает нам длительность одного OFDM символа в 1/T = 1/(15 кГц) = 66 мкс или один сабфрейм длительностью в 1 мс, образованный 14-ю OFDM символами. Это никак не связано с защитным интервалом. Защитный интервал в OFDM - это циклический префикс.
Расстояние между поднесущими это интервал в частотной области, который определяет такую длительность OFDM символа, что поднесущие оказываются ортогональны (при любом порядке модуляции на каждой из поднесущих, между прочим, но это так, заметка на полях). Можно определить длительность OFDM символа, которая, в свою очередь, будет определять расстояние между поднесущими, необходимое для их ортогональности. Проще говоря, условие ортогональности поднесущих:
А вот циклический префикс помогает справиться с межсимвольной (в смысле между OFDM символами) интерференцией во временной области.
Таким образом, расстояние между поднесущими и защитный интервал, это два разных параметра, не имеющих никакой особой связи между собой.
Да, вы правы, я даже график здесь приведу из https://ieeexplore.ieee.org/document/5898951. При
SEFDM вырождается в OFDM.
Отличная идея для серии статей, буду следить за вами)
По теме SEFDM. Идея прикольная, но приемник уж больно сложный получается. Впрочем, это верно для многих альтернативных методов мультиплексирования, такой простоты как в OFDM нет нигде. Еще ложку дегтя добавляет пик-фактор SEFDM сигналов, по-моему, он выше, чем у OFDM, что тоже будет критически важно для усилитилей передатчиков в ТГц диапазоне. Так что передатчик тоже получится сложным из-за сложного DPD.
@YuriPanchul, а что вы думаете по поводу вот этих вещей?
https://chipsalliance.org/
https://developers.google.com/silicon
https://f4pga.org/
Там вроде как красной нитью (особенно у google) проходит мысль о том, что HW разработка должна стать очень похожей на SW. Реалистично ли ожидать на горизонте 10 лет создания открытого тулчейна и новых инструментов для облегчения входа SW инженеров в HW?
И все это хозяйство должен поддерживать один разработчик? Ужас.
Ну вот смотрите, я такие блоки не дизайнил. Но вы весь "навык" сформулировали в одном предложении, теперь он у меня тоже есть. На каком основании вы тогда делаете выводы о качестве разработчика? На основании обладания знанием, которое передается за 30 секунд? Какие-то странные критерии.
Напишу в чатик коллегам "ребят, кто сталкивался, подкиньте идейку". Мне напишут, что "можно двигать не данные, а пойнтеры на данные". Я такой "окей, понял, сейчас будет". Т.е. опять же это не какой-то супер навык отличающий хорошего разраба от плохого.
Ну если есть, так зачем из этого делать критерий отбора на собесе? Вы же уже написали это, зачем вам человек, который будет знать и мочь написать то, что уже написано? Мб про что-нибудь другое лучше поспрашивать? Опенсорсного мало и оно плохое, если честно. В любом случае здесь просто нужно написать генератор (200-300 строк на питоне). А еще лучше выложить его в опенсорс потом и больше не мучать людей вопросами "как написать уже написанное".
Knowledge sharing и менторство наше все вообще-то, как иначе передавать знания? С такой логикой это очередной замкнутый круг по типу "на стартовую вакансию нужны люди с опытом". Ну и что вы заладили с этими автоматами. Там опять же шаблон меньше, чем на страницу. Любой человек с техническим образованием идею за 5 минут ухватит. И время отбирать у коллег не надо, когда у вас есть внятные гайдлайны, проблема в том, что часто их нет, потому что HW разрабы очень кичатся своими "знаниями" и упорно не шерят их, а все "знания" состоят из двух половиной концепций, схватывающихся на лету.
Здесь согласен. Действительно, лучший способ научиться что-то делать, просто пытаться делать это.
Да, с концептуальной точки зрения это так. Но инструменты очень плохие в HW и UVM очень вычурная и усложненная (больше, чем обычно нужно) методология. Хотелось бы упрощения и улучшения инструментов.
Сам в такой работаю, знаю)
Ну вот об этом и речь, когда я говорю про отсталость и слабую осведомленность HW о том, что происходит вокруг. Вордовские файлы в гите никто не хранит, их невозможно мерджить и сравнить версии. Вообще никто доки в ворде не пишет. Про "писать тексты в HTML" тоже не понял. Вы на HTML доку пишете?
Обычно дока пишется в markdown (или что-то похожее) и хранится в одном репозитории с кодом. Дальше есть генераторы и паблишеры, которые вам хоть HTML, хоть PDF отрендерят или на корпоративном конфлюенсе запостят, если надо.
Вы намеренно утрируете сказанное. Мы же с вами прекрасно понимаем, что 99% SW это не написание компиляторов. То же самое с HW. Есть множество проектов, компаний, устройств, где нет тех или иных проблем, связанных с дизайном. Я все-таки настаиваю на том, что важнее как человек мыслит, может ли понятно изложить свои идеи, думает ли о том, как в будущем будет "жить" его код, кто с ним будет работать, тяжело или легко это поддерживать, масштабировать. Это сейчас важнее, потому что это пока что сложно формализовать и передать в виде знания. А особенности предметной области, будь это оптимизация по мощности или алгоритмические "фишки" передаются в виде пары слайдов и гайдов.
Крупные не значит хорошие. Как раз таки крупные и страдают больше всего от плохих и отсталых процессов. Если что-то используется крупной компанией, это не означает автоматически, что это какая-то хорошая практика. Вполне вероятно, что это просто тяжелое наследие, продолжающее существовать из-за ригидности больших компаний.
Из учебника или нет, на валидность моего тезиса и дальнейшее рассуждение это никак не влияет.
Серьезно? Блок на 200 тысяч строк? Какой же ужас творится в "крупных электронных компаниях в Калифорнии".
Каким образом определение глубины очереди FIFO "на автомате", а не за полчаса, например, отделяет опытного разработчика от неопытного? Это очень смахивает на какое-то когнитивное искажение. Если я очень часто или в данный момент времени часто сталкиваюсь с какой-то задачкой, то мне тоже начинает казаться, что остальные должны это понимать и делать "на автомате", но это неправда.
Частенько бывает так, что в самом начале новенькое ядро не вызывает проблем с мощностью, да и даже с таймингами на чипе. И только потом, когда появляются новые фичи, ядро растет, такие проблемы могут себя проявить. Да, мощность это важно, но можно и не столкнуться с такой проблемой, если ты просто дизайнер. Clock gating это базовая техника, о ней все должны знать и применять автоматически. Все остальное, ну такое. Да, есть специальные тулы, каждый ли дизайнер должен ими владеть? Нет, не каждый. Достаточно просто написать нормальный дженкинсовский пайплайн, который сам все сделает и вернет отчет дизайнеру. Это больше что-то на уровне архитекторов, которые должны решить, какие техники мы применяем и раздать гайдлайны дизайнерам. А лучше опять же построить нормальный CI пайплайн.
Вот это очень интересный момент. Да, с одной стороны это правда, что если не может закодировать простой valid/ready интерфейс, претендуя на реальный опыт, это странно. Но с другой стороны, а нужно ли кодировать valid/ready интерфейс? Я понимаю, что в HW зоопарк технологий и подходов. Но вроде бы обычно используется axi/apb, для этого доступны генераторы кода. Т.е. как бы нет никакой нужды писать это руками. Даже если у вас свой кастомный интерфейс между блоками, так напишите для него генератор один раз и используйте, зачем каждый раз писать один и тот же credit based flow control? Старшие инженеры понимают его как раз потому, что пишут его каждый раз руками, вместо того, чтобы написать (или лучше взять опенсорсный) питоновский генератор, что отнюдь не добавляет им плюсов как хорошим разработчикам. Господи, даже если я не знаю, как писать этот ваш credit based flow control. Покажите мне один раз реализацию, и я пойму, как это написано, очень быстро. Т.е. это не какой-то супер важный скилл, по которому можно отсекать людей на собесах.
Да какая разница, какая задачка? Опять же, это не какие-то супер знания, на освоение которых уходят годы. Вы просто нормальные гайдлайны на проекте напишите, где будет сказано, как вы работаете с автоматами или с арифметикой, какие техники для оптимизации по мощности применяете, и все. Линтер натяните, чтобы эти правила соблюдались. Это не надо запоминать, все, о чем вы говорите, легко решается процессами и разумной автоматизацией (jenkins пайплайны, код чекинг и т.д.).
Так вы дайте ему шпаргалку по микроархитектуре на страницу, чтобы он строил конвейер, как вы договорились, разделял память и скрывал латентность. Об этом и речь, что большинство вопросов покрывается нормальными процессами и гайдлайнами. Сложности разработки возникают совершенно в других местах.
Многие используют, многие нет. Речь о том, что проникновение хороших практик из SW в HW довольно слабое. Опять же, кто и как пишет вам пайплайны, автотесты? Вот очень интересно, как решается эта проблема в HW компаниях Калирофнии. Это входит в набор скиллов верификатора? Разработчик должен предоставить автотест (хотя бы sanity) для своего блока?
Здесь я пошучу, но можно вообще не писать циклы, если это функциональщина :)
Ну, процесс-то имеется, вопрос в том, работает ли? То же SW уже прошло этот этап и признало такой подход медленным и просто неадекватным реальности. Очень часто приходится видеть на практике, как вносится множество правок в такого рода документы уже после реализации. Ну не работает то, что вы здесь описываете. Опять же это очень архаично, когда-то, может быть, работало для простых систем, но для чего-то +/- сложного не работает это. Да и вы здесь умолчали о том, в каком формате пишутся файлы и как хранятся. Признайтесь, это ворд и шейрпоинт, да?)
Надо просто сжечь скрипты на tcl (ну если это не фронтенд проприетарных тулов) и perl. Да и с bash и make уже надо завязывать. Ну не поддерживаемо все это. Сдвигаются лет 10 все никак сдвинуться не могут, потому что практики, что в разработке, что в менеджменте отсталые и неэффективные, что особенно поражает, когда рядом есть SW, из которого просто можно воровать все хорошее и получать лайки. Не уверен насчет проприетарности SystemRDL (точнее, это как посмотреть), вроде стандарт открытый и есть открытый же компилятор. Ну и вы представьте, какую-нибудь SW компанию, которая говорит, что у них есть какие-то скрипты на perl, который до сих пор используются для автоматизации рутинных задач. Смешно же, ну. А вот HW этим гордится. Хотя гордится нечем.
Да какая разница какая задача опять же. Я вот вас спрошу на собесе про что-то, что вам не встречалось, а потом скажу, что мол вы нам не подходите, потому что за оптимальную реализацию CIC фильтра сходу не пояснили. А то, что вы отличный разработчик и, если надо, в этом за пару дней разберетесь, ничего не значит. Нет, значит нет.
10 лет или не 10, не знаю. Но все рано или поздно придет к этому. Ну никому не нравится писать на HDL, давайте будем честны. Те, кто говорят, что им нравится, страдают от стокгольмского синдрома. Мне кажется, что было много разработчиков (да и сейчас встречаются), которые утверждали, что ассемблер надежнее и они всегда напишут лучше, чем копилятор. Увы, компиляторы победили. Это вопрос времени.
Так если часто, вы вынесите в либу и не паритесь, зачем людей мучать?)
Есть такая практика, как код ревью. Вы один раз человеку покажите, что он делает не так и как надо, и вопрос решен.
Мое личное мнение. Вы супер опытный и крутой человек из HW и без сомнения с крутыми скиллами, сделавший очень многое для популяризации этой области среди российских студентов и школьников. Здесь вам можно только поаплодировать стоя. Но у HW разработки есть очевидная проблема. Это ее отсталость. SW гораздо более конкурентная и многочисленная область, поэтому прогресс там произошел значительно быстрее. Многие вещи, которые вы считаете важными, в SW уже давно отмели, как незначительные. Этот путь, который только предстоит пройти HW уже пройден в SW. Не надо наступать на те же грабли. Большинству компаний в SW, на подавляющее большинство позицией в SW не нужно жесткое алгоритмическое интервью, не нужно уметь на доске в режиме реального времени писать рабочий код для переворачивания бинарных деревьев. Важны, по-настоящему важны, совершенно другие вещи. HW еще видимо не совсем освоилось с идеей открытых доступных либ, версирования и прочего, иначе как объяснить эту странную страсть к подсчетам остатков от деления числа, приходящего бит за битом? Зачем это знать всем, если Панчул может написать оптимальную реализацю, которую мы все можем просто использовать в своих проектах? Это же трата времени и денег, разве не так?
Довольно олдовый и скучный подход к собесам. В резюме достаточно просто напихать buzzwords (за которые надо бы уметь пояснить), чтобы триггернуть hr-а. Лучший собес для обеих сторон это беседа про то, какие задачи удалось решить, какие не удалось, какими способами. Фрешградам можно дать порешать какие-то задачки, потому что опыта у них еще нет. Требование выдать околорабочий код за 5-10 минут на собесе для решения задачки из учебника (которая в реальной разработке никогда и не встретится) довольно бесполезное требование. Такого формата собеседования ничего по сути и не проверяют. Только вгоняют в стресс соискателя, да и самому интервьюеру надо тратить время и готовиться к таким собесам. Очень неэффективный формат. Почему?
Да потому что можно уметь решать такие задачки за время собеса и быть очень хорошим разработчик, а можно и не уметь, и тоже быть очень хорошим разработчиком. Т.е. такой формат хороших разработчиков не отбирает, а отбирает людей, умеющих решать "необычные" задачки в реальном времени. После такого процесса найма часто оказывается, что все в команде умеют очень эффективно "обрабатывать треугольники", но никто не умеет писать понятный поддерживаемый код, вести внятную документацию и работать именно с процессом разработки.
Вообще в HW (да и в embedded) есть определенный пул вопросов, который надо знать на разных уровнях профессионализма. Вот их и можно обсуждать, да и то +/- в общем виде. Специфика работа такова, что можно за 20 лет опыта ни разу не столкнуться с реализацией и внедрением методик оптимизации по мощности, например. Или с интерфейсами, или с арифметикой. Да, надо знать все эти вопросы в общем виде, но вот набить руку на практике может и не получится. А если методика найма подразумевает, что все эти вопросы опыт соискателя должен покрывать, причем с примерами из практики, то воронка найма очень сильно сужается.
Ни одного вопроса про разработку и процессы в статье не заметил. А в HW с этим все очень и очень плохо. В больших компаниях не все до сих пор перешли на git, не говоря уже о CI/CD и прочих полезных практиках. И ведь ничего этому не мешает, кроме отсталости и ретроградства самих разработчиков. Документация пишется кое-как после проекта, причем часто в вордовских файлах, распространяющихся через шейрпоинт какой-нибудь. Хороший тулинг тоже отсутсвует, чаще всего это кривые скрипты на каком-нибудь tcl (благо, ситуация вроде меняется и молодые разработчики хотя бы интересуются тем же питоном). Зато все умеют делить в RTL на 3. Почему-то считается, что надо обладать каким-то особым экспертным знанием, "ноу-хау". Но дело в том, что как только это ноу-хау попало в хорошо управляемую и версированную кодовую базу, то это больше не ноу-хау. Гораздо важнее умение выстроить процесс разработки. Увы, но лет через 10 HLS вытеснит RTL и HW разработка (для большинства задач) станет очень и очень похожа на разработку софта. Поэтому не стоит уже сейчас цепляться за решение "необычных" задачек, а стоит все больше обращать внимание на то, насколько способны люди поддерживать общий большой проект без превращения его в дремучее легаси. Как-то так.
Статья неплохая, но слишком все пропитано шведской традицией сглаживать или не замечать острые углы и проблемы. У меня есть личный опыт с такими компаниями как Klarna, Ericsson, ABB, Tieto. Это условный Big Tech. Со стартапами сталкиваться пока что не приходилось, поэтому про них ничего не могу сказать. Забавно, что та же Klarna до сих пор считает себя стартапом, но это ладно, так многие делают. Про Klarna верно отмечено, что там есть хоть какая-то культура работы, поощеряющая эффективность. Остальные же компании максимально неэффективны в плане труда. Очень часто за плоской структурой скрывается импотенция менеджмента и отсутствие даже намека на какие-то процессы внутри компании.
Что плохо:
Система FILO. Тебя не могут сократить, если после тебя еще кого-то наняли. Впервую очередь должны уволить тех, кого наняли позже. Если работаешь в компании много лет, то тебя практически невозможно уволить сколь бы неэффективным и бесполезным ты ни был. Все это приводит к засилью "специалистов" 50+. Среди них есть отличные спецы, но большинство вяло занимается "кодированием", а не разработкой, всеми силами препятствуя всему новому. Мотивации развиваться у возрастных специалистов нет, потому что все равно не уволят, а зп можно только повышать, понижать нельзя. Такую ригидность и стагнацию стимулируют шведские профсоюзы, из-за которых становится крайне сложно уволить объективно бездарного и ленивого сотрудника.
Как это ни странно профсоюзы это плохо. По крайней мере в шведском их варианте. Единственный бонус, который они могут дать, это страхование дохода на случай увольнения. Несложное сравнение ежемесячных взносов и обещаемой страховки показывает, что в профсоюзах нет никакого смысла, если работник проработал хотя бы 10 лет в шведской системе. К тому же обещаемые профсоюзом дополнительные выплаты при безработице на практике получить очень сложно, так как профсоюз оставляет за собой право отказать в выплате, если профсоюз усмотрел, что ситуация не такая однозначная, как кажется уволенному сотруднику.
А вот вреда от них много. Профсоюз продвигает уравниловку в самом плохом ее варианте. Например, выравнивание зарплат. Если Паша и Света закончили университет 3 года назад, но Паша эффективно работает, тратит личное время на обучение, решает сложные рабочие задачи, берет на себя ответственность и лидерскую роль в некоторых проектах, а Света просто ходит на работу что-нибудь поделать, то зарплата у Паши и Светы все равно будет примерно одинаковая. Пашу нельзя поощерить зарплатой, потому что против этого восстанет профсоюз. С точки зрения профсоюза Паша и Света работают одинаково, потому что у обоих одинаковое образование и опыт работы, а значит и зарплата не может быть разной. Поэтому зарплата Паши, должна быть как у Светы. А еще Света девочка. К тому же, вы что, гендерное неравенство тут продвигаете? Нехорошо-с.
Вот вам недавний пример из жизни, насколько профсоюзы на все влияют. Из-за профсоюзов шведы много лет сидели без складов Amazon на своей территории, который очень хотел открыться в Швеции. Камнем преткновения был тот факт, что надо обязательно договриться с профсоюзом по поводу минимальной зарплаты. У Amazon и шведских профсоюзов были очень разные оценки минимальной оплаты труда работников складов, поэтому много лет шведы сидели без быстрой доставки и кучи рабочих мест.
Маятник гендерного неравенство улетел в другую сторону. В Klarna за референс девушки дают в 2 раза большее вознаграждение, чем за референс мужчины. При найме предпочтение отдается женщинам, если соотношение мужчин и женщин в вашей компании страдает, даже если ваша компания работает в отрасли, где в высшем образовании тот же перекос в сторону студентов мужского пола.
Отсутствует рынок жилья, назревает ипотечный пузырь, снижаются инвестиции в инфраструктуру, разваленное школьное и высшее образование до такой степени, что выпускник местной образовательной системы на шведском же рынке труда не может конкурировать с выходцами из Китая, восточной Европы, Индии, Пакистана, Бангладеша и т.д. Все это итог 50-летнего засилья шведских социалистов у власти.
Корень всех этих бед один - шведское понимание равенства, где под равенством понимается не равенство возможностей, а равенство результата. Звучит абсурдно, но для шведов это абсолютная истина, постулат, внушенный социалистами у власти, который даже нет смысла обсуждать, а уж тем более крамольно выражать сомнение в верности этого утверждения.
Что хорошо:
На работе можно придумывать свои проекты и работать над ними. По большей части это из-за бездарного, слабого, а зачастую еще и старого и немощного менеджмента, но для активного автономного разработчика это можно обернуть в плюс.
В целом жизнь в Швеции довольно спокойная. Есть, конечно, много "приколов", которые людям из СНГ понять сложно, как например магазины, закрывающиеся в 8 вечера и аптеки, которые не работают по воскресеньям. Но это ничего. Зато есть хорошая транспортная доступность, чистые улицы и т.д.
Я пробежал глазами и ссылку на самую главную статью так и не увидел, о чем и написал и попросил поправить меня, если это не так. Статья, действительно, очень важная, а самое главное, что находится в открытом доступе, в отличие от платного американского семинара. Про российский семинар просто еще раз отмечу, что странно построить практически весь семинар на чужой статье, выдрав даже картинки, не упоминая ту самую статью в открытом доступе. Надеюсь, что Александр Силантьев ссылку добавит.
Львиная доля материалов в видео украдена из статьи Clifford E. Cummings, представленной на конференции SNUG-2008. Статья есть в открытом доступе здесь:
http://www.sunburst-design.com/papers/CummingsSNUG2008Boston_CDC.pdf
Вообще поразительно просто. Что в этой статье у Панчула нет ссылки на первоисточник, что в видео, думаю, ни одной ссылки тоже нет (поправьте меня, если это не так). Хотя нагло украдено все, даже картинки свои поленились нарисовать, а просто выдрали из статьи. Пиарить свои семинары, используя чужой материал, причем из 2008 года, без упоминания авторства, ну-ну, хороший подход.
Здесь я несогласен. Аргумент, что учителя знают Паскаль, в принципе, нормальный. Цель информатики в школе это познакомить детей с информатикой как с областью знания вообще. В паскале есть все необходимые концепции (явные указатели, ООП и т.д.), с которыми надо познакомиться на базовом уровне. Язык сам по себе простой и понятный, что очень хорошо для обучения. Алгоритмы и структуры данных довольно наглядно реализуются на паскале. Единственный минус это невостребованность языка бизнесами. Но школа и академия это не прислужка бизнеса, как бы бизнесу этого не хотелось, и не обязана штамповать готовых python/java/c++ интернов для очередного владельца очередного мобильного приложения. Простота и наглядность основные принципы, наверное, для обучения программированию, особенно школьников, и паскаль полностью удовлетворяет этим требованиям.
Меньшего от корпоративного блога и не ожидал. Действительно, это же не человек, не инженер, а заготовка, просто единица ресурса для бизнеса. Ведь все вокруг просто обязаны со школьной скамьи знать стек вашей компании, ведь это очень удобно и экономно. Давайте в школе на информатике изучать сразу PHP, Angular, Android и iOS, ведь скайенгу так нужна армия рабов, да и потом всегда можно сказать «Вот ты пару лет поработай, ума наберись, заготовка ты эдакая, а потом и до джуна может быть дорастешь».
Зачем изучать информатику как область знания? Надо сразу с python начинать, потому что всем нужен
Больше всего он нужен Александру Ларьяновскому, ведь это прямо конвертируется в его личный карман. Да, в РАО сидят одни идиоты, а идиоты они потому, что хотят учить детей программированию на простом и понятном паскале, а бедный Александр от этого очень страдает, ибо не хочет вкладываться в обучение и развитие своих же молодых специалистов, поэтому РАН и РАО такие идиоты, не хотят обслуживать бизнес-интересы скайенга. В академии вообще одни некомпетентные люди сидят, как вы сказали. Хотят там информатику изучать, дискретную математику, алгебру там, а БИЗНЕС-РЕЗУЛЬТАТ кто показывать будет?
Мда, прошу прощения за столь едкий пост, но эти телеги бизнесов про то, что все вокруг идиоты и государственная система образования должна штамповать для них готовых рабов за бюджетные деньги вместо развития науки (извините, ни мобайл, ни веб-разработка никакого отношения ни к какой науке и развитию не имеют) уже просто задолбали.
Опять не соглашусь с вами. Львиная часть тулчейна уже лет 5 отлично работает на линуксах. Ни в одной большой и серьезной компании ни fpga, ни asic разработка не ведутся под виндой, из того что я видел, это всегда линукс.
Шифрование битстрима это хорошо. Фишка fpga в том, что это reprogrammable устройство. Поэтому многие используют fpga в конечном продукте, чтобы если что, можно было выкатить «патч». Дешевле и эффективнее, чем отзывать продукцию и делать респин, если у вас asic. Но в этом случае вашим продуктом становится сам дизайн. Дело в том, что по битстриму вполне себе без проблем реверсится netlist, ну и в итоге, сам дизайн. Поэтому шифрование битстрима это нормально и хорошо.
Про «дерет в тридорога за лицензии на свой софт». Xilinx коммерческая компания (стоявшая у истоков fpga, между прочим). Она заинтересована в извлечении прибыли, извините, коммунизм еще не настал. Зарабатывать с продажи fpga нереально, на чем же тогда зарабатывать? На лицензиях к своему тулчейну. Это же довольно сложный софт, специфический. Там свои специфические алгоритмы. Это результат 40-летнего труда многих хороших инженеров и разработчиков. С чего бы им отказываться от извлечения прибыли и конкурентного преимущества?
Сделать из hw open-source странная идея. Не то чтобы это плохо, мне, как инженеру и пользователю, это скорее выгодно. Просто непонятно как это должно происходить и кто будет этим заниматься. В sw open-source возможен отчасти потому, что разработчиков, способных его развивать и поддерживать условно много. В части fpga, найдется довольно мало инженеров, способных и готовых пилить открытые тулчейны. Там очень специфические алгоритмы. В целом разработчиков, специализирующихся на этом довольно мало. Не понимаю, как это должно происходить и развиваться, если честно.
Если у вас было легальное разрешение на работу, то вы должны были получить personnummer, а не налоговый номер, это во-первых. Наверное вы про personnummer и говорите. Обычно получить personnummer и открыть банковский счет занимает около месяца, но, может, в Стокгольме очереди какие-то большие?
Не очень понятны перипетии с жильем. Вы тратили 20000 крон. В Стокгольме, самом дорогом городе Швеции, очень хорошая двушка стоит 15000 крон, а просто хорошая от 11000 крон. Хорошая трешка стоит 15-18 тысяч, да, но обычно в таких домах, с такими ценами, галдящие арабы не живут. Да и квартиры в том панельном гетто, в которым вы жили, стоят намного дешевле и за те же деньги можно найти жилье намного лучше. Не совсем понял ваши претензии к арендодателям. В Швеции права квартиросъемщика защищены лучше, чем права арендодателя, и все всегда происходит по контракту. В стандартном контракте 2-3 месяца notification period — т.е. вы должно предупредить о своем желании съехать за 2-3 месяца, точно так же арендодатель должен за 2-3 предупредить о своем намерении вас выселить. Мне кажется, вас очень сильно обманывали с жильем.
Жилищный фонд лучше, чем в СНГ. Даже в старых домах хорошая инфраструктура, нет каких-то во все стороны торчащих сантехнических труб, нет кривых стыков плит. Новые дома строятся по заветам современных урбанистов — малоэтажное жилье с хорошим благоустройством. Отличные планировки в квартирах и площади. Может на Украине жилищный фонд гораздо лучше, чем в Швеции, и уж тем более лучше, чем в России, это объяснило бы ваш наброс на жилье.
Почему так сложно и дорого снять жилье? Ну, читайте про first-hand, second-hand contract в Швеции. Если вкратце, то государство выдает гражданам жилье в дешевую аренду, а большинство жилья на рынка это субаренда жилья, выданного государством. Построить новое жилье сложно и дорого, слишком большая зарегулированность строительства. Хорошая ли это система? Для кого как, лично меня она сильно пугает и сильно мне не нравится.
Из социальности страны как раз-таки следует то, что это flat country, и доходы выравниваются. Да, по всем специальностям зарплатная вилка довольно узкая, это 18000 — 40000 крон после налогов. Да, айтишник в Европе это не барин, как вы привыкли в СНГ, а обычный представитель среднего класса. Как вы думаете, если каждая маникюрщица и парикмахерша получает около 2000 евро после налогов, то может ли стрижка стоить столько же, сколько на Украине? Если вас это не устраивает, то так и заявите, что вам нравится в СНГ, когда соотечественники, чей труд не продашь заграницу, зарабатывают намного меньше вас, и у вас появляется возможность потреблять кучу дешевых услуг. Увы, в стране, где у каждого есть право на достойную жизнь, айтишник не будет барином, а будет обычным средним классом, как и должно быть.
Но даже здесь не все так просто. После 7-10 лет хорошего опыта многие начинают работать subcontractor, т.е. становятся ИП, предоставляющим услуги какой-то большой компании. Там уже меньше налогов, гораздо выше зарплата, сложнее проекты, но в то же время меньше безопасности, больше рисков. Spotify таким по 70-90 тысяч крон платит, но не всем такой путь подойдет, да это и не надо.
Про природу тоже странно. Страна довольно небольшая и вытянутая, какое природное разнообразие вы ожидаете увидеть? Про одинаковые кафе и магазины в городах тоже не понял. В Швеции фишка в том, что в любом маленьком городе, будет набор современных кафешек и магазинов, в этом смысле жизнь в Стокгольме мало отличается от жизни в какой-нибудь Эскилстуне. Как по мне это наоборот плюс, а не минус. Децентрализация, развитие регионов и все такое.
Про медленные поезда вранье. Да, настоящих скоростных поездов со скоростями 300км/ч нет, но все остальные ездят со скоростью 100 км/ч. Вся страна на поезде пересекается за 4-5 часов. Также они довольно удобные внутри. Дорогие ли они? Да, дороговато, но это от времени зависит.
Каждое предложение это неточность, вранье или глупость. Понимаю, скорее всего непреднамеренная, но тем не менее. Вам не понравилось, что переехав, вы перестали быть барином среди нищих холопов, а оказались обычным гастарбайтером. Да, вам надо зарабатывать на дорогое жилье. Местному шведу хорошую квартиру купят родители, у которых тоже свой дом в предместье Стокгольма, доставшейся по наследству. Жизнь местных шведов намного проще вашей, но это цена, штраф, за переезд в чужую страну.
Очень глупо бежать в Европу за деньгами и роскошной жизнью. Люди переезжают в поисках стабильности и уверенности в завтрашнем дне. В Швеции у меня гораздо больше шансов сохранить сбережения, накопить капитал, нежели в России, где раз в 20 лет случается полный ребут всего. И как это ни странно, на покупку своего жилья в Швеции уйдет примерно столько же времени, сколько на покупку своего жилье в том же Питере. Вот только качество шведского жилье будет намного выше.
И да, в скандинавских странах принято, что работают все, а не так, что работает один, а тратят двое. Может тогда что-нибудь даже и накопили.
Что я только что прочитал? Что за бред?