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

[Aprox]

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

[des00]

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

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

2 zltigo

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

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

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

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

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

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

2 CaPpuCcino

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

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

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

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

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

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

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

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

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

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

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


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

[blackfin]

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

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

[Postoroniy_V]

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

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

[blackfin]

ыыы....как бы это...а где тут место для плис то???

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

[Postoroniy_V]

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

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

[blackfin]

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

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

[yes]

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

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

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

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

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

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

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

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

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

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

[blackfin]

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

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

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

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