Все нижепречисленное для случая, когда процессор занимает несколько процентов, ну пару десятков процентов в 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 запросов клиентов?