Фильтр из Matlab'a не компилируется в quartus'е Опции

[S.Mishutina]

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

[Methane]

С помощью Matlab сделала БИХ-фильтр нижних частот (фильтр Баттерворта).

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

[Гяук]

Правильно я понимаю, что такой код в реальном устройстве работать не будет и следует написать другой код?

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

Где найти примеры (книги, коды) IIR фильтров, которые скомпилируются в квартусе и смогут работать в реальном устройстве?

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

[Чиповод]

Правильно я понимаю, что такой код в реальном устройстве работать не будет и следует написать другой код?

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

Сообщение отредактировал Чиповод - Aug 28 2011, 15:46

[Methane]

Матлаб позволяет получить код, пригодный для синтеза в ПЛИСке.

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

[Чиповод]

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

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

[Methane]

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

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

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

[Чиповод]

Умножители. Они будут ужосом.

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

Даже плавающая точка в квартусе в общем-то есть.

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

[ViKo]

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

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

[Чиповод]

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

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

[ViKo]

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

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

[S.Mishutina]

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

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

Тут об этом немного. http://www.chipovod.ru/plis/proektirovanie-filtrov-plis/

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

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

Код

module filter (data_in, data_out, clock, reset);
    output reg  [15:0]  data_out=16'b0;
    input          [15:0]   data_in;
    input                clock, reset;

    reg  [15:0]  sample_in=16'b0;
    reg  [15:0]  sample_out=16'b0;
    always@(posedge clock)
  begin
    if(reset==1'b1)
          data_out<=16'b0;
    else
        data_out<=((data_in+sample_in)*3-sample_out)/5;
      //i.e.    y = 0.6*x(n) + 0.6*x(n-1) - 0.2*y(n-1)
                
    always@(posedge clock)
        begin
        if(reset==1'b1)
          begin
             sample_in<=0;
             sample_out<=0;
          end
        else
          begin
             sample_in<=data_in;
             sample_out<=data_out;
          end
        end        
endmodule

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

[Hoodwin]

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

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

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

[S.Mishutina]

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

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

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

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

[Hoodwin]

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

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

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

[des00]

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

[S.Mishutina]

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

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

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

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, так как это выходы регистров, которые легко таскать по кристаллу не снижая быстродействия.

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

[des00]

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

то выходной отсчет
будет вычислен с некоторой ошибкой, которая сохранится при вычислении следующего отсчета y(n+1), который тоже будет вычислен с ошибкой. Не получится ли так, что AЧХ недопустимо исказится из-за грубого округления?

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


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

[Hoodwin]

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