Кстати это хороший пример преимуществ chisel/spinal. На самом деле ускорение в разработке на них достигается не при первичной разработке дизайна, а при его доработке и модификации. Когда трудоёмкость модификации стандартного sv кода большая по сравнению с проектированием изменений.
Моё глубокое убеждение, что это хороший инструмент для повышения производительности разработчиков, которые хорошо умеют проектировать и писать rtl. Когда возможности systemverilog уже ограничивают их возможности.
Но для начинающих разработчиков или тех кто переходит из мира разработки ПО это пленительный но отравленный "плод". Когда есть все возможности языков программирования, но нет понимания rtl-проектирования. И результат вроде бы есть, но скорость разработки невысокая из-за множества ошибок и результат так себе по характеристикам.
Вы не правы. Вы путаете верификационное окружение и модель. Согласен для описания моделей все что нужно в chisel как dsl на scala есть. А если рассмотреть требования к покрытию тестами rtl то тут возможностей а самое главное интеграции с инструментами симуляции у chisel нет.
Чтобы написать тоже окружение в концепции Constraint Random Verification возможностей сейчас нет.
Разные исследовательские работы, сделанные разными командами через MPW запуски есть. И в МИЭТе и в других Вузах. Не могу говорить кто, что и для чего делает. Но есть самые разные прототипы цифровых и СВЧ микросхем. Через год сможем рассказать про NPU для микроконтроллеров с Edge AI, который проектируется не в рамках учебного процесса а в рамках исследований своей университетской команды. Но пока анонсировать результаты рано.
Конечно же относительно большая, потому под более сложные техпроцессы предусматривается командная разработка. А вот под нормы от 350 до 1500 нм это вполне можно сделать большому количеству студентов. Университетский MPW запуск финансирует МинОбр и МинПром. Все что просят с участников это публикация статей и РИДов.
Сейчас у нас ( в МИЭТ) есть план факультатива для бакалавров, на котором они свои курсовые работы смогут адаптировать под конкретный техпроцесс от 350 до 1500 нм. У каждого будет свой чип пройдя "кастомный" маршрут проектирования. Пока основная сложность не в стоимости таких запусков и их сложности а в повышенной нагрузке на преподавателей.
Видимо вы не уловили мысль. Сейчас OpenLane существенно хуже по качеству результата чем коммерческие тулы. При ограниченных технологических возможностях жертвовать конечными характеристиками сейчас не имеет смысла. Проигрыш по частоте в два раза и в площади ставит крест на любом использовании за исключением образовательного.
Ниже в комментарии привел скрин сравнения тулов который показывает разницу при использовании одинакового дизайна и одинаковых PDK. И да частота и площадь зависят от качества инструментария тоже иначе зачем большая тройка компаний выпускает новые версии тулов. Поищите публикации про сравнение эффективности OpenLane и увидите разницу.
А еще например эффектность тулов зависит от логической сложности дизайна. Конечно если запустить пример с одним счетчиком то разницы почти не будет. И при увеличении количества гейтов в дизайне OpenLane начинает проигрывать все сильнее.
Да, конечно нет желания ни у минфина ни у налоговой ни у минпрома и т.д. И потому к сожалению невозможно.
Первое, с нашим законодательством и подходом к выделению средств на ниокр финансировать все как opensource невозможно. И тогда не понятно кому преднадлежит результат и как финансировать команды разрабочиков. И развитие openlane это задачка не для пары аспирантов.
Второе, OpenLane ещё предстоит долгий путь даже на нодах 90-180 нм не говоря о 28 нм и представьте что вы предлагаете делать микроконтроллер с помощью него например Байкалу. Частота в два раза ниже а площадь больше.
Нет, официально PDK/ DDK Микрона поддерживает только коммерческие САПР. Можно попробовать пройти часть маршрута проектирования в открытых инструментах, в которых используются форматы данных совместимые с коммерческими - например Liberty/LEF/DEF. Но RCX/DRC/LVS этапы придется делать в коммерческих тулах, либо пытаться самому переписать правила на совместимые с OpenLane, но для производства в итоге все равно нужен чистый DRC отчет на коммерческом софте. Вся информация о PDK предоставляется зарегистрированным участникам от ВУЗов из-за NDA фабрик.
Тогда за чем вообще строить три фабрики в Аризоне если они не будут экономически оправданы и отстают по нанометрам? Зачем расширять производство в Америке? Разве не для страховки от утраты критических технологий/производств? Или если это экономически не оправдано сейчас, то мб тогда не надо это делать?
Согласен с вами. Ведь если посмотреть не на один пункт из спецификации SystemVerilog окажется что в ней есть две части. Синтезируемое и не синтезируемое подмножество. Одно для реализации цифровых схем, другое для использования в симуляции. И конечно синтезируемое подмножество поддерживается симуляторами, но синтезатор не поддерживает преобразование несинтезируемого подмножества в цифровую логику. И получается что есть HDL-инженеры которые в первую очередь пишут код на SV для реализации конкретного дизайна. А с другой есть верификаторы где конечно используются и классы и программные модели. И действительно верификационное окружение можно считать программным продуктом которое проверяет соответствие дизайна спецификации. Даже вот есть, например cocotb использующий python, более доступная вариация инструмента для верификации вместо SV. Но еще с кучей ограничений и более медленный! И если программист перейдет в разработку цифровой электроники ему легче стать верификатором и делать эффективные верификационные решения, чем проектировать и писать дизайн который пойдет в чипы.
Ну раз они работу и найм ведут значит план есть. Но по понятным причинам раскрывать его не будут. И конечно наличие плана не гарантия успеха особенно в таких условиях.
Байкал Электроникс и сейчас занимается проектированием. А после Байкал-T1 у них были Baikal-M в 2019(первая версия), серверный Baikal-S в 2021 году. Не похоже что там никаких разработок там уже нет и не будет.
По поводу пункта 3 - цель работы проверить два метода управления EUV для безмасочной литографии. Поисковый НИР. Один похож на идею Mapper. Микромеханическая матрица с множеством отверстий и створками. Пиксельная матрица. Только вместо пучка электронов EUV. Второй, аналог матрицы для проекторов с совокупностью отклоняемых микромеханических зеркал. Конечно непонятна пока что реализуемость в виде конечного устройства, множество трудностей надо преодолеть. Например, повышение отражения EUV от микромеханических зеркал и т.д. Но путь осилит идущий. https://www.zelenograd.ru/hitech/v-miete-razrabotayut-koncepciyu-bezmasochnogo-fotolitografa-dlya-vypuska-mikroshem/
Тут специально оптимизировали время. Например, в RTL треке верификация изменений процессора в CI занимала от 3 до 10 минут. В зависимости от того найдены ли ошибки. Получение Coremark в симуляции и результатов STA после синтеза в сумме примерно минут 15-25.
Отличная история! Согласен такое тоже может быть.
Кстати это хороший пример преимуществ chisel/spinal. На самом деле ускорение в разработке на них достигается не при первичной разработке дизайна, а при его доработке и модификации. Когда трудоёмкость модификации стандартного sv кода большая по сравнению с проектированием изменений.
Моё глубокое убеждение, что это хороший инструмент для повышения производительности разработчиков, которые хорошо умеют проектировать и писать rtl. Когда возможности systemverilog уже ограничивают их возможности.
Но для начинающих разработчиков или тех кто переходит из мира разработки ПО это пленительный но отравленный "плод". Когда есть все возможности языков программирования, но нет понимания rtl-проектирования. И результат вроде бы есть, но скорость разработки невысокая из-за множества ошибок и результат так себе по характеристикам.
Вы не правы. Вы путаете верификационное окружение и модель. Согласен для описания моделей все что нужно в chisel как dsl на scala есть. А если рассмотреть требования к покрытию тестами rtl то тут возможностей а самое главное интеграции с инструментами симуляции у chisel нет.
Чтобы написать тоже окружение в концепции Constraint Random Verification возможностей сейчас нет.
не могу говорить, NDA ((
Разные исследовательские работы, сделанные разными командами через MPW запуски есть. И в МИЭТе и в других Вузах. Не могу говорить кто, что и для чего делает. Но есть самые разные прототипы цифровых и СВЧ микросхем.
Через год сможем рассказать про NPU для микроконтроллеров с Edge AI, который проектируется не в рамках учебного процесса а в рамках исследований своей университетской команды. Но пока анонсировать результаты рано.
Конечно же относительно большая, потому под более сложные техпроцессы предусматривается командная разработка. А вот под нормы от 350 до 1500 нм это вполне можно сделать большому количеству студентов. Университетский MPW запуск финансирует МинОбр и МинПром. Все что просят с участников это публикация статей и РИДов.
Сейчас у нас ( в МИЭТ) есть план факультатива для бакалавров, на котором они свои курсовые работы смогут адаптировать под конкретный техпроцесс от 350 до 1500 нм. У каждого будет свой чип пройдя "кастомный" маршрут проектирования. Пока основная сложность не в стоимости таких запусков и их сложности а в повышенной нагрузке на преподавателей.
Видимо вы не уловили мысль. Сейчас OpenLane существенно хуже по качеству результата чем коммерческие тулы. При ограниченных технологических возможностях жертвовать конечными характеристиками сейчас не имеет смысла. Проигрыш по частоте в два раза и в площади ставит крест на любом использовании за исключением образовательного.
Ниже в комментарии привел скрин сравнения тулов который показывает разницу при использовании одинакового дизайна и одинаковых PDK. И да частота и площадь зависят от качества инструментария тоже иначе зачем большая тройка компаний выпускает новые версии тулов. Поищите публикации про сравнение эффективности OpenLane и увидите разницу.
А еще например эффектность тулов зависит от логической сложности дизайна. Конечно если запустить пример с одним счетчиком то разницы почти не будет. И при увеличении количества гейтов в дизайне OpenLane начинает проигрывать все сильнее.
Да, конечно нет желания ни у минфина ни у налоговой ни у минпрома и т.д. И потому к сожалению невозможно.
Первое, с нашим законодательством и подходом к выделению средств на ниокр финансировать все как opensource невозможно. И тогда не понятно кому преднадлежит результат и как финансировать команды разрабочиков. И развитие openlane это задачка не для пары аспирантов.
Второе, OpenLane ещё предстоит долгий путь даже на нодах 90-180 нм не говоря о 28 нм и представьте что вы предлагаете делать микроконтроллер с помощью него например Байкалу. Частота в два раза ниже а площадь больше.
Нет, официально PDK/ DDK Микрона поддерживает только коммерческие САПР. Можно попробовать пройти часть маршрута проектирования в открытых инструментах, в которых используются форматы данных совместимые с коммерческими - например Liberty/LEF/DEF. Но RCX/DRC/LVS этапы придется делать в коммерческих тулах, либо пытаться самому переписать правила на совместимые с OpenLane, но для производства в итоге все равно нужен чистый DRC отчет на коммерческом софте.
Вся информация о PDK предоставляется зарегистрированным участникам от ВУЗов из-за NDA фабрик.
Тогда за чем вообще строить три фабрики в Аризоне если они не будут экономически оправданы и отстают по нанометрам? Зачем расширять производство в Америке? Разве не для страховки от утраты критических технологий/производств?
Или если это экономически не оправдано сейчас, то мб тогда не надо это делать?
Согласен с вами. Ведь если посмотреть не на один пункт из спецификации SystemVerilog окажется что в ней есть две части. Синтезируемое и не синтезируемое подмножество. Одно для реализации цифровых схем, другое для использования в симуляции. И конечно синтезируемое подмножество поддерживается симуляторами, но синтезатор не поддерживает преобразование несинтезируемого подмножества в цифровую логику.
И получается что есть HDL-инженеры которые в первую очередь пишут код на SV для реализации конкретного дизайна. А с другой есть верификаторы где конечно используются и классы и программные модели. И действительно верификационное окружение можно считать программным продуктом которое проверяет соответствие дизайна спецификации. Даже вот есть, например cocotb использующий python, более доступная вариация инструмента для верификации вместо SV. Но еще с кучей ограничений и более медленный!
И если программист перейдет в разработку цифровой электроники ему легче стать верификатором и делать эффективные верификационные решения, чем проектировать и писать дизайн который пойдет в чипы.
Ну раз они работу и найм ведут значит план есть. Но по понятным причинам раскрывать его не будут. И конечно наличие плана не гарантия успеха особенно в таких условиях.
Не лярды а миллионы. И не взыскали. https://habr.com/ru/news/675904/
Новости с МЦСТ от февраля 22 года связаны остановкой производства. https://habr.com/ru/news/653727/
А про разработку тут говорить нечего раз публичных пруфов невозможно привести.
Байкал Электроникс и сейчас занимается проектированием. А после Байкал-T1 у них были Baikal-M в 2019(первая версия), серверный Baikal-S в 2021 году.
Не похоже что там никаких разработок там уже нет и не будет.
Если Володя под санкциями из-за Яндекса. Тогда почему сам Яндекс не под санкциями? Раз дело в нем. Санкции на Воложа наложили в июне если не ошибаюсь.
Часть спецификации выложена в открытом виде
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
По поводу пункта 3 - цель работы проверить два метода управления EUV для безмасочной литографии. Поисковый НИР.
Один похож на идею Mapper. Микромеханическая матрица с множеством отверстий и створками. Пиксельная матрица. Только вместо пучка электронов EUV.
Второй, аналог матрицы для проекторов с совокупностью отклоняемых микромеханических зеркал.
Конечно непонятна пока что реализуемость в виде конечного устройства, множество трудностей надо преодолеть. Например, повышение отражения EUV от микромеханических зеркал и т.д. Но путь осилит идущий.
https://www.zelenograd.ru/hitech/v-miete-razrabotayut-koncepciyu-bezmasochnogo-fotolitografa-dlya-vypuska-mikroshem/
Тут специально оптимизировали время. Например, в RTL треке верификация изменений процессора в CI занимала от 3 до 10 минут. В зависимости от того найдены ли ошибки. Получение Coremark в симуляции и результатов STA после синтеза в сумме примерно минут 15-25.