С помощью Matlab сделала БИХ-фильтр нижних частот (фильтр Баттерворта). Matlab сгенерировал Verilog HDL, который прекрасно компилируется и работает в ModelSim. Но verilog-код не компилируется в quartusII: "real variable data type are not suppotred", также не поддерживаются директивы $bitstoreal и $realtobits.
Правильно я понимаю, что такой код в реальном устройстве работать не будет и следует написать другой код?
Где найти примеры (книги, коды) IIR фильтров, которые скомпилируются в квартусе и смогут работать в реальном устройстве?

Сгенерируйте в матлабе только коэффициенты фильтра.

Да, правильно

http://www.google.ru/search?q=iir+fpga
А по поводу коэффициентов Methane вам уже подсказал.

Матлаб позволяет получить код, пригодный для синтеза в ПЛИСке. Проверял в железе, код работает. Для этого надо перевести коэффициенты вашего фильтра из вещественного типа в целочисленный. Тут об этом немного. http://www.chipovod.ru/plis/proektirovanie-filtrov-plis/

Но зрелище получается, душераздирающим...

Ага, особенно аккумулятор, но если надо вчера...

Умножители. Они будут ужосом. Но если нада вчера, в очень толстую ПЛИСину, и частота 20мигагерц, устроит, то все нормально. А если оно нада "для галочки", то это вообще самый оптимальный вариант.

Вообще, с генережем матлабом верилога, у меня, есть некоторые сомнения. С одной стороны, CIC фильтр, выглядел вполне вменяемым, но я его не пробовал по серьезному в железе тестировать. Для FIR фильтров в квартусе есть готовые макрофункции, куда можно только коэффициенты загрузить. Для IIR скорее всего тоже. Даже плавающая точка в квартусе в общем-то есть.

С этим вроде стало полегче. В опциях Матлаба можно настроить, чтобы умножение в HDL коде выполнялось с помощью оператора умножения *. Ну а дальше Квартус или другая среда разложит его на аппаратных умножителях, которые есть в любой современной ПЛИСине.

Интересно, а в каком виде?

В Quartus 9.1 я только что насчитал 13 мегафункций, начинающихся с ALTFP_. Угадайте, что это за функции.

А, понятно. Я почему то подумал, что квартус начал синтезировать тип real.

Я сам не пользовался, но мне кажется, что именно так и есть. 13 функций...

ViKo, ALTFP_ - это мегафункции для работы с плавающей точкой, но если у меня входные отсчеты фильтра с фиксированной точкой?
То есть, нужно перевести число из формата с фиксированной точкой в формат с плавающей точкой?


Чиповод, спасибо за ссылку, полученный код в квартусе действительно компилируется! Но не работает в ModelSim. Почти все сигналы - хххххх. На выходе также хххххх. И в силу сложности кода пока не разберусь, что нужно исправить.

Найден компромисс: из коэффициентов, полученных в Matlab, по образцу из учебника написан БИХ-фильтр:


Все прекрасно работает в Квартусе и ModelSim'е,
но моему руководителю дико не нравится деление на 5: ((data_in+sample_in)*3-sample_out)/5.
требует переделать в целочисленную арифметику, или найти другой способ.
Вопрос: как следует осуществлять "деление" в таких случаях?
Или: как в этом случае воспользоваться мегафункциями ALTFP_??

Ну, например, как gcc поступает в таких случаях:

a/5 = a * 65536 / 5 / 65536 = a * (65536/5) / 65536 = a * 13107 / 65536

То есть, свелось к умножению на константу со сдвигом. Устраивает?

Hoodwin, а те 16 отсчетов, на которые мы сдвинули результат при делении на 2^16, мы используем при вычислении следующих отсчетов фильтра как дробную часть?
То есть, получаются дополнительные 16 отсчетов для дробной части и, например, 16 для целой?
И точность расчета выходного сигнала повышается в зависимости от количества битов дробной части?

Я не думаю, что все так радужно. 16 младших битов придется выкинуть, потому что нужно согласовывать типы данных. В приведенном тексте сигналы представлены 16-разрядными числами без дробных частей. Умножение на 13107 делает из 16 битного числа 32-битное, которое затем вновь становится 16-битным после откидывания младших битов. Чтобы повысить точность, нужно в целом перейти к вычислению с большей разрядностью, только зачем?

Кстати, по поводу самого кода. Умножение на 3, конечно, вполне тривиально преобразовывается в сложение, но вот при более сложных коэффициентах, по-видимому, придется делать аппаратный умножитель. Записать его можно так же, но нужно помнить, что для получения хорошего быстродействия аппаратного умножителя и вход и выход должны быть регистрами, что потребует некоторой структурной переработки данного кода. Если частота будет приемлемой, то можно ничего не менять.

Еще из структурных соображений я бы выдал на выход не data_out, а sample_out, так как это выходы регистров, которые легко таскать по кристаллу не снижая быстродействия.

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

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 Гц это абсолютно без разницы. Кроме того, БИХ фильтр неприятен тем, что имеет обратную связь по данным, то есть это не конвейерный алгоритм, поэтому увеличение максимальной частоты умножителя будет компенсироваться увеличением числа тактов обработки между входом и выходом. Причем с тенденцией к падению общей производительности, так как уравнять задержки на всех тактах практически невозможно, а частота будет определяться длиной самого длинного такта.