ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
28 марта
653905
Evgeny_CD, Архитектор (18.02.2016 21:49, просмотров: 21656)
С подачи LightElf, о грядущей ARMv8-M ->, которая последует за Cortex-M7 http://caxapa.ru/651863.html
http://caxapa.ru/653870.html
Заточка под "безFLASH" архитектуру и "библиотека - наше фсе. Любопытное поделие. Опять же, люди читали мои посты :) 1. как мы знаем, к 2020 году ожидаeтся пришествие 28 нм в мир embedded. --> 2. Почему так долго? Дык NOR FLASH пока для этого техпроцесса нет. И непонятно, когда будет. И сколько будет стоить его разработка - тоже вопрос. Кстати, для простых контроллеров 28 нм не окупится - будет кристалл вместо 1 кв. мм. 0.5 кв. мм. - как его паковать-то? 3. Т.е. при наличии 45 нм NOR FLASH его можно использовать и по 28 нм - просто сделать ячейки большого размера [мое ламерское предположение]. Если FLASH EEPROM надо мало - можно так и поступить. И не тратить миллиарды на рисеч 28 нм NOR. 4. 28нм NOR. А что есть? SRAM. Его там как грязи. 8Мбайт на кристалле, 16 Мбайт на кристалле - нет проблем. Или 1М кеша L2 (за счет асоциативности транзюков в нем много), что полезнее. 5. Что важно в RT? Важно быстро обрабатывать критические процедуры. Но код и данные критических процедур едва ли будут более 1 Мбайта. Ок, ставим на кристалле 1М SRAM для "критики". 6. А чего может быть много? SDRAM!!! 512мбайт DDR3 1 чипом сейчас стоят недорого. И пинов в варианте x8 займут мало. 7. Тонкий техпроцесс позволит напихать в кристалл дофига всего. И оно будет хорошее. Только полная дока, вероятно, будет 10к страниц (ага, и 1к страниц errata) как минимум. 8. Что делает освоение камня небольшой фирмой в рамках конкретного проекта невозможным. От слова совсем. 9. Много ОЗУ, где перемешаны код и данные - источник большого гемороя. MPU нового поколения обещает нас избавить от этого. И оно есть! 10. MMU нет, и я не понимаю, почему! Это шанс для PIC32MZ! http://caxapa.ru/652792.html 11. Что надо, чтобы чудо камень нового поколения хорошо продавался? Долбаный Time To Market. 10к страниц против, но готовая либа - за! Что для нее надо? TrustZone!!! Conceptually TrustZone for ARMv8-M is similar to the TrustZone technology found in ARM Cortex-A Processors. The underlying operations of TrustZone for ARMv8-M are however very different as they are optimized for embedded systems that requires real-time responsiveness, whilst at the same time allowing for high energy efficiency and low silicon area overhead. Там очень дофига накручено в части взаимодействия секурного и несекурного кода - чтобы одно из другого вызывать без проблем. А TrustZone не даст слазить куда не надо "изнутри" камня. 12. 28 нм позволит сделать стойкую криптографию на SDRAM в RT. С индивидуальным ключем, прошитым на заводе в набортный EEPROM. 13. Секурный boot loader тоже влезет в набортный FLASH - там скорость и объем не важны. 14. Будет 28 нм быстрый NOR FLASH (кеш не спасет, если устоявшаяся производительность памяти будет в десятки раз ниже скорости хавания данных и кода ядром) - хорошо, нет - и без него проживем. 15. Не забыввем про 4$ (при 4-х нехилых ярах по >= 1Ггц тактовой) алвиннеры и прочая от китайцев, что показывает, что 28 нм могут быть дешевы. Если не страдать херней и не рисечить ненужное. http://caxapa.ru/651650.html Только, как мы знаем, все эти "китайцы" - это нихера не решение для embedded мира. Я имею в виду профессиональные решения, а не игрушки пионеров. 16. Итоговый облик такой: * 28 нм чудо камень с 1M кеша L2, 1-2М SRAM, DDR3-4 контроллером на борту, небольшими EEPROM и FLASH * внешний DDR3-4 чип. Разводку камня оптимизируем, чтобы протянуть линии к чипу "1 в 1" без проблем в одном слое. 4-х слойный дизайн целевого устройства даже сейчас совсем не проблема. * мегалиба, которая решает проблему TTM и навсегда привязывает юзера к производителю. API Win, Mac и Lin открыты, только писать код, совместимый со всеми платформами без эпических прослоек (VM, адовы нагромождения С++ типа Qt) никому не удается. * JS и прочие рюшечки - по желанию, будет куда мощу ядра девать. С другой стороны, управляющая часть верхнего уровня на удобном скриптовом языке - мечта почти любого проекта, а здесь они будут жить успешно вместе на одном кристалле. * камень и SDRAM уложить на одну подложку - 9.5 лет назад я назвал это дримбордой... http://caxapa.ru/65085.html http://caxapa.ru/65177.html О... какой тонкий намек на 9.5. 17. Вот почему все так кинулись тренироваться в "Синергиях". Выращивание библиотеки-монстра - это процесс долгий и нудный. Надо запускать кроликов тестировать, что есть сейчас. Кролики, ау, вот вам сладкая морковка http://caxapa.ru/649610.html 18. Ну почему аборигены съели Кука? Почему нет MMU? Да потому, что это был бы конец истории. Для ARM. Лицензировав такое суперядро, производитель чипов мог бы делать почти все - и чипы для сотиков, и для embeded рынка. Число лицензий сократилось бы, ARM ушел бы в небытие. Я немного утрирую - там, кроме MMU, есть много защит - шины AXI не увидел, что с многоядерными конфигурациями непонятно, да и по производительности это ядро почти наверняка будет уступать 64 битным Cortex-A5* A7*. Но... Но... Разработка мегалибы - это очень дорого для производителя конечного решения. И большой код в варианте без MMU и с MMU - это две большие разницы. В целом, ARM хочет сохранить все виды embedded как отдельную экосистему, которая никогда бы не слилась с миром сотиков. У ARMа перед глазами происходит полупроводниковый горец, все скупают всех, и тоска в головах у стратегов ARM должна быть сильной. Кто лицензии покупать-то будет? Я не понимаю, может в идеологии ARM MMU как-то совсем противоречит малому потреблению и RT? Но это странно, заявленые фичи TrustZone тоже потребуют много много быстрых транзюков. Ага, кажется есть момент - MMU идеологических непросто совместить с TrustZone, фиг его знает, что там юзер и куда наремапит.... Т.е. если делать полную изоляцию - TrustZone совсем отдельно от несекурной части, то RT точно пострадает, вызов любой функции мегалибы будет очень дорог по расходу тактов.... 19. Да, кто сможет предложить производителям хотя бы куски мегалибы - тот станет очень богатым. 20. С эрой открытых для независимого программирования камней с выходом ARMv8-M мы, с высокой вероятностью, попрощаемся. Зачем публиковать в открытом виде 10к страниц, если их "независимые" никогда не прочтут?