[aprox 0]

Если уже есть FPGA в которой осталось лишнее место, то почему бы не засунуть в неё и процессор?

А лишние слоты времени в шине доступа, например к DDR2, тоже остались? Представляете, сколько сразу проблем возникнет, чтобы вклиниться софтпроцессору к внешней памяти, если она уже используется для основной деятельности FPGA. Я просто не понимаю, зачем искать лишние приключения?

[Postoroniy_V 0]

А лишние слоты времени в шине доступа, например к DDR2, тоже остались? Представляете, сколько сразу проблем возникнет, чтобы вклиниться софтпроцессору к внешней памяти, если она уже используется для основной деятельности FPGA. Я просто не понимаю, зачем искать лишние приключения?

да остались :)

не представляю(у авалон свич фабрик путь болит голова)

не понимаете...ну что ж делать бывает :)

[aprox 0]

А лишние слоты времени в шине доступа, например к DDR2, тоже остались?

да остались :)

Значит, FPGA выбрана неэффективно, с большой переплатой.

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

не представляю(у авалон свич фабрик путь болит голова)

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

[Postoroniy_V 0]

да остались :)

 

Значит, FPGA выбрана неэффективно, с большой переплатой.

 

не представляю(у авалон свич фабрик путь болит голова)

 

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

 

да скорей всего так и есть, вам виднее, я ничего не выбирал :)

да авалон свич фабрик страшная весчь, никто не знает где его взять :)

что есть высокопроизводительная обработка видеоизображений ? фотошоп запускаете на ниосе?

[des00 25]

Значит, FPGA выбрана неэффективно, с большой переплатой.

 

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

 

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

 

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

 

И не рекомендую так узко оценивать круг задач решаемых на фпга и возможные пути их решения.

 

2 CaPpuCcino

 

ваши примеры лишь ещё раз утверждают мои высказывания.

 

с позиции здравой логики это очевидно %)

 

2 zltigo

 

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

 

Мамы разные нужны, мамы разные важны (с) С.Михалков

 

Вам этого не надо, забудьте и не возвращайтесь к этой теме. Никто не предлагал вам выкинуть свои армы и поставить вместо них софт ядра (если найдете в топике что кто-то вам такое предлагал, простите его, он бредит).

 

Вы гуру, вам все виднее, не обращайте внимания на наши ковыряния в песочнице софт процов. %)

[CaPpuCcino 0]

интересно, скоро дойдёт до вызывов на дуэль... :yeah:

[zltigo 2]

Никто не предлагал вам выкинуть свои армы и поставить вместо них софт ядра..

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

Вам этого не надо, забудьте и не возвращайтесь...

меня куда-то?

[aprox 0]

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

Эффективность я измеряю соответствием тому принципу, ради чего собственно FPGA и создавалось- параллельность действий на аппаратном уровне. Внедрение софтпроцессоров, шин с множественным арбитражем доступа - это отход от первоначальной затеи и опускание FPGA до уровня автомата последовательного действия. Hо в этой сфере любой готовый MCU дает сто очков форы. И не требуется той траты нервов и времени, чтобы "утоптать" неутаптываемое, как вы образно пишете.

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

И не рекомендую так узко оценивать круг задач решаемых на фпга и возможные пути их решения.

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

 

Мамы разные нужны, мамы разные важны (с) С.Михалков

 

Пусть сияют тысячи солнц! Пусть цветут тысячи цветов! (с)- Мао.

[des00 25]

2 CaPpuCcino

 

интересно, скоро дойдёт до вызывов на дуэль

 

не вижу причин, идет обычный флуд, отчасти по делу.

 

2 zltigo

 

читаем внимательно до конца.

 

Вам этого не надо, забудьте и не возвращайтесь к этой теме

 

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

 

2 Aprox

 

Эффективность я измеряю соответствием тому принципу, ради чего собственно FPGA и создавалось- параллельность действий на аппаратном уровне.

 

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

опускание FPGA до уровня автомата последовательного действия

не верно.

 

Hо догадываюсь, что вы потратили массу времени и сил на освоение софтядер,

 

время на это тратиться не много, 3-4 обзорных статьи с альтеры вам будет достаточно что бы въехать в курс дела.

 

и вопросы эффективности теперь сводятся к пословице: "лучшее- враг хорошего"

 

скажу честно, было время когда я думал как вы, но многоуважаемый Bill снял с меня розовые очки, сказав аналогичную фразу.

 

ИМХО работать надо по принципу "проект укладывается в ТЗ ? все баста карапузики, идем дальше : доводим функциональность до ТЗ"

 

 

Удачи !!!

[CaPpuCcino 0]

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

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

[zltigo 2]

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

Да, и не думать не мог, что Вам трудно даже название топика прочитать, прежде, чем в него писать :(. Так вот, топик называется "О целесообразности всяких ниосов в FPGA", а не так, как Вам показалось/захотелось. Мне позволительно было в рамках названной темы высказать свое мнение?

[CaPpuCcino 0]

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

ну раз флуд, давайте, я это дело лю:

прикольная новая классификация! :) ну ветвь понятно - у нас домохозяет это называется поток (thread), функций тож понятно - параллелизм задач(task), комманд дано полагать это параллелизм инструкций (ILP как в VLIW), ещё забыт паралеллизм операций (OLP как в любом конвеере), но вот что скрывается под параллелизмом объектов? (в смысле трудно представить как они могут существовать непараллельно?)

[blackfin 32]

... но вот что скрывается под параллелизмом объектов? (в смысле трудно представить как они могут существовать непараллельно?)

Так если их (объекты) в FIFO затолкать (не спрашивайте зачем, - не знаю..), то будут "существовать непараллельно"..

 

 

...перечислить проекты где применялись софт процы...

Я, лично, вопрос понял так же, а выводы каждый желающий должен был сделать для себя сам..

 

Хм.. Правда, это был уже другой участник:

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

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

ЗЫ: я чесное слово понимаю что идея сконфигурировать процессор последовательной интерпритации инструкций на ПЛИС - это круто. но так ли это эффективно по сравнению с полностью задача-оптимизированной системой на кристалле?

Изменено 30 июля, 2008 пользователем blackfin

[CaPpuCcino 0]

Так если их (объекты) в FIFO затолкать (не спрашивайте зачем, - не знаю..), то будут "существовать непараллельно"..

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

[aprox 0]

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

Тут, по-моему, очень хорошо получается остаться в топике. Отбросим игры в красивые термины, а попросту возьмем простейший пример- реализация FIR-фильтра в FPGA. По-существу, это длинный сдвиговый регистр, много умножителей и один сумматор. Умножения и суммирование здесь производятся одновременно, за один цикл поступления данных. Что здесь существует параллельно, данные или операции,- неважно. Важно, что на софтпроцессоре последовательного действия такой же скорострельности фильтра никогда не достичь. Это один из тех примеров, когда ниосы не нужны и даже вредны. Более того, глядя на задачи скоростной обработки данных, я рискну заявить, что софтпроцессорам там тоже нет места. Потому, что проект в конечном счете приходит к некоторому разветвленному конвееру, каждый узел которого работает одновременно с остальными. Софтпроцессор такое принципиально не может. Поэтому, дело даже не в эффективности, не в стоимости, а именно в принципиальной невозможности применить софпроцессор в быстродействующей конвеерной обработке данных. И этот тезис очень сильно расходится с залихвасткой рекламой, например Альтеры, мол "ниосы могут все!"