Прошу прощения, но вынужден взять таймаут до вторника. Пока постарайтесь разобраться по статье википедии. Вопросы по ней можете пока записать здесь... Во вторник продолжим.

P.S. Если Вам так про дополнительный код читали, то преподу жирная 2 с минусом.

Я прочитал статью, ну да знак представляется самым старшим битом.

Я просто не правильно выразился:

Знак то представляет по-прежнему один разряд - старший:
Но расширение - это просто добавление справа чисел, тех же , что и знак, т.е.:

(-5)10 это (1011)2

А если расширить до 8 бит:

(-5)10 это (1111 1011)2

Но при перемножении чисел с разрядностями n и k все равно вначале получаем (n+k) битное число. Вопрос только сколько бит мы оставляем при округлении не так ли?

Не могу понять, что именно меня сбило с толку, но я сам попался на "знаковом разряде" Позор! Позор на мою голову!

Конечно же в общем случае разрядность результата умножения n+k.

Но тут все равно есть о чем поговорить, особенно в нашем конкретном случае - ведь первая версия умножителя все равно работала не правильно.

Ну ничего, сейчас все расставим по местам.

Я Вас просил

Сделайте это, пожалуйста, оно-то нам и поможет во всем разобраться.

Я не совсем понял, что значит описать математическим выражением то, что делают умножители, имеется в виду описать с помощью частичных произведений и сложений со сдвинутыми множимыми?

Например выход y0_re бабочки = (x0_re + x1_re + x2_re + x3_re + 2)/4.

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

Видим о это будет как-то так:

result_re <= (y_re_sig*w_re_sig - y_im_sig*w_im_sig + '1')/4096;
result_im <= (y_re_sig*w_im_sig + y_im_sig*w_re_sig + '1')/4096;

Непонятно откуда взялось 4096 - последней версии умножителя это число не соответствует. Должно быть другое. Также непонятно откуда появилось + '1' - в коде умножителя этого нет.

Замените 4096 на правильное, уберите + '1' и

result_re <= (y_re_sig*w_re_sig + y_im_sig*w_im_sig)/2048;
result_im <= (y_re_sig*w_im_sig - y_im_sig*w_re_sig)/2048;



Деление на 2048 - это сдвиг на 11 разрядов или что эквивалентно берем старшие 17 и отбрасываем 12 младших...



result_re <= (y_re_sig*w_re_sig + y_im_sig*w_im_sig)/2048;
result_im <= (y_re_sig*w_im_sig - y_im_sig*w_re_sig)/2048;



Деление на 2048 - это сдвиг на 11 разрядов или что эквивалентно берем старшие 17 и отбрасываем 12 младших...

А вот теперь непонятно, откуда Вы взяли 2048 в формуле для коэффициентов? Вы же сами решили, что диапазон -1.0 ... +1.0 мы представляем числами -2047 ... +2047!

Исправляйте.

С диапазонам данных у Вас тоже бардак! У Вас с АЦП идут знаковые 16-ти разрядные данные, которые мы расширяем знаком до 17-ти разрядных. Делаем мы это для того, чтобы иметь возможность хранить значение +32768, которое появится при вычислениях и которое в 16-ти разрядах знакового числа не помещается и требует для представления 17 разрядов. Если мы будем правильно выполнять все операции, то диапазон значений всегда будет от -32768 до +32768. Еще раз повторяю, для представления такого диапазона значений требуется 17, а не 16 разрядов. Я-то думал, что Вы в симуляции умножителя 60 000 просто так задали, а Вы, оказывается решили, что раз мы увеличили разрядность до 17 бит, так у нас и диапазон в 2 раза вырос.

Исправляйте.

Честно говоря я его просто так и задал=)) Просто раз уж в симуляции было 60000, так думаю и в формуле написать.

Да, про 2048 я накосячил, только сейчас проснулся и понял, сразу за комп, тогда нам лучше делить (мне так кажется) на 2047:

result_re <= (y_re_sig*w_re_sig + y_im_sig*w_im_sig)/2047;
result_im <= (y_re_sig*w_im_sig - y_im_sig*w_re_sig)/2047;

Но это число не очень хорошее (опять же как мне кажется), ибо не является степенью двойки... Не уж то опять придется расширять до 2048?

Есть 2 варианта. Либо, как и в бабочке увеличить разрядность коэффициентов на 1 бит и -1.0 ... +1.0 представлять диапазоном -2048 ... +2048, либо оставить разрядность как есть, но опуститься до -1024 ... +1024.

Я Вас еще просил проанализировать, что же получается с точки зрения БПФ, если диапазон коэффициентов оставить как Вы изначально выбрали (-2047 ... +2047), но вместо честного деления на 2047 делить на 2048 (как и было реализовано).

Деление на 2047 потребует честного делителя, что не так уж и здорово. Обходиться сдвигами вместо честного деления куда приятнее и ресурсы экономятся.

Я склоняюсь ко 2 варианту. с точки зрения БПФ мы получаем "дополнительный шум" не знаю только как его обозвать. Мне так кажется, а так не знаю.

Если говорить очень кратко, то в силу того, что значения всех коэффициентов уменьшаются (пусть даже всего-то на 1/2048), коэффициенты перестают быть значениями e^(-j*2*pi*n/N) в соответствующих точках и теряют свое главное свойство - ортогональность.

Если столь краткое объяснение будет не понятным, то дайте знать - объясню подробнее.

Да, все понятно, спасибо!

Тогда продолжим.

Во-первых, подправьте код умножителей под диапазон коэффициентов -1024 ... +1024, поскольку после умножения делить нам надо теперь на 1024.

Во-вторых, теперь, когда мы разобрались с умножением, нужен ли нам 0-ой умножитель в блоке умножителей?

В-третьих, в начале было решено, что вычисление бабочки и умножение на коэф. делаем за один такт. В таком случае, регистры на выходе бабочки нужно перенести на выход умножителей.

В-четвертых, все блоки нашего БПФ имеют на входе и выходе один и тот же набор сигналов (относящийся к данным БПФ) и эти сигналы представляют собой комплексные числа. Я предлагаю воспользоваться такой возможностью языка как record и задать тип complex_data и complex_coef для данных и коэффициентов. Еще задать тип complex_data_vector и complex_coef_vector с параметризованной размерностью, чтобы не "таскать" везде по четыре сигнала данных и по три сигнала с коэффициентами. Все это, для удобства, объявить в package - скажем fft_pkg. Все сказанное в это пункте никак не влияет на работоспособность, поэтому если не хотите, то можете этого не делать.

Жду от Вас поправленный код бабочки и умножителей.

Вы с ModelSim работали?