все так, но БИХ фильтры крайне не любят грубого усечения. лучше посчитать в матлабе БЧХ фильтр на фиксед поинт и увидеть что с ним да как. Ну а сгенерировать рабочий код дело времени.

des00, расчет в матлабе на фиксед пойнт делается так?






Hoodwin, но если при сдвиге на 16 отсчетов откидываются младшие биты, то выходной отсчет
y(n)=0.6*x(n)+0.6*x(n-1)-0.2*y(n-1)
будет вычислен с некоторой ошибкой, которая сохранится при вычислении следующего отсчета y(n+1), который тоже будет вычислен с ошибкой. Не получится ли так, что AЧХ недопустимо исказится из-за грубого округления?
Какие проблемы есть при переходе к вычислению с большей разрядностью? Быстродействие?
Частота дискретизации фильтра 32 Гц, с той же частотой поступают входные отсчеты.



Hoodwin, что значит делать аппаратный умножитель? При записи умножения со * и при сложных коэффициентах квартус сам сделает умножение на аппаратных умножителях, а мне остается только улучшить быстродействие?
записать коэффициенты b0, b1, a1 в регистры таким образом годится?
reg [15:0] a1=13107 ?





Насколько я понимаю, data_out и sample_out - оба регистры, и мне казалось, что безразлично, какой из них подавать на выход. почему если sample_out, а не data_out будет на выходе быстродействие будет выше?

да и матлаб рисует вам АЧХ с учетом разрядности математических операций. Видно что с АЧХ все гут, проверьте нули и полюсы на устойчивость и вперед %)


ЗЫ. при генерации ртл кода, если мне память не изменяет, надо задавать фиксед поинт или флоат хотите вы.

S.Mishutina
Вот в Filter Designer есть такой инструмент как анализ устойчивости цифрового фильтра. Он проверяет, как изменится характеристика фильтра, если вычисления будут с ограниченной разрядностью, и не будет ли там каких-либо существенных аномалий. Если мне память не изменяет, то можно на одном графике увидеть АЧХ до и после обрезания разрядности. Так что не стоит переживать по этому поводу, сама по себе проблема вычислений с fixed point числами там проработана. Другое дело, что деление на 5 решили заменить на умножение на 13107/65536, то есть мы немного исказили коэффициенты фильтра. например, в 16 разрядной арифметике 0,6 будет 39321,6, а реально с учетом умножения на 13107 и деления на 65536 коэффициент будет просто 39321. Поэтому нужно будет пересчитать коэффициенты фильтра и посмотреть на новую АЧХ. Думаю, что разница будет совершенно для Вас несущественна.

По поводу аппаратного умножителя. Если у Вас частота 32 Гц, то не морочьте себе голову тем, что я сказал. Я это говорил для частот больше ~100 МГц, когда производительность умножителей сильно зависит от того, есть ли регистр на входе и выходе. Дело в том, что регистры вокруг умножителя стоят прямо в DSP-блоке FPGA, и они дают наибольшее быстродействие по умножению (указано в даташите на FPGA). А если результат или аргументы умножения используются без регистра, то к времени распространения сигнала добавляется довольно существенная задержка, поскольку DSP блок находится в стороне от массива общей логики. В итоге частота падает, по моим наблюдениям для Cyclone III, раза в полтора-два от максимально заявленной. Для конвейерной обработки это может стать неприятным ограничением. Но для 32 Гц это абсолютно без разницы. Кроме того, БИХ фильтр неприятен тем, что имеет обратную связь по данным, то есть это не конвейерный алгоритм, поэтому увеличение максимальной частоты умножителя будет компенсироваться увеличением числа тактов обработки между входом и выходом. Причем с тенденцией к падению общей производительности, так как уравнять задержки на всех тактах практически невозможно, а частота будет определяться длиной самого длинного такта.