Началось общеобразовательством а закончилось любительством, не это я ожидал увидеть в блоге Ядра. На мой взгляд, куда интереснее было бы почитать про dft архитектуру для soc: как тестировать блоки и их меж-интерфейсы, как писать обертки типа iee1500, контроллеры с режимами типа at-speed, объединять в сети типа SSN или SMS и т.д. Так, пожелания, на будущее.
Кстати, любопытно, что происходит с топологом после того, как микросхема выпущена в производство?
Вы все верно написали. Чем больше штат, тем больше заказов, и эффективнее загрузка инженеров работой. Не говоря уже про лицензии на софт.
Разовые проекты интересны инженеру только если это твой стартап, либо если работаешь как ИП с несколькими клиентами. Понятно, что в РФ мало кто так может, поэтому предпочитают сидеть на зарплате ровно и пинать балду между проектами. Так же и менеджменту интереснее работать с ИП, а не содержать штат, но на деле мало кто готов бодаться с налоговой (за работу с ИП "кошмарят").
Еще потихоньку развиваются аутстафф сервисы, но туда идут работать только с иностранцами (китайцами), во всех остальных случаях это никому не выгодно - ни инженерам, ни их клиентам. Могу ошибаться.
Чат умеет читать даташиты, использовал его для поиска ОУ на замену, в частности искал аналоги TI у AD, и наоборот. Для такой задачи работает, но - требовать написать драйвер на основе описания регистров в даташите, конечно же перебор. Т.е. в данном примере я бы попросил сгенерить код для чтения/записи по интерфейсу (I2C?), а вот уже с регистрами команд и данных этого конкретно датчика разбирался бы вручную. Проверять как это сработает в реале не буду, разумеется. Просто мысли с дивана :-) У себя по работе (топология ИС) тоже теперь часто использую ИИ. Буквально за последний год все изменилось, стало проще накидать промт, чем кодить самому. Но - не агитирую, и не спорю что пока это костыли, а не тул
Я не думаю, что изменились параметры для сравнения: по прежнему имеет смысл вылизывать дизайн, к примеру, отдельных элементов библиотеки. Но и время на разработку должно укладываться в разумные рамки, отсюда обязательное использование и библиотек, и тулов - в ущерб остальному. Для больших дизайнов, конечно. В данном же случае один разряд счетчика можно считать элементом библиотеки, и изобретательский подход оправдан, однако если говорить, к примеру, о 16три разрядном счетчике со сбросом, загрузкой и т.д., то приемлемые сроки уже можно достичь только "строя из кирпичиков".
В принципе, частные решения тоже получили некоторую автоматизацию, и скажем так -верификацию. У Вас это совсем не затронуто, хотя решению уже лет 30: проверять полученную схему на основе анализа сигнального графа с помощью тулов, таких как Petrify. 10 лет назад, по совпадению, я описывал это на примере практически такого же счетчика, взятого то ли из патента, то ли из книг: https://habr.com/ru/articles/306056/ В этой публикации важно то, что возможности тулов ограничены примерно 50 вершинами графа. А как это вручную проверять, строить куб, я даже не представляю. Слишком сложно.
Изобретательство - хорошо, но лично мне куда больше импонирует GALA-подход: отдельно строим схему управления, в данном случае это будет закольцованный пайплайн из 3х элементов (меньше нельзя), скажем на основе ячеек Давида, или лучше - двувходовых С-элементов с инвертором в обратной связи. А управлять эта схема будет всего лишь одним клеточным автоматом, состоящим из RS защелки с отсечкой, и выходы которого замкнуты на входы. Получится автомат, считающий в логическом времени: 01-10-01 где '-' надо заменить на спейсер 00 или 11, в зависимости от типа защелки. Ну и добавить индикацию окончания переходных процессов в автомате. Вот и все. Просто по кирпичикам (базируясь на теореме Маллера о соединении полумодулярных схем - если правильно помню название) построили автомат. Который можно наращивать как угодно с помощью перекрестного преобразования из обычных не-самосинхронных логических схем. Чем и хорош GALA-подход, он получился более технологичным, поскольку можно писать на языках высокого уровня типа верилога, и использовать современные синтезаторы. Жаль, что это все уже (или пока еще?) не актуально.
Удивился на цитату. Ну что же, тогда вот и мои три копейки. Не критика, а просто в дополнение. По совпадению, примерно с месяц назад откопал свою старую макетку STM32F4 DISCOVERY и решил оживить. Последний раз я что то кодил для мк более 10 лет назад, и тогда же последний раз писал на Си, т.е. забыл почти все по этой теме. Но, мне было очень интересно как LLM может помочь в эмбиддерстве. Что я сделал: - спросил чатгпт, какой софт ставить. Был дан ответ, ставить STM CubeMX и CubeIDE. Поставил, запустил. - спросил чатгпт, как сгенерить профиль в CubeMX для проекта VirtualCom port для моей платы. Не сразу, но по наводящим вопросам удалось пробиться через конфиги и сгенерить проект. Т.е. все изложенное в этой публикации я проделал под четким руководством чатагпт буквально минут за 15, без чтения документации/гайдов, и вообще не включая мозг (гордиться нечем, знаю, но сам факт). - попросил чатгпт сгенерить мне код для VirtualCom port, включая небольшой обработчик команд / эмуляцию консоли. Заработало почти сразу: Я копипастил код в IDE, запускал, ошибки копипастил обратно в чатгпт, и следовал его указаниям. После нескольких таких итераций все заработало. - потом еще спросил чатгпт от файн-тюнить код для максимальной пропускной способности виртуального компорта. Ну и заодно спросил хороший терминал для винды, чтобы все это погонять в железе. Что я хочу сказать. У меня несколько знакомых программистов сейчас сидят без работы. Компании сокращают штат в пользу LLM, отсюда массовые увольнения. Похоже, это скоро коснется и эмбиддеров. А там и до меня доберутся. Но! Есть и плюсы. Для хоббистов теперь открыты все возможности, порог вхождения опустился ниже плинтуса.
Для больших корпораций типа фаанг это хороший способ посадить инженеров на крючок еще глубже, чем раньше. Поясню. Если раньше в виде морковки выдавали рсу с приличной суммой вестинга на ближайшие нцать лет, то теперь достаточно дать в "кредит" 100к на визу, с последующим списанием в течении этих же н-цати лет, и конечно же угрозой отобрать все обратно в случае увольнения. Еще большая кабала, одним словом. Возможно, фаангами и пролоббированная. А индусы как ехали так и едут, куда им еще деваться
Добавлю еще что это так же и шикарный фильтр отсеивать инженеров без паровоза в виде семьи. Хорошая такая циничная гребенка
И снова хочу заметить, что говоря об имплементации, нужно учитывать и особенности базиса элементов. Если базис - т.н. 'россыпуха', отдельные корпуса (ЭСЛ, БТ и т.д.), то очень сложно будет найти элементы с числом входов больше 4-5, а если говорить об интегральных схемах (ASIC, т.е. фактически КМОП), то проблема ровно та же, поскольку элементы с большим числом входов очень медленные (в разы и даже на порядки, в зависимости от числа входов). И получается что изложенный подход (составление функций сброса и установки RS защелки) работает только на бумаге. Как только мы переходим в 3-4 входовой базис элементов, картинка становится непрезентабельной. А если отталкиваться от имплементации, то окажется - выскажу частное мнение -, что самыми компактными (по числу транзисторов) будут схемы на С-элементах, а не RS триггерах. Даже при том, что на практике, для интегрального исполнения, реально спроектировать только 2-х и 3х входовые С-элементы, а большее число входов получать уже их каскадированием. Ну или не говорить об имплементации вообще. Тогда это материал для математиков, а не электронщиков. Не воспринимайте вышесказанное как критику, просто мнение инженера-практика, который микросхемы (обычные, не асинхронные) проектирует каждый день.
Можно еще добавить, что наиболее хорошо эта тема изложена в статьях Мараховского (и самых поздних - Варшавского), где они называют этот процесс синхронизацией (обработки данных) в логическом времени (при этом асинхронно - в физическом времени), и в противовес pipeline (волновая обработка информации - по Варшавскому) приводят альтернативу - параллельную синхронизацию (так же обработки данных, и так же в логическом времени, но асинхронно - в физическом). Более того, производится выделение в отдельные категории схем управления (материал данной статьи, в частности), и автоматов обработки информации - которыми собственно и надо управлять. Мухи отдельно от котлет т.с. Другими словами, поздние публикации Мараховского излагают данный материал более глубоко, шире, и понятнее, на мой взгляд. Такое вот частное мнение
Картинки из патентов, а патенты на то и патенты, чтобы защищать изобретение, а понимание наоборот усложнить.
Это схемы времен СССР, общепринятых правил рисования схем тогда либо не было, либо они сильно отличались от современных. Взять хотя бы аналоговые схемы времен СССР, где земля и питание рисовались не как рейлы внизу-вверху соотв., а могли быть где угодно, как угодно, равно как и транзисторы поворачивали как бог на душу положит. В общем, остается только понять и простить (сначала простить, а потом попытаться понять).
Очень важно уточнять, в каком базисе выполнены эти три инвертора. Потому что схема на КМОП и биполярных транзисторах практически нежизнеспособна из-за паразитной обратной связи между входом и выходом инвертора. Можно добавить линию задержки (RC в общем случае), либо использовать 5 инверторов - так будет работать стабильно.
На мой взгляд, практическое применение - основная проблема всей теории самосинхронных (основанных на решетках) схем. Последние разработки пришлись на развал СССР, а все что было позже, так и не пошло в мейн стрим. Наука ради науки мало интересна. Да и нового, после ГАЛА ничего не появилось, теория выглядит законченной. Наверное по этим причинам никто в мире больше и не занимается самосинхронными схемами. Нет ниши.
Первый раз увидел доказательство через "штаны", и через векторное отображение. Немного напрягшись, понял оба. Мое мнение, как не-математика, а инженера: оба доказательства сложны для понимания. Не помню, как это объясняли в моей, еще советской, школе, но сейчас доказательство через квадраты видится мне наиболее простым/понятным.
Все зависит от жизненного опыта и привычек, одному кажется простым одно, другому другое. Гуманитарий может быть будет в восторге от штанов, инженер тяготеет к квадратам, а математик тащится от векторов. Привычные (и потому наиболее удобные) пути искать объяснения, у всех разные.
Не очень понятно, на каком питании меряется архитектурная скорость на гигагерц. Если указанный ТТ 1В, то это очень много для указанной технологии, должно быть где то 0.8-0.85, а все что выше будет слишком горячим/потребляющим. Этот ТТ - уже разгон, фактически.
И еще я полагаю что 0.72В это низ работы SRAM, т.е. дизайн еще не пытались перевести на разные питания и домены. И DFT там наверное нет, т.е. сделано максимально облегченно и быстро, чисто для бенчмарка. В реальном же чипе все эти режимы питания и тестирования будут, и получится медленнее.
С другой стороны, судя по картинке лейаута, он сильно оценочный, так что и частоты могут быть больше. Все же 1.35 в 0.72 это не много.
Итого, в целом, новость впечатляет, но низкие частоты и нереалистичный ТТ - есть над чем поработать.
Патентный анализ очень слабенький, не упомянуты известные американские стартапы и их связь с российским патентом 15 года. Честно говоря вообще не понятно, зачем была сделана эта публикация
Отвечу, господин хамло. Архитектура (схема тактирвоания, сброса, дфт, иерархия блоков, границы доменов питания и т.д.) как правило меняется на первых этапах физического проектирования - в целях именно физического проектирования. Если нужно, то возвращаются к самому началу. Даже интерфейсы могут меняться в зависимости от расположения в чипе: если надо, к примеру, пробросить сквозной интерфейс между ближайшими соседями.
Пункты 9 (плис) и 11 (эсик) должны быть форками, а не последовательностью. Причем в этом форке приоритет на запросы по оптимизации и архитектурным изменениям должен быть у эсика, а не плис.
Тут надо добавить, что пройти указанный путь - явление редкое. Есть куда более простые способы подняться, но они больше подходят для имеющих нужных родственников, либо ж#полизов и карьеристов, и как показывает практика эти категории намного более многочисленные, чем те кто идет путем саморазвития. Я не говорю что это хорошо, это очень плохо. Но в текущих российский реалиях это данность, с которой приходится считаться.
Ну, как сказать, ничего не значит? Вспомнить тот же Арпэ: организация, высосанная из пальца одним человеком, усиленно самопиарилась и зазывала к себе руководителей организации, поднялась, и начала рубить деньги. Возможно, и у Горшенина получится просамопиариться до подобной прокладки между государством и бизнесом. Главное, убедить всех что ты нужен. Это почти как профсоюз, единожды наступив в него, потом не отмоешься
Должны быть GDS файлы. Очень любопытно, как их получали для ддр5 и рокчипа; такие микроскопы еще поискать надо (рокчип это 8нм, к примеру), еще и число слоев там за десяток. Итого, есть основания считать, что в регистрации топологии лежит фейк.
Не понятно, как генерация айпи соотносится с проектированием микросхем, это как сравнить теплое с мягким.
Но идея генерации кода вычислительных айпи, с оптимизацией инструкций, перфоманса, и если еще и компилятор на выходе будет - это очень круто. Правда сокрее всего тут речь об архитектуре фон-неймана, так что ничего существенно прорывного все равно не получится, просто конструктор под частные задачи
Началось общеобразовательством а закончилось любительством, не это я ожидал увидеть в блоге Ядра. На мой взгляд, куда интереснее было бы почитать про dft архитектуру для soc: как тестировать блоки и их меж-интерфейсы, как писать обертки типа iee1500, контроллеры с режимами типа at-speed, объединять в сети типа SSN или SMS и т.д. Так, пожелания, на будущее.
Вы все верно написали. Чем больше штат, тем больше заказов, и эффективнее загрузка инженеров работой. Не говоря уже про лицензии на софт.
Разовые проекты интересны инженеру только если это твой стартап, либо если работаешь как ИП с несколькими клиентами. Понятно, что в РФ мало кто так может, поэтому предпочитают сидеть на зарплате ровно и пинать балду между проектами. Так же и менеджменту интереснее работать с ИП, а не содержать штат, но на деле мало кто готов бодаться с налоговой (за работу с ИП "кошмарят").
Еще потихоньку развиваются аутстафф сервисы, но туда идут работать только с иностранцами (китайцами), во всех остальных случаях это никому не выгодно - ни инженерам, ни их клиентам. Могу ошибаться.
Чат умеет читать даташиты, использовал его для поиска ОУ на замену, в частности искал аналоги TI у AD, и наоборот. Для такой задачи работает, но - требовать написать драйвер на основе описания регистров в даташите, конечно же перебор. Т.е. в данном примере я бы попросил сгенерить код для чтения/записи по интерфейсу (I2C?), а вот уже с регистрами команд и данных этого конкретно датчика разбирался бы вручную. Проверять как это сработает в реале не буду, разумеется. Просто мысли с дивана :-)
У себя по работе (топология ИС) тоже теперь часто использую ИИ. Буквально за последний год все изменилось, стало проще накидать промт, чем кодить самому. Но - не агитирую, и не спорю что пока это костыли, а не тул
Я не думаю, что изменились параметры для сравнения: по прежнему имеет смысл вылизывать дизайн, к примеру, отдельных элементов библиотеки. Но и время на разработку должно укладываться в разумные рамки, отсюда обязательное использование и библиотек, и тулов - в ущерб остальному. Для больших дизайнов, конечно.
В данном же случае один разряд счетчика можно считать элементом библиотеки, и изобретательский подход оправдан, однако если говорить, к примеру, о 16три разрядном счетчике со сбросом, загрузкой и т.д., то приемлемые сроки уже можно достичь только "строя из кирпичиков".
В принципе, частные решения тоже получили некоторую автоматизацию, и скажем так -верификацию. У Вас это совсем не затронуто, хотя решению уже лет 30: проверять полученную схему на основе анализа сигнального графа с помощью тулов, таких как Petrify. 10 лет назад, по совпадению, я описывал это на примере практически такого же счетчика, взятого то ли из патента, то ли из книг: https://habr.com/ru/articles/306056/ В этой публикации важно то, что возможности тулов ограничены примерно 50 вершинами графа. А как это вручную проверять, строить куб, я даже не представляю. Слишком сложно.
Изобретательство - хорошо, но лично мне куда больше импонирует GALA-подход: отдельно строим схему управления, в данном случае это будет закольцованный пайплайн из 3х элементов (меньше нельзя), скажем на основе ячеек Давида, или лучше - двувходовых С-элементов с инвертором в обратной связи. А управлять эта схема будет всего лишь одним клеточным автоматом, состоящим из RS защелки с отсечкой, и выходы которого замкнуты на входы. Получится автомат, считающий в логическом времени: 01-10-01 где '-' надо заменить на спейсер 00 или 11, в зависимости от типа защелки. Ну и добавить индикацию окончания переходных процессов в автомате. Вот и все. Просто по кирпичикам (базируясь на теореме Маллера о соединении полумодулярных схем - если правильно помню название) построили автомат. Который можно наращивать как угодно с помощью перекрестного преобразования из обычных не-самосинхронных логических схем. Чем и хорош GALA-подход, он получился более технологичным, поскольку можно писать на языках высокого уровня типа верилога, и использовать современные синтезаторы. Жаль, что это все уже (или пока еще?) не актуально.
Удивился на цитату. Ну что же, тогда вот и мои три копейки. Не критика, а просто в дополнение.
По совпадению, примерно с месяц назад откопал свою старую макетку STM32F4 DISCOVERY и решил оживить. Последний раз я что то кодил для мк более 10 лет назад, и тогда же последний раз писал на Си, т.е. забыл почти все по этой теме. Но, мне было очень интересно как LLM может помочь в эмбиддерстве. Что я сделал:
- спросил чатгпт, какой софт ставить. Был дан ответ, ставить STM CubeMX и CubeIDE. Поставил, запустил.
- спросил чатгпт, как сгенерить профиль в CubeMX для проекта VirtualCom port для моей платы. Не сразу, но по наводящим вопросам удалось пробиться через конфиги и сгенерить проект. Т.е. все изложенное в этой публикации я проделал под четким руководством чатагпт буквально минут за 15, без чтения документации/гайдов, и вообще не включая мозг (гордиться нечем, знаю, но сам факт).
- попросил чатгпт сгенерить мне код для VirtualCom port, включая небольшой обработчик команд / эмуляцию консоли. Заработало почти сразу: Я копипастил код в IDE, запускал, ошибки копипастил обратно в чатгпт, и следовал его указаниям. После нескольких таких итераций все заработало.
- потом еще спросил чатгпт от файн-тюнить код для максимальной пропускной способности виртуального компорта. Ну и заодно спросил хороший терминал для винды, чтобы все это погонять в железе.
Что я хочу сказать. У меня несколько знакомых программистов сейчас сидят без работы. Компании сокращают штат в пользу LLM, отсюда массовые увольнения. Похоже, это скоро коснется и эмбиддеров. А там и до меня доберутся. Но! Есть и плюсы. Для хоббистов теперь открыты все возможности, порог вхождения опустился ниже плинтуса.
Для больших корпораций типа фаанг это хороший способ посадить инженеров на крючок еще глубже, чем раньше.
Поясню. Если раньше в виде морковки выдавали рсу с приличной суммой вестинга на ближайшие нцать лет, то теперь достаточно дать в "кредит" 100к на визу, с последующим списанием в течении этих же н-цати лет, и конечно же угрозой отобрать все обратно в случае увольнения. Еще большая кабала, одним словом. Возможно, фаангами и пролоббированная. А индусы как ехали так и едут, куда им еще деваться
Добавлю еще что это так же и шикарный фильтр отсеивать инженеров без паровоза в виде семьи. Хорошая такая циничная гребенка
И снова хочу заметить, что говоря об имплементации, нужно учитывать и особенности базиса элементов. Если базис - т.н. 'россыпуха', отдельные корпуса (ЭСЛ, БТ и т.д.), то очень сложно будет найти элементы с числом входов больше 4-5, а если говорить об интегральных схемах (ASIC, т.е. фактически КМОП), то проблема ровно та же, поскольку элементы с большим числом входов очень медленные (в разы и даже на порядки, в зависимости от числа входов). И получается что изложенный подход (составление функций сброса и установки RS защелки) работает только на бумаге. Как только мы переходим в 3-4 входовой базис элементов, картинка становится непрезентабельной. А если отталкиваться от имплементации, то окажется - выскажу частное мнение -, что самыми компактными (по числу транзисторов) будут схемы на С-элементах, а не RS триггерах. Даже при том, что на практике, для интегрального исполнения, реально спроектировать только 2-х и 3х входовые С-элементы, а большее число входов получать уже их каскадированием.
Ну или не говорить об имплементации вообще. Тогда это материал для математиков, а не электронщиков.
Не воспринимайте вышесказанное как критику, просто мнение инженера-практика, который микросхемы (обычные, не асинхронные) проектирует каждый день.
Можно еще добавить, что наиболее хорошо эта тема изложена в статьях Мараховского (и самых поздних - Варшавского), где они называют этот процесс синхронизацией (обработки данных) в логическом времени (при этом асинхронно - в физическом времени), и в противовес pipeline (волновая обработка информации - по Варшавскому) приводят альтернативу - параллельную синхронизацию (так же обработки данных, и так же в логическом времени, но асинхронно - в физическом). Более того, производится выделение в отдельные категории схем управления (материал данной статьи, в частности), и автоматов обработки информации - которыми собственно и надо управлять. Мухи отдельно от котлет т.с.
Другими словами, поздние публикации Мараховского излагают данный материал более глубоко, шире, и понятнее, на мой взгляд. Такое вот частное мнение
Картинки из патентов, а патенты на то и патенты, чтобы защищать изобретение, а понимание наоборот усложнить.
Это схемы времен СССР, общепринятых правил рисования схем тогда либо не было, либо они сильно отличались от современных. Взять хотя бы аналоговые схемы времен СССР, где земля и питание рисовались не как рейлы внизу-вверху соотв., а могли быть где угодно, как угодно, равно как и транзисторы поворачивали как бог на душу положит. В общем, остается только понять и простить (сначала простить, а потом попытаться понять).
Очень важно уточнять, в каком базисе выполнены эти три инвертора. Потому что схема на КМОП и биполярных транзисторах практически нежизнеспособна из-за паразитной обратной связи между входом и выходом инвертора. Можно добавить линию задержки (RC в общем случае), либо использовать 5 инверторов - так будет работать стабильно.
На мой взгляд, практическое применение - основная проблема всей теории самосинхронных (основанных на решетках) схем. Последние разработки пришлись на развал СССР, а все что было позже, так и не пошло в мейн стрим. Наука ради науки мало интересна. Да и нового, после ГАЛА ничего не появилось, теория выглядит законченной. Наверное по этим причинам никто в мире больше и не занимается самосинхронными схемами. Нет ниши.
Первый раз увидел доказательство через "штаны", и через векторное отображение. Немного напрягшись, понял оба. Мое мнение, как не-математика, а инженера: оба доказательства сложны для понимания. Не помню, как это объясняли в моей, еще советской, школе, но сейчас доказательство через квадраты видится мне наиболее простым/понятным.
Все зависит от жизненного опыта и привычек, одному кажется простым одно, другому другое. Гуманитарий может быть будет в восторге от штанов, инженер тяготеет к квадратам, а математик тащится от векторов. Привычные (и потому наиболее удобные) пути искать объяснения, у всех разные.
Не очень понятно, на каком питании меряется архитектурная скорость на гигагерц. Если указанный ТТ 1В, то это очень много для указанной технологии, должно быть где то 0.8-0.85, а все что выше будет слишком горячим/потребляющим. Этот ТТ - уже разгон, фактически.
И еще я полагаю что 0.72В это низ работы SRAM, т.е. дизайн еще не пытались перевести на разные питания и домены. И DFT там наверное нет, т.е. сделано максимально облегченно и быстро, чисто для бенчмарка. В реальном же чипе все эти режимы питания и тестирования будут, и получится медленнее.
С другой стороны, судя по картинке лейаута, он сильно оценочный, так что и частоты могут быть больше. Все же 1.35 в 0.72 это не много.
Итого, в целом, новость впечатляет, но низкие частоты и нереалистичный ТТ - есть над чем поработать.
Патентный анализ очень слабенький, не упомянуты известные американские стартапы и их связь с российским патентом 15 года. Честно говоря вообще не понятно, зачем была сделана эта публикация
Отвечу, господин хамло. Архитектура (схема тактирвоания, сброса, дфт, иерархия блоков, границы доменов питания и т.д.) как правило меняется на первых этапах физического проектирования - в целях именно физического проектирования. Если нужно, то возвращаются к самому началу. Даже интерфейсы могут меняться в зависимости от расположения в чипе: если надо, к примеру, пробросить сквозной интерфейс между ближайшими соседями.
Пункты 9 (плис) и 11 (эсик) должны быть форками, а не последовательностью. Причем в этом форке приоритет на запросы по оптимизации и архитектурным изменениям должен быть у эсика, а не плис.
Тут надо добавить, что пройти указанный путь - явление редкое. Есть куда более простые способы подняться, но они больше подходят для имеющих нужных родственников, либо ж#полизов и карьеристов, и как показывает практика эти категории намного более многочисленные, чем те кто идет путем саморазвития. Я не говорю что это хорошо, это очень плохо. Но в текущих российский реалиях это данность, с которой приходится считаться.
Ну, как сказать, ничего не значит? Вспомнить тот же Арпэ: организация, высосанная из пальца одним человеком, усиленно самопиарилась и зазывала к себе руководителей организации, поднялась, и начала рубить деньги. Возможно, и у Горшенина получится просамопиариться до подобной прокладки между государством и бизнесом. Главное, убедить всех что ты нужен. Это почти как профсоюз, единожды наступив в него, потом не отмоешься
Должны быть GDS файлы. Очень любопытно, как их получали для ддр5 и рокчипа; такие микроскопы еще поискать надо (рокчип это 8нм, к примеру), еще и число слоев там за десяток. Итого, есть основания считать, что в регистрации топологии лежит фейк.
Не понятно, как генерация айпи соотносится с проектированием микросхем, это как сравнить теплое с мягким.
Но идея генерации кода вычислительных айпи, с оптимизацией инструкций, перфоманса, и если еще и компилятор на выходе будет - это очень круто. Правда сокрее всего тут речь об архитектуре фон-неймана, так что ничего существенно прорывного все равно не получится, просто конструктор под частные задачи