Перейти к содержанию
    

А в каких случаях лучше использовать ПЛИС(FPGA) вместо микроконтроллеров?

Если нужно быстрее - поствим паралельно чуть больше FPGA :) и получим РЕАЛЬНО паралельную обработку за такт

Нету таких толстых FPGA.. По крайней мере для 65536 точек их РЕАЛЬНО нет.. :)

 

А если делать так же как в DSP - "бабочку за бабочкой", а потом "stage за stage", то никакого значительного преимущества от FPGA-параллелизма над DSP и вовсе не будет..

 

Все будет определяться частотой клока, а он у DSP в среднем по больнице в разы выше.. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую

 

НУ давайте фантазировать

 

XCVU13P - DSP : 11,904 штук - тоесть - если берем radix4 бабочку то на одном чипе 1 stage поместится (65536/4 * 0.75) а нужно то всего 8 stage - фи, 8 чипов всего - даже оптимизировать лень ;)

 

Успехов! Rob

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

О какой "полной хардварной параллельности" Вы ведете речь?

 

О гибкой хардварной параллельности мы говорим. Хотите, делайте все последовательно, но долго, зато с малым количеством ресурсов. Или же задействуйте все ресурсы что у вас есть, и получайте быстрый результат. Кроме того, на оставшихся ресурсах можно делать в параллель другие задачи.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

НУ давайте фантазировать

Про комплексное_умножение = 4*вещественное_умножение не забыли? :)

 

А про 65536*4 гигабитных трансивера не забыли? :)

 

Или же задействуйте все ресурсы что у вас есть, и получайте быстрый результат.

Это всё "бла-бла-бла".. Пока не возьмете в руки калькулятор и не посчитаете "все ресурсы, что у вас есть".. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Про комплексное_умножение = 4*вещественное_умножение не забыли? :)

Можно 3.

 

Это всё "бла-бла-бла".. Пока не возьмете в руки калькулятор и не посчитаете "все ресурсы, что у вас есть".. :)

 

Как принято меряться у нас толщиной, берем самую популярную функцию в ЦОС - умножение с накоплением (MACС). Каждый DSP может это делать 1 раз в 1 такт. Предположим средняя скорость работы каждого DSP блока 500 МГц, предположим, что вы не дочка Рокфеллера, и у вас есть всего лишь ПЛИС с 2000 тыс DSP блоков. 2000*500 МГц= 1 000 000 МACС/s = 1 TMACС/s

Ваш DSP так умеет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветству!

 

Про комплексное_умножение = 4*вещественное_умножение не забыли? :)

Нет - при этом помня про то что вобще все умножение будет на константы да и гектар логики пустой имеется.

 

Так что задача посчитать за ТАКт 64K FFT полностью паралельно сейчас не кажется фантастикой

 

Это всё "бла-бла-бла".. Пока не возьмете в руки калькулятор и не посчитаете "все ресурсы, что у вас есть"..

Естетствено это "бла-бла-бла" надо же чемто занятся пока 64K FFT корка компилируется в FPGA :) - Для оченки требование к РЕАЛЬНОЙ системе нужно имет РЕАЛЬНОЕ тз на нее. Это всегда важно для DSP пректов ну а тем более для FPGA, посколку чем конкретнее требования тем больший профит можно получить от оптимизации.

 

Успехов! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как принято меряться у нас толщиной, берем самую популярную функцию в ЦОС - умножение с накоплением (MAC). Каждый DSP может это делать 1 раз в 1 такт.

Небольшое уточнение:

 

Каждый DSP может это делать 2 раза в 1 такт.

 

2000*500 МГц= 1 000 000 МAC/s = 1 TMAC/s

Ваш DSP так умеет?

А надо?

 

Приветству!

Да хватит уже меня приветствовать! Утомили! :biggrin: :laughing:

 

Так что задача посчитать за ТАКт 64K FFT полностью паралельно сейчас не кажется фантастикой

Никто и не говорил, что "кажется"..

 

Я пробовал считать (только P&R, не в железе) на XC7VX690T. 128К@32bit влазит, но впритык по BRAM. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Небольшое уточнение:

 

Каждый DSP может это делать 2 раза в 1 такт.

Наверно это неправильные пчелы....

 

А надо?

Надо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Наверно это неправильные пчелы....

Самые обычные пчелы:

Blackfin+ core with up to 400 MHz performance

- Dual 16-bit or single 32-bit MAC support per cycle

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Но у меня сложилось впечатление, что кроме гемороя и доп. сложнеостей использование ПЛИС ничего не дает в большинстве случаев. По сравнению с MCU.
Задача из реального проекта: Есть АЦП 100 МГц, который выдает данные по обоим фронтам тактового сигнала, т.е. 200 Msp/s. Эти данные нужно без пропусков записать в память в количестве 262144 отсчета. Данная операция повторяется n количество раз. При этом данные в память нужно не просто записывать, а записывать с накоплением, т.е. суммировать каждый отсчет с содержимым той ячейки, в которую он пишется. Потом все эти данные читаются из памяти таким же сплошным потоком и выдаются на дисплей, при этом операция усреднения происходит прямо на лету, непосредственно при чтении.

Или такой пример: периодически на ножку нужно выдавать импульс заданной длительности. Импульс выдается относительно некоторого события несколько раз подряд. Но каждый последующий момент выдачи импульса должен смещаться относительно предыдущего на 3 нс.

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

Я считаю, что МК и ПЛИС занимают каждый свою нишу и выбор здесь должен идти по вполне конкретным требованиям, присущим конкретно взятому проекту: быстродействие, потребление, стоимость и т.д.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Самые обычные пчелы:

 

Звиняйте, не досчитал. У Xilinx 4 MACC за один такт при разрядности 12 бит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У Xilinx 4 MACC за один такт при разрядности 12 бит.

Для длинных FFT "разрядность 12 бит", это не актуально! :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можно 3.

Звиняйте, не досчитал.

И, кстати, раскройте секрет, как Вы одно комплексное умножение сводите к трем вещественным:

 

(b.re + b.im*j) * (cos[2*pi*k/N] + sin[2*pi*k/N]*j) = (b.re * cos[2*pi*k/N] - b.im * sin[2*pi*k/N]) + (b.re * sin[2*pi*k/N] + b.im * cos[2*pi*k/N])*j == ???...

 

А что дальше?

 

:biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Надежность в любом случае зависит от старательности разработчика. Как для МК, так и для ПЛИС. Пр

 

Но разница есть. И она ГИГАНТСКАЯ.

 

Микроконтроллер выпускается годами миллионами штук.

Микроконтроллер тестировался в работе миллионами разработчиков.

В результате его архитектура "вылезана/вычещена до звона".

 

Чего не скажешь про плисину, выпускающуюся в одном-двух экземпляров.

Там скрытых багов закопано больше чем у блохастого пса вшей.

И они могут проявиться в самый неожиданный момент

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Я считаю, что МК и ПЛИС занимают каждый свою нишу и выбор здесь должен идти по вполне конкретным требованиям, присущим конкретно взятому проекту: быстродействие, потребление, стоимость и т.д.

 

Именно, что не знаете!

Вот что удивительно, человек не знает всего спектра микроконтроллеров и тут же утверждает чего на них сделать нельзя.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Гость
Эта тема закрыта для публикации ответов.
×
×
  • Создать...