У Promwad действительно большой опыт работы с различнными видами платформ, в двух комментариях выше мы уже объяснили выбор именно такой реализации.
Для работы с сетью на stm32 всегда возможно воспользоваться lwip, но тут опять же быстрота реализации и поддержка бизнес-логики со всеми вытекающими.
Любой проект, связанный с сетью, на микроконтроллерах занимает в разы больше времени чем на Linux. Аппартных подходов для решения нашей задачи и правда много. Но мы подозреваем, что если бы наша система была на rtos, мы бы делали данный проект до сих пор х-), а если на bare metal — так еще в 2 раза больше чем на rtos. Может, и не так долго, но было бы больно. :-)
У нас был overhead по времени, мы рассматривали вариант вашего решения, но отказались, т.к. платформа должна легко масштабироваться. Также нужно было оставить запас на документирование для файловой системы.
Вообще среди микроконтроллеров stm32 выбор небольшой, нужно должны знать fat от чена, либо yaffs. Другое дело linux, тут большое количество файловых систем. Выбор fpga был обусловлен тем, что все распространенные проекты в данной теме имеют ip-ядро для синхронизации.
Ваше решение тоже имеет право на жизнь, только нужно подойти комплексно, не только с аппаратной точки зрения. :-)
Мы остановились на системе на кристалле (SoC) Zynq 7000, т.к. она проще в плане написании программных приложений и дает больше функциональных возможностей для текущих и будущих задач. У нас был Linux на проекта, и при выборе микроконтроллеров пришлось бы использовать RTOS либо bare metal, плюс много бизнес-логики. На микроконтроллерах такое решение нам показалось нецелесообразным.
Эта реализация хорошая, только у нас была отправка для каждого канала аудио по rtp (ethernet), также там в потоке рассчитывалось fft и много было дополнительных математических вычислений. С такой функциональностью stm32 или другие микроконтроллеры не справились бы, при том условии, что на pri и bri у нас было 8 каналов (link-ов), для аудио — 16 каналов.
Нам было важно максимально быстро решить задачу и ограничиться только настройкой dts для Linux, без написания всех уровней для работы с аудио в Linux. Под наши требования подошла только реализация AXI-I2S-ADI controller (Analog Devices).
Чтобы это обеспечить, необходимо периодически проводить перекалибровку. В некоторых публикация этот подход описан. В результате «тапы» привязываются к такту PLL, и абсолютная погрешность определяется температурным дрифтом PLL.
Все верно. Если точнее, здесь существенно отношение времени установки состояния к времени распространения сигнала между соседними LE. В эксперименте это видно на исходных термокодах: вблизи «границы» «дрожат биты» (bubble error). С учетом статистической природы эффекта с ним борются статистическим методами — многократное измерение одного и того же события. Основные направления wavelauncher и измерение несколькими экземплярами TDC.
В режиме Fast-charge достигается максимальное значение тока. При полной разрядке устройство работает в режиме Pre-charge, в котором максимальный ток составляет 400мА, чтобы зарядить АКБ до минмально допустимого уровня.
Если серьезно, то платы, как и всё остальное, это интеллектуальная собственность заказчика. У нас остаются знания и опыт, которым мы с радостью делимся.
Всё так. Разработка в Европе, а производство — в Азии, но это не значит, что все этапы реализуются на одном заводе в Китае. Чаще всего для защиты продукта задачи распределяются по разным специализированным компаниям: основные ноу-хау остаются у владельца продукта, второстепенные задачи в ПО и железе передаются на аутсорсинг, платы производят на одном заводе, корпус отливают — на другом, а сборку делают в третьем доверенном месте. Всё это даёт экономический эффект и защиту.
ПЛИС не очень энергоэффективная платформа в принципе, поэтому, конечно, об этом речи не идет. Имелось в виду, что при реализации на ASIC можно добиться лучшего энергопотребления. И то не факт.
Что касается приложений, их не очень много. На данный момент мне известна компания, которая делает различные девайсы для безопасности: http://verayo.com/tech.php. Что касается остальных новостей, я в тексте привел ссылки на анонсы использования ФНФ в качестве ID компаниями Xilinx и Intel для серийных ПЛИС.
Если я вас правильно понимаю, то продукты, которые делает Verayo, немного шире «хаков для защиты интеллектуальных прав». Если нет, то поясните, пожалуйста.
В пионерских работах есть теория по поводу того, почему ФНФ можно считать односторонними (хеш) функциями (см. главу 6). Лично я на ФНФ не реализовывал хеш-функции, поэтому у меня должной экспертизы в этом вопросе нет.
Насчет генераторов ответ положительный. Разумеется, реализации исследовались на стандартных тестах (NIST, Diehard). В ссылке на мою статью, которая приведена в тексте, есть пример этого. На эту тему есть множество работ и статистические свойства генерируемых последовательностей изучались неоднократно.
Насчет шумящих диодов согласен. Они гораздо дешевле в использовании, но если имеется проект на ПЛИС, и добавить туда истинно случайный генератор на ФНФ не стоит больших ресурсов. Разумеется если делать генератор ради генератора, то это очень спорная затея. Однако люди до сих пор делают генераторы на ФНФ и это говорит о том, что зачем-то им это надо :) Подозреваю, что борются за быстродействие и снижение энергопотребления. В таком случае ресурсы отходят на второй план.
У Promwad действительно большой опыт работы с различнными видами платформ, в двух комментариях выше мы уже объяснили выбор именно такой реализации.
Для работы с сетью на stm32 всегда возможно воспользоваться lwip, но тут опять же быстрота реализации и поддержка бизнес-логики со всеми вытекающими.
Любой проект, связанный с сетью, на микроконтроллерах занимает в разы больше времени чем на Linux. Аппартных подходов для решения нашей задачи и правда много. Но мы подозреваем, что если бы наша система была на rtos, мы бы делали данный проект до сих пор х-), а если на bare metal — так еще в 2 раза больше чем на rtos. Может, и не так долго, но было бы больно. :-)
Добавим еще фактов в поддержку нашей реализации:
У нас был overhead по времени, мы рассматривали вариант вашего решения, но отказались, т.к. платформа должна легко масштабироваться. Также нужно было оставить запас на документирование для файловой системы.
Вообще среди микроконтроллеров stm32 выбор небольшой, нужно должны знать fat от чена, либо yaffs. Другое дело linux, тут большое количество файловых систем. Выбор fpga был обусловлен тем, что все распространенные проекты в данной теме имеют ip-ядро для синхронизации.
Ваше решение тоже имеет право на жизнь, только нужно подойти комплексно, не только с аппаратной точки зрения. :-)
luntik2012 прав. Наш основной центр разработок расположен в Минске.
О таком разделении процессов можно почитать тут:
1. Аутсорсинг: как защитить свои разработки от копирования
2. Из чего состоит продукт: ноу-хау и IP внутри новой электроники
Пока расклад такой:
Cypress: HyperFlash 512 Mbit, HyperRAM 64 Mbit
ISSI: HyperFlash 512 Mbit, HyperRAM 128 Mbit
Что касается приложений, их не очень много. На данный момент мне известна компания, которая делает различные девайсы для безопасности: http://verayo.com/tech.php. Что касается остальных новостей, я в тексте привел ссылки на анонсы использования ФНФ в качестве ID компаниями Xilinx и Intel для серийных ПЛИС.
Если я вас правильно понимаю, то продукты, которые делает Verayo, немного шире «хаков для защиты интеллектуальных прав». Если нет, то поясните, пожалуйста.
Насчет генераторов ответ положительный. Разумеется, реализации исследовались на стандартных тестах (NIST, Diehard). В ссылке на мою статью, которая приведена в тексте, есть пример этого. На эту тему есть множество работ и статистические свойства генерируемых последовательностей изучались неоднократно.
Насчет шумящих диодов согласен. Они гораздо дешевле в использовании, но если имеется проект на ПЛИС, и добавить туда истинно случайный генератор на ФНФ не стоит больших ресурсов. Разумеется если делать генератор ради генератора, то это очень спорная затея. Однако люди до сих пор делают генераторы на ФНФ и это говорит о том, что зачем-то им это надо :) Подозреваю, что борются за быстродействие и снижение энергопотребления. В таком случае ресурсы отходят на второй план.