Комментарии 56
(статью ещё не читал). Спасибо, КДПВ шикарна. Сначала подумал даже, что монтаж. DB-9 перпендикулярно плате впервые вижу. Да и контраст с SFP-cage смущает :-)
Я бы ещё добавил платы для тех кто хочет попробовать Ethernet на FPGA но не имеет возможности отдать больше 500$ за хобби.
www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=746 (PCIe x1 + Ethernet 1Gb)
www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=53&No=30 (хорошая плата с большим набором переферии однако старый чип(Cyclone II) и всего лишь 100Мегабит)
www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=529&PartNo=2 (Необычная плата Intel Atom + Cyclon IV на обоих по гигабитному порту.)
www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=746 (PCIe x1 + Ethernet 1Gb)
www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=53&No=30 (хорошая плата с большим набором переферии однако старый чип(Cyclone II) и всего лишь 100Мегабит)
www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=529&PartNo=2 (Необычная плата Intel Atom + Cyclon IV на обоих по гигабитному порту.)
Вижу здесь явных пособников роскомнадзора.
Почему нет варианта «не делать карточку»?
Идея конечно стара. В свое время для обработки трафика народ пробовал использовать GPGPU и вполне неплохо получалось.
GPU — плохая идея, там шина очень узкая. Потому что нужно аж дважды прогнать трафик от NIC/PCIE к CPU, потом в GPU, потом вернуть по той же схеме и отправить в сеть. Не особо оптимальная тема выходит. Обработка без затрагивания шины PCIE наиболее приятный вариант :)
Давно уже не надо. У современных GPU есть DMA в полный рост. Так что они могут напрямую читать данные из сетевухи и обратно.
norguhtar А может видели проекты, где такое реализовано, интересно было бы посмотреть
НЛО прилетело и опубликовало эту надпись здесь
Вы вот, например, вспомнили про GPGPU, а что именно неплохо получалось не стали указывать. Предположим GPU помог кому-то распараллелить операции с плавающей точкой одинарной точности, а кроме биллинга есть здесь еще какая-то практическая польза?
Держите ссылочку
shader.kaist.edu/packetshader
Статья пятилетней давности, но в целом для понимания пойдет. И да причем тут биллинг? :) Это использовать можно для анализа и управления трафиком. Там знаете и целочисленных операций хватит.
Топик-оунеру хотелось бы пожелать отталкиваться не от голосования по числу портов, а от библиотек и алгоритмов, которые они смогли бы наиболее эффективно задействовать (в соответствии с уровнем накопленной экспертизы и профессиональных интересов разработчиков).
Не их специализация. Ребята делают сетевые железки. До DPI доберутся постепенно :) Хотя сейчас DPI в малых масштабах до 10G отлично делается и на CPU.
НЛО прилетело и опубликовало эту надпись здесь
Если говорить о примерах использования FPGA в big data, то есть классика — Netezza (ныне часть IBM), которые часть обработки осуществляют на FPGA. Непонятно, правда, почему вы в пункте про MS смешиваете highload и bigdata.
Офтопный вопрос, а сколько стоят курсы FPGA и когда они проводятся? :) Просто Ваш офис от меня через дорогу и не хочется упустить такую возможность =)
Звучит очень интересно, но это же просто железо. То есть здорово, хорошо, но в реальной жизни не применимо.
Как оно поддерживается софтом? Каким софтом? Какие SDK/либы есть для работы с этим?
Могу я взять, например, программу на scapy и «скомпилировать» в код для FPGA?
И ещё, вопрос по железу: до какого уровня оно управляемое? Можно «своё» на phy слать, или SFP'шная часть сама по себе?
Как оно поддерживается софтом? Каким софтом? Какие SDK/либы есть для работы с этим?
Могу я взять, например, программу на scapy и «скомпилировать» в код для FPGA?
И ещё, вопрос по железу: до какого уровня оно управляемое? Можно «своё» на phy слать, или SFP'шная часть сама по себе?
С одной стороны, это действительно просто железо, как, скажем процессор от Интела. Программы для него — это уже проблема разработчика.
Действительно для FPGA мало открытых либ, т.к. эта сфера очень специфичная. Кому надо либо покупают готовые IP-ядра (см. выше, где был пример про TCP/UDP ядра), либо пишут сами (заказывают у контор, которые пишут IP-ядра).
Для зашивки/разрботки программ на FPGA используются SDK от вендоров, разработчики плат предоставляет референсные дизайны/bsp.
Программу на scapy и скомпилировать в код в FPGA не сможете.
Без проблем управляемая до уровня XGMII, на более низком уже сложнее/невозможно.
Действительно для FPGA мало открытых либ, т.к. эта сфера очень специфичная. Кому надо либо покупают готовые IP-ядра (см. выше, где был пример про TCP/UDP ядра), либо пишут сами (заказывают у контор, которые пишут IP-ядра).
Для зашивки/разрботки программ на FPGA используются SDK от вендоров, разработчики плат предоставляет референсные дизайны/bsp.
Программу на scapy и скомпилировать в код в FPGA не сможете.
Без проблем управляемая до уровня XGMII, на более низком уже сложнее/невозможно.
Интел делает очень много софта, чтобы это не было «проблемой разработчика». Есть и свой компилятор, и патчи в gcc, и в llvm, и патчи в ядро для поддержки новых фич процессора операционной системой.
Разработчик железа, который говорит «поддержка в софте это не мои проблемы» никогда не получит значительного рынка. См пример ардуинки, которая сама по себе никому не сдалась, если бы не студия.
Разработчик железа, который говорит «поддержка в софте это не мои проблемы» никогда не получит значительного рынка. См пример ардуинки, которая сама по себе никому не сдалась, если бы не студия.
Я не разработчик железа: я как раз пишу софт под FPGA, поэтому понимаю проблемы о которых вы говорите :)
(продолжая)
… а вот идея насчёт «easy fpga» у меня как раз зудит. Что-то очень казуальное и простое для программирования логики. Если под это дело будет свой высокоуровневый язык (пусть и не такой гибкий как «напрямую в бездну») и поддержка экосистемы вокруг — то просто конфетка получается.
Например, модуль для iptables, реализующий их на аппаратном уровне на подобном железе. С руками же отрывать будут.
Или аппаратно-программная поддержка туннелей/виланов силами fpga (читай, модуль ядра), анонсирующая в систему псевдосетевые адаптеры, которые можно использовать не глядя на обвязку.
Конфетка же, а не применение.
… а вот идея насчёт «easy fpga» у меня как раз зудит. Что-то очень казуальное и простое для программирования логики. Если под это дело будет свой высокоуровневый язык (пусть и не такой гибкий как «напрямую в бездну») и поддержка экосистемы вокруг — то просто конфетка получается.
Например, модуль для iptables, реализующий их на аппаратном уровне на подобном железе. С руками же отрывать будут.
Или аппаратно-программная поддержка туннелей/виланов силами fpga (читай, модуль ядра), анонсирующая в систему псевдосетевые адаптеры, которые можно использовать не глядя на обвязку.
Конфетка же, а не применение.
OpenCL — это высокоуровневый язык :)
У Альтеры есть пример парсера OPRA FAST (для HFT) на OpenCL, который:
www.altera.com/support/support-resources/design-examples/design-software/opencl/opra-fast.html
UDP оffload engine — это ядро, ссылку на который я давал ранее.
Поэтому высокоуровне программировать FPGA можно. Насколько это будет эффективно в конкретной задаче — это другой вопрос.
Многих пугает и останавливает большой ценник на такие платы с FPGA: от 4 до 15 тысяч долларов (и более).
Кому реально надо — те покупают готовые решения с фильтрацие за очень большие деньги, либо покупают девкиты и нанимают разработчиков для написания аппаратных фильтров/туннелей и пр.
Если платы будут по 300$, то это наверно будет совершенно другой разговор, да и цена формируется же рынком)
У Альтеры есть пример парсера OPRA FAST (для HFT) на OpenCL, который:
The kernel parses incoming compressed OPRA Fast data from a UDP offload engine, and returns a subset of fields over Ethernet with the UDP offload engine. The UDP offload engines are represented as I/O channels to the kernel.
www.altera.com/support/support-resources/design-examples/design-software/opencl/opra-fast.html
UDP оffload engine — это ядро, ссылку на который я давал ранее.
Поэтому высокоуровне программировать FPGA можно. Насколько это будет эффективно в конкретной задаче — это другой вопрос.
Многих пугает и останавливает большой ценник на такие платы с FPGA: от 4 до 15 тысяч долларов (и более).
Кому реально надо — те покупают готовые решения с фильтрацие за очень большие деньги, либо покупают девкиты и нанимают разработчиков для написания аппаратных фильтров/туннелей и пр.
Если платы будут по 300$, то это наверно будет совершенно другой разговор, да и цена формируется же рынком)
Ценники на платы совсем не пугают, т.к. в промышленном смысле эти цены равны нулю. А вот тот факт что разработка идет в 10-100 раз медленнее (и соответственно дороже) чем банальный x86 — вот это как раз пугает.
Вторая проблема — я не вижу хорошей IDE для того же VHDL. Непонятно как писать код без хорошего инструментария.
Вторая проблема — я не вижу хорошей IDE для того же VHDL. Непонятно как писать код без хорошего инструментария.
В качестве IDE для написания кода под FPGA (Verilog), я использую vim. Особых проблем с этим не имею)
По поводу медленнее расскажу пример из конкретной жизни:
балансировка 100G -> 10x10G и 1000 правил фильтрации 100G linerate при уже имеющихся MAC-ядрах 100G и 10G у двух FPGA-разработчиков заняло месяц.
Если это медленно и пугает, то я даже не знаю…
По поводу медленнее расскажу пример из конкретной жизни:
балансировка 100G -> 10x10G и 1000 правил фильтрации 100G linerate при уже имеющихся MAC-ядрах 100G и 10G у двух FPGA-разработчиков заняло месяц.
Если это медленно и пугает, то я даже не знаю…
Пример номер два:
система мониторинга RTP-потоков, которую описывал мой коллега в habrahabr.ru/company/metrotek/blog/266561
от FPGA требовалось парсить пакет (MAC/IP/UDP) на 10G, находить там RTP-данные, упаковывать в специальный бинарный формат, а затем упаковывать в UDP-пакеты и отправлять на 1G. При уже готовых 10G и 1G MAC-ядрах и готовой системе парсинга пакета от идеи до демонстрации на реальном трафике у оператора прошло две недели. Под FPGA пиcал один человек.
Если и это медленно, то наверно мне надо начать медленее писать код)
система мониторинга RTP-потоков, которую описывал мой коллега в habrahabr.ru/company/metrotek/blog/266561
от FPGA требовалось парсить пакет (MAC/IP/UDP) на 10G, находить там RTP-данные, упаковывать в специальный бинарный формат, а затем упаковывать в UDP-пакеты и отправлять на 1G. При уже готовых 10G и 1G MAC-ядрах и готовой системе парсинга пакета от идеи до демонстрации на реальном трафике у оператора прошло две недели. Под FPGA пиcал один человек.
Если и это медленно, то наверно мне надо начать медленее писать код)
Насчет IDE: VHDL беспощадный язык, в нем очень просто написать что-то что вообще не компилируется, а процесс компиляции (по крайней мере у меня в Quartus) — очень медленный. Конечно можно писать и в Notepad, я не спорю.
А у меня было такое что сложный проект состоящий из навороченной иерархии сворачивался после компиляции в 0 ячеек.
Хотя там была общая шина, управляющие сигналы на кучу устройств на этой шине, сложная обработка. Многоуровневая вложенная иерархия с кучей арбитров по каждому устройству для каждой задачи.
И общий арбитр шины всех устройств.
Дак-вот, причина была в том что я взял библиотеки работающие в одинаковых фазах этого общего арбитра и квартус понял что они никогда не получат из-за этого доступ к шине и свернул всё в NULL. Подав на выходы константы.
А время компиляции было подозрительно маленьким, минута вместо 10 мин и я сразу понял что-то не то.
Так что если компилируется до безобразия быстро хотя должно долго — это отличный плюс самой среде.
Да и просьба не забывать что в отличии от GCC компилятор квартуса смотрит общее взаимодействие всех модулей ко всем ко всем состояния во всей прошивке в целом, и благодаря этому отлично оптимизирует. А это важнее чем отладка через тестирование на железе с быстрыми итерациями, что в плис по-моему не уместно.
Хотя там была общая шина, управляющие сигналы на кучу устройств на этой шине, сложная обработка. Многоуровневая вложенная иерархия с кучей арбитров по каждому устройству для каждой задачи.
И общий арбитр шины всех устройств.
Дак-вот, причина была в том что я взял библиотеки работающие в одинаковых фазах этого общего арбитра и квартус понял что они никогда не получат из-за этого доступ к шине и свернул всё в NULL. Подав на выходы константы.
А время компиляции было подозрительно маленьким, минута вместо 10 мин и я сразу понял что-то не то.
Так что если компилируется до безобразия быстро хотя должно долго — это отличный плюс самой среде.
Да и просьба не забывать что в отличии от GCC компилятор квартуса смотрит общее взаимодействие всех модулей ко всем ко всем состояния во всей прошивке в целом, и благодаря этому отлично оптимизирует. А это важнее чем отладка через тестирование на железе с быстрыми итерациями, что в плис по-моему не уместно.
Кстати, почему-то Microsoft не пугает использовать FPGA и ставить их в 1632 сервера)
Если очень надо, и без FPGA никак, а разработка занимает в 10 раз больше времени, то может тогда просто нанять 10 FPGA разработчиков? ;) Если это экономически невыгодно, то тогда просто не беритесь за эту задачу :)
Если очень надо, и без FPGA никак, а разработка занимает в 10 раз больше времени, то может тогда просто нанять 10 FPGA разработчиков? ;) Если это экономически невыгодно, то тогда просто не беритесь за эту задачу :)
Вспомнилось про девять женщин, которые должны были родить одного ребенка за месяц.)
Нет, я понял что Вы абстрактно. Я не придираюсь, просто вспомнилось.
Нет, я понял что Вы абстрактно. Я не придираюсь, просто вспомнилось.
Непонятно где искать этих 10 разработичков. И да, точно так же как 9 женщин не сделают ребенка за месяц, совсем не файт что 10 разработчиков сделают продукт в 10 раз быстрее.
Возвращаясь к вопросу, что медленно идёт разработка:
PLDA предлагает использовать QuickPlay: http://www.quickplay.io/networking
Демки, где в "удобной IDE" создается приложение с приёмом и отправкой данных на 10Gb интерфейс без Verilog'a:
PLDA предлагает использовать QuickPlay: http://www.quickplay.io/networking
QuickPlay enables the rapid development of FPGA based network processing applications. With QuickPlay, networking equipment manufacturers can securely open up their FPGA designs to end users. End users can modify and tune vendor’s designs or create their own networking designs without ever requiring hardware skills.
Демки, где в "удобной IDE" создается приложение с приёмом и отправкой данных на 10Gb интерфейс без Verilog'a:
НЛО прилетело и опубликовало эту надпись здесь
это не черепаха на трёх китах,
у ПЛИС есть существенные минусы:
1. Норма когда проект компилируется час или два, и потребляет 8-32 гигов озу на компиляцию.
2. Решения или сырые или крайне сырые (нет даже нормальных примеров)
3. Сама разработка под ПЛИС это не написание кода по шагам, а описание схемы в целом (это очень тяжело и чертовски долго).
4. Сами производители не отстают от моды, маркетологи и дизайнеры лютуют: новая версия квартуса с редизайном UI и только она поддерживает новые чипы и это норма.
5. Баги: иногда что то падает или мастер не вызывается. и это после 2-3 сервис пака и это норма и не считается нестабильной средой.
(а особо весёлые сюрпризы уготовлены тем кто использует пути с кириллицей даже не явно — имя пользователя например в documents and settings)
6. Быдлокод, очень адский, потому что каждый модуль не зависит от другого и всю систему целиком не уронит, плюс сумашедшая гонка чипов.
7. Стоимость IP ядер за гранью разумного.
8. Всякие мутные нюансы: шин нет а есть соединения всех ко всему с вытекающим жором ресурсов (если не учесть архетектуре), не самые оптимальные либы от производителей которые жрут в 2-3 раза больше и медленнее работают (будто заставляют брать пожирнее камень).
это даже хуже
у ПЛИС есть существенные минусы:
1. Норма когда проект компилируется час или два, и потребляет 8-32 гигов озу на компиляцию.
2. Решения или сырые или крайне сырые (нет даже нормальных примеров)
3. Сама разработка под ПЛИС это не написание кода по шагам, а описание схемы в целом (это очень тяжело и чертовски долго).
4. Сами производители не отстают от моды, маркетологи и дизайнеры лютуют: новая версия квартуса с редизайном UI и только она поддерживает новые чипы и это норма.
5. Баги: иногда что то падает или мастер не вызывается. и это после 2-3 сервис пака и это норма и не считается нестабильной средой.
(а особо весёлые сюрпризы уготовлены тем кто использует пути с кириллицей даже не явно — имя пользователя например в documents and settings)
6. Быдлокод, очень адский, потому что каждый модуль не зависит от другого и всю систему целиком не уронит, плюс сумашедшая гонка чипов.
7. Стоимость IP ядер за гранью разумного.
8. Всякие мутные нюансы: шин нет а есть соединения всех ко всему с вытекающим жором ресурсов (если не учесть архетектуре), не самые оптимальные либы от производителей которые жрут в 2-3 раза больше и медленнее работают (будто заставляют брать пожирнее камень).
про плюсы забыл, для меня плюсы такие:
самый главный плюс это скорость и параллельность, это реально нечто, как будто вместо дискет 5 дюймовых на SSD пересел.
ну и то что можно сделать многие вещи не прибегая к внешним IP на уровне описания что мне нужно от входов и как выхода зависят от входов и внутренних состояний — а компилятор как нибудь сам сделает реализацию.
В ряде случаев на плис существенно быстрее разрабатывать электронику если можно обойтись своими силами не покупая готовые либы.
Особенно нравится делать свою простую но специальную периферию для внешнего МК: существенно быстрее написать на плис реализацию хитрого таймера с запуском ацп и прочими фишками чем углубляться в дебри описания и конфигурирования того же STM32 и его таймеров — порой это экономия недель.
самый главный плюс это скорость и параллельность, это реально нечто, как будто вместо дискет 5 дюймовых на SSD пересел.
ну и то что можно сделать многие вещи не прибегая к внешним IP на уровне описания что мне нужно от входов и как выхода зависят от входов и внутренних состояний — а компилятор как нибудь сам сделает реализацию.
В ряде случаев на плис существенно быстрее разрабатывать электронику если можно обойтись своими силами не покупая готовые либы.
Особенно нравится делать свою простую но специальную периферию для внешнего МК: существенно быстрее написать на плис реализацию хитрого таймера с запуском ацп и прочими фишками чем углубляться в дебри описания и конфигурирования того же STM32 и его таймеров — порой это экономия недель.
Попробую защитить разработку под FPGA (применительно к Альтере, т.к. я пишу под неё).
1. Да, это норма. Бывает и побольше. Когда мы делали анализатор/балансировщик 100G, то полная сборка с нуля занимала 5-6 часов. На самом деле это не так страшно, т.к. сборка производится очень редко (допустим, в конце недельного спринта, когда делается релиз прошивки), и, разумеется, делается ночью. Весь код предварительно прогоняется в симуляторе, где очень быстрая сборка (минута), отлаживается там же, и затем просто собирается квартусом. Очень редко что-то приходится смотреть сигналтапом (раз в квартал, наверно).
2. Вы про BSP для девкитов?
3. Это такое же программирование, как и любое другое: с предсказуемым временем на разработку. Есть небольшой свод правил, которым надо следовать и всё будет хорошо. Да, сортировку под FPGA надо писать с нуля день, а в C просто вызвать qsort, но таковы реалии. Кстати, попробуйте с нуля, никуда не подглядывая, написать сортировку на ассемблере, думаю тоже будет «тяжело и чертовски долго».
4. Да, есть такой минус.
5. За четыре года работы я видел только три бага квартуса. Не знаю, это много или нет. Не забываете, что пользователей gcc в десятки тысяч раз больше, чем пользователей квартуса. Ну, а проблемы с кириллицей и documents and settings мне не знакомы — я на linux'e сижу)
6. Наличие быдлокода зависит очень о того, кто пишет) Да, иногда не самые оптимильные по количеству строк решения вылезают из-за ограничения языка, который используется. Но есть у вас в проекте быдлокод, это значит, что тот код делает ревью, делает это неправильно, или сам пишет быдлокод (как и в любом другом языке). Не очень понял про независимость модулей и про сумасшедшую гонку чипов.
7. Да, дорогие, потому что разработка под FPGA это «тяжело и чертовски долго» :).
8. Да, такое встречается. Зависит от специфики проектов/IP-ядер.
1. Да, это норма. Бывает и побольше. Когда мы делали анализатор/балансировщик 100G, то полная сборка с нуля занимала 5-6 часов. На самом деле это не так страшно, т.к. сборка производится очень редко (допустим, в конце недельного спринта, когда делается релиз прошивки), и, разумеется, делается ночью. Весь код предварительно прогоняется в симуляторе, где очень быстрая сборка (минута), отлаживается там же, и затем просто собирается квартусом. Очень редко что-то приходится смотреть сигналтапом (раз в квартал, наверно).
2. Вы про BSP для девкитов?
3. Это такое же программирование, как и любое другое: с предсказуемым временем на разработку. Есть небольшой свод правил, которым надо следовать и всё будет хорошо. Да, сортировку под FPGA надо писать с нуля день, а в C просто вызвать qsort, но таковы реалии. Кстати, попробуйте с нуля, никуда не подглядывая, написать сортировку на ассемблере, думаю тоже будет «тяжело и чертовски долго».
4. Да, есть такой минус.
5. За четыре года работы я видел только три бага квартуса. Не знаю, это много или нет. Не забываете, что пользователей gcc в десятки тысяч раз больше, чем пользователей квартуса. Ну, а проблемы с кириллицей и documents and settings мне не знакомы — я на linux'e сижу)
6. Наличие быдлокода зависит очень о того, кто пишет) Да, иногда не самые оптимильные по количеству строк решения вылезают из-за ограничения языка, который используется. Но есть у вас в проекте быдлокод, это значит, что тот код делает ревью, делает это неправильно, или сам пишет быдлокод (как и в любом другом языке). Не очень понял про независимость модулей и про сумасшедшую гонку чипов.
7. Да, дорогие, потому что разработка под FPGA это «тяжело и чертовски долго» :).
8. Да, такое встречается. Зависит от специфики проектов/IP-ядер.
2. Вы про BSP для девкитов?
и про BSP и про всё в целом, выходят например макс5, ок, покупаешь отладку их, всё работает, но в реальной работе мало приминимо и выплёвывается как обычно стопятьсот варнингов, а порой тыща. Понимаешь что попал на огромную кучу программных и аппаратных нюансов. Пишешь в саппорт «да да скоро исправим», и всё, через пару лет «покупайте макс 10». Я понимаю что это только по сути демоплата и ожидать с неё нечего, но блин дорабатывать железо и как то развивать софт надо а не просто выпускать новый чип и новые особенности и
3. Это такое же программирование, как и любое другое: с предсказуемым временем на разработку.
У меня всё норм, а вот те кому я пытался это дело передать и обучить — было очень плохо и долго. Даже если человек сразу слёту рулит в сигнальной обработке и может накатать алгоритм детекции женского голоса например, а вот в плис вообще никак. Так что я думаю мы с тобой братья по складу ума и не всем дано.
6. Быдлокод внутри либ квартуса (особенно в AHDL) и сторонних либ, его почему то больше чем в обычных исходниках на си или с++. Возможно из за цены бага — они существенно меньше в FPGA. На некоторых либах workaround: reset before send eatch packet
5. Блин, чертовски завидиую, а у нас фирма упёрлась в винду и не хотят своё оборудование никчему другому адаптировать — кое как сделали для люникса «порт» (под вайном) и… забросили.
На самом деле FPGA в этом смысле проще, чем процессор. Потому как тут все создаешь сам с нуля и сам себе царь и бог. Настоящие ошибки в софте или «железе» FPGA, нарушающие функциональность, встречаются крайне редко. Хуже когда приходится подлючать сторонние ip-компоненты, и чем сложнее его интерфейс, тем больше сомнений в себе и окружающем мире ;)
Но по сравнению с запуском банального SPI на каком-нибудь многоядерном монстре (коллега тут мучался. долго) по невнятной документации TI — не так и страшно.
Но стоимость отладки багов, конечно, значительно больше.
Но по сравнению с запуском банального SPI на каком-нибудь многоядерном монстре (коллега тут мучался. долго) по невнятной документации TI — не так и страшно.
Но стоимость отладки багов, конечно, значительно больше.
Потому как тут все создаешь сам с нуля и сам себе царь и бог.
Да так и есть — делаешь всё сам и держишь под полным контролем вообще всё. Но в этом и сложность что надо делать всё самому. Не все с этим справляются. Опыт велосипедостроения тут может пригодится, как ни странно. Главное чтоб он был хорошо совмещён с здравым смыслом и инженерным умением оставлять запас и делать казалось бы лишнее.
Например: не просто сделать голый UART а ещё добавить хотя-бы банальные фильтры, и защиту от слишком быстрого и медленного потока с индикацией её срабатывания. Иначе будешь отлаживать чёрный ящик без обратной связи, который просто не работает и всё тут, а почему непонятно вообще. Это кстати очень частая ошибка новичков — они пишут что-то, а возможность понять как оно реально работает не закладывают.
Я использую для телефонии FPGA и CPLD в связке с 32битными ARM MCU серии STM32F103 или STM32F405. Подключается МК по шине внешней памяти FSMC. В итоге процессор получает уже готовые массивы байт, с пойманной синхронизацией и проверенным CRC. И на процессоре остаётся только делать уже то, что на проце проще делать — работа с звуком и обработка сигнализации, коммутации и прочие самые высокоуровневые вещи. Те вещи которые как раз и надо менять чаще всего.
Да интересный момент есть — я закладываю обычно ещё возможность обновления прошивки ПЛИС самим клиентом, но это не разу не понадобилось делать. А вот обновление прошивки у STM — это постоянно (раз в несколько месяцев).
Риквестую статьи про FPGA с минимальным порогом входа :) Мне из софтварного мира крайне сложно разобраться с сабжем без возможности потрогать руками на недорогом девките :(
Таки было-же, и на хабре в своё время, и вроде как существует по ныне вот такой marsohod.org замечательный проект.
Всем советую, ибо сейчас люди в FPGA за деньгами приходят, взрослые разработчики, книжек начитаются и сразу начинают делать проекты из готовых блоков, не сильно вдаваясь в их внутреннее устройство и идеологию разработки, а она совершенно ИНАЯ!
Всем советую, ибо сейчас люди в FPGA за деньгами приходят, взрослые разработчики, книжек начитаются и сразу начинают делать проекты из готовых блоков, не сильно вдаваясь в их внутреннее устройство и идеологию разработки, а она совершенно ИНАЯ!
Этот весь анализ данных, что описан в статье делается без Microblaze?
Я в статье рассказал про карточки от различных вендоров, их ТТХ, а так же общий обзор: что туда запихивают из железа.
Кто и как их использует — это сумма того, что я видел в интернете, какие запросы на разработку к нам приходят, а так же общение с коллегами из других фирм. А использует ли кто-то [в мире] для этих задач Microblaze или нет — я не знаю.
Когда мы решаем эти (или похожие) задачи на своих железках (они с FPGA, но без PCIe) — мы не используем NIOS/Microblaze, потому что когда ты хочешь фильтровать 5-tuple или LPM на linerate 10G/40G/100G, то, боюсь, производительности софтового проца не хватит. Возможно для какого-то более глубокого анализа и можно его применить, не знаю.
Кто и как их использует — это сумма того, что я видел в интернете, какие запросы на разработку к нам приходят, а так же общение с коллегами из других фирм. А использует ли кто-то [в мире] для этих задач Microblaze или нет — я не знаю.
Когда мы решаем эти (или похожие) задачи на своих железках (они с FPGA, но без PCIe) — мы не используем NIOS/Microblaze, потому что когда ты хочешь фильтровать 5-tuple или LPM на linerate 10G/40G/100G, то, боюсь, производительности софтового проца не хватит. Возможно для какого-то более глубокого анализа и можно его применить, не знаю.
Мне всегда нравилась разработка под FPGA разных сетевых проектов, но в последнее время стал сильно думать прежде чем связываться еще.
Развитие современных процов и разных модулей для Линукс для работы с сетью сильно повысили возможности и производительность систем на базе х86. И я сейчас не касаюсь DPDK или решений от 6wind.
Как-то решения на базе FPGA становятся все более и более узкоспециализированные. Найти толковых разработчиков ПЛИС все сложнее и сложнее, девкиты дорогие и достать не всегда просто, отладка сложнее, переносимость кода не супер.
Развитие современных процов и разных модулей для Линукс для работы с сетью сильно повысили возможности и производительность систем на базе х86. И я сейчас не касаюсь DPDK или решений от 6wind.
Как-то решения на базе FPGA становятся все более и более узкоспециализированные. Найти толковых разработчиков ПЛИС все сложнее и сложнее, девкиты дорогие и достать не всегда просто, отладка сложнее, переносимость кода не супер.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ethernet + PCIe + FPGA = LOVE