DSP vs FPGA, Нужен совет Опции

[Neon_613]

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

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

[dxp]

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

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

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

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

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

[bogaev_roman]

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

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

[dxp]

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

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

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

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

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

[bogaev_roman]

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

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

А что мешает программисту рассчитывать все эти блоки, какими они будут, как они будут соединены, как они будут работать? Почему вы отказываете программисту в этом?

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

Сообщение отредактировал bogaev_roman - Jun 8 2011, 14:17

[dxp]

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

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

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

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

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

[bogaev_roman]

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

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

схемотехники как таковой нет

, что в ПЛИС уже есть готовые шифраторы, конечные автоматы или их самому наворотить надо? Тогда нафиг вообще знать что такое триггер и счетчик? И вообще - почему разработчики до сих пор полностью не перешли скажем на xilinx core generator - чего там - взял модель матлаба, разрисовал ее из xilinx блоков и все - готовый синтезируемый RTL?

[dxp]

Хорошо, а что тогда в Вашем понимании вообще цифровая схемотехника?

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

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

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

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

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

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

Я, например, считаю что логика работы основных устройств и задание логических функций это и есть именно она, а не программирование.

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

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

И тогда объясните мне, почему ООП и Паскаль изучаются на 1-2 курсах института, а языки описания дискретных устройств (кстати также как и DSP) на 3-4 и только после цифровой схемотехники и дискретной математики?

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

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

И еще - что значит , что в ПЛИС уже есть готовые шифраторы, конечные автоматы или их самому наворотить надо? Тогда нафиг вообще знать что такое триггер и счетчик?

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

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

И вообще - почему разработчики до сих пор полностью не перешли скажем на xilinx core generator - чего там - взял модель матлаба, разрисовал ее из xilinx блоков и все - готовый синтезируемый RTL?

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

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

[Mahagam]

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

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

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

[dxp]

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

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