Всем привет.

Реализовал на ПЛИС квадратурный смеситель. Дальнейшую обработку упоминать не буду,ибо она вся многократно проверена и точно работает корректно. Поэтому соль в том,что при просмотре спектра выходного сигнала со смесителя я вижу в спектре гармонику на нулевой частоте (которой быть не должно,поскольку на входе,по сути,просто шум). Таким образом, где-то в моем смесителе возникла постоянная составляющая. У кого есть идеи,откуда она могла взяться?

Подробности:

Входной сигнал 16 бит поступает на умножители. Умножается он там на синус/косинус разрядностью 26 бит. Выходные сигналы с умножителей - 18 бит.

Эти 18 бит подаются на вход КИХ фильтра,который понижает частоту дискретизации. Выход фильтра - 16 бит (2 сигнала),которые потом записываются в сигнал 64 бита.

ПЛИС: Xilinx Virtex 5

Ядра, которые я использовал:
-DDS Compiler (синтезатор частоты);
-FIR Compiler (КИХ фильтр);
-Multiplier (умножитель).

После DDS или умножителя, например, нет округления.

Есть понижение разрядности,что эквивалентно делению.
Как я понимаю,это не то что вы имеете в виду.
Я знаю несколько способов округления. Какой наиболее предпочтителен для ПЛИС?

Предпочтения должны определяться задачей.

https://en.wikipedia.org/wiki/Rounding

В стандарте IEEE 754 по умолчанию принят метод "Round half to even", как симметричный. Часто хватает и "Round Up".

Округляю так:



Все равно вижу постоянную составляющую в спектре.

Не правильно округляю или какие еще могут быть варианты?

Сообщение отредактировал qwa - Jul 5 2015, 18:22

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

Насчет вашей угадайки: показывайте спектры
Входной сигнал
Гетеродин
Смеситель

Без них угадывать не интересно.

Как-то так



К сожалению,я не смогу получить спектр сигнала до понижения частоты дискретизации - сигнальный процессор просто не успеет обработать. До децимации получается поток 120 МГц по 64 бита....



Мне просто подумалось,что раз все выполнено в синхронном дизайне, то и округление надо бы так сделать... Новичок.

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

Итак,вот что я увидел.
На вход - синус,частота его в полосе пропускания фильтра.
Первый сигнал - клок.
Следующий - сигнал асинхронного сброса.
Далее - управляющий сигнал от процессора.
Далее - входной сигнал.
Следующие 2 сигнала - выход умножителей после умножения на син/кос с округлением.
Последние 2 сигнала - выход фильтра с округлением.

UPD : нашел косяк,исправляю

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

Сделал так,чтобы попадал - результат аналогичный представленному.

Посмотрел выход непосредственно фильтра - там нули. Загадочно.

Сообщение отредактировал qwa - Jul 5 2015, 21:05

А в случае знаковых чисел не надо иногда еще и вычитать?
1.2 + 0.5 = 1.7 -> 1
1.6 + 0.5 = 2.1 -> 2
Тут все ок, но для отрицательных
-1.2 + 0.5 = -0.7 -> 0
-1.6 + 0.5 = -1.1 -> -1
Сдвиг спектра на постоянные 0.5 в итоге за счет подброса на 1 отрицательной области
-1.2 - 0.5 = -1.7 -> -1
-1.6 - 0.5 = -2.1 -> -2
С учетом знака будет равномерное округление, или я совсем не про то?

Я вчера немного погуглил и нашел такую интересную статью : http://kanyevsky.kpi.ua/okruglenie.html
Думаю,там вы найдете ответ на свой вопрос.

Вчера,перед тем как лечь спать,нашел дурацкую ошибку. Потом отпишусь о результататах.

Подтянулась тяжелая артиллерия...

-0.7 в вашем примере надо усекать, а не пытаться округлять к нулю дальше.
Усечение (оно же "округление в сторону " или "округление к меньшему") значения -0.7 до целых даст -1.

Ваша правда, вот проверил на пальцах....

6 битное число, усекаем до 4 битного

3.25 == 0011 01, прибавляем 0.5 = 0000 10 и отбрасываем 2 последних бита 0011 01 + 0000 10 = 0011 11 -> 0011 = 3 - OK
3.75 == 0011 11 + 0000 10 = 0100 01 -> 0100 = 4 - 0k

-3.25 == 1100 11 по той же схеме... 1100 11 + 0000 10 = 1101 01 -> 1101 == -3 - Ok
-3.75 == 1100 01 + 0000 10 = 1100 11 -> 1100 == -4 - Ok

Всегда думал что преобразование действительного в целое в процах делается отбросом бит после учета знака, а получается они это делают до учета знака. Там обязательно учитывать знак прибавки, а то будет сдвиг, никогда не думал это проверять... вот оно как бывает.... Спасибо...

В общем,я обнаружил,что умножал просто на синус, а вообще надо бы на минус синус.
К улучшению результата это не привело....

Почему косинус и синус у Вас выбирается со значительно большей точностью, чем входные данные? Я бы взял те же 16 бит. А вот после умножения бы оставил все 32 бита и все их пользовал бы в фильтре, и только после фильтра округлял бы. При умножении 16 бит на 26 бит и последующем округлении до 18 бит Вы ни при каких обстоятельствах не будете использовать значения синусов больше 18+2 бит. В то же время, выбрасывать что-то после умножения на осциллирующую функцию, а потом усреднять (Ваш фильтр) то у Вас будут накапливаться ошибки от того, что большие и маленькие числа с разным знаком складываются.

Я не в курсе, как устроена DDS, но если ее строить на линейной аппроксимации, то для 26 бит точности она будет хотеть 2 умножителя и таблицу в 200кбит, а для большего порядка точности будет необходимо 4 умножителя и тоже десятки килобит.

Если все-таки хочется оставить синус и косинус такими точными, то и результат разумнее до фильтра тащить до 42 бит, а на самом фильтре, в зависимости от характерной длины, еще 10-20 бит накидывать, и только после получения округлять.

Хотя мне почему-то кажется, что у Вас нулевая частота из-за неправильного или неточного синуса получается.


а дурацкий вопрос, а в Вашем белом входном шуме постоянной составляющей точно нет? Может посчитать другими средствами, на всякий случай интеграл?