Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Спасибо за статью.
С уважением отношусь к тем, кто делает что-то конкретное.
Сколько человек работало над этим проектом, если не секрет?
И в каком городе находится ядро команды?
С уважением отношусь к тем, кто делает что-то конкретное.
Сколько человек работало над этим проектом, если не секрет?
И в каком городе находится ядро команды?
djinninia, спасибо за отзыв! Над проектом работали 3 программиста (linux embedded), 4 FPGA-программиста, команда схемотехников и трассировщиков.
luntik2012 прав. Наш основной центр разработок расположен в Минске.
luntik2012 прав. Наш основной центр разработок расположен в Минске.
При проверке передачи данных через Axi DMA замеряли производительность? Интересно было бы посмотреть на реальные цифры.
не похоже чтоб в их задаче стояла проблема скорости.
двух мегагерцовый поток PRI это очень медленно и очень маленький трафик.
я такой на атмеге8515-ой разруливал в реалтайме с CPLD MAX (да да первый в 128 LUT/Reg) только в качестве DMA устройства и CRC4 акселератора.
А когда появились STM32 то и плис не понадобилась — ножкодрыганием в реалтайме через DMA справился плюс bitbanding помог очень сильно в подсчёте крк4 и прочих поисках мультифрейма и тд.
двух мегагерцовый поток PRI это очень медленно и очень маленький трафик.
я такой на атмеге8515-ой разруливал в реалтайме с CPLD MAX (да да первый в 128 LUT/Reg) только в качестве DMA устройства и CRC4 акселератора.
А когда появились STM32 то и плис не понадобилась — ножкодрыганием в реалтайме через DMA справился плюс bitbanding помог очень сильно в подсчёте крк4 и прочих поисках мультифрейма и тд.
Эта реализация хорошая, только у нас была отправка для каждого канала аудио по rtp (ethernet), также там в потоке рассчитывалось fft и много было дополнительных математических вычислений. С такой функциональностью stm32 или другие микроконтроллеры не справились бы, при том условии, что на pri и bri у нас было 8 каналов (link-ов), для аудио — 16 каналов.
Скорость не замеряли для axi_dma. Для аудио — 12 Мбайт/c. Для pri/bri — в разы меньше.
Непонятно, почему был сделан выбор такой ПЛИС. На мой взгляд микроскопом по гвоздям.
Вы взяли ПЛИС, отказались от микроконтроллеров, а сами начали искать IP-ядро для i2S, который есть в каждом втором контроллере. И Ethernet, и DMA, и параллельные порты тоже есть в контроллерах для связи с памятью/ПЛИС.
Вряд ли вы расскажете о заказчике и инвесторе, но на разработку деньги (imho) вы потратили сверхмеры.
Вы взяли ПЛИС, отказались от микроконтроллеров, а сами начали искать IP-ядро для i2S, который есть в каждом втором контроллере. И Ethernet, и DMA, и параллельные порты тоже есть в контроллерах для связи с памятью/ПЛИС.
Вряд ли вы расскажете о заказчике и инвесторе, но на разработку деньги (imho) вы потратили сверхмеры.
возможно они эту платформу знали, был опыт и были наработки.
а так я бы лично сделал бы на STM32F7 — в реалтайме отлично тянет ффт до мегасемпла в сек (125 каналов по 8к семпла), дма и прочие акселераторы тяжёлых вычислений есть (даже SIMD и даже может 4 тапа FIR фильтра за такт), но опять же таки у меня есть такие наработки и мне нужно применить только готовые блоки и чуток доработать окружение и мейн функцию шаблонного ISDN проекта.
а так я бы лично сделал бы на STM32F7 — в реалтайме отлично тянет ффт до мегасемпла в сек (125 каналов по 8к семпла), дма и прочие акселераторы тяжёлых вычислений есть (даже SIMD и даже может 4 тапа FIR фильтра за такт), но опять же таки у меня есть такие наработки и мне нужно применить только готовые блоки и чуток доработать окружение и мейн функцию шаблонного ISDN проекта.
я думаю если компания делала данный проект на bare metal или rtos, то они бы делали бы еще) (а bare metal в данной реализации вообще пагубное дело), плюс мне кажется у них был жесткая необходимость в работе с файловыми системами, а если это микроконтроллеры выбор не большой, чтобы не передумывать велосипеды полностью поддерживаю реализацию promwad. Плюс судя по статье у них очень много логики заточено на ethernet, поэтому делать на lwip это можно, но за чем, плюс автор пишет система должна быть масштабируемой, на linux это делать гораздо проще, так как по описанию у них явно много поточное приложение. Спасибо за статью.
Mirn, спасибо за дополнение!
У Promwad действительно большой опыт работы с различнными видами платформ, в двух комментариях выше мы уже объяснили выбор именно такой реализации.
Для работы с сетью на stm32 всегда возможно воспользоваться lwip, но тут опять же быстрота реализации и поддержка бизнес-логики со всеми вытекающими.
Любой проект, связанный с сетью, на микроконтроллерах занимает в разы больше времени чем на Linux. Аппартных подходов для решения нашей задачи и правда много. Но мы подозреваем, что если бы наша система была на rtos, мы бы делали данный проект до сих пор х-), а если на bare metal — так еще в 2 раза больше чем на rtos. Может, и не так долго, но было бы больно. :-)
У Promwad действительно большой опыт работы с различнными видами платформ, в двух комментариях выше мы уже объяснили выбор именно такой реализации.
Для работы с сетью на stm32 всегда возможно воспользоваться lwip, но тут опять же быстрота реализации и поддержка бизнес-логики со всеми вытекающими.
Любой проект, связанный с сетью, на микроконтроллерах занимает в разы больше времени чем на Linux. Аппартных подходов для решения нашей задачи и правда много. Но мы подозреваем, что если бы наша система была на rtos, мы бы делали данный проект до сих пор х-), а если на bare metal — так еще в 2 раза больше чем на rtos. Может, и не так долго, но было бы больно. :-)
Мы остановились на системе на кристалле (SoC) Zynq 7000, т.к. она проще в плане написании программных приложений и дает больше функциональных возможностей для текущих и будущих задач. У нас был Linux на проекта, и при выборе микроконтроллеров пришлось бы использовать RTOS либо bare metal, плюс много бизнес-логики. На микроконтроллерах такое решение нам показалось нецелесообразным.
Costic, спасибо за комментарий!
Добавим еще фактов в поддержку нашей реализации:
У нас был overhead по времени, мы рассматривали вариант вашего решения, но отказались, т.к. платформа должна легко масштабироваться. Также нужно было оставить запас на документирование для файловой системы.
Вообще среди микроконтроллеров stm32 выбор небольшой, нужно должны знать fat от чена, либо yaffs. Другое дело linux, тут большое количество файловых систем. Выбор fpga был обусловлен тем, что все распространенные проекты в данной теме имеют ip-ядро для синхронизации.
Ваше решение тоже имеет право на жизнь, только нужно подойти комплексно, не только с аппаратной точки зрения. :-)
Добавим еще фактов в поддержку нашей реализации:
У нас был overhead по времени, мы рассматривали вариант вашего решения, но отказались, т.к. платформа должна легко масштабироваться. Также нужно было оставить запас на документирование для файловой системы.
Вообще среди микроконтроллеров stm32 выбор небольшой, нужно должны знать fat от чена, либо yaffs. Другое дело linux, тут большое количество файловых систем. Выбор fpga был обусловлен тем, что все распространенные проекты в данной теме имеют ip-ядро для синхронизации.
Ваше решение тоже имеет право на жизнь, только нужно подойти комплексно, не только с аппаратной точки зрения. :-)
Итого, список прецедентов для работы:
Bare metal — IP core для I2S (Digilent ZYBO audio)
opencores.org
AXI-I2S-ADI controller (Analog Devices)
И дальше рассказ только про одно ядро. Поделитесь сравнением-то) Чем именно другие ядра оказались хуже или менее удобны?
Нам было важно максимально быстро решить задачу и ограничиться только настройкой dts для Linux, без написания всех уровней для работы с аудио в Linux. Под наши требования подошла только реализация AXI-I2S-ADI controller (Analog Devices).
а куда торопились-то? Сделать демонстрацию и забыть? Зачем тогда об этом статьи писать, если это все не серьезно?
Наверное, самым сложным моментом при работе с аудиопотоком в Xilinx Zynq 7020 было то, что на процессорной части этой системы на кристалле в принципе нет I2S-шины, поэтому нужно было найти I2S-ядра. Эта задача усложнялась тем условием, что ip-ядро должно было быть бесплатным.
неужели на родине, во всех ее университетах нет компетенции по созданию I2S-ядра? Это же не сложнее SPI или UART! или родине не нужны такие компетенции? Грустно это.
Ух как. А можно пруф по поводу D-канала в 31 таймслоте для E1 PRI?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка интерфейсных плат на SoC Xilinx Zynq 7000 для записи речи в аналоговом и цифровом формате