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

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

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

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

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

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



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

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

2 CaPpuCcino



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

2 zltigo



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

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

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

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

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

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

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

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



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

2 CaPpuCcino



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

2 zltigo

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



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

2 Aprox



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



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



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

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


Удачи !!!

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

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

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

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


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

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


Сообщение отредактировал blackfin - Jul 30 2008, 15:21

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

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