Да, у нас тоже с ПЛИС всё очень тяжко, хотя начальство их очень любит.
На город 3 конторы, где нужны ВериЛожники, и они мигрируют туда-сюда по текущим политическим реалиям...
Я уж лет 5 пропагандирую параллельную разработку -- задача ставится и DSP-шникам, и ПЛИСоводам, они параллельно её решают как-то, моделят скорости-потребности, потом собрание, обсуждение с плакатами -- и принятие решения.
Но ввиду преобладания "железячников" среди руководства и разработки плат, всё очень тормозится, хотя большинство наших алгоритмов гораздо более DSP-шные -- Тексасы их параллелят отлично, частота у них на порядок больше, цена -- на порядок меньше, время отладки при наличии отладчика и нормальных голов -- тоже, ну только вот санкции последнего периода и выделяемая в Ваттах мощь ограничивают...
ПЛИС хорошо может помочь, если некий "молодой" интерфейс ещё не встроен в серийные процессоры, не завоевал большую нишу, тогда ПЛИС будет "подносить снаряды" "круто"-процессору, здесь однокристалльный SoC -- очень перспективное направление.
Вот с ARM-ом их скрестили, я сижу мучаю Альтерную реализацию уже довольно долго -- плохо с обучением и поддержкой. Интел вроде тоже что-то мутил...
Когда с Тексасами-VLIW заварится настоящая каша -- будет бомба ! Ибо у них документация на порядок приличнее, всё сразу понятно, пара DSP-шных ядер, одно управляющее, 100К ячеек для навесной логики -- и будет нам "щастие", если доживём до конца "чёрных" дней
К нашим процам типа Эльбруса тоже можно прикрутить ончипную ПЛИС для реализации чего угодно интерфейсного "на вырост", но уж сразу со флэшной ориентацией конфигурации, для суровых применений -- включил, и оно сразу дышит.

...Для Darti надо бы определиться в своём городе политически, какой "касте" больший кусок пирога достаётся (не считая самих политиков и обслуживающих их юристов-экономистов-менеджеров), и рулить в том направлении. Смешанные спецы должны быть в гораздо большем почёте, вон сколько объявлений тут мелькает !

А по конкретной задаче -- очень хорошая будет результативность и авторитет "в цеху" ПЛИСоводов, если реализовать (как тут не раз просилось) логический анализатор типа СигналТапка Альтерного, но с функционалом сохранения-чтения на внешней памяти, который сможет не только тычки фиксировать, но и периоды между ними, выгружать всё наловленное по JTAG-у более-менее быстро, а ширину шины входных контрольных точек не ограничивать вообще. Памяти внутренней не хватает всегда, а DDR -- вагоны, только надо суметь накопить данных об изменениях в небольшом буфере накристаллки, в каждую дырку обменов на DDR встрять и вылить пачку в кольцевой буфер... Как-то б ещё вместо СТапка (или параллельно с ним) подключаться к записываемой в него шине данных -- её Квартус отлично формирует в GUI своём...
Хостовую прогу тоже бы неплохо написать свою, чтоб из ПЛИС по JTAG читала параметры этого анализаторного ядра, стартовала-стопила-отображала времянки -- и выложить потом на свободный доступ !
Автор такого конгломерата будет гораздо выше среднероссийского плинтусного уровня !
Дополнительного функционала тогда все ещё запросят индивидуально, но тогда уж можно начать бабки стрелять
У нас на фирме давно пытаются сделать такую PnP-ядрищу, чтобы и имена контрольных точек хранила в прошивке сразу, но пока тяжеловато... Я ещё прошу быстрый/широкий интерфейс внутри платы, чтобы по 32 бита тянуть времянку на девайсе, если что-то явно сдохло, а JTAG не подключён -- дело жизненное, глюки не всегда бывают, когда их ловят в пробирках, а так во флэшь можно скинуть наловленное и по почте авторам заслать с объекта...

Так может писать только человек, который никогда не искал хорошего FPGAшника

И много Вы видели людей, которые одновременно и 1С знают и драйвера писать умеют?

Уважаемые участники. Остаемся в пределах темы ТС, не сваливаемся в размышления о жизни (с) модератор

Задачи, наверное, разные. А вот мы наоборот - используем процы, когда уж без него никак. В нашем случае у проца удел - коммуникационные стеки TCP/IP, вебсерверы, операционка, параметризация и прочая лабуда.

Зато как просто с железом - еще на этапе концепции задал Spartan или Virtex 6, как и во множестве предыдущих проектов - и не волнуешься, что потом на конечных этапах что-то будет нереализуемо. Также на любую плату с ПЛИС можно легко достать second source, так как начинка одинаковая и различие в мелких деталях. А вот попробуй отыскать похожую плату с Intel Core i3-i5 - кроме чипсета там может быть все разное.

По поводу вопроса "что можно реализовать на ПЛИС такого чего нельзя на МК?", сообщу следующее:
Вот есть, например, такой интерфейс стандарта ГОСТ-18977. Ни в каком МК таких приёмопередатчиков нет, может и есть в каких-то специфических, но я не встречал.
И вот приходится такой модуль воротить на ПЛИСе. Да, можно эти сигналы на порты в/в завести в МК, но а что если нам нужно несколько таких каналов? Ставить несколько процессоров? Тоесть несколько корпусов? Сами понимаете, крайне не рационально.

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

"Back to the Future"? Такое уже было, ещё до изобретения микропроцессоров в 1969 году. Первые калькуляторы, то есть до 1971 года, делали без микропроцессоров..

Jackov
Вот тут вроде есть ГОСТ-18977 с Ethernet (даже с Phy).
WitFed
Лучше всё же модель "обкатать" на Matlab, а не давать FPGAшникам и DSPшникам. IMHO, гораздо дешевле.
Darti
Кстати, интересное направление SDR/SCA на Zynq. Можно попробовать реализовывать софтовые и аппаратные реализации прикладных протоколов. И признание и опыт.

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


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

Сообщение отредактировал Jackov - Sep 18 2014, 17:40

Так никто, вроде, и не спорит, что если автомат состояний (state machine) небольшой, то устройство можно сделать на ПЛИС.
Вопрос в том, что на дешевом МК, причем самыми стандартными инструментами, можно легко сделать конечный автомат с числом состояний 2^{размер_HDD_в_битах},
удовлетворив при этом все самые невероятные хотелки пользователя и превратив, тем самым, этот "конечный автомат" в "полезное в быту законченное устройство".
Не этого ли спецэффекта добивался ТС?

То что у процессора состояний больше это понятно, просто выше спор был, может ли устройство обойтись без процессора.
Но опять таки, количество состояний это ведь не единственный показатель. Вот например, когда передаётся кадр через Езернет, ПЛИС успевает подготовить следующий, и передаётся он сразу после передачи предыдущего, получаем максимальное число кадров в единицу времени. Можно такого же добиться на процессоре? Я вот даже не знаю. С учётом того что процессор должен заниматься ещё и второстепенными задачами.
Всё же у ПЛИС, есть свои преимущества.

У меня есть пример работы для ПЛИС не реализуемой на МК.
512-канальный частотомер. Все асинхронное...

Эт уже не серьезно.
Все знают BeagleBoard. Или вы не знаете?
Там нет никаких ПЛИС, но он в легкую имея на борту еще и линукс отрабатывает протокол EtherCat на шине 1 Gbit.

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

А вот разработчикам на микроконтроллерах на ПЛИС оглядываться не нужно. Их тему одним голым ПЛИС-ом без программирования не закроешь по любому.

Мастер или Слейв?

Очень правильно сказано.
А техническим руководителям - ждать когда же наконец появится мультиядерный процессор/DSP на которым можно сделать то, что пока приходится делать на ПЛИС

так зачем, ждать, если двуядерный ARM A9 уже внутри ПЛИС
PS скоро появится Quad-Core 64-bit ARM Cortex-A53