[_4afc_ 25]

7 minutes ago, blackfin said:

Длина БПФ равна 262 144. Основание БПФ (кол-во ветвей в "бабочке") равно 64.

То есть, в каждом такте БПФ вычисляются 64 новых комплексных семпла.

BRAM'ы в основном для констант.

В вашем Radix64 DataRAM какой длины и на чём?

 

[blackfin 16]

On 6/16/2023 at 5:12 PM, _4afc_ said:

В вашем Radix64 DataRAM какой длины и на чём?

На URAM. Длина всегда N/Radix.

[_4afc_ 25]

On 6/16/2023 at 5:03 PM, blackfin said:

То есть, в каждом такте БПФ вычисляются 64 новых комплексных семпла.

Интересно, а как решается вопрос с нормировкой и переполнением при FFT262144 на Radix64?

Старшие 18 разрядов при белом шуме - такие же как "знак" или обрезаются? Сколько разрядов на входе\выходе FFT?

[RobFPGA 27]

Все же остается вопрос зачем Radix64?
Да еще  для такой схемы FFT, и для такого чипа FPGA?

[blackfin 16]

On 6/22/2023 at 4:25 PM, _4afc_ said:

Интересно, а как решается вопрос с нормировкой и переполнением при FFT262144 на Radix64?

Старшие 18 разрядов при белом шуме - такие же как "знак" или обрезаются? Сколько разрядов на входе\выходе FFT?

Есть два режима:

- с ограничением при переполнении разрядной сетки;

- со сдвигом на log2(Radix) разрядов после каждой "бабочки".

 

Собс-но, это почти так же как у Xilinx'а.

При этом кол-во разрядов на выходе равно кол-ву разрядов на входе.

 

On 6/22/2023 at 4:34 PM, RobFPGA said:

Все же остается вопрос зачем Radix64?
Да еще  для такой схемы FFT, и для такого чипа FPGA?

Так Latency..

 

При прочих равных условиях и при больших N:

- Radix8 считает в 3 раза быстрее, чем Radix4;

- Radix16 считает в 8 раз быстрее, чем Radix4;

- Radix32 считает в 20 раз быстрее, чем Radix4;

- Radix64 считает в 48 раз быстрее, чем Radix4;

 

Есть много приложений, в которых важно время вычисления FFT:
- радиолокация быстрых целей;

- передача видео в формате DVB-T2 на соревнованиях по гонкам на квадракоптерах;

- связь 5G с использованием OFDM;

- спектроанализаторы на АЦП с частотой дискретизации 20 ГГц (напр., AD9084);

- да мало ли, где ещё.. 🙂

 

Опять же, если ставить впараллель несколько FFT, то с точки зрения BRAM, экономнее параллелить FFT с Radix32 или Radix64.

 

Что касается чипа, то Radix64 на 4096 точек легко умещается в KU5P (12% по BRAM, 64% по DSP)..

Так же легко Radix32 на 32768 точек умещается в тот же KU5P (37% по BRAM, 26% по DSP)..

 

[RobFPGA 27]

6 hours ago, blackfin said:

Так Latency..

При прочих равных условиях и при больших N:

- Radix8 считает в 3 раза быстрее, чем Radix4;

- Radix16 считает в 8 раз быстрее, чем Radix4;

- Radix32 считает в 20 раз быстрее, чем Radix4;

- Radix64 считает в 48 раз быстрее, чем Radix4;

Latency ... 
Я  не зря упомянул "... для такой схемы FFT"  Так как  при такой  схеме  время счета  складывается со временем ввода/вывода данных в буфер.  Да еще и  весь буфер нужно иметь  на полную разрядность на выходе FFT. 
Минимальное latency счета имеют стримовые схемы  при которых расчет FFT идет в процессе ввода/вывода.  При этом можно и на памяти сэкономить,  так как  разрядность требуeмых буферов нарастает.   

[blackfin 16]

On 6/23/2023 at 12:26 AM, RobFPGA said:

Минимальное latency счета имеют стримовые схемы  при которых расчет FFT идет в процессе ввода/вывода.  При этом можно и на памяти сэкономить,  так как  разрядность требуeмых буферов нарастает.

Да, pipelined_streaming считает быстрее, чем burst_io, спору нет.

Но и ресурсов pipelined_streaming требует в несколько раз больше, чем burst_io.

Фактически, модуль pipelined_streaming представляет собой конвейер из нескольких burst_io соединенных последовательно в одну цепочку.

Поэтому для FFT длиной больше 65536 схема burst_io является единственно возможной для реализации на одном чипе FPGA.

[_4afc_ 25]

2 hours ago, blackfin said:

1. Да, pipelined_streaming считает быстрее, чем burst_io, спору нет.
2. Но и ресурсов pipelined_streaming требует в несколько раз больше, чем burst_io.
3. Фактически, модуль pipelined_streaming представляет собой конвейер из нескольких burst_io соединенных последовательно в одну цепочку.
4. Поэтому для FFT длиной больше 65536 схема burst_io является единственно возможной для реализации на одном чипе FPGA.

Если догматировать 3 пункт - то возможно из него следует 2, и даже 4 и никак иначе , но жизнь разнообразнее.

[RobFPGA 27]

2 hours ago, blackfin said:

Но и ресурсов pipelined_streaming требует в несколько раз больше, чем burst_io.

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

[blackfin 16]

On 6/23/2023 at 11:33 AM, RobFPGA said:

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

"Может, дождик.. Может, снег.. Может, будет.. Может, нет.."

 

"Разнообразная жизнь" IP Catalog'а наглядно показывает, что для схемы Pipelined, Streaming I/O требуется существенно больше BRAM памяти, нежели для схемы Radix-4, Burst_I/O и уж тем более, для схемы Radix-2, Burst I/O:

 

 

[_4afc_ 25]

12 minutes ago, blackfin said:

"Разнообразная жизнь" IP Catalog'а наглядно показывает,

Всего 50MSPS на DSP у таких крутых камней  :(

Потоковый Radix8 на логике в GW2A даёт  150MSPS при R(840) LUT(518) ALU(834) DSP(0) BSRAM(0) SSRAM(8)

 

[blackfin 16]

On 6/23/2023 at 3:02 PM, _4afc_ said:

Всего 50MSPS на DSP у таких крутых камней  :(

Потоковый Radix8 на логике в GW2A даёт  150MSPS при R(840) LUT(518) ALU(834) DSP(0) BSRAM(0) SSRAM(8)

 

А для какой длины FFT этот "Radix8 на логике" дает 150 MSPS ?

[RobFPGA 27]

1 hour ago, blackfin said:

"Может, дождик.. Может, снег.. Может, будет.. Может, нет.."

А я  что, говорил про стандартные готовые корки?

К тому же  вариантов построений stream несколько  и которые отличаются требуемым объемом памяти.
Я уже  когда то писал тут - в одном из stream вариантов, оптимальном по памяти,  для N точек FFT при ширине входных данных M требуется всего N слов памяти для данных с возрастающей разрядностью, по схеме: (N/2 x M+1),  (N/4 x M+2),  ... .  И  (если ленится) N/4 слов для коэффициентов. 
Можете посчитать сколько это будет, и будет ли это дождик или снег если сравнивать со схемой burst-io N x M+log2(N) ...  

И опять же, как  раньше я и говорил, мерятся просто толщино своего FFT глупо если нет конкретных условий  на параметры входных/выходных потоков. 
Если для схемы для burst-io нормальный порядок входа/выхода дается фактически бесплатно (по памяти), то вот для stream уже нужен доп. буфер для "разворота" из/в  bit-revers. 

[_4afc_ 25]

3 hours ago, blackfin said:

А для какой длины FFT этот "Radix8 на логике" дает 150 MSPS ?

Для FFT8 конечно. Он же потоковый, последовательный.

На вход запихиваем символы во времени, на выходе они по частоте.

Надо больше - цепляй дальше ещё...

Скорость проекта то уже не упадёт, если добавлять такие же  "Radix8 на логике" и BRAM/DSP... (если везде не более 18 бит конечно).

[blackfin 16]

On 6/23/2023 at 6:16 PM, _4afc_ said:

Для FFT8 конечно. Он же потоковый, последовательный.

На вход запихиваем символы во времени, на выходе они по частоте.

Надо больше - цепляй дальше ещё...

Скорость проекта то уже не упадёт, если добавлять такие же  "Radix8 на логике" и BRAM/DSP... (если везде не более 18 бит конечно).

Разговор глухого с немым.. 

 

Спрошу по-другому.

Сколько времени требуется "потоковому Radix8 на логике в GW2A" для вычисления БПФ от массива комплексных данных длиной 32768 точек ?

Назовите время между загрузкой в модуль БПФ последнего семпла под номером 32767 и временем появления на выходе модуля первого семпла вычисленного спектра.

Для вычисления первого семпла спектра по схеме Radix32 Burst I/O модулю БПФ требуется 6,55 микросекунды при условии, что сам модуль БПФ работает на частоте 500 МГц.

 

Упоминавшаяся тут "быстрая" схема Pipelined, Streaming I/O Xilinx'а вычисляет спектр при прочих равных условиях за 197 микросекунд: