Как показывает пример Южной Кореи и Тайваня, для небольшой страны очень выгодно интегрироваться в международную экосистему проектирования и производства микроэлектронных чипов. Каким же образом может интегрироваться страна, у которой есть опыт разработки программного обеспечения, но нет сообщества разработчиков микросхем? Она может создать группу по аутсорсу так называемой функциональной верификации. Эта группа технологий очень востребована и имеет реалистичный порог входа. Японская компания Seiko Epson создала такую группу на Филиппинах, корейская компания SK Hynix купила такую компанию в Беларуси.
Микросхемы внутри смарфонов, компьютеров и сетевого оборудования построены из блоков, спроектированных с помощью языка описания аппаратуры Verilog. Для этих блоков пишутся тесты на SystemVerilog, которые во многом похожи на программы на таких языках как Java. Кроме этого, для создания среды верификации блоков используют скриптовый язык Python. Для задач верификации аппаратных блоков можно переучить программистов с Java и Python на SystemVerilog, если добавить к их умениям понимание, как работает цифровая логика.
Это всё не абстрактные рассуждения. Американский Университет в Центральной Азии и Siemens Electronic Design Automation GmbH решили провести 1-3 августа пилотный семинар в Бишкеке, чтобы: 1) выяснить интерес у бизнесменов Кыргызстана к такого рода проектам и 2) показать студентам бишкекских вузов и коледжей, как работать с верилогом на ПЛИС, чтобы понять, пойдет ли им эта тематика. Участники из других стран тоже могут приехать.
Немного деталей. Типичная команда, разрабатывающая блок чипа в игровой приставке или роутере, работает так:
Четыре инженера получают архитектурную спецификацию от архитектора, после чего:
Инженер по моделированию пишет программу, которая имитирует, как ведет себя блок, но без погружения в детали на уровне тактов.
Инженер по логическому проектированию добавляет от себя эти детали, то бишь пишет микроархитектурную спецификацию (не путать с просто архитектурной), а затем и код на языке Verilog, который описывает, что блок делает в каждом такте. Эту специальность также называют "проектировщих на уровне регистровых передач", RTL Design Engineer (RTL = Register Transfer Level).
Инженер-верификатор пишет тесты, которые проверяют, что модель первого инженера и RTL код второго инженера одинаково реагируют на одинаковые события.
Инженер по физическому проектированию помогает RTL инженеру превратить его код на верилоге в схему, которая вписывается в тактовую частоту, бюджет размера и энергопотребления.
При наличии хороших программистов построить аутсорс функциональной верификации (3) и высокоуровневого моделирования (1) проще, чем аутсорс логического и физического проектирования. Квалификацию для верификации можно построить на основе курсов, плотной работы с консультантами из компаний типа Siemens EDA и представителями заказчиков.
С (2) и (4) сложнее. Для нетривиального логического проектирования нужен опыт в микроархитектуре, который развить без соответcтвующей среды нереально. А у физического проектирования высокий барьер входа, из-за бОльшей близости к физическим эффектам транзисторов и дорожек. Но это следующие ступени - в верификации и моделировании даже больше работ, чем в RTL и физике.
Эти темы мы обсудим на семинаре в АУЦА, который пройдет 1-3 августа 2022 года в Бишкеке. В начале каждого из трех дней будут выступать представители Siemens EDA, одного из трех мировых лидеров в области средств автоматизации проектирования микросхем. Они расскажут о бизнес-модели аутсорса функциональной верификации, маршруте разработки современных микросхем RTL-to-GDSII, и представят Questa Advanced Simulator, программное обеспечение для симуляции и отладки проектов.
БОльшая часть каждого из трех дней будет занята практическим семинаром. Он предназначен для студентов, которые умеют программировать на языках типа C или Java и хотят понять, чем проектирование чипов на верилоге отличается от программирования. Мы введем базовые элементы цифровой схемотехники: комбинационную и последовательностную логику, а также конечные автоматы. Затем мы проиллюстрируем эти понятия на трех уровнях сложности: с помощью микросхем малой степени интеграции, с помощью элементарных упражнений с синтезом кода на верилоге для FPGA, и с помощью более сложных упражнений с графикой и звуком.
Мы также затронем темы, которые возникают в повседневной работе проектировщика: как вычисляется максимальная тактовая частота, на которой может работать схема; что такое конвейерные вычисления; как организованы процессоры, графические чипы и сетевые маршрутизаторы. И расскажем об организации труда команд, разрабатывающих массовые устройства в крупных электронных компаниях.
Для практического семинара мы будем использовать платы Omdazz с ПЛИС IntelFPGA Cyclone IV и средой Intel® Quartus® Prime Lite Edition Version 21.1.1 которую можно скачать отсюда для Windows и отсюда для Linux.
Программа семинара:
Модели бизнеса и основы технологий микроэлектроники для Центральной Азии
Совместный семинар Американского Университета в Центральной Азии и Siemens EDA
1 августа 2022
9:30 - 10:00. Утренний кофе и открытие семинара.
Алмаз Бакенов, директор департамента информационных технологий АУЦА.
10:00 - 11:00. Лекция: Мировая экосистема проектирования микросхем и возможности для интеграцию в нее новых стран.
Денис Лобзов, Siemens Electronic Design Automation GmbH
11:00 - 13.00. Практический семинар: Основы современного маршрута проектирования цифровой логики.
Юрий Панчул, проектировщик микросхем для смартфонов и сетевых устройств
Часть 1. Синтез комбинационных схем из описаний на языке Verilog для микросхем программируемой логики.
13:00 - 14:00. Обед.
14:00 - 16.00. Практический семинар. Часть 2. Использование выученного материала для генерации изображений на графическом экране.
2 августа 2022
9:30 - 10:00. Утренний кофе.
10:00 - 11:00. Лекция: Обзор маршрута проектирования и производства микросхем
Siemens Electronic Design Automation GmbH
11:00 - 13.00. Практический семинар. Часть 3. Последовательностная логика и анализ временных задержек.
13:00 - 14:00. Обед.
14:00 - 16.00. Практический семинар. Часть 4. Использование выученного материала для распознавания звуков из микрофона.
3 августа 2022
9:30 - 10:00. Утренний кофе.
10:00 - 11:00. Лекция: Questa Advanced Simulator, программное обеспечение для симуляции и отладки проектов.
Siemens Electronic Design Automation GmbH
11:00 - 13.00. Практический семинар. Часть 5. Конечные автоматы и отладка в симуляторе.
13:00 - 14:00. Обед.
14:00 - 16.00. Практический семинар. Часть 6. Использование выученного материала для создания графической игры и распознавания мелодий флейты.
16:00 - 16.30. Закрытие семинара.
Для регистрации на семинаре вы можете прислать емейл Директору департамента информационных технологий Американского Университета в Центральной Азии Алмазу Бакенову bakenov_a@auca.kg
Комментарии (64)
WST
07.07.2022 10:02+8Я, когда был в Индонезии, открыл для себя со слов своих друзей, что электроника там изучается как школьный предмет — пусть и необязательный, но который многие выбирают по желанию. Думаю, нам этого не хватает. С другой стороны, в период моей юности я видел вокруг гораздо больше интереса к электронике, нежели сейчас, хотя возможностей сейчас несоизмеримо больше. Парадокс.
YuriPanchul Автор
07.07.2022 10:17+2Да, в Индонезии еще в 1970-е годы собирался каждый четвертый в мире телевизор, да и рядом Малайзия с фабами и Сингапур, так что вовлеченность в школьной программе понятна.
iliasam
07.07.2022 10:52+1С другой стороны, в период моей юности я видел вокруг гораздо больше интереса к электронике, нежели сейчас, хотя возможностей сейчас несоизмеримо больше. Парадокс.
Если ваша юность приходилась на СССР, то тогда многим приходилось делать электронные устройства самостоятельно из-за дефицита. Теперь же можно без проблем купить какую угодно электронику.WST
07.07.2022 11:06+5Нет, на 1990-е, но ни мной, ни моими знакомыми двигало явно не это, просто был банальный интерес к творчеству, создать что-то своими руками ощущалось «круто». Мы делали порой нелепые и странные вещи (например напаивали светодиоды на спицы советского велосипеда — до сих пор помню, как на удивление легко они лудились) и переключали их примитивным мультивибратором на 2 транзисторах. И сколько эмоций потом приносила езда на таком — не описать!
iliasam
07.07.2022 11:17+2В таком случае, думаю, что компьютеры со смартфонами с их развлекательными возможностями просто вытеснили другие виды хобби.
IvanPetrof
07.07.2022 11:58+2У меня в детстве был целый мешок релюшек РЭС-15, я их разбирал, доставал из них катушки, крепил к спицам и соединял со светодиодами на спицах. А на вилке крепил круглый магнит от динамика. Получались светодиоды с индуктивным питанием. Причём, можно было сделать соединение со смещением таким образом, что получался эффект бегущего огня, который «бежал» в противоположную, относительно вращения колеса, сторону.
WST
07.07.2022 12:06+1Да, велосипед широко использовался как способ демонстрации своих наработок :)
Ещё одна конструкция, которая иногда встречалась — на руле крепился калькулятор, к контактам «=» был подпаян геркон, закреплённый на раме, а где-то на спицах крепился магнит. На калькуляторе вводилась длина окружности колеса (к примеру 1.16), затем «+ 1.16» — и дальше можно было просто ехать и на экране отображалось пройденное расстояние.У кого скиллов побольше — собирали оптический аналог, вроде в одном из номеров журнала «в помощь радиолюбителю» была схема цифрового спидометра (измерял скорость по частоте «мелькания» спиц) между источником и приёмником.
sogarkov
09.07.2022 09:51Когда я менял специализацию, выбирал между микроэлектроникой (дизайн, проектирование) и web-программированием. Анализ предложений на рынке труда сделал выбор за меня в пользу последнего. Какой смысл идти в направление, где зарплаты в 2 раза ниже при одинаковом уровне квалификации?
YuriPanchul Автор
09.07.2022 10:13О рынке какой страны вы говорите? Можете назвать конкретные цифры?
sogarkov
09.07.2022 10:29В момент выбора речь шла о РФ, конечно.
YuriPanchul Автор
09.07.2022 10:36Под моим постом Хабр показал следующие текущие российcкие вакансии. Это для России много или мало? По сравнению с веб-программированием в России же
sogarkov
09.07.2022 10:53Верно, это уровень сеньора. Обратите внимание на сеньорские позиции в разработке. Хотел отметить ещё один важный момент, начинаем мы с джунов и далее растём. Временная кривая профессионального роста на девелоперских позициях, особенно на "галерах", выглядит существенно круче. 3 года до миддла вполне реально. В инженерии микроконтроллеров это лет 5-6 в силу различных особенностей физических систем.
Daffodil
07.07.2022 10:11-4Она может создать группу по аутсорсу так называемой функциональной верификации
А какой смысл растить UVMщиков, ведь всем известно что в функциональную верификацию идут только те, кого не взяли в нормальные программисты? Уровень computer science подготовки в РФ пока выше чем в Индии или Филиппинах, зачем нам отбирать хлеб у самых бедных стран? Лучше сфокусироваться на разработке архитектур и компиляторов, а группу по верификации создавать в дружественных странах, например в Иране, Венесуэле или Центральной Африканской Республике.
YuriPanchul Автор
07.07.2022 10:27+2Вы похоже не дочитали до третьего абзаца и начали комментировать
YuriPanchul Автор
07.07.2022 10:34+1Также насчет функциональной верификации вы неправы. Есть люди, которые занимаются интересным задачами в этой области, скажем верификацией многоядерных кластеров с когерентными кэшами. Или скажем формальной верификацией конвейера в процессоре.
И сводить верификаторов к UVMщикам - это вы просто не очень знаете реальную ситуацию в большом количестве компаний. Хотя про UVM говорили "все индустрия выстраивается вокруг UVM" еще в 2010 году, но реально в больших компаниях UVM используют достаточно ограниченно и часто выдумывают свои наборы примитивов, так как в UVM трудно делать многие вещи (скажем гибкие sequences) и UVMщики часто заняты борьбой с вычурностью UVM вместо реальной работы по верификации.
UVM можно использовать скажем для некоторых блоков сетевых чипов, но для верификации CPU она слабо применима.
LinearLeopard
07.07.2022 10:54+4Спасибо за статью, если небольшое уточнение:
корейская компания SK Hynix создала такую компанию в Беларуси
Скорее купила:In 2014, SK Hynix acquired the embedded software division of the Softeq Development Company in Minsk.
tropinkin
07.07.2022 11:57В 2014 - купила, в 2022 - фактически закрыла (сейчас в состоянии релокации в Польшу).
victor_1212
07.07.2022 14:59еще одна полезная статья,
> Инженер по моделированию пишет программу, которая имитирует, как ведет себя блок, но без погружения в детали на уровне тактов
если возможноj чуть подробнее, желательно с примерами, как определяется уровень детализации/абстракции, и использьзуемое для моделирования sw, не совсем понятно что можно сделать полезного "без погружения в детали на уровне тактов", точнее понятно что это возможно далеко не всегда
YuriPanchul Автор
07.07.2022 19:18+1Например есть шина 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, но вот проверить очередность (что некая запись не переписыват данное по адресу, и последующее чтение почитает именно то, что надо) - это можно и без знания потактового поведения.
victor_1212
07.07.2022 21:13очень интересно, какое sw используется для моделирования (looks like event driven)?
достаточно знаком с многоуровневым моделированием в том числе в сетях, но в другом контексте, поэтому относительно хорошо понимаю, о чем идет речь,
пожалуй еще более интересно - как и кто решает на каком уровне абстракции необходимо моделирование по данному изделию (IC) т.е. описывает функциональную модель исходную для моделирования ?
YuriPanchul Автор
07.07.2022 22:06+1*** очень интересно, какое 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 (с ограниченной скоростью симуляции по сравнению с платной).
lexxsu
08.07.2022 18:25Чем обосновано использования чистого Verilog, а не синтезируемой части SV?
YuriPanchul Автор
08.07.2022 21:27В больших компаниях - инерцией, хотя они постепенно переходят. У поставщиков semiconductor IP - необходимостью совместимости c клиентами и всеми EDA тулами. Пример несовместимости - тул для анализа динамического энергопотребления Synopsys PTPX глючит, если использовать многомерные порты "input [10:0][7:0] abc" которые есть в SV, но нет в Verilog-2001/2005.
lexxsu
09.07.2022 03:47Да, инерция есть, но двигаясь вперёд улучшаешь результаты работы.
А Synopsys что по этому поводу говорит, или вы используете старую версию.
Если обьявить тип 8 бит и сделать 1D массив из этих элементов или заменить 2D порт на 11×8 и применить вектор как индекс?
Меня больше раздражает проблемы дамп в fsdb и Verdi для нескольких вызовов функции в одном модуле (он их не распознает и показывает зачения только для одной функции), а также невозможность посмотреть значения для automatic function.
YuriPanchul Автор
07.07.2022 22:11+2*** пожалуй еще более интересно - как и кто решает на каком уровне абстракции необходимо моделирование по данному изделию (IC) т.е. описывает функциональную модель исходную для моделирования ? ***
Verification architect - он на основе опыта решает стратегию проверки. Например в Интеле, где много инженеров, делают избыточно точные модели процессорных ядер на С++ со всеми деталями конвейера, но в большинстве других компаний как правило RTL описание на Verilog проверяют против модели процессоров (написанных на Си) на уровне инструкций (без моделирования конвейера, например с помощью симулятора Imperas) . И баги ловят, сравнивая результаты записи в видимые программисту регистры в конце конвейера в RTL.
victor_1212
07.07.2022 22:49+1спасибо за оба сообщения, супер интересно, т.е. в части event driven system simulation proprietary C, C++ код, это знакомо
Anton_Menshov
08.07.2022 02:20+3Статья очень грамотная. Единственное, что многие инженеры, как только получат минимальный опыт в России - мгновенно уедут. Во всяком случае я (и многие-многие другие, гораздо большие акулы) буду со своей стороны следить за этим очень внимательно и пытаться привлекать их из-за рубежа, способствуя этому тренду "уезда". Хотя я, конечно, больше по пункту 4: физическое моделирование.
DmitryZlobec
08.07.2022 08:38Интересная мысль, верификатор-то как раз может быть индивидуальным предпринимателем и работать удаленно, ему по сути нужен только доступ к софту. Другое дело что это подсознательно воспринимается как работа "второго сорта", всё-таки не сам придумываешь...
YuriPanchul Автор
08.07.2022 08:49Зависит от типа верификатора. Он может продавать скажем Verification IP (Intellectual Property) - параметризуемый код на SystemVerilog для генерации транзакций для стандартных шин (AXI например) и мониторингу шины с экстрагированием транзакций из сигналов (правда это уже хорошо заезженная область). Если речь идет о verification IP для чего-нибудь сложного (например кластере процессорных ядер с когерентными кэшами), то такая работа может быть творческой.
Brak0del
08.07.2022 09:03Единственное, что многие инженеры, как только получат минимальный опыт в России - мгновенно уедут.
Статья всё же не про РФ. Многих может удержать возможность заниматься клёвыми вещами за хорошие деньги по месту жительства с сохранением друзей, родственников, связей и прочих активов.
lexxsu
09.07.2022 06:28Уехать не так и просто, нужно конкурировать с другими за визы, конкурировать за места с 'говорливыми' индусами. Потом одно дело позиция senior и уже другое staff и выше.
te3s
08.07.2022 21:27@YuriPanchul, а что вы думаете по поводу вот этих вещей?
Там вроде как красной нитью (особенно у google) проходит мысль о том, что HW разработка должна стать очень похожей на SW. Реалистично ли ожидать на горизонте 10 лет создания открытого тулчейна и новых инструментов для облегчения входа SW инженеров в HW?
YuriPanchul Автор
08.07.2022 21:40+1Про открытые тулчейны и 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, чем массажировать Си-код прагмами".
volchenkodmitriy
Спасибо за статью! Проблема действительно острая! Но хочу обратить внимание что опять даже в разработке физических чипов присутствует тяга к программированию. Как в анекдоте про студента который выучил на экзамене только про блох, а его спросили про рыб. Он и говорит что рыбы живут в воде и у них нет шерсти, но если бы была, то там водились блохи и давай про блох дальше... Кто сейчас лидеры в производстве чипов - те у кого лучший техпроцесс, как все эти среды разработки позволят улучшить техпроцесс? Есть такой чудесный предмет в ВУЗах - называется ФОЭ (Физические основы электроники) Вот расспросите современных программистов - что они знают про p-n переход. А ведь именно с ним в конечном счете связано все их программирование.
YuriPanchul Автор
Как я описал выше, все эти вещи должны хорошо представлять process engineer на фабе, разработчик ASIC library и немного physical design engineer.
Для разработчика микроархитектуры и проектировщика на уровне регистровых передач вся физика - задержки в пикосекундах, статическое и динамическое энергопотребление и размеры - изолированы в ячейках standard cell library и алгоритмах EDA. То есть от него требуется анализировать static timing analysis report, в которых конечно есть пикосекунды, но от ФОЭ это далеко.
А для функциональной верификации это еще меньше нужно, так как в ней пикосекунды и нановатты появляются очень косвенно - для верификатора стоит знать про clock gating и стадии конвейера, которые непрямым образом связаны с той физикой.
Так что в этом деле есть место для специализаций разной степени удаленности от физики.
YuriPanchul Автор
*** Кто сейчас лидеры в производстве чипов ***
Является ли скажем Apple лидером в производстве чипов? Нет, не является, он использует фабы других компаний. При этом является ли Apple лидером в проектировании чипов? Конечно является - Apple M1 пример. Что является фокусом Apple M1 ? Микроархитектура. Связана ли микроархитектура с техпроцессом? Косвенно.
volchenkodmitriy
Вот если бы на apple сейчас наложили санкции как на нас, то они бы уже обанкротились наверно). В наших условиях, я считаю, важно именно осваивать полный цикл и выходить в лидеры начиная с физики, а использование готовых физических решений обрекает нас всегда быть догоняющими.
YuriPanchul Автор
Но в посте же я обсуждаю совсем другую проблему - не проблему России, которой производители оборудования для фабов не хотят продавать степперы, а проблему Кыргызстана, где нет даже российкого уровня понимания полупроводникового производства, поэтому заходить с этой стороны менее эффективно, чем с других, в частности функциональной верификации. Это подход, который оправдал себя например c аутсорсом верификации от японской Seiko Epson филиппинским аутсорсерам.
volchenkodmitriy
Ну в принципе Американскому Университету в Центральной Азии и Siemens Electronic Design Automation GmbH только того и надо - сделать группу разработчиков "без понимания" и в полной зависимости от внешних ресурсов...
YuriPanchul Автор
А есть альтернатива для первого шага? Или вы предлагаете начать с изобретения оборудования для производства микросхем уровня начала 1970-х и за каких-нибудь двести лет изобрести все степперы итд до 3 нм?
StanKondrat
Мир это глобальная конкуренция. Может цель корпорации не помочь маленькой стране развиться и конкурировать, а высосать потенциальные таланты?
cepera_ang
А может для человечества лучше, чтобы потенциальные таланты высасывались туда, где они могут стать реальными талантами? Да и для талантов хорошо. Кому от этого хуже? Только тем, кто сидел бы на этих талантах как собака на сене — ни сам не использовал, ни другим не давал?
StanKondrat
И делать софт/хард для людей что бы те больше смотрели рекламы. Это известная проблема, что лучшие программисты занимаются тем что бы было больше рекламы. То что выгодно корпорациям очень часто не выгодно человечеству.
Может вы знаете какие нибудь цели человечества, которые логически доказуемые?
Я как то об этом думал, но остановился на том, что человечеству быть — это хорошо, а не быть — плохо, следовательно бэкап на луне и на марсе, то же хорошо, но что-то за последние 50 лет на луне много людей не живет, хотя и техническая возможно есть.
cepera_ang
Вполне себе хороший вопрос для хабра. И не сложный: если даже мы не можем сказать, что человечеству лучше, то можем сказать что ему точно хуже — не забирать таланты из места, где они не смогут себя проявить в место где смогут.
А будет это реклама или что-то ещё — дело десятое. В конце концов, вы же понимаете, что реклама составляет единицы процентов от деятельности человечества, поэтому никак не может быть так, что все таланты ушли исключительно в рекламу?
xSVPx
Как проценты ? Маркетинг это как бы не половина в цене продаваемого продукта...
cepera_ang
Далеко не каждого продукта. Это во-первых. А во-вторых, далеко не вся экономика требует маркетинга. Как думаете, сколько на рекламу тратит провайдер электричества в вашем доме? А водоканал? И т.д.
Выручка всего мирового рынка рекламы (включая телевизор, интернет, печатные издания, баннеры на улицах и т.д.) составляет порядка 900 миллиардов долларов. Много конечно, но это всего ~1% от валового мирового продукта.
nporaMep
Думаю многие были бы не против если бы их высосала международная корпорация, чем если это сделают российские чинуши.
LinearLeopard
А электронщиков, видимо, надо начинать учить добыче лития?
Если завтра все схемы волшебным образом заменятся на оптические или биологические без p-n переходов (но с такой же скоростью и процентом ошибок) — программирование не изменится совсем.
volchenkodmitriy
Было бы неплохо если бы у электронщиков было понимание об этом процессе. Они бы лучше понимали что может повлиять на поставку электронных компонентов.
LinearLeopard
Было бы не плохо, осталось уместить это в 4-6 лет обучения. Боюсь, если даже сделать невозможное и выкинуть философию — времени может не хватить)
volchenkodmitriy
Что поделать, нужна не только Философия, но и История философии, без них техническим специалистом не стать))
cepera_ang
И ремня ещё всыпать, чтобы мужиками выросли.
Sarjin
биологические есть. каждый человек обладает как минимум одним. программирование ребенка довольно отличается от ЭВМ
Sergeant101
p-n переход?
Серьезно?
Микропроцессорная техника давным давно ушла в КМОП, а может и дальше.
vadimbudnyaev
а в КМОП-схемах нет p-n-переходов?)
Serge78rus
Именно в КМОП схемах их как раз и нет, если не считать защитных диодов на входах. А вот в реальных микросхемах, реализующих КМОП логику, они есть в виде изоляции цепей обратносмещенными p-n переходами.