[mishutinaalex 0]

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

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

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

[Methane 0]

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

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

[zvs 0]

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

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

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

http://www.google.ru/search?q=iir+fpga

А по поводу коэффициентов Methane вам уже подсказал. :)

[chipovod 0]

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

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

Изменено 28 августа, 2011 пользователем Чиповод

[Methane 0]

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

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

[chipovod 0]

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

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

 

[Methane 0]

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

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

 

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

[chipovod 0]

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

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

 

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

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

[ViKo 1]

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

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

[chipovod 0]

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

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

 

[ViKo 1]

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

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

[mishutinaalex 0]

В 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_??

[vpd 0]

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

 

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

 

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

[mishutinaalex 0]

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

 

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

 

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

 

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

То есть, получаются дополнительные 16 отсчетов для дробной части и, например, 16 для целой?

И точность расчета выходного сигнала повышается в зависимости от количества битов дробной части?

 

[vpd 0]

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

 

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

 

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