При этом мегабит в секунду всегда было 10^6 бит в секунду (во всех спеках на сетевое оборудование). Почему так - хз, провайдеры не при чем.
Рассмотрим старый добрый Fast Ethernet (который 100 Mbps). PHY подключается к MAC c использованием MII-интерфейса. Для скорости 100 Mbps данные толкаются нибблами (по 4 бита) с частотой 25 МГц. Вот и получается что максимум что вы можете протолкать в секунду - 4*25e6 == 100e6 бит в секунду. То что там Fast Ethernet PHY использует кодирование 8b/10b, модуляцию MLT-3 и фактически внутри "качегарит" 125 МГц - это уже другая история.
Если вдруг кому интересно про "обходные варианты", речь про то, что обычно называют "Single-poly Flash". При желании можно найти профильные статьи по теме. Например, https://ieeexplore.ieee.org/document/6918412
Нет, не таким же. Между IP-блоком Flash и условным UART разница кардинальная.
Первый интегрируется исключительно на фабрике (этот процесс чаще всего называется "IP Merge"). При этом свой блок Flash вы разработать не можете, в PDK вам банально не доступны необходимые слои для формирования плавающего затвора.
А условный UART синтезируется на базе библиотеки стандартных цифровых ячеек самим потребителем IP из RTL. Если UART поставляется в незакодированном виде, то его даже можно подправить под свои нужды (если лицензия это не запрещает).
Вот RTL цифрового контроллера обёрнутого вокруг этого IP блока, как правило, уже разрабатывается самостоятельно. Условно говоря, если вы хотите Flash с QSPI интерфейсом, то вот эту обёртку реализующую QSPI вы пишите сами, ну и синтезируете сами. Ещё вам понадобится пачка дополнительных блоков, типа PoR, RC-генератора и прочего.
Т.е. разработать свою микросхему Flash с выбранным интерфейсом вы всё же можете, это тоже вполне себе полноценная и достаточно сложная разработка.
Разработать вы не можете именно современный IP блок Flash памяти. Есть обходные варианты нагородить блок Flash на General Purpose CMOS процессе, но такие поделки медленные и с кучей проблем.
Вот прям совсем просто это не сделать. Нужно будет изготавливать отдельный набор фотошаблонов с новым лейблом. В простейшем случае, когда был Single Mask запуск и лейбл был сделан только в одном металле можно обойтись заменой всего одного "стекла". Но всё равно, для этого нужно иметь исходный gds и, насколько я понимаю, такое может сделать в рамках металлокоррекции только оригинальный разработчик. Нельзя будет туда-сюда произвольно менять набор стёкол, в производстве они используются комплектом.
Если у вас почти полностью цифровой дизайн, то при наличии полного RTL - переход на другую фабрику относительно тривиальный процесс. Ну т.е. поменяли обёртки вокруг Flash, блоков памяти, падов, меняете в настройках тулов RTL2GDS пути к стандартным цифровым библиотекам и погнали. Таким образом можно получить относительно быстро полностью совместимый со старым дизайн на уровне софта и пинов, но на другой фабрике. Вот перенос аналоговых блоков/дизайнов - это уже более сложное приключение. Если кратко, то если у вас есть исходники дизайна, то перенос на другую фабрику принципиально возможен за какое-то обозримое время. Естественно, с некоторыми ощутимыми трудозатратами. Но вот если у вас этого нет - то воспроизвести дизайн "один в один" с функциональной точки зрения имея только даташит - практически невыполнимая задача.
Кадры и компетенции. Большинство топовых разработчиков микроэлектроники в мире - это fabless. AMD печёт свои чипы на TSMC, даже Intel начал печь свои чипы на TSMC. Если у нас будут просто делать перемаркировку зарубежных чипов - то откуда взяться инженерам способным что-то разработать.
Блок Flash - это очень закрытая история. Даже не у всех фабрик доступен компилятор Flash, у некоторых доступны только фиксированные конфигурации в виде HardMacro. Простым смертным (то бишь разработчиком конечных чипов) даже не дают доступ к слоям, которые необходимы для разработки блока Flash. Т.е. нет возможности самим нарисовать топологию структуры с плавающим затвором. У российских фабрик с Non Volatile Memory всё плохо, а с Flash вообще полный швах - ни у кого нет. Поэтому выпустить современный микроконтроллер на условном Микроне нельзя. У них доступен только маленький EEPROM. А вот контроллер, обёрнутый вокруг этой Flash - это каждый уже делает сам как может.
Периферия, как правило, 50/50. Контроллеры вокруг аналоговых блоков почти всегда свои. Высокоскоростные интерфейсы типа PCIe, DDR и т.п., ммм..., я бы сказал с большой долей вероятности покупные. Тут проблема, в том что они стыкуются с достаточно сложными блоками PHY. Мелкая периферия (UART, SPI, CAN), так как её относительно просто разработать самостоятельно - может быть как своя, так и покупная. Даже такая простая, на первый взгляд, периферия требует трудозатрат на верификацию.
Interconnect/Crossbar, как правило либо самописные, либо генерируются специальными доморощенными тулами.
Вряд ли в таком корпусе его кто-то будет применять в счётчиках. У Миландра находится внешний сигма-дельта АЦП в пластике: https://www.milandr.com/ic/42635/
Это я всё видел. Мне интересно что там в реальности.
Ну вот смотрите, таблица 2.4. Пункт 19 (почему-то без номера): SAR ADC INL+-3 LSB Пункт 20: SAR ADC DNL: +-2 LSB
При таком DNL там должны быть выпадающие коды, это достаточно посредственные параметры. При том эти параметры получены на номинальном питании 3.3В и при низкой частоте преобразования (fs = 250 kHz). Но правда это в диапазоне температур от -40 до +85 градусов Цельсия.
Смотрим дальше. Пункт 21 (опять без номера). SINAD (Signal-to-noise and distortion ratio) 60 dB. Из этого параметра можно легко высчитать эффективную разрядность (ENOB, Effective Number of Bits). ENOB = (SINAD - 1.76) / 6.02 = (60 - 1.76) / 6.02 = 9.67 bit Это, на самом деле, не плохо. Но в таблице указано что частота преобразования fs = 1 MHz, но при этом не указана частота входного сигнала на которой это было получено.
Offset Error, Gain Error я там не вижу, механизма для калибровки оффсета тоже не вижу (может просто проморгал).
Ладно, для SAR мы что-то нашли. Ткните меня, пожалуйста, в параметры сигма-дельта АЦП. Что-то я их не вижу.
То что пишут большие допустимые ошибки INL, DNL - это понятно. Это делают для того чтобы увеличить выгод годных.
Но вот для счётчика электроэнергии нужны хорошие метрологические свойства, которые обеспечиваются в первую очередь АЦП.
В итоге: для SAR АЦП указано три параметра, да и те посредственные, для сигма-дельта параметров нет вообще.
Вот поэтому мне очень хотелось бы посмотреть что там в реальности, есть подозрения что контроллер от НИИЭТ не позволит обеспечить нужный класс точности.
Там по ряду решений и по списку ошибок сразу чувствуется что чип разрабатывался в России. Вот характеристики встроенного АЦП посмотреть интересно было бы, это да.
Покопавшись в коде я обнаружил ошибку в программе SNANDer при инициализации программатора в режиме работы с микросхемами серии 24Сxxx. Потом я нашел еще одну ошибку с порядком следования байт при записи и чтении микросхем MicroWire - 93xxx в 16-битном режиме. Так я понял, что придется писать программу самому.
Плюс вам за то, что отправили Pull Request-ы с обновлением базы данных чипов в SNANDer, но вот обоснование необходимости писать свою программу какое-то слабенькое. То есть в существующем решении проблема была найдена и локализована, было понятно как её поправить. Признайтесь честно, реальная причина "потому что могу", тут никто не осудит %)
Вспоминается книга Д. Канемана "Шум. Несовершенство человеческих суждений". Там как раз рассказывается про то, что настроение судьи из-за погоды или близости времени обеда может влиять на выносимое им суждение.
Я такой же. Следил за игрой и оформил предзаказ Oil Rush именно потому, что они пообещали поддержку Linux. По тем же причинам покупал игрушки в составе Humble Bundle (4 или 5 выпусков). Но должен признаться честно, почти ни во что из купленного я толком не играл. Максимум запускал "на посмотреть" на пару часов %)
Знаете, у меня в такие моменты в голове возникает примерно такая картинка: сидит чиновник в своём кабинете, бьёт себе по лбу лютый facepalm и восклицает: "Ах, так вот зачем была нужна эта куча разнообразных НИИ в СССР, которые мы так старательно банкротили и превращали в ТЦ и бизнес-центры!"
А кто что может вспомнить про OpenRISC?
Ну кроме того что когда-то Cadence на его основе проводил пару тренингов.
Так-то оно вроде пока живое, относительно недавно даже его поддержку в upstream GCC продвинули.
Я в него палочкой потыкал, с помощью FuseSOC собрал битстрим для платы DE0-Nano, запустил mainline Linux 5.1.2 + BusyBox и на этом пока успокоился.
У меня дома лежит пачка старых роутеров и ADSL модемов.
Что-то отличное от Linux встречается очень редко.
Могу вспомнить разве что VxWorks и ZyNOS. Всё-таки ядро Linux — это весьма хороший framework для написания драйверов, плюс там очень много поддерживаемых «плюшек» (сетевых протоколов, алгоритмов шифрования и прочего). А тут важен параметр Time To Market, поэтому в большинстве случаев берут именно его, ибо цена доработки под свою железку минимальна.
А с WinCE и Platform Builder мне пришлось немного пострадать, не могу сказать что мне понравилось.
Рассмотрим старый добрый Fast Ethernet (который 100 Mbps). PHY подключается к MAC c использованием MII-интерфейса.
Для скорости 100 Mbps данные толкаются нибблами (по 4 бита) с частотой 25 МГц. Вот и получается что максимум что вы можете протолкать в секунду - 4*25e6 == 100e6 бит в секунду.
То что там Fast Ethernet PHY использует кодирование 8b/10b, модуляцию MLT-3 и фактически внутри "качегарит" 125 МГц - это уже другая история.
Если вдруг кому интересно про "обходные варианты", речь про то, что обычно называют "Single-poly Flash". При желании можно найти профильные статьи по теме. Например, https://ieeexplore.ieee.org/document/6918412
Нет, не таким же. Между IP-блоком Flash и условным UART разница кардинальная.
Первый интегрируется исключительно на фабрике (этот процесс чаще всего называется "IP Merge"). При этом свой блок Flash вы разработать не можете, в PDK вам банально не доступны необходимые слои для формирования плавающего затвора.
А условный UART синтезируется на базе библиотеки стандартных цифровых ячеек самим потребителем IP из RTL. Если UART поставляется в незакодированном виде, то его даже можно подправить под свои нужды (если лицензия это не запрещает).
Вот RTL цифрового контроллера обёрнутого вокруг этого IP блока, как правило, уже разрабатывается самостоятельно. Условно говоря, если вы хотите Flash с QSPI интерфейсом, то вот эту обёртку реализующую QSPI вы пишите сами, ну и синтезируете сами. Ещё вам понадобится пачка дополнительных блоков, типа PoR, RC-генератора и прочего.
Т.е. разработать свою микросхему Flash с выбранным интерфейсом вы всё же можете, это тоже вполне себе полноценная и достаточно сложная разработка.
Разработать вы не можете именно современный IP блок Flash памяти. Есть обходные варианты нагородить блок Flash на General Purpose CMOS процессе, но такие поделки медленные и с кучей проблем.
Есть ощущение что Вы в теме, можете тогда рассказать что именно занимает такой объём?
Ещё интересно было бы получить комментарии от уважаемого @AlexFTF как человека, судя по статьям и комментариям (например, https://habr.com/ru/articles/526142/comments/#comment_22277382), также занимавшегося данным направлением разработки.
Вот прям совсем просто это не сделать.
Нужно будет изготавливать отдельный набор фотошаблонов с новым лейблом.
В простейшем случае, когда был Single Mask запуск и лейбл был сделан только в одном металле можно обойтись заменой всего одного "стекла".
Но всё равно, для этого нужно иметь исходный gds и, насколько я понимаю, такое может сделать в рамках металлокоррекции только оригинальный разработчик. Нельзя будет туда-сюда произвольно менять набор стёкол, в производстве они используются комплектом.
С вашего позволения, совершу каст разработчика.
CC:@Strijar
В данных рассуждениях есть несколько упущений.
Если у вас почти полностью цифровой дизайн, то при наличии полного RTL - переход на другую фабрику относительно тривиальный процесс.
Ну т.е. поменяли обёртки вокруг Flash, блоков памяти, падов, меняете в настройках тулов RTL2GDS пути к стандартным цифровым библиотекам и погнали.
Таким образом можно получить относительно быстро полностью совместимый со старым дизайн на уровне софта и пинов, но на другой фабрике.
Вот перенос аналоговых блоков/дизайнов - это уже более сложное приключение.
Если кратко, то если у вас есть исходники дизайна, то перенос на другую фабрику принципиально возможен за какое-то обозримое время. Естественно, с некоторыми ощутимыми трудозатратами.
Но вот если у вас этого нет - то воспроизвести дизайн "один в один" с функциональной точки зрения имея только даташит - практически невыполнимая задача.
Кадры и компетенции. Большинство топовых разработчиков микроэлектроники в мире - это fabless. AMD печёт свои чипы на TSMC, даже Intel начал печь свои чипы на TSMC.
Если у нас будут просто делать перемаркировку зарубежных чипов - то откуда взяться инженерам способным что-то разработать.
Как уже писали в комментариях к прошлой статье, что у НИИЭТ, что у Миландр ядро лицензировано у питерксой компании https://cloudbear.ru/
У НИИЭТ BM-310S6 (https://niiet.ru/wp-content/uploads/2025/02/РП-К1921ВГ015_250219.pdf ,раздел 3)
У Миландр тоже BM-310 https://www.milandr.com/ic/42635/
Так что ядро у обоих производителей самое что ни на есть отечественное.
Блок Flash - это очень закрытая история. Даже не у всех фабрик доступен компилятор Flash, у некоторых доступны только фиксированные конфигурации в виде HardMacro.
Простым смертным (то бишь разработчиком конечных чипов) даже не дают доступ к слоям, которые необходимы для разработки блока Flash. Т.е. нет возможности самим нарисовать топологию структуры с плавающим затвором.
У российских фабрик с Non Volatile Memory всё плохо, а с Flash вообще полный швах - ни у кого нет. Поэтому выпустить современный микроконтроллер на условном Микроне нельзя. У них доступен только маленький EEPROM.
А вот контроллер, обёрнутый вокруг этой Flash - это каждый уже делает сам как может.
Периферия, как правило, 50/50. Контроллеры вокруг аналоговых блоков почти всегда свои. Высокоскоростные интерфейсы типа PCIe, DDR и т.п., ммм..., я бы сказал с большой долей вероятности покупные. Тут проблема, в том что они стыкуются с достаточно сложными блоками PHY. Мелкая периферия (UART, SPI, CAN), так как её относительно просто разработать самостоятельно - может быть как своя, так и покупная. Даже такая простая, на первый взгляд, периферия требует трудозатрат на верификацию.
Interconnect/Crossbar, как правило либо самописные, либо генерируются специальными доморощенными тулами.
Разработка микросхем для счётчиков электроэнергии есть у НИИЭТ и ПКК Миландр.
Если говорить про микросхемы конкретно в данной статье, то это сигма-дельта АЦП.
У НИИЭТ с наскоку находится только такой сигма-дельта: https://niiet.ru/product/1273пв19т/
Вряд ли в таком корпусе его кто-то будет применять в счётчиках. У Миландра находится внешний сигма-дельта АЦП в пластике: https://www.milandr.com/ic/42635/
Простите, а что не так?
2999 рублей за 3 чипа, т.е. примерно 1к за 1 чип.
Это я всё видел. Мне интересно что там в реальности.
Ну вот смотрите, таблица 2.4.
Пункт 19 (почему-то без номера): SAR ADC INL+-3 LSB
Пункт 20: SAR ADC DNL: +-2 LSB
При таком DNL там должны быть выпадающие коды, это достаточно посредственные параметры. При том эти параметры получены на номинальном питании 3.3В и при низкой частоте преобразования (fs = 250 kHz). Но правда это в диапазоне температур от -40 до +85 градусов Цельсия.
Смотрим дальше. Пункт 21 (опять без номера). SINAD (Signal-to-noise and distortion ratio) 60 dB. Из этого параметра можно легко высчитать эффективную разрядность (ENOB, Effective Number of Bits). ENOB = (SINAD - 1.76) / 6.02 = (60 - 1.76) / 6.02 = 9.67 bit
Это, на самом деле, не плохо. Но в таблице указано что частота преобразования fs = 1 MHz, но при этом не указана частота входного сигнала на которой это было получено.
Offset Error, Gain Error я там не вижу, механизма для калибровки оффсета тоже не вижу (может просто проморгал).
Ладно, для SAR мы что-то нашли. Ткните меня, пожалуйста, в параметры сигма-дельта АЦП. Что-то я их не вижу.
То что пишут большие допустимые ошибки INL, DNL - это понятно. Это делают для того чтобы увеличить выгод годных.
Но вот для счётчика электроэнергии нужны хорошие метрологические свойства, которые обеспечиваются в первую очередь АЦП.
В итоге: для SAR АЦП указано три параметра, да и те посредственные, для сигма-дельта параметров нет вообще.
Вот поэтому мне очень хотелось бы посмотреть что там в реальности, есть подозрения что контроллер от НИИЭТ не позволит обеспечить нужный класс точности.
Там по ряду решений и по списку ошибок сразу чувствуется что чип разрабатывался в России. Вот характеристики встроенного АЦП посмотреть интересно было бы, это да.
Разработать процессор на котором запускается Linux - это лишь часть проблемы, при том не самая большая.
Почему-то никто не говорит про самое интересное... А что там будет в качестве GPU?
Это последовательное преобразование типов .
1) (long)-1 -> 0xFF..FF
2) + 0xFF..FF -> 0xFF..FF
3) (int) 0xFF..FF -> 0xFF..FF
4) - 0xFF..FF -> 1
5) +(char)1 -> 1
6) (byte)1 -> 1
Т.е. куча унарных операций перемажающихся преобразованием типа. (byte) - (int) - 1 по идее даст тоже самое.
Плюс вам за то, что отправили Pull Request-ы с обновлением базы данных чипов в SNANDer, но вот обоснование необходимости писать свою программу какое-то слабенькое. То есть в существующем решении проблема была найдена и локализована, было понятно как её поправить. Признайтесь честно, реальная причина "потому что могу", тут никто не осудит %)
Вспоминается книга Д. Канемана "Шум. Несовершенство человеческих суждений". Там как раз рассказывается про то, что настроение судьи из-за погоды или близости времени обеда может влиять на выносимое им суждение.
Я такой же. Следил за игрой и оформил предзаказ Oil Rush именно потому, что они пообещали поддержку Linux. По тем же причинам покупал игрушки в составе Humble Bundle (4 или 5 выпусков). Но должен признаться честно, почти ни во что из купленного я толком не играл. Максимум запускал "на посмотреть" на пару часов %)
Знаете, у меня в такие моменты в голове возникает примерно такая картинка: сидит чиновник в своём кабинете, бьёт себе по лбу лютый facepalm и восклицает: "Ах, так вот зачем была нужна эта куча разнообразных НИИ в СССР, которые мы так старательно банкротили и превращали в ТЦ и бизнес-центры!"
Ну кроме того что когда-то Cadence на его основе проводил пару тренингов.
Так-то оно вроде пока живое, относительно недавно даже его поддержку в upstream GCC продвинули.
Я в него палочкой потыкал, с помощью FuseSOC собрал битстрим для платы DE0-Nano, запустил mainline Linux 5.1.2 + BusyBox и на этом пока успокоился.
Что-то отличное от Linux встречается очень редко.
Могу вспомнить разве что VxWorks и ZyNOS. Всё-таки ядро Linux — это весьма хороший framework для написания драйверов, плюс там очень много поддерживаемых «плюшек» (сетевых протоколов, алгоритмов шифрования и прочего). А тут важен параметр Time To Market, поэтому в большинстве случаев берут именно его, ибо цена доработки под свою железку минимальна.
А с WinCE и Platform Builder мне пришлось немного пострадать, не могу сказать что мне понравилось.