[Sefo 0]

Что-то затихло это Великое Дело? :(

 

Да - времени свободного поубавилось и у меня и, видимо, у ZED. Я сейчас решил "причесать" весь тот код, что написал ZED и оформить это в проект с которым будет удобно дальше работать. Правда быстро сделать это у меня не получится из-за нехватки времени. Думаю, что продолжения можно ожидать в начале апреля. Осталось не так уж и много - протестировать и исправить баги и разобраться с перестановкой гармоник на выходе.

[ZED 0]

Да у меня тоже со временем до конца марта туго...

[jb83 0]

Кстати вопрос, а почему такие формулы вычисления гармоник?

--

-- -- Вычисление y1

-- y_sig(1).re <= x_sig(0).re + x_sig(1).re - x_sig(2).re - x_sig(3).re + 2;

-- y_sig(1).im <= x_sig(0).im - x_sig(1).im - x_sig(2).im + x_sig(3).im + 2;

 

а не такое:

--

-- -- Вычисление y1

-- y_sig(1).re <= x_sig(0).re + x_sig(1).im - x_sig(2).re - x_sig(3).im + 2;

-- y_sig(1).im <= x_sig(0).im - x_sig(1).re - x_sig(2).im + x_sig(3).re + 2;

 

Туда же в догонку:

должно быть

 

-- Вычисление y3

y_sig(3).re <= x_sig(0).re - x_sig(1).im - x_sig(2).re + x_sig(3).im + 2;

y_sig(3).im <= x_sig(0).im + x_sig(1).re - x_sig(2).im - x_sig(3).re + 2;

 

З.Ы.

Кстати, (пользуясь случаем ) посоветуйте, пожалуйста, литературу по алгоритмам БПФ.

Изменено 24 марта, 2010 пользователем jb83

[Sefo 0]

Кстати, (пользуясь случаем ) посоветуйте, пожалуйста, литературу по алгоритмам БПФ.

 

Например, Л. Рабинер и Б. Гоулд "Теория и применение цифровой обработки сигналов".

[ViKo 1]

Ричард Лайонс - Цифровая обработка сигналов

[jb83 0]

Спасибо, поищу

[Maverick_ 15]

Какой результат, этой титанической работы?

 

Предложение администрации - вынести эту ветку в шапку

 

PS На мой взгляд, труд уже проделан очень большой!

[Sefo 0]

Какой результат, этой титанической работы?

 

Осталось уже не так и много. Я не оставляю надежду в октябре найти, все-таки, время и довести дело до конца.

[ZED 0]

Я тоже, правда еще понадобится время вспомнить, но я думаю все получится!

[Sefo 0]

Продолжим, по-тихоньку. Сейчас написано много кода и, как я уже писал, пора его "причесать" и оформить в проект. Начнем с package. В БПФ у нас есть необходимость выполнять некоторые промежуточные вычисления с "повышенной" разрядностью – поэтому есть необходимость в 2-х операциях расширение знака и извлечение определенных бит (как правило это старшие разряды). Чтобы избежать неудобоваримых выражений вроде "b_size + w_size - 3 downto w_size – 2" (complex_multiplier) в коде, перенесем их в функции, где они никого с толку сбивать не будут. Напишем 2 простые функции expand_sign и get_msb. Добавим в них проверку на корректность параметров. Проверим, что нумерация бит в передаваемом векторе имеет нисходящий порядок ( a downto b ) и что кол-во бит во входном векторе и результате правильно соотносятся друг с другом.

 

FFT_Project.rar

 

Теперь поработаем над бабочкой. В синхронном дизайне не стоит оставлять регистры без Reset. Регистры без Reset также могут доставить массу неудобств и при моделировании. В начальный момент выходы регистров устанавливаются в неопределенное состояние 'U'. Далее лавинообразно все зависимые цепи также переходят в 'U', причем 'U' имеет приоритет. К примеру, "0000" and "UUUU" = "UUUU". В результате значительная часть или весь проект быстро переходит в состояние 'U'. Не самое лучшее состояние для анализа :). Выходит проект из этого состояния гораздо медленнее (тривиальные случаи не в счет), чем попадает, что так же не упрощает анализ. Тип сброса (синхронный/асинхронный) следует выбирать исходя из конкретной задачи и платформы для ее решения. Поскольку в нашем случае никаких ограничений нет, то выбираем синхронный сброс.

 

Посмотрим на нынешний код бабочки:

 

process (switch, x_sig, y_sig)
begin
    if (switch = '0') then

        y_sig(0).re <= x_sig(0).re + x_sig(1).re + x_sig(2).re + x_sig(3).re + 2;
        y_sig(0).im <= x_sig(0).im + x_sig(1).im + x_sig(2).im + x_sig(3).im + 2;

        ...

        y_reg(0).re <= y_sig(0).re(data_size-1 + 2 downto 2);
        y_reg(0).im <= y_sig(0).im(data_size-1 + 2 downto 2);

        ...

    else

        y_sig(0).re <= x_sig(0).re + x_sig(1).re + 1;
        y_sig(0).im <= x_sig(0).im + x_sig(1).im + 1;

        ...

        y_reg(0).re <= y_sig(0).re(data_size-1 + 1 downto 1);
        y_reg(0).im <= y_sig(0).im(data_size-1 + 1 downto 1);

        ...

    end if;
end process;


process
begin

    wait until (rising_edge(CLK));
      y <= y_reg;

end process;

 

Чтобы избежать лишних промежуточных регистро ZED разделил код на 2 process – комбинаторный, где производятся все операции и регистровый, где защелкивается результат. В этом случае, упростить код помогает использование variable.

 

В коде есть копирование в вектор с большей разрядностью с расширением знака:

 

x_sig(0).re <= (1 downto 0 => x(0).re(b_size-1)) & x(0).re;
x_sig(0).im <= (1 downto 0 => x(0).im(b_size-1)) & x(0).im;
...

и извлечение старших бит:

y(0).re <= y_sig(0).re(b_size-1 + 2 downto 2);
y(0).im <= y_sig(0).im(b_size-1 + 2 downto 2);
...

Для того, чтобы избавиться от множества одинаковых строк с разными индексами мы не ограничимся использованием функций expand_sign и get_msb из FFT_Package. Добавим в Butterfly свои expand_sign и get_msb, которые будут вызывать функции из FFT_Package для всех членов complex_data_bus.

 

FFT_Project.rar

[Sefo 0]

Модули памяти я предпочел переименовать т.к. у нас есть не только память данных, но и память коэффициентов. Организацию памяти я оставил как она была у ZED, однако сам код написал несколько иначе. Стоит отметить, что Data_Memory является платформо зависимым модулем. В зависимости от того, какая ПЛИС будет выбрана, будет ли использована внутренняя память ПЛИС или внешняя микросхема начинка этого модуля может меняться. В некоторых случаях, может быть выгодно объединить Re и Im данные в один банк памяти (сейчас они храняться раздельно).

 

FFT_Project.rar

[ZED 0]

В архиве единственная непустая папка RTL, где хранятся vhdl-файлы описания компонентов бабочки, памяти и файл констант FFT_Package.

Мне пока не очень понятна целесообразность введения всех этих функций.

[Jhonny 0]

Здравствуйте. Спасибо за очень полезную тему. У меня есть несколько вопросов касательно БПФ.

Необходимо реализовать преобразователь на 1152, 1024, 704 и 448 отсчетов, при этом длина должна выбираться динамически. Возможно ли сделать такой универсальный преобразователь или лучше сделать четыре отдельных с фиксированной длиной? Как я понял, здесь применим алгоритм Cooley-Tukey со смешанными основаниями, т.е. например, 1152 раскладывается как 4³3²2. Также читал про алгоритм Блуштейна (Bluestein's chirp-z) и ряд других. Какой лучше подходит для данной задачи?

Может кто-то сталкивался с подобной проблемой? Буду признателен за советы.

 

[ZED 0]

Динамически тут будет сделать трудно, ибо для каждого из Ваших БПФ (на 1152, 1024, 704 и 448 отсчетов) используются разные виды "бабочек" - двухточечная, трехточечная и четырехточечная. Таким образом, алгоритм не имеет постоянной структуры вычислений. Вот если бы, например, Вам нужно было вычислить БПФ на 512, 1024 и 2048 точек, то нет проблем динамически задавать какое из этих БПФ должно выполняться, т.к. можно взять в качестве базовой операции двухточечную "бабочку", а меняется только количество этапов и количество итераций в этапе. Ну это мое мнение, оно может быть ошибочно.

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

Наверное, проще всего будет дополнять исходные массивы (1152, 1024, 704 и 448) нулями до степени 2 (получатся БПФ на 2048, 1024, 1024 и 512 отсчетов соответственно), выбрать в качестве базовой операции двухточечную бабочку и делать как я описал выше.

[Jhonny 0]

К сожалению, нулями дополнить нельзя. БПФ нужно для демодулятора OFDM, соответственно длительность OFDM-символа определяет количество точек преобразования (если я все правильно понял).