Особенности оконной фильтрации на ПЛИС

[lazifo]

Товарищ докручивает на своем велосипеде, последние болты.

[Refridgerator]

На практике спектр реального гармонического сигнала эквивалентен функции ~sin(x)/x

По-моему, вы тут фигню написали. Если спектр сигнала — это sinc, то значит сам сигнал — это прямоугольная функция, в которой не может быть ничего гармонического.

[hukenovs]

Спасибо за замечание! Пожалуй, стоит поправить, да. В данном контексте я имел ввиду, что ограниченный по времени гармонический сигнал sin(f0*t) вырождается в произведение прямоугольной огибающей и синусоидального сигнала, что в результате дает спектр на частоте f0 и по форме совпадающий с формой спектра прямоугольного импульса (иными словами — спектры сворачиваются). Если же период гармонического сигнала = длине ДПФ, либо если на длину ДПФ укладывается несколько целых периодов сигнала, то разумеется, спектр выглядит как дельта-функция на определенной частоте. Собственно, теория это подтверждает (ниже картинка спектра из Matlab для прямоугольного радиоимпульса):

[Refridgerator]

И это не совсем точно)

Если у нас синусоида действительная, а не комплексная со сдвигом в 90°, то в спектре у нас будет две дельта-функции, а не одна. Соответственно, и при свёртке мы получим сумму двух sinc-функций, разнесённых по оси частот. Если период синусоиды нацело укладывается в ДПФ, тогда точки семплирования будут попадать в нули sinc-ов и в дискретном спектре у нас будет только два ненулевых значения.

А с теорией сверяться лучше не в Matlab, а в Mathematica, потому что там символьное преобразование Фурье есть. Как-то так:



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

[Electrovoicer]

Про х12 по скорости разработки я понял. Вот как понять, какой оверхед случицца по ресурсам ПЛИС? Мы пока не осваиваем новые технологии проектирования, сидим на классических трудозатратных подходах, потому что три года назад хватило матлаба, сгенерившего hdl-код, как потом оказалось в 6(!) раз менее эффективный, чем вручную (я имею в виду, что в один и тот же кристалл, с кодом из матлаба, влезло 8 каналов цифрового радиоприема, а ручками потом запихнули 48). Кристалл стоит, скажем, $150. Если не оптимизировать, пришлось бы за $700 ставить. Где разумная грань?

[Brak0del]

Присоединяюсь к предыдущему вопросу. С HLS, что называется, только игрался, реализовывал несколько алгоритмов и сравнивал по ресурсам/скоростям со своими эталонами на vhdl. Поразило то, что существенно различных результатов можно добиться используя комбинации разных опций, но при этом было совсем не очевидно, когда остановиться, а когда попытаться попробовать ещё какие-то опции. Возможно, у вас есть какие-то критерии или метрики для этого?

[nerudo]

На мой взгляд метрика простая. Из самого алгоритма легко оценить сколько на него требуется умножителей/сумматоров/памяти (в области DSP по-крайней мере). Ну плюс оверхед на конвейер и т.п. Если вы близки к этим значениям — ок. Если расхождение в несколько раз — значит есть что пооптимизировать.

[Brak0del]

Понял, благодарю.

[hukenovs]

Кстати, вот результаты имплемента ядра Блэкмана-Харриса 5 порядка в Vivado HLS и на VHDL. Видно, что по логике расхождение в 2 раза, причем по DSP и регистрам результаты примерно схожи. Но я вообще забил на оптимизацию в HLS, вставил те прагмы, какими часто пользуюсь для распараллеливания и всё.



Тайминги сошлись в обоих случаях (задал 350МГц).

[nerudo]

Во втором случае явно сумматоров в два раза больше. Вероятно какое-то из распараллеливаний оказалось лишним ;)

[hukenovs]

Как уже ответил nerudo — все упирается в предварительную оценку алгоритма. Нам по ТЗ всегда известен такой параметр, как скорость входного потока. И уже от неё мы понимаем — какого вида будет алгоритм. Для некоторых задач на малых скоростях достаточно одного умножителя, поскольку он работает на скорости Fdsp >> Fs, и все можно сделать сериально. Для других задач на более высоких частотах — решение исключительно в виде параллельной схемы. А иногда требуется смешанное решение, как в случае с полифазными КИХ-фильтрами, например.

Так вот самое главное — это заранее оценить по ТЗ в какие ресурсы выльется реализация алгоритма. Далее всё просто: можно сделать традиционным способом (долго) — и получить то, что и задумывалось. Можно попытаться сделать на HLS (быстро) и путём задания директив приближаться к требуемому результату. К счастью, Vivado HLS позволяет очень быстро проводить C Synthesis для разных решений, поэтому временные затраты — минимальны.

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

[dsmv2014]

Есть ещё область применения HLS — это проведение моделирования алгоритма с большим объёмом данных. Что на VHDL/Verilog практически невозможно.