Не дурят ли нашего брата?, О целесообразности всяких ниосов в FPGA. Опции

[Aprox]

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

[LeonY]

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

[CaPpuCcino]

А нафига писать, если Вам и так все ясно? Или не ясно?

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

[Postoroniy_V]

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

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

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

[CaPpuCcino]

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

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

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

ок. поищу

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

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

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

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

Так что испытываю глубокое уважение к создателям софт-процессоров от Альтеры, сколько это надо иметь пядей во лбу, чтобы изобрести такое!
Но опять же, все определяется условиями задачи..

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