[des00 25]

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

Зачем вам генерация кода? В симулинке возьмете сумматоры, константы, триггеры и соберете свой фильтр в графическом виде, там же подадите на него шум или свои сигналы, подключите FFT и посмотрите как он работает. На этом форуме валяется куча симулинк моделей, можно попробовать несколько архитектур полифазных фильтров просто двигая мышкой кубики в гуе.

[desmond breezey 0]

Что скажите про такой вариант? Работает вроде нормально, но надо как-то поднять предел по тактовой частоте. Немного поднять - примерно на 10 МГц.

Что скажите?

t_module.vhd

[desmond breezey 0]

Есть мысль, что можно сделать это по двухкаскадной схеме. То есть, структура та же, только в первом фильтре понижать будем в 3 раза, а во втором в 2 раза.

[Golikov 0]

а иксов то нафига 10 штук, если используется только 6?

и снова на Dout попадают данные каждый клок) коэффециент меняется раз в 6 тактов, данные входные ползут, а на выходе все каждый клок происходит, и смысл всего в начале?

 

и опять же у вас в выходе участвует только 1 коэфициент....

 

по мне вы что-то не то делаете... где то должна быть сумма

[Amurak 0]

Эмм. А про то, что если это дециматор, то для выходного сигнала нужно добавлять еще сигнал значимости, уже говорили?

[desmond breezey 0]

а иксов то нафига 10 штук, если используется только 6?

и снова на Dout попадают данные каждый клок) коэффециент меняется раз в 6 тактов, данные входные ползут, а на выходе все каждый клок происходит, и смысл всего в начале?

 

и опять же у вас в выходе участвует только 1 коэфициент....

 

по мне вы что-то не то делаете... где то должна быть сумма

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

 

По поводу остального. Тест в симуляторе показывает, как все происходит: выход меняется раз в 6 тактов. Не знаю, как вы увидели изменение выхода каждый такт.

 

Суммы здесь быть не может. Точнее,может, но тогда придется увеличить линию задержки. За каждые 6 тактов в линии задержки длиной 6 регистров ( да и при 10 регистрах тоже ) остается только один отсчет, который не отбрасывается, поэтому суммы нет.

 

Эмм. А про то, что если это дециматор, то для выходного сигнала нужно добавлять еще сигнал значимости, уже говорили?

В первый раз слышу.

Изменено 21 ноября, 2014 пользователем desmond breezey

[Amurak 0]

В первый раз слышу.

Ну а как же он тогда децимирует, если к нему на вход приходят данные на частоте Х и на этой же частоте данные выходят?

[desmond breezey 0]

Заменил константы в процессе на шины, получил прирост по максимуму тактовой частоты на 50 МГц.

 

Ну а как же он тогда децимирует, если к нему на вход приходят данные на частоте Х и на этой же частоте данные выходят?

Очевидно, за счет того, что выходной отсчет формируется за 6 тактов входного сигнала.

[Amurak 0]

Очевидно, за счет того, что выходной отсчет формируется за 6 тактов входного сигнала.

Отлично. То есть на шестом такте на выходе формируется новый отсчет. А на первом, втором, третьем, четвертом, пятом тактах на выходе что формируется?

 

Даже лучше спрошу, отличаются ли сигналы "000000AAAAAABBBBBBCCCCCC" и "0ABC"?

Изменено 21 ноября, 2014 пользователем Amurak

[desmond breezey 0]

Отлично. То есть на шестом такте на выходе формируется новый отсчет. А на первом, втором, третьем, четвертом, пятом тактах на выходе что формируется?

Ничего.

 

Даже лучше спрошу, отличаются ли сигналы "000000AAAAAABBBBBBCCCCCC" и "0ABC"?

Ну очевидно же, что второй - это в 6 раз прореженный первый.

 

Я ни разу не видел в книгах по ЦОС ничего про сигнал значимости. Что это за зверь такой?

 

Я не понимаю - алгоритм не верен? Но почему?

[Golikov 0]

Не знаю, как вы увидели изменение выхода каждый такт.

не разглядел что case под else от i<6, тогда да....

 

 

сигнал значимости, я так понимаю имелось ввиду что можно сделать так

 

на выход идут данные со входа умноженные на коэффициент всегда, то есть меняются каждый такт. А к ним добавляют сигнал который 5 тактов в 0, и 1 такт в 1. И данные с выхода забираются только когда этот сигнал в 1, сигнал который означает что данные имеют значение... думаю так...

[Amurak 0]

Я ни разу не видел в книгах по ЦОС ничего про сигнал значимости. Что это за зверь такой?

Потому что книги по ЦОС - это теория, а ПЛИС - практика.

Представьте, что после вашего фильтра стоит триггер и ему в лицо летит поток данных. Если он принимает данные просто по клоку (с), то ему в лицо летит как раз-таки "000000AAAAAABBBBBBCCCCCC" - да, сигнал меняется каждый шестой такт, но триггер в течение шести тактов принимает и обрабатывает это изменившееся значение. А если ему дополнительно идет сигнал значимости, который устанавливается в единицу на один такт и - в ноль на пять тактов, то триггер принимает и обрабатывает сигнал только по значимости, то есть "0ABC".

 

А что касается алгоритма, то у вас реализовано непонятно что. Это даже не фильтр, и, тем более, не полифазный. Суммирование-то где? Где свертка?

[desmond breezey 0]

на выход идут данные со входа умноженные на коэффициент всегда, то есть меняются каждый такт. А к ним добавляют сигнал который 5 тактов в 0, и 1 такт в 1. И данные с выхода забираются только когда этот сигнал в 1, сигнал который означает что данные имеют значение... думаю так...

Может я чего не понимаю, но разве это не бессмысленно?

 

Ведь так делается куча ненужных вычислений.

[Golikov 0]

но я хотел бы обратить ваше внимание на такой факт

ни X1 ни x2 и так далее не участвую в формуле вашего фильтра, вы их тащите через набор регистров, но не используете какой в этом смысл?

Ваша схема равносильной такой:

вы из сигнала берете значение умножаете на коэффициент и выдаете наружу, потом просто пропускаете N значений (в вашем случае 5), и опять берете сигнал со входа, умножаете и на выход... и так далее...

 

конвейер из 6 регистров имел бы смысл, если бы на выход шла их комбинация, то есть вы собираете 6 отсчетов, их сумма с коэффициентами на выход, и набираете новые, так бы это имело смысл...

 

 

 

Может я чего не понимаю, но разве это не бессмысленно?

 

Ведь так делается куча ненужных вычислений.

 

ну вы же не руками считаете:) железка пусть считает...

смысл в этом такой, любая ваша схема превращается в набор элементов используемых для ее реализации,

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

[desmond breezey 0]

Потому что книги по ЦОС - это теория, а ПЛИС - практика.

Представьте, что после вашего фильтра стоит триггер и ему в лицо летит поток данных. Если он принимает данные просто по клоку (с), то ему в лицо летит как раз-таки "000000AAAAAABBBBBBCCCCCC" - да, сигнал меняется каждый шестой такт, но триггер в течение шести тактов принимает и обрабатывает это изменившееся значение. А если ему дополнительно идет сигнал значимости, который устанавливается в единицу на один такт и - в ноль на пять тактов, то триггер принимает и обрабатывает сигнал только по значимости, то есть "0ABC".

 

А что касается алгоритма, то у вас реализовано непонятно что. Это даже не фильтр, и, тем более, не полифазный. Суммирование-то где? Где свертка?

А что с чем суммировать? В линии задержки данной длины за 6 тактов есть всего один отсчет, который не отбрасывается при децимации.

 

Разве есть еще какие-то отсчеты, которые не отбрасываются. кроме тех, которые выделены?

 

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