Здравствуйте, уважаемые форумчане!
Стоит задача в реальном времени делать БПФ с частотой оцифровки не менее 600 МГц, входной сигнал комплексный, поступает с 12 разрядных АЦП, количество точек - 1024. Данные обрабатываются непрерывным потоком. Склоняюсь к применению Virtex-7.
Судя по даташиту на LogiCORE IP Fast Fourier Transform v8.0 одним IP ядром не обойтись, т.е. нужно делать конвейер или что-то в этом духе. Вопрос к людям, имеющим реальный опыт разработки высокоскоростных систем ЦОС: является ли данная задача потенциально решаемой, или даже и возится не стоит?

На правах совета, если область использования подойдёт то можно вот - полифазное БПФ

http://www.dsplib.ru/content/polyphasefft/polyphase.html

Снизит частоту поступления данных, но есть ограничения на применение.

Нужно делать именно БПФ. Задача связана с формированием OFDM.

Надеюсь, Вы не скользящий БПФ вычислять собираетесь, когда БПФ вычисляется с каждым отсчетом входного сигнала?
Задача решаемая.
Но БПФ надо делать самому, и архитектуру его вычисления подбирать, чтобы уложиться в жесткие тайминги и логические ресурсы.
Реально работает БПФ 128 точек на 1000 МГц, правда на Альтере.

FFT Radix-2 За 1 такт расчет 2-х точек, соответственно 600МГц -> 300МГц. Уже нормальная частота

..ещё можно входным сигналом - минуя АЦП промодулировать лазер, лазер подать на призму с призмы сфоткать ПЗС матрицей , с матрицы снять БПФ получившийся .

Спсибо. БПФ не скользящий. Набрали 1024 семпла - посчитали.

Приветствую!

Без проблем такое. Но естественно придется паралелить обработку. В зависимости от структуры последующей обработки либо делая параллельное FFT (несколько параллельно работающих FFT меньшей длинны и объединяющая "бабочка" на выходе), либо запуская несколько одинаковых FFT нужной длины работать по очереди и мультиплексирование на выходе.

У меня так вот сейчас в реале считается 2K точек FFT для 2.2 GHz данных, с окном и перекрытием 50 % (суммарно 4.4 Gs/s). 8 потоков FFT, Правда поскольку данные реальные то на длине FFT сэкономил в 2 раза, считая входные данные как 1024 комплексные с последующей коррекцией на выходе. Сами FFT стандартные из coregen.

Все это добро занимает ~25 % в Virtex5sx240 и работает на 312 MHz.

Успехов. Rob.

А записать весь поток и потом посчитать, нельзя никак? связь не сеансовая?
А то записали бы не спеша на несколько винтов, а потом считайте хоть 64к БПФ.

Такой вариант тоже рассматривается. Но на передаче все равно надо БПФ делать. Поэтому от реалтайма не уйти.



Круто. Спасибо за информацию. Вдохновляет))

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

Линия однонаправленная, от гипотетического устройства поступают данные их надо в реальном времени замодулировать (тут то и надо посчитать БПФ) и передать.
На приемной же стороне допустимо оцифрованные данные записать и обработать позднее.
Т.е. в общем случае БПФ нужно делать в реальном времени.

Извиняюсь за флуд, кажется мы с Rob одним и тем же занимаемся
Задача ТС вполне решаема, 7 виртекс для этого врятли нужен, но будет не лишним. А вообще нужно в сторону кинтексов посмотреть. По Фурье – во многих случаях можно обойтись корегенератором. Само фурье поддается распараллеливанию, так что были бы ресурсы... Ну и как Rob написал, если сигнал действительный, то можно сэкономить на мнимомй ветви, заставив ее работать.

Свежая статья из Xcell Journal Issue 82 : "Using the Parallel FFT for Multigigahertz FPGA Signal Processing" Вам в помощь .

Познавательно, спасибо.

Всем спасибо за советы!

Поясните, пожалуйста, это момент. Как имея комплексное БПФ и действительные отчеты снизить количество точек БПФ?

http://electronix.ru/forum/lofiversion/index.php/t91130.html

http://electronix.ru/forum/lofiversion/index.php/t82229.html

Спасибо.

Могу дать один совет.
Лучше написать самому FFT на Xilinx.
Это даст Вам возможность полностью выжать быстродействие, уйти от шины AXI,
а главное - распараллелить процесс вычисления как Вам нужно.
Я пошел по этому пути, как бы не соблазнительно было использовать коре от Xilinx,
но как показала практика, не зря, все универсальное, к сожалению, не работает там, где
нужно выжать скорость и использовать не так много ресурсов плис.
Удачи.

..выложите вашу корку и люди будут вам благодарны.

Чуть возражу, что бы никто не пугался — AXI совершенно опционально, есть ядро у xilinx и без него. Pipelined версия ядра Xilinx разводится на хороших частотах. И как бы там ни было, писать свое фурье долго и часто не целесообразно. А то может получится что time-to-market сравняется с временем жизни проекта

Поддерживаю