Здравствуйте!

Я занимаюсь программированием МК. этого не хватает для качественной обработки сигналов). Скажите что "круче" FPGA или DSP.
Я понимаю их различие. мне ближе DSP, но меня интересует:
1) кто быстрее?
2) кто дешевле?
3) кто проще
4) в мире что активнее юзают и почему?

Дык, местный Нострадамус уже давно все разжевал: DSP процессоры -, уходят в никуда..

че то не черта не понял
по одному мнению трудно судить, сколько людей столько и мнений.
кто за дсп кто да фпга.

не знаю чем заняться, что бы не оказалось что время потрачено зря...

Без конкретной задачи трудно выбрать, тем более как DSP так и FPGA очень разные бывают.

проще и дешевле будет взять DSP процессор/микроконтроллер .
На ПЛИС законченное DSP решение сделать трудно , проще делать разные автоматы а окончательную обработку делать в МК.
плис - дороже DSP процессоров/МК.

для DSP нужен программер их щас дофига
Для ПЛИС нужен повернутый мозг) не каждый прогрммер сможет.

платят вроде одинаково, непонятно

ПЛИС - более мощный инструмент, чем DSP. В ПЛИС кирпичики, при помощи которых разрабатываете проект, это триггеры, логические элементы, т.е. ниже (мельче) уже некуда, если проект на ПЛИС работает, то он будет всегда работать, потому что все отлажено с точностью до фронта сигнала. При этом не надо думать, что на ПЛИС задачи придется решать на триггерах и лог. элементах (так и убиться недолго ), есть до фига более высокоуровневых инструментов, те же мегафункции и языки описания аппаратуры VHDL, Verilog и т.д. В DSP все может быть отлажено с точностью до тех блоков, которые наваяли разработчики, и при всем к ним уважении, багов там до хрена: некоторые задокументированны(аномалии), некоторые нет, некоторые вообще за баги не считают, типа багофичи . Так что ИМХО ПЛИС надежнее и универсальнее, но не без минусов: во-первых, с ПЛИС тупо больше инфы придется освоить, ну и они дороже по стоимости.

Идущий человек, быстрее стоящего поезда. Но поезд в движении, быстрее любого человека. Но перемещаться на поезде из комнаты в комнату не совсем оправдано. Но если у вас комнаты площадью несколько квадратных километров, то тогда, наверно, выгоднее поезд. И тд...
Если ситуации где без FPGA ну совсем никак. А если ситуации, где он совсем не нужен.
Специалист по FPGA будет говорить что они лучше всех. Специалист по DSP будет бить себя в грудь, и кричать что на на своем любимом DSP сможет решить любую задачу. И оба они будут по своему правы. Я, например, не использую ни DSP, ни FPGA. Я честно могу сказать, что в моей области они не используются, но будет ли мое мнение репрезентативным?

Если хотите получить конкретный ответ, то уточните, что значит "быстрее", "дешевле", "проще"?
Т.к. "быстрее" купить готовое, "дешевле" стоит К155 рассыпухой на радиобазаре а "проще" сделать все на ПК, используя уже готовый инструментарий.

Да ну?! Хачу такую ПЛИС! Почему то в реальной жизни ПЛИС'ы иногда так глючат, что мама не горюй Баги бывают как в софте, так и в прошивках ПЛИСов. В каждом случае они свои специфические, но они бывают, увы

Самые коварные (и специфичные для ПЛИС) - асинхронные цепи самых разных форм и содержания

С задачами определитесь сначала, а потом уже голову ломать будете. Есть задачи, с которыми DSP не справится, есть задачи в которых применение FPGA не оправданно дорого, есть естественно и спорные области. Я, например, не могу ответить даже на вопрос кто дешевле, так как ПЛИС могут стоить и 10 баксов и 10000 баксов. Тоже самое и с остальным.



Программированием ПЛИС занимаются не программисты, а схемотехники со знанием языков программирования или вообще без них, если Вы считаете себя программером, то лучше оставьте затею их программирования, ибо действительно придется перестраивать мозг и чтобы стать именно хорошим разработчиком fpga придется потратить много времени.

Приветствую!

Выбор - FPGA/DSP/MK/CPU/GPU/... зависит от многих факторов.

В первую очередь от требований к системе обработки которую вы разрабатываете. Поэтому оценивая требуемые ресурсы для реализации требуемых алгоритмов хороший системщик должен учитывать все +/- как FPGA так и DSP.

Для FPGA :
+ возможность организации различных/нестандартных интерфейсов
+ потоковая обработка
+ параллельная обработка как во времени так и в "пространстве" (железе)
+ высокое быстродействие
- сложность реализации вычислительных алгоритмов
- сложность разработки дизайна
- высокая стоимость системы (в среднем)

Для DSP :
+ сложные вычислительные алгоритмы
+ повторное использование кода / стандартные библиотеки
+ легкость (относительная) разработки
+ средняя стоимость системы (в среднем)
- последовательная обработка во времени
- среднее быстродействие

При этом естественно также учитывается и то окружение в котором работаешь - доставабельность комплектации, возможность изготовления модулей, наличие и уровень программистов/дизайнеров, собственную лень и.т.д. и.т.п. ....

Для многих задач сейчас можно реализовать решения только на DSP. Некоторые без FPGA не реализуются.
Но наиболее оптимальные решения как всегда находятся при правильном делении обработки на АППАРАТНУЮ и ПРОГРАММНУЮ реализации.

Сам я последние 10 лет активно использую как FPGA так и DSP и MK в различных комбинациях и по сути (с идеологической точки зрения) разницы в них не вижу - для меня это своеобразные кирпичики /ресурсы с помощью которых (ну и какой-то матери естественно ) приходится решать насущные проблемы.


Успехов! Rob

может и так, хотя я честно говоря с ПЛИСами никогда ещё не залетал, может не все еще повидал... А вот с DSP... ох,ё моё, наелся уже вдоволь , Blackfinы в частности. А вообще просто из общих соображений плохо понимаю, что там в ПЛИС может глючить, если после отладки все работает.



Бич DSP, я бы сказал, это не баги в софте (к нему у меня по крайней мере претензий нет), а баги (или багофичи ) в харде, который непонятно как (для разработчика) функционирует, в общем конечно ясно, но детали... о них в курсе только разрабы. Вообще интересно какого рода баги могут быть в прошивках ПЛИС? Просто мне самому на будущее интересно знать, чего ждать

В основном всякая асинхронщина. Классический пример - автомат (FSM), управляющие сигналы для которого приходят напрямую из внешнего мира (без синхронизации с клоком самого автомата). Проявляется как 'может работать неделями, а потом вдруг встает в известную позу и ни на что не реагирует'.
Вторая известная бага - пересечение клоковых доменов без соответствующей синхронизации. Проявляется так же.
Третья бага - ввод данных без синхронизации (подавления метастабильности). От случая с FSM отличается в проявлениях тем, что не 'все слетает', а на выходе периодически появляются неправильные данные.
Четвертая бага - отсутствие (полное или частичное) констрейнов. Проявляется тем, что иногда (при колебаниях температуры или питающего напряжения) FPGA начинает сбоить. Так же проявляется тем, что FPGA при малейших изменениях схемы (буквально поменяли один провод или константу) вдруг совершенно перестает работать.

Это все так сказать 'физические' баги. Но никто не застрахован и от логических багов - неправильно расписали FSM (забыли какое нибудь состояние), что то недописали в логике и пр. Проявления - такие же как и в обычном программировании.

А кто такой программист? Вообще? И почему человек, занимающийся программируемыми логическими схемами (aka ПЛИС) является не программистом, а неким схемотехником? Я вот вообще не понимаю, причём тут схемотехника. Схемотехника - это проектирование схем, т.е. проектирование устройств в графических моделях. А в ПЛИС рулит HDL, т.е. язык.

Регулярно встречается термин FPGA программист. Считаю его вполне адекватным. Программирование вообще - это достаточно широкая область. И HDL - это программирование на языках с нативной поддержкой параллельно исполняемых [алгоритмических] блоков. Никто не спорит, что думать тут приходится несколько иначе, чем при традиционном программировании на С. Но и при программировании на С на РС и МК тоже приходится думать весьма по-разному. Однако, это не отменяет того, что и то, и другое является программированием.


Подписываюсь под каждым словом!

Так ведь сначало нужно по кирпичикам железо создать, на базе которого уже можно программировать.
FPGA дизайнер получается.
(Меня уже не удивляет, что молодое поколение за основу проектирования берет системы на кристалле там , где двумя автоматами можно обойтись.
Руками кубики собирают.)

Если речь о ПЛИС, то железо уже создано. Остаётся только его запрограммировать, определив логические функции на имеющиеся логических блоках и соконфигурировав межсоединения между ними.

FPGA дизайнер. HDL - язык описания цифровой аппаратуры, дискретных устройств. Да, есть схожесть с языками программирования, но создан он для других целей. Конечно, если использовать скажем SV для верификации со всеми возможностями, то это уже будет подобно программированию. Я же веду речь лишь применительно к синтезируемым конструкциям. Конструкция на verilog/vhdl будет воспринята синтезатором/разработчиком как конкретное логическое устройство - шифратор/мультиплексор/память, а не некое абстрактное понятие. И схемотехник, а не программист рассчитывает все эти блоки и соединяет их между собой с учетом особенностей архитектуры конкретной ПЛИС.

Э-э-э... запрограммировать...
Я сначала обдумываю структуру своего устройства. Потом рисую электрическую схему, с учетом допустимых сигналов и питаний на ногах ПЛИС. Потом развожу печатную плату, пытаясь балансировать между "как положено" и "как задумано". Если нахожу лучшее решение, переделываю схему...
И только потом запрограммировываю... Никто мне ничего не создает.
Неподалеку от ПЛИС у меня микроконтроллер. Его тоже запрограммировываю

Как насчёт SystemC? Или работы с CUDA? Или когда уже и на настольном компе стоит энядерный процессор и там реально происходит распараллеливание выполнения программы? Чем это принципиально отличается от написания программы на HDL?


А что мешает программисту рассчитывать все эти блоки, какими они будут, как они будут соединены, как они будут работать? Почему вы отказываете программисту в этом? Ведь и при написании программы для обычного микропроцессора, но работающего под управлением вытесняющей ОС, скажем, с карусельным планировщиком, программист должен иметь в виду, что у него куча кода выполняется параллельно (во всяком случае - логически), и должен заботится от синхронизации между этими параллельно выполняемыми [алгоритмическими] блоками.

То, что написание программ, где поток выполнения распараллеливается, сложнее последовательно выполняемых программ, не даёт оснований одно считать программой, а другое схемой.

Здесь я ничем не могу ответить, ибо в данном вопросе некомпетентен.

В этом вопросе я не отказываю программисту, просто говорю о том, что для того чтобы получить реально работающую схему, имеющую хорошие характеристики требуется хорошо знать архитектуру ПЛИС и логику работы простейших элементов. Утверждаю, что для выполнения подобных задач требуется знать схемотехнику больше нежели программирование, требуется знать как созданное описание ляжет на "железо", сколько будет уровней логики и почему. Я же теоретически могу запрограмировать ПЛИС и без знания HDL с помощью схемотехнического ввода.
Не раз видел, когда программист "программируя" алгоритм на ПЛИС вместо структуры case использует кучу вложенных if, или использует схему с нереальной разрядностью с использованием деления, а потом удивляется почему у него все это не влазит или работает не на сотни мегагерц, а на килогерцах.

Приветствую!

Все эти "звездные войны" 'схемотехник by программист' происходят из за стереотипов и узости восприятия соответствующих терминов.
Поскольку скорости развития технологий и инструментов в этих областях действительно космические.
Первые проекты я рисовал в MaxplusII и не представлял что можно как то по другому. К слову как раз дружественный интерфейс MaxplusII очень сильно помог в быстрой адаптации к "виртуальному железу". Однако лень как известно двигатель прогресса и когда рисования стало мало начался переход от рисования схемотехники к программированию железа.
Сейчас различные инструменты разработки позволяют выбрать каким способом вы будете реализовывать ваше устройство. Можно ПРОГРАММИРОВАТЬ железо в FPGA. Можно РИСОВАТЬ схемы для генерации программ в DSP. В обоих случаях результат будет зависит в первую очередь от КВАЛИФИКАЦИИ разработчика и понимании им того что он делает и с чем работает. Особенно это важно в области обработки сигналов.

Успехов! Rob.

Ну, так тут вопрос просто в квалификации. Если человек, много писавший на РС, начинает писать программу на tinyAVR и не вникает в особенности целевого МК, не представляет, во что выливаются его конструкции на С при кодогенерации, то результат будет плачевен. И, вроде, тут уж точно все программисты - и для РС, и для МК.

По вашим аргументам получается, что "программист" - это человек, который берётся за низкоуровневое программирование, но не разбирающийся в нюансах целевой платформы. Будь то МК или ПЛИС. Ровно та же ситуация, кстати, и при программировании с использованием CUDA - без чёткого понимания, как там оно структурно организовано, что может выполняться эффективно, а что нет, без знания всех этих системных нюансов целевой платформы успеха не достичь.

Да и схемотехники на ПЛИС как таковой нет - схема там почти готовая, а работа сводится к заданию логических функций и передаче возвращаемых значений (выходов) одних функций в качестве аргументов другим (на входы). Программирование, то бишь. Только с использованием в качестве целевой платформы структуры с аппаратными параллельно работающими ресурсами. Что, кстати, вполне справедливо и для той же CUDA.

Термин "схемотехника", используемый в контексте ПЛИС, возник исторически и до сих пор жив, пока живы соответствующие стереотипы. Но уже недолго осталось.

Приветствую!




Вот вот - как только уйдут монстры схемотехники которые еще помнят то время когда триггеры были большими (155TM2 DIP14)

Успехов! Rob.

Даже очень недолго :-) За дело уже взялись крупные игроки
http://newsroom.intel.com/community/intel_...90004-c1-262281

Microsoft так уже давно этими вопросами занимается
http://research.microsoft.com/apps/pubs/de...t.aspx?id=71425

Хорошо, а что тогда в Вашем понимании вообще цифровая схемотехника? Я, например, считаю что логика работы основных устройств и задание логических функций это и есть именно она, а не программирование. И тогда объясните мне, почему ООП и Паскаль изучаются на 1-2 курсах института, а языки описания дискретных устройств (кстати также как и DSP) на 3-4 и только после цифровой схемотехники и дискретной математики? И еще - что значит , что в ПЛИС уже есть готовые шифраторы, конечные автоматы или их самому наворотить надо? Тогда нафиг вообще знать что такое триггер и счетчик? И вообще - почему разработчики до сих пор полностью не перешли скажем на xilinx core generator - чего там - взял модель матлаба, разрисовал ее из xilinx блоков и все - готовый синтезируемый RTL?

Есть вариант - посмотри http://www.xmos.com/

Дешевые чипы с параллельной обработкой, поддержкой функций DSP (на среднем уровне), программируются на С/С++ с open-source средой, отладчиком, симулятором... Сам захотел пока писал

Как следует из самого термина, схемотехника - это создание устройств (систем) путём организации межсоединений между готовыми элементами. Цифровая схемотехника - подраздел, где элементы имеют выходы и выходы, способные работать с сигналами, представляющими собой логические уровни. Это позволяет драматически уменьшить требования к качеству передаваемых сигналов, но в то же время порождает свои специфические нюансы:

• сигналов в таких схемах, как правило, много больше, чем в аналоговых;
• сигналы являются быстроизменяющимися во времени (фронты), что накладывает требования на конструкцию (проблема целостности сигналов);
• возникают сопутствующие проблемы с организацией питания (быстродействующие импульсные токи) - обилие развязывающих конденсаторов, SSN и т.п. - тема достаточно непростая.
• организация схемы (и топологии конечного устройства) так, чтобы времена распространения сигналов были учтены и не возникало нарушения логической целостности работы устройства из-за гонок (один из способов борьбы - использование синхронного дизайна, который является основным при разработке устройств на FPGA по причине того, что сам класс этих ПЛИС спроектирован для организации дизайна именно по этому методу.

Перечень можно продолжать, но, надеюсь, и суть и так ясна. Так вот, что касается ПЛИС, то цифровой схемотехникой там занимаются разработчики самих ПЛИС - именно они решают все (кроме обвешивание конденсаторами снаружи) эти вопросы. А конечный пользователь, он был схемотехником, когда делал рисовал схемы на бумаге (или в пикаде) - схемы, которые строго соответствовали тому, что будет реализовано в железе. Т.е. каждая микросхема на схеме строго соответствовала микросхеме на плате. Каждый сигнал на схеме имел однозначную физическую реализацию на плате в виде проводника. И схема была точной принципиальной моделью реального устройства, которое являлось схемой на физическом уровне.

Когда этот конечный пользователь пересел на ПЛИС, он фактически перестал быть схемотехником (кроме вопросов, связанных со схемным обрамлением ПЛИС на печатной плате). Все вышеперечисленные вопросы внутри ПЛИС он уже не решает, а остаётся ему только запрограммировать совокупность готовых функциональных блоков под свои нужды. И даже когда он рисует схему - эта схема не является той принципиальной моделью, каковой она была в случае реализации в виде печатной платы, а тут схема - это функциональная модель, которая описывает только алгоритм. А конечная точная принципиальная модель получается уже после синтеза. Т.е. по сути "схемотехником" в каком-то смысле являются синтезатор и P&R.

Именно потому, что пользователь вводит описание алгоритмов на функциональном уровне, получается, что его схема в ПЛИС и близко не похожа на схему, которая получается в конечном устройстве - там нет ни этих высокуровневых устройств типа счётчиков, регистров и прочего, зачастую нет даже многих сигналов, которые явно присутствуют в пользовательской схеме.

Поэтому по большому счёту нет никакой принципиальной разницы, как вводится функциональная модель - текстом на HDL, схемой, в виде временных диаграмм, на основе блок-схемы и т.п. - это всё является программированием, отличающимся только способом ввода модели


А на Си вы когда пишете программу - вот все эти функции, передача аргументов при вызове одних функций из других, разве это не задание логики работы? А когда у вас тестбенч работает на HDL - это не программа? И когда вы пишете этот код, который будет исполнятся на симуляторе и который впоследствии будет обработан синтезатором - это не один и тот же код? Да, понятно, что синтезируемый код должен разрабатываться с учётом известных ограничений и нужно иметь всё это в виду, иначе удачи не видать, но принцип от этого не меняется.

Симулятор и синтезатор - это просто два разных инструмента, которые подготавливают разные реализации. И выполнение на РС и в ПЛИС - это тоже просто две разные реализации одного и того же алгоритма, функциональное описание которого осуществлено на языке (либо схемой). Представьте себе, что в РС установлен специальный ускоритель для симулятора, который сам реализован на основе толстой ПЛИС, и симулятор при элаборации проекта всё что можно реализует в виде исполняемых на этом ускорителе фрагментов. Такое возможно? Возможно, и подобные симуляторы даже производились (возможно, и производятся до сих пор - вопрос удобства и экономической целесообразности - это другой вопрос). А для пользователя это всё будет прозрачно. Ему без разницы, как оно там внутри организовано, ему надо, чтобы это работало корректно с точки зрения алгоритма и чтобы это работало как можно более быстро.


Ну, ООП на первом курсе - это уровень так себе, скорее просто познакомить с термином и слегка ввести в курс дела. Паскаль же сам по себе очень простой язык (почему и снискал популярность). А почему ПЛИС идёт позже - это естественно: программирование параллельных систем много сложнее программирования последовательных. И как уже говорилось выше, надо всегда включать голову при разработке этих вещей, поэтому совершенно необходимо иметь представление о том, как там оно внутри реализовано. Например, реализация логики в FPGA осуществляется на основе LUT - таблицы данных. Которая представляет собой не что иное, как память с организацией Nx1. А что такое память, какие бывают её виды, какие преимущества и недостатки у них имеются - это всё надо знать хотя бы на уровне общего представления.

Аналогично по устройствам хранения информации - триггерам. Поэтому сперва нужно человеку дать основы аппаратной части, потом уже учить программированию на её основе. Сам этот принцип универсален и применим, например, к тому же программированию МК, т.е. устройства с очень ограниченными ресурсами. Программист должен очень хорошо представлять, во что выливаются его конструкции на Си (if'ы, for'ы, вызовы функций и т.п.).


Это частный вопрос о том, на какой степени детализации реализованы внутренние программируемые блоки. Например, полно ПЛИС с готовыми аппаратными устройствами в виде контроллеров памяти, DSP блоков и т.п.

Что касается "знать", то для достижения эффективности знать надо всегда. И не только в области ПЛИС, но и традиционного программирования тоже. Про CUDA уже говорил, но и для настольных РС всё это справедливо - если пишете программу, которая должна рабоать максимально эффективно и выжать всё из целевой платформы, то надо эту платформу знать - например, сколькиядерный процессор, и как эти ядра меж собой взаимодействуют, как разложить потоки по ядрам и как организовать синхронизацию между ними. Область другая, нежели плисоводство, но суть ровно та же.


А такая тенденция уже давно есть. И не только на основе генератора, а прямо из матлаба. Или эта софтина Synphony от синопсиса (Synplify). Тендеция, кстати, такова, что по мере увеличения ресурсов ПЛИС меньше приходится тратить времени и сил на оптимизацию алгоритмов. В пределе это сводится к тому, что алгоритм описывается вообще на высокоуровневом языке типа Ruby, Python или даже функциональных языках, а синтезатор делает реализацию. Пока этот путь далёк от эффективности, поэтому массового перехода нет. Но тенденция устойчивая.

Эта же тенденция была и остаётся в области традиционных компьютеров. Ещё 20-30 лет назад писать программы для настольных компьютеров на ассемблере было часто оправдано и эффективно, а сегодня в ходу языки, где одна строчка кода делает работы, как сотни строк на асме. Да, на асме это можно было бы реализовать куда эффективнее (наверное даже в разы, если не в десятки раз), но если производительность алгоритма на современной платформе устраивает, то кого это волнует?

Водку пейте. И не терзайте себя глупостями. С утра не принял - день потрачен зря.
А если серьёзно, вопрос не должен так стоять вообще. Займитесь и тем, и другим. Развитие извилин ещё никогда зря не проходило.

неверный подход. причина - стоимость копии программы, и копии схемы различается по своей сути. поэтому никаких "забодяжь проект для плисины на питоне за 21 день" никогда не будет.

Приветствую!



Как это ни печально - как раз такой подход сейчас очень активно развивается/применяется. И иногда очень даже успешно. В Matlab набросали кубиков из Xilinx SystemGenerator - ап - и модуль обработки готов! При этом люди рисующие кубики о FPGA до этого ничего не знали - только прослушали 2-х недельные курсы обучающие работе с SystemGenerator!. Естественно в трюмах этого красивого лайнера мечты во всю трудятся кочегары/системщики перелопачивая горы угля/кода. Но их всего 2 а вот пассажиров на этом корабле много!. И корабль плывет!!!


Успехов! Rob.

Во-первых, про 21 день - это всегда была туфта, туфтой и останется, потому что человеку на освоение надо время, и мощность технических средств тут мало что меняет. А во-вторых, посмотрим лет через 20, на чём будут лабать параллельную логику.

У меня задача кодировать и декодировать на лету 128 PCM каналов кодеками GSM, G.723, G.729, Speex, iLBC. Поддержка одного или нескольких. Что лучше использовать FPGA или DSP? Преимущество последнего вижу такое, что некоторые кодеки открытые и исходники на них есть, с энным кол-вом усилий их можно портировать на DSP. А еще можно взять DSP+ARM поскольку последний там будет обязательно. Другое дело ПЛИС, с ними я никогда не работал, но очень хочу, к тому же кристал FPGA там в любом случае будет и не один (для интерфейсных нужд). Что посоветуете?

Если бы речь шла об 1 канале, то DSP без сомнений. А вот для 128 Понадобится очень шустрый DSP, или очень толстая FPGA (в ней можно сделать шеренгу DSP и запустить хоть все 128 каналов в параллель)

Попробую по сравнивать цены:
Какой DSP думаете подошел бы?
Сколько логических элементов понадобилось бы для этого на FPGA?

Для TI C64+:

G723.1: Необходимое кол-во MIPS'ов = 128 * 7.6 = 972,8.

G729AB: Необходимое кол-во MIPS'ов = 128 * 7.0 = 896,0.

Т.е., достаточно одного TI C64+ @ 1GHz, с поддержкой одного из кодеков G723/G729.

хорошо, а по ПЛИС?
и если по времени разработки соотнести?