Я конечно могу жутко ошибаться, но покумекав на предмет применения процессорных ядер а матрице пришел к выводу, что не стоит овчинка выделки. С одной стороны создается монстр, с внешней шиной DDR2 и FLASH , а с другой он работает не лучше и не быстрее напичканных периферией ARM9. Спрашивается- нафига козе баян? Не проще ли использовать какой-нибудь готовый чип с ядром ARM? Чем хороша FPGA, где она вне конкуренции? На мой взгляд там, где нужно вести несколько тредов параллельно на аппаратном уровне. И какой смысл в данном случае опускать FPGA до конечного автомата последовательного действия - я не понимаю. Короче, для себя принял стратегию использовать FPGA только в связке с микроконтроллером со встроенным Flash. Много проблем, включая загрузку и защиту проекта сразу решаются автоматом. А ниосы пусть отдыхают в сторонке. Рекламные трюки на нас не действуют!

Вот нравятся мне такие категоричные заявления Типа "вы там все дураки, один я умный". А нафига писать, если Вам и так все ясно? Или не ясно? Тогда может форму послания изменить? Contradiction имеет место быть...

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

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

3)не подошли внешний проц+плис потомучто имеется п.1

странно, что эта тема "торкнула" вас только сейчас. тема неоднократно обсасывалась на этом форуме, в том числе были примеры реальных проектов. Чуть не дошло до холивара.

рекомендую почитать.

что касается моих проектов мне крутые софт процы без надобности. А небольшого размера : пикоблейз и самописный использовал, для отладки, медленного управления или что бы "патроны подносить".

может доживу когда потребуется ниос )

"Элементарно, ватсон"
Если уже есть FPGA без которой уже никак и нужен небольшой проц для юзер-интерфейса или чтоб не городить огромный автомат состояний или для верхнего логического уровня интерфейса, и т.п. то удобнее засунуть небольшой проц внутрь уже существующей фпга. Это же упрощает конструкцию и HDL-код.
Но вот если задачи чисто-процессорные с ба-а-льшой логически-развитой программой, то фпга нисколько не выгоднее специального проца.
По этому поводу уже высказались более мудрые товарищи. Суть такова: "не нравится - не ешь".
А еще - "колхоз- дело добровольное. Не вступишь-расстреляем."

А отдельный чип загрузки FPGA почему не считаете? Тоже ведь денег и места на плате требует. Конструкция FPGA+внешний проц мне представляется эквивалентной по п.1.

2 Aprox - отдельный чип загрузки не сильно много места занимает

Применял FPGA в задачах ввода быстрых аналоговых сигналов(полоса до 20 MГц) , сжатия поступающей информации и передача ее в PC. Одновременно, устройства должны были "управляться" со стороны PC и вручную, через переднюю панель прибора. Решил, что управляемостью прибора должен заведовать отдельный микроконтроллер потому, что он для этого и заточен со всей своей встроенной периферией. А FPGA пусть будет по-минимуму цены и сложности, заниматься только быстрыми задачами, которые не по зубам микроконтроллеру. Очень удобно оказалось использовать избыток FLASH микроконтроллера для загрузки FPGA.

Сейчас встала задача управления прибором, который должен запускать IP-пакеты с данными в сеть со скоростью до 200 Mbps. Речь идет о 1G Ethernet. Микроконтроллеров со встроенным MAC на такие скорости не найти. Поэтому эту часть работы отдаем FPGA, а отдельному микроконтроллеру, как и раньше - управление прибором в целом.

дык а внешний проц без внешней памяти? если да, то спору нет, а если внешние flash + ram, то один чип экономится
в софт-процессоре.

Главное в применении связки FPGA + MCU - условия задачи. Рискну высказать свое мнение.
NiosII хорош, но очень сложен, а обучать Альтера хочет за деньги... К сожалению, в горах документации найти зерно истины - все равно, что добывать уран из гранита. Но когда NiosII освоен, пользоваться им очень приятно, т.е. создан как бы барьер для непосвященных... Зачем только, не понятно.
Мое применение - цивильная прибрежная радиолокация, первичная обработка, без FPGA здесь не обойтись. АЦП 25 МГц и всякие мудрые алгоритмы. Здесь NiosII применен пока для управления и передач по Ethernet 100 на уровень вторичной обработки. Очень нравится мне идеология "пользовательской переферии" со спец.операциями в том числе, а также внутренняя память в FPGA, когда можно делать большую ширину слова с данными... Сигнальные процессоры с такими алгоритмами не справляются, к сожалению. Так что испытываю глубокое уважение к создателям софт-процессоров от Альтеры, сколько это надо иметь пядей во лбу, чтобы изобрести такое!
Но опять же, все определяется условиями задачи..

Вставлю свои 5 копеек ....

Я разрабатываю на проекты на ниосе достаточно давно и могу сказать следующее.
В первую очередь все зависит от задачи - никто не сомневается что ARM9 или BLACKFIN ядра по вычислительной производительности уделывают ниос2.
Но ведь вычислительная производительность ядра не всегда нужна.
К примеру нужно сделать систему с таким набором периферии где есть 10 уартов, которые работают на скорости 115200 а то и больше , + ещё что-нибудь .
И при всём при этом вам необходимо с SD карточки выводить на экран картинку с разрешением 1280х1024 х16
да ещё и анимацию крутить с нормальной скоростью.

Вот и получается что - решить такую задачу уже на каком-нибудь процессоре не выйдет даже если у него 600 Mhz тактовая (периферии то такой нет на борту) - надо городить фпга да схему связки с процессором на который надо замыкать весь поток данных, а если уже есть фпга, то гораздо логичнее поставить ядро НИОС2 - будет и дешевле и проще.

В моём текущем проекте к примеру не 1 монитор а 2 - и всё на ниосе и тут уж точно использование внешнего процессора, как по мне нецелесообразно вообще.

А ещё не следует забывать о такой вещи как errata для процессоров - допустим не работает ДМА там где оно должно, или ещё бог знает что, а проект уже запущен и плата готова.
На ФПГА в этом отношении полная свобода - всегда можно всё изменить и сделать так как хочется, путём создания своей собственной периферии.


Вот к стати что парни недавно сделали на Ниосе
http://www.tesbv.com/index.php?site=TES_EN_1_dave
Так что Ниос вещь очень хорошая, если правильно понимать как им пользоваться.


p.s.
В идеале на мой взгляд это решения где есть CPU HardCore ядро, которое находиться внутри фпга.
но к сожалению на данный момент это редкость, да и дорого стоит.

он почему-то требует поменьше места и денег
но всё очень и очень зависит от внешнего проца
он конечно же может быть и pic12


ну...началось...
не умение читать доки это не минус софт проца

Ну если не говорить конкретно о NIOS, а вообще о softCPU, то кто мешает использовать Actel продукты. Там, например, на Fusion можно добиться действительно Single Chip Solution. А все остальное представляемое как Single Chip Solution - маркетинговое фуфло: нужны еще кристалл, пару-тройку Voltage Regs. Так что на фоне всего этого SO8 SPI загрузочная память и по цене и по размерам - below noise. Хотя никому не посоветую использовать Actel - но это персональное, не люблю я их, хотя вынужден работать.

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

Все нижепречисленное для случая, когда процессор занимает несколько процентов, ну пару десятков процентов в FPGA. Что на данный момент времени встречается в очень больших и дорогих проектах на толстых FPGA, или при достаточности уж совсем мелкого вырожденного контроллерного ядра. Для мелко-средних массовых FPGA использование хоть cколь-нибудь приличного пороцессорного ядра тянет за собой использование явно избыточных FPGA и обвеска их, как минимум памятью. Это получается и громозче, и дороже использования массового ( но достаточно мощного хотя и несколько баксового) контроллера с Flash/RAM на борту. FPGA естественно толстеют и дешевеют и ситуация меняется на глазах, но на данный момент для большинства применений CPU+FPGA оптимальнее.

Имхо, вы забыли вставить ИМХО в начале

По-моему от периферии требуется соблюдение стандартов функционирования, но никак не гибкость и не скорость. За такие "коры" стандартной периферии, Альтера например, хочет слишком много денег при том, что ее FPGA как правило идут в изделия очень малыми сериями, а то и вообще- разовый заказ. Hе проще ли взять простой и дешевый чип MCU со всей готовой стандартной периферией на борту? По-моему, гораздо проще.



Прошу извинить за невольные обиды. Хотел выяснить другое: почему, например Альтера, с такой настойчивостью продвигает Soft-процессоры в FPGA, когда преимущества их в реальных конструкциях устройств совершенно неочевидны, и даже вредят основной идее FPGA- настоящая ПАРАЛЛЕЛЬНОСТЬ выполнения задач. Я ни разу не встретился с жестокой необходимостью вставлять какой либо Soft-процессор в FPGA. И. собственно, хотел узнать от других про задачи, в которых без ниосов никак не обойтись.

Пастернака я не читал, но осуждаю

arexol же вам примерную задачу описал - 4 sdram контроллера, 2 видеоконтроллера с кучей фишек, 8 uart, ethernet, sd (в режиме sd), spi, i2c, 64 пина io, и т.п. Все описаное необходимо. Назовите мне примерную конфигурацию, выполненную на микроконтроллере.

Нет. На данный момент это практически объективная реальность. Стоимость и размеры FPGA в которой можно собрать 5-10 баксовый контролер в разы превосходит стоимость такого контроллера. Посему запихивать в FPGA контроллер в 95% случав логично, когда ресурсы FPGA используется более, чем на 90% для других целей и контроллер в "уголке" этой FPGA получается "бесплатный". Вы каких размеров FPGA пользуете? Лично я пока уровня циклон2-3 - своего железа наворотить уже можно в нем очень и очень много, а собирать там, например, дохленький ARM со сколь-нибудь памятью - совершенно расточительно. Если навешать внешнюю память, то вроде и не смертельно по остальным ресурсам, но нафига, если вместо памяти можно настоящий копеечный ARM навесить....

В NiosII есть три метода ускорения для математики (см. Embedded Design Handbook, edh_ed_handbook.pdf, стр.20):
1. C2H accelerated software, аппаратное выполнение функций, очень мощно.
2. Custom instructions, дополнительные инструкции, любые!.
3. Custom peripherals, это еще более сверх-вешь.
И всем этим можно пользоваться без ограничений. По моему, универсальные CPU и MCU такими свойствами не обладают, Даже если вокруг них поставить несколько FPGA, то все равно возникнут проблемы с узостью интерфейсов между CPU и FPGA. В NiosII этих ограничений нет.
Да, в моей FPGA на NiosII (Fast) ушло 7% ресурсов, это тоже значимо.
Опять же, все определяется условиями задачи.

п.1. - это теория. мы сами писали теоретические ворчалки с доказательствами подобных замечательных выгод и даже более того скажу о необозримых горизонтах открывающихся при применении концепции Application Specific Instruction Set, но на счёт последнего задача автоматизации ASIS оказалась сравнима с задачей поведеньческого синтеза (по трудоресурсам) и нам её поднять по финансовым причинам не выдится возможным.
п.2. так вот и хотелось бы услышать что за каналы (скорость потока), сколько их было, и сколько удалось разместить таких процессоров и какие задачи они выполняли (я так понимаю только обработку заголовков). иначе это снова п.1


ок. поищу

вот видите-ли, в этом то и загвоздка. я не вижу надобности в полноценных процессорных ядрах(архитектурах) на ФПГА. по моим ощущениям (мнение которое здесь также было высказано) последовательные интерпретаторы (в просонародии процессоры) необходимы только для интерфейсов к другим частям системы (пользовательский интерфейс, если это плата расширения, телекоммуникационный интерфейс, если сетевой коммутатор, и т.п.) есть другая точка зрения? (видел ссылку на использования ниоса в графике, но на мой взгляд жёсткая логика могла бы быть эффективнее, а использование проца даёт только лишь скорость развёртывания системы на кристалле)
я маленькие "процессоры" сам использую в алгоритмах, но это именно самописные задача-ориентированные процы последовательной интерпритации (в моём случае в основном стековой архитектуры). процессоры со своей ISA в моих задачах я не могу назвать эффективными совсем (именнов алгоритмической части, а не интерфейсной)


вот у меня тоже абсолютно подобное ощущение


это совсем и далеко не их идея и даже концепция. например см. разработки HP labs. (PICO program-in chip-out), Tensilica (например Xtensa), и т.д. (мы пытались продвинуть сходный по принципу с PICO подход)

Свои 5 копеек вставлю. IMHO

Встроенный софт процессор может:
1. Сэкономить выводы ПЛИС.
2. Сократить номенклатуру.
3. Уменьшить трудоемкость сборки.
4. Уменьшить вероятность возникновения ошибок при сборке и соотв. время их устранения.

это имеет какое-нибудь отношение к эффективности реализации целевого алгоритма?
1. сэкономить выводы ПЛИС относительно чего(какого решения /можно реализовывать алгоритм вообще без участия процессора/)?
2. сократить номенклатуру относительно чего(какого решения)?
3. это безусловно (использование любого reusable IP со стандартными интерфейсами уменьшает трудоёмкость сборки, но стандартизованные интерфейсы не всегда эффективны в целевой системе, и стандартные интерфейсы бывают и у других типов IP)
4. это не безусловно, потому как софт-процессор не является единственным вариантом reusable IP

Ага, для навешивания, например, внешней 32bit памяти потребной этому софтпроцессору а без такой "мелочи" либо получится микроскопический процессор, либо он обойдется достаточно дорого.

Слишком абстрактно - BOM любого приличного устройства и так изрядно обширен, а контроллеры по нынешним временам совсем не дифицит.

Или увеличить ибо размер внутренних ресурсы к сожалению сильно коррелирует с корпусом и улететь на много более здоровый корпус и дополнительные слои в печати можно очень легко..

См. п 3. А устранение ошибок при "хорошем" BGA со хорошей стоимостью вообще-то совсем не рентабельно. А локализация через Boundary Scan достаточно эффективна при любом количестве чипов.

IMHO конкуренцию составят очень серьёзную. И, возможно, очень скоро.
Лед тронулся STM уже объявили:
средняя модель - SPEAr BASIC ARM 926, 300Kgates , LFBGA289 package
старшая - SPEAr Plus600 Dual ARM 926, 600Kgates, PBGA420 package

ЗЫ: Только вот куда по ним сообщения постить - в FPGA или в ARM?

строго говоря PSoC на рынке уже пару лет присутствуют см. например http://electronix.ru/forum/index.php?showtopic=33095&hl= (микроконтроллер + hard-cores сетевая переферия + ПЛИС обвязка). когда к таким изделиям будет интерес, думаю будем открывать отдельную смежную ветку, либо обсуждать вопросы касающиеся конфигурабельной части таких систем здесь

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



1)Речь шла, насколько смог понять, про софт ядра, а имено ниос.
зависимость от 2-х поставщиков это не теория, это практика.
2) всего 1 ниос, основная задача поддержка snmp, конфигурировния, администрирование


Вообщем наблюдаю два лагеря "дурят" и "не дурят"
Предлагаю провести голосование

Ну блин так и чувствовал что начнется холивар (как раз пятница кстати).

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

2 zltigo



младший ниос ~500 плиток, средний ниос занимает ~800 плиток, младший кулон2 c5 содержит 4608, что то не так в консерватории.



ИМХО вы мыслите другими категориями. Смысла собирать ядро класса АРМ (впрочем как и других готовых процессорных ядер) НЕТ никакого и ждать от него чуда НЕ ИМЕЕТ никакого СМЫСЛА.

Т.к. трассировочные ресурсы и логика сожрет всю производительность и будет либо калека на 20-40МГЦ, либо бегун на 200МГц, но оччень тормозной.

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

2 CaPpuCcino



Что бы не уйти во флуд, тогда уж дайте определение что по вашему "полноценное процессорное ядро".
И что вы от него ждете.

Считать математику на софт-ядрах это бред, ИМХО именно здесь и делают ошибку все кто оценивает их с категории обычных процов.

Вы же сами пишете "необходимы только для интерфейсов к другим частям системы" + я еще добавлю задачи управления, контроля и мониторинга.

"ссылку на использования ниоса в графике, но на мой взгляд жёсткая логика могла бы быть эффективнее" - очень сильно подозреваю что там ниос всего лишь "подносит патроны". А Avalon Switch Fabric используется как системная шина, т.к. она уже готова, гарантировано рабочая и легко конфигурируемая.

Ну есть у вас крутые аппаратные математические акселераторы(движки). Но данные для них лежат во внешней памяти, адрес начала куска данных для работы вычисляется по какому нибудь хитрому алгоритму, но 1 раз на блок + результаты работы блоков нужно еще и синхронизировать.

Какой смысл делать вот это на конечном автомате, тут производительность нужна очень маленькая. Это легко реализуется на проце, который вычисляет адреса и заряжает Scather - Gather DMA контроллеры.

Другой пример ну нужно вам 20 UART каналов, положить в память, объединить и плюнуть ну например в USB. Можно сделать все на логике, но не проще ли (и быстрее) поставить ниос, 20 уарт блоков и приделать интерфейс к усб ?

Сколько времени вы потратите на отладку и разработку первой системы и второй ?

Postoroniy_V привел кста хороший пример "основная задача поддержка snmp, конфигурировния, администрирование"

Еще пример для ленивых : на сайте хилых есть апнота на Пикоблейзе разруливают i2c мастер/слейв. Все просто 96 плиток проц и маленькая прога : готовый мастер без проблем, логику работы которого можно менять на лету.
прикручиваем к нему готовый уарт, вот вам диагностический мост i2c-UART, используемый например при отладке проекта.


ИМХО Софт ядра создавались прежде всего для ленивых, но и профессионалы быстро оценили их достоинства при грамотном их позиционировании. Нужно всего то посмотреть на это с другой стороны.

Жизнь, конечно, одной лишь математикой не ограничивается..
Что Вы, например, можете сказать в оправдание использования софт-процессоров в задачах парсинга запросов HTTP? Текстовые поля в заголовках HTTP могут быть довольно длинными (несколько КБайт), особенно, если требуется поддержка SSL. Самих заголовков тоже может быть много, а если помножить все это на количество одновременно подсоединенных клиентов (например 100), то вообще - мрак.
Как пример - обычная Web-камера с Web-интерфейсом. Можно, конечно, распараллелить задачу, синтезировав несколько процессоров так, чтобы каждый проц, работал со своими клиентами, но где хранить методы/заголовки HTTP? Где, опять же, хранить страницы HTML? В общей для всех процессоров внешней памяти? Тогда какую мы получим скорость обработки HTTP запросов клиентов?

ыыы....как бы это...а где тут место для плис то???
поставьте 1 проц "имени вас" и усё... и веб и дсп обработка с камеры. :-)
жизнь как правило ограничена только смертью..почему то
про здравый смысл все забывают...

Для плис тут место - MJPEG сжатие катринки..

извините я не в курсе - проц "имени вас" сдается здесь?

Смотря "что" и "как" сжимать: Performance Metrics
А если нужно "N-мегапикселей"?

фраза вырвана из контекста, ну если уж холиварить, да еще и в пятницу :

скажите что вы вкладываете в понятие математика ? FIR, IIR, DCT и все ?

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

И опять же не ждал бы чуда от софт проца, который работает на 80-100 МГц, с 5 ти стайдийным конвейером, без нормальной системы предсказания ветвлений и малым кешем.

Как уже было сказано выше, все зависит от задачи.



странно, почему бы не жать mjpeg на проце, вроде не самый сложный алгоритм. или у вас 4К видео ? Почему бы не положить его на дсп бошку от давинчи. а на второй бошке обрабатывать хттп.

2 Postoroniy_V



+1

Так именно в этом и дело! Причем, параллельная обработка тут весьма затруднительна, т.к. лексемм много, они могут иметь разную длину и встречаться в разных местах запроса HTTP в зависимости от структуры самого запроса..
Как раз "крутизна" процессора значения не имеет.. Важна именно частота на которой он работает и объем кэша..

так это очевидно, к чему тогда был ваш пост



если ответ заранее очевиден и известен ?

Не только известен, но и озвучен: "Как уже было сказано выше, все зависит от задачи. "

Причем тут категорический выбор? Не дурят, но на данный момент использование логично только в некоторых нишевых применениях. Граница логичности несомненно сдвигается прямо на глазах

Устойте опрос сколько людей на данном форуме используют вторые стратиксы и узнаете количество людей использующих или задумывающихся об использовании софтпроцессоров



Не вижу такого.

Про память потребную контроллерам не помянули из забывчивости и про относительную мощу младших софтконтроллеров тоже . Говоря о ресурсах не стоит сбрасывать со счетов и то, что кроме ядрышка железныеконтроллеры еще содержат нужные во многих случаях периферийные вещички начиная с банальных UART и кончая контроллерами памяти, MACами...Они ведь тоже при софтизации ресурсов потребуют, причем немалых.

Ну а то, что процессор из "~500 плиток" во многих случаях просто ни нафиг не сдался Вы мысль не допускаете ? Кроме того, та-же Altera начала работать с ARM Cortex ядром.... И ничего особо монстрального в этом уже нет.

в который раз вижу что "вам всё известно заранее"
циклоны1-2 в той форме до сих пор юзают и до сих пор применяют ниос. ниша - телеком.
категоричность взята из названия треда

ндя разговор глухого с немым.

нет не забыл, младший кулон2 содержит 13 килобайт встроенной памяти, для размещения загрузчика и небольшого кеша более чем. Кроме того я видел рабочие проекты где весь код проекта умещался в 8 килобайт и все крутилось во внутренней памяти.

Повторюсь еще раз. все зависит от задачи. Ставить фпга только что бы запустить на ней проц, бессмысленно, готовый проц порвет ее как тузик грелку. (с) dxp.

кстати дайте ответ на вопрос arexol указанный выше :



покажите такой процессор ?



опять же передергиваете. я делал и видел рабочие проекты в которых хватало процессора на 96 плиток. при этом все что требовалось от железа функционировало.

средний ниос, кстати вполне серьезный процессор и весит порядка 900-1000 плиток,
топовый ниос порядка ~1500 - 1700 (вроде такую цифру читал в доках).

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

а если учесть что этот софт арм весит как 2-3 ниоса, и то что их арм основан на AMBA AHB, а не на AXI , то в системе ниосы порвут его как тузик грелку.

Большая часть из описанного прекрасно ложится на готовые современные мультимедийные чипы с ARM9 на борту. За исключением 8-ми UART-ов (их там как правило не более 4-х), и 4 sdram (как правило один). Hу, так и надо все недостающее отдать FPGA. И она оказалась бы совсем не таким монстром, как если все описанное реализовать в SoPC с ниосом.

Покажите облась применения такого "франкенштейна" c двумя LCD и всего остального по 4, по 8 , его серийность... Тогда можно будет и порассуждать о том на чем его делать. Кроме того, здесь идет речь не о замене FPGA контроллерами - исключительно об их сочетании. C учетом того, что те-же ARM9 с приличными набортным LCD, SD и прочими контроллерами баксов за 10-15 продаются то и вариант с прицепить к нему "10 UART" в самой копеечной FPGA отнюдь не безумен.

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

поэтому использование ПЛИС для этого неоправдано

-----------------------------

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

а для заточенных под архитектуру ПЛИС NIOS/BLAZE и соответственно систем и софта для них (тип EDK), более сложная задача, имхо, компилер написать и весь софт/тулы (ну или комплексно, и компилер и архитектуру такую, чтоб по производительности не уступал), чем ксайлинс и альтера успешно занимаются, и наверно, получают прибыль
то есть - раз усилия фирмы прикладывают - значит, какую-то прибыль с софтпроцессоров получают (причем альтера прикрыла ПЛИС с хардпроцессором)

в дополнение к сказаному:
я вижу следующие применения
1) когда DSP приложение вертится на встроеных умножителях, а фабрик используется мало - почему бы туда не засунуть софтпроцессор для управления, всяко проще, чем снаружи контроллер ставить

2) когда мелкая логика (какой-нибудь коммутатор, хитрая glue logic и т.п.) - в мелкой ПЛИСине : стоимость ПЛИС ксайлинкс довел до 2$ в партиях, в розницу реально за 10$, вставить туда пикоблейз или что-то подобное - дешевле, чем снаружи 1$ пик повесить (тем более, что у ПИКов с пинами плохо - нужно какие-то SPI и т.п. - то есть что-то в ПЛИС отожрать на декодирование)

возможно и для средних ПЛИС апроксимировать

то есть использование софт процессоров не для прототипирования ASIC, а для продукта оправдано для ситуации с банкой заполненой камнями (функциональными ядрами) - туда можно засыпать песок (софтпроцессоры). при этом бесплатно.

Потому, что оно совсем неплохое и поддерживается многими средствами разработки, и позволяет проще производить миграцию FPGA+ARM -> большой FPGA c софтпроцессором.

Так, именно про это и спич, что реализовать такое на FPGA -умопомрачительно и никому не нужно. И тем не менее, Альтера дает ссылки на реализацию TCP стека на Си через ниос! Скажете. не дурят нашего брата бессовестные промоутеры?

А лично в повседневной жизни пользую проекты в которых затраты памяти ну никак меньше 60-70K (средние под 200K) не опускаюся. Ну и что мне прикажете делать с голыми FPGA? Использовать старшие стратиксы c десятком мегабит на борту и соответствуюющей им стоимостью вместо 5-6 баксового ARM + 10-30 баксового FPGA?? А оно мне сегодня надо???


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

к слову - миграцию и на ниос/блейз с арма или чего-угодно - не проблема : компилятор есть, ОС правильно брать с открытым кодом (NIOS, если я не ошибаюсь, даже имеет ММУ и порт Линукса)

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

имхо, Cortex они хотят для привлечения прототипистов и еще раз "обдурить нашего брата" на предмет, что АРМ компатибле софтпроцессор уж однозначна стоит использовать

Что, конкретно, подразумевается под "... входного и выходного канала"? PPI? Ethernet? SDRAM? В BF, например, невозможно впихнуть поток HDTV, а в FPGA - можно.

Ну, Вы это вот этим товарищам объясните: Andrey Filippov, 4dsp. Или сожмите на BF533 MJPEG со скоростью 500 frames/s или в 2048 x 2048 пикселей.

потоки, типа HDTV, как-то несерьезно обрабатывать без межкадровой корреляции, предказания движения и т.п.

проект Andrey Filippov-а никак не просто MJPEG

ну а кор разных наделать - не проблема, помоему в корегене есть JPEG (может отдельно DCT и HUFFMAN)
я пытался с некой "общетехнической целесообразности" посмотреть на вопрос