Квадратурный смеситель и постоянная составляющая Опции

[qwa]

Всем привет.

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

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

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

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

ПЛИС: Xilinx Virtex 5

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

[rloc]

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

[qwa]

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

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

[rloc]

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

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

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

[qwa]

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

Код

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;




ENTITY rounding_mixer_1 IS
   PORT(
      arst   : IN     std_logic;
      clk    : IN     std_logic;
      dout_i : OUT    std_logic_vector (17 DOWNTO 0);
      i_in   : IN     std_logic_vector (41 DOWNTO 0)
   );

-- Declarations

END rounding_mixer_1;

--
ARCHITECTURE rounding_ach OF rounding_mixer_1 IS
  signal prev : std_logic_vector (17 downto 0) := (others=>'0');
BEGIN
  process(clk,arst,i_in)
  begin
  if arst='1' then
    prev <= (others => '0');
  elsif rising_edge(clk) then
    if i_in(23)='1' then
      prev <= std_logic_vector(signed(i_in(41 downto 24)) + 1);
    else
      prev <= i_in(41 downto 24);
      end if;
      end if;
      end process;
      dout_i <= prev;
END ARCHITECTURE rounding_ach;

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

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

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

[Fat Robot]

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

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

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

[qwa]

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

Как-то так

Код

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;


ENTITY rounding_mixer_1 IS
   PORT(
      dout_i : OUT    std_logic_vector (17 DOWNTO 0);
      i_in   : IN     std_logic_vector (41 DOWNTO 0)
   );

END rounding_mixer_1;

--
ARCHITECTURE rounding_ach OF rounding_mixer_1 IS
  signal prev : std_logic_vector (17 downto 0) := (others=>'0');
BEGIN
  process(i_in)
  begin
    if i_in(23)='1' then
      prev <= std_logic_vector(signed(i_in(41 downto 24)) + 1);
    else
      prev <= i_in(41 downto 24);
      end if;
      end process;
      dout_i <= prev;
END ARCHITECTURE rounding_ach;

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

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

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

[Fat Robot]

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

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

[qwa]

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

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

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

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

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

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

Эскизы прикрепленных изображений

 

[Golikov A.]

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

А в случае знаковых чисел не надо иногда еще и вычитать?
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
С учетом знака будет равномерное округление, или я совсем не про то?

[qwa]

А в случае знаковых чисел не надо иногда еще и вычитать?

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

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

[Fat Robot]

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

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

но для отрицательных
-1.2 + 0.5 = -0.7 -> 0

[Golikov A.]

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

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

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

[qwa]

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

[iiv]

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

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

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

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

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

... вижу в спектре гармонику на нулевой частоте... где-то в моем смесителе возникла постоянная составляющая

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

[serjj]

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

Про точность представления синуса вы тут совершенно правы, 26 бит действительно перебор. Большая разрядность скорее важна на шине управления частотой для задания очень маленького и точного шага перестройки частоты (делал 24 бита на управление и 16 бит на собственно сами синус/косинус, шаг был доли Гц). После умножения нет никакой надобности оставлять полную разрядность, т.к. динамический диапазон гармонического сигнала задаёте вы, нужно поставить соответственно в полную шкалу, тогда можно все 16 бит после перемножения отбросить. В случае комплексного смесителя там ещё дальше будет сложение, это ещё +1 бит. Тогда у такого смесителя на входе 16 бит, на выходе - 17 бит. И вот их уже скармливать фильтру. Никаких потерь и ошибок, о которых вы говорите, в данном случае не будет.

[iiv]

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

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

[Fat Robot]

Точность описания сигнала гетеродина определяется требованиями к избирательности по соседнему каналу и/или к блокированию

Пример дизайна NCO для гетеродина:

фазовый аккумулятор: 32 бита
LUT: 4096x18
на выходе: 22 бита

макс уровень внеполосных составляющих: ~-116-117 dBc

Почему косинус и синус у Вас выбирается со значительно большей точностью, чем входные данные?

[serjj]

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

Вы можете объяснить в чём тут опасность с точки зрения арифметических ошибок и сигнал-шума? Всякий рост разрядности должен быть обоснован, а брать с запасом "на всякий случай" не очень хороший подход. Почему растёт разрядность на фильтрах, я понимаю. А зачем её ростить здесь? Если есть опасения после окргуления получить постоянку, которую фильтр низких частот конечно раздует (за счёт интегрирования), то достаточно сделать арифметическое округление и проблемы не будет.

Точность описания сигнала гетеродина определяется требованиями к избирательности по соседнему каналу

Вы имеете в виду в случае передатчика? В приёмнике же избирательность определяется фильтрами.

[Fat Robot]

Я имею в виду приемник. Соседний или блокирующий канал "снесется" spur'oм гетеродина прямо в рабочий на BB. И никакие фильры вам уже не помогут.

Вы имеете в виду в случае передатчика? В приёмнике же избирательность определяется фильтрами.

[serjj]

Я имею в виду приемник. Соседний или блокирующий канал снесется spur'oм прямо в рабочий на BB.

А ведь и правда, не сообразил сразу.. )

[qwa]

Большая разрядность скорее важна на шине управления частотой для задания очень маленького и точного шага перестройки частоты

Именно по этому она и выбрана такой большой.

Тогда у такого смесителя на входе 16 бит, на выходе - 17 бит. И вот их уже скармливать фильтру. Никаких потерь и ошибок, о которых вы говорите, в данном случае не будет.

В текущей версии прошивки я именно так и сделал.

[iiv]

Вы можете объяснить в чём тут опасность с точки зрения арифметических ошибок и сигнал-шума?

я в гетеродинах не разбираюсь, но, давайте рассмотрим такой пример.

Возьмите несколько периодов синуса на равномерной сетке. Умножьте их на целое и округлите. Посчитайте сумму. Она будет или 0, или кратна числу периодов. Умножьте на большую целую константу, результат не изменится. Итого, имеем, что ошибка интегрирования будет обратной от этой целой константы (то бишь нашей точности после умножения), умноженной на число периодов, которые влезли в окно интегрирования. Соответственно и битность всех операций надо бы выбирать исходя из этих соображений.

[serjj]

Возьмите несколько периодов синуса на равномерной сетке. Умножьте их на целое и округлите. Посчитайте сумму. Она будет или 0, или кратна числу периодов. Умножьте на большую целую константу, результат не изменится.

Вы говорите об ошибке округления видимо. Во первых её можно избежать, если в NCO предусмотреть правильное арифметическое округление. Но даже если его нет, то прибегнем к математике:
с постоянной составляющей сигнал с гетеродина (квадратура re например) есть c + cos(wt), где c - 1 бит (ошибка окргуления это 1 бит, если не было интегирования этой самой ошибки, случай NCO), cos(wt) - N бит. Теперь умножим сигнал s на наш гетеродин x = s*(c + cos(wt)) = s*c + s*cos(wt). А теперь отбросим N бит. Что получится? Первый компонент "уйдёт" в случае, если N >= WIDTH_IN. Вот вам и критерий )

Сообщение отредактировал serjj - Jul 6 2015, 11:33

[iiv]

Точность описания сигнала гетеродина определяется требованиями к избирательности по соседнему каналу и/или к блокированию

с точностью задания самой частоты - я полностью согласен. А вот с битностью синуса - не понимаю.

Давайте рассмотрим такой пример, пусть исходная функция - суть синус с частотой омега, + случайный шум s порядка -16 бит (точность входных). Пусть мы имеем сгенеренный гетеродинный синус с той же частотой и некоторой новой заданной точностью r.

Результат точного интегрирования будет

\int (sin(omega*t)+s)*(sin(omega*t)+r) dt =
\int sin(omega*t)^2 dt + \int sin(omega*t)*(s+r) dt + \int s+r dt

тогда ошибка интегрирования будет определяться нормой шума s или r, причем то, что больше, то и будет эту ошибку определять. Посему я продолжаю не понимать зачем брать больше 16 бит при генерации синуса, и, если кто доступно и математически меня сможет переубедить, буду очень благодарен.

[serjj]

тогда ошибка интегрирования будет определяться нормой шума s или r, причем то, что больше, то и будет эту ошибку определять. Посему я продолжаю не понимать зачем брать больше 16 бит при генерации синуса, и, если кто доступно и математически меня сможет переубедить, буду очень благодарен.

Пожалуйста, другой пример.
После гетеродина со смещением сигнал x = s*c + s*cos(w*t). Допустим мы не делаем усечение разрядности и тащим такой сигнал на наш фильтр-интегратор. s*c << s*cos(w*t) с одной стороны (думаю в доказательстве это не нуждается) и s*c - ВЧ компонент, тогда как s*cos(w*t) - НЧ -- с другой стороны. Тоже думаю логично т.к. s - сигнал на несущей, а c - константа (это некоторое постоянное смещение, т.к. другому шуму там просто неоткуда взяться, шум фазы модулирует синус и имеет совершенно другое воздействие на сигнал, если вдоваться в подробности). Отсюда видно, что наш фильтр-интегратор, являющийся ФНЧ просто отфильтрует эту ВЧ компоненту, которая добавляется к НЧ сигналу после гетеродинирования.

[Fat Robot]

Желаем принимать полезный сигнал на частоте
На частоте присутствует сигнал помехи, превышающий по мощности полезный

принимаемый сигнал



сигнал идеального гетеродина



Сигнал "шумного" гетеродина. Шум упрощенный - единственная спектральная составляющая на частоте .

[iiv]

Сигнал "шумного" гетеродина

как точность-битность вычисления синуса влияет на ???

[Fat Robot]

В реальности шум квантования NCO (для фазы, LUT addr и sin/cos) будет причудливо распределен во всей полосе.

Здесь и например здесь подробнее

Точность-битность влияет на в этом упрощенном описании с единственной "вредной" гармоникой. И, как следствие, на то минимальное отношение , которое не будет приводить к существенному ухудшению харакетристик приемной системы.
Опять же упрощенно это и будет избирательностью по соседнему каналу и/или по блокированию. Т.е. есть сигнал в рабочем канале, а есть гораздо более сильный на отстройке . В идеальном случае сигнал вне рабочей полосы не должен влиять на чувствительность. Но он, негодяй, влияет, в том числе и из-за собственных шумов гетеродина, т.е. из-за значения .

Если в ваших задачах отсутствуют сосредоточенные по полосе помехи, то ваши рассуждения верны.

как точность-битность вычисления синуса влияет на ???

[qwa]

Попробую написать блок работы с файлами,чтобы в симуляторе посмотреть спектр белого шума (сгенерирую в Матлабе).

[des00]

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

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

[Golikov A.]

да про это написано в приведенной раньше ссылке про округление
3.5 == 0011 10 + 0000 10 = 0100 00 -> 0100 = 4 - 0k
-3.5 == 1100 10 + 0000 10 = 1101 00 -> 1101 == -3 - не Ok

[qwa]

Я сделал вот какую вещь : я посмотрел сигнал с выхода фильтра, который равен '1' когда новый отсчет готов на выходе. И он не поднимается из '0' в '1'.
Короче говоря, от умножителей в фильтр что-то поступает, а с фильтра уже ничего не идет.

[qwa]

Разобрался,что я делал не так с ядром фильтра.

[_Anatoliy]

Разобрался,что я делал не так с ядром фильтра.

Вы главное никому не открывайте эту страшную тайну...

[qwa]

Вы главное никому не открывайте эту страшную тайну...

Мне просто стыдно перед самим собой,насколько я был невнимателен.

Есть там такая опция Input Sampling Frequency - она и стала камнем преткновения.

Сообщение отредактировал qwa - Jul 9 2015, 08:49

[qwa]

Тема остается актуальной.

Со всеми округлениями и тд работаю - все равно есть эта поганая постоянная составляющая.

Внесены следующие изменения :
-разрядность на выходе синтезатора частоты установлена на 16 бит;
-выход умножителя 16 на 16 : 17 бит.

По симулятору : работает нормально. Прикладываю скрины :
1) Синус на входе имеет ту же частоту,что и синтезатор частоты;
2) Частота синуса на входе на 1 МГц больше,чем у синтезатора.

И последний полученный спектр.

Первая картинка - частота синуса на входе на 1 МГц больше,чем у синтезатора.
В обоих случаях,выход всей системы - два последних сигнала.

Сообщение отредактировал qwa - Jul 14 2015, 17:19

Эскизы прикрепленных изображений

 

[Fat Robot]

Я предположу, что где-то в умножителях знаковые данные интерпретируются, как беззнаковые.

Если в этом сомнений нет, то проверяйте по каскадам

[qwa]

Я предположу, что где-то в умножителях знаковые данные интерпретируются, как беззнаковые.

Я посмотрел - везде указан тип используемых данных signed (знаковый).

[Fat Robot]

На 1м входе смесителя постоянное значение. На 2м входе - выходной сигнал NCO.
Что на выходе смесителя?

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

Я посмотрел - везде указан тип используемых данных signed (знаковый).

[qwa]

На 1м входе смесителя постоянное значение. На 2м входе - выходной сигнал NCO.
Что на выходе смесителя?

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

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

[Fat Robot]

Оставьте в покое фильтр до поры. К нему мы еще вернемся. Сосредоточьтесь на поставленном вопросе.

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

[qwa]

Всем привет!

В общем, как это обычно и бывает,меня подвела собственная невнимательность.

Не буду рассказывать всю историю, но ситуация такая,что я смотрел спектр сигнала с неразделенными квадратурами (которые,соответственно,не было объединены в комплексный сигнал), о чем разработчик программы для DSP сообщил мне только вчера. В общем,нет больше этой загадочной проблемы с постоянной составляющей, но есть другая.

Мой гетеродин настроен на частоту 75.42 МГц. Я провел 2 теста.

Тест №1.

Внутри моего модуля стоял еще один DDS и выдавал синус. Частота синуса - 76.42 МГц.

Тест №2.

Я подключил к моей системе внешний генератор (гармонических сигналов). Частоту поставил так же 76.42 МГц.

В обоих случаях результат одинаков: в спектре есть нужная и ожидаяемая гармоника на 1 МГц, но есть так же и какая-то левая гармоника в отрицательных частотах (-14.86 МГц). Пересобрал фильтр так,чтобы эта частота была за полосой,и все равно эта гармоника осталась! Спектр в приложении.

Первая картинка - спектр синуса.

Вторая картинка - спектр с генератором до смены фильтра.

Третья картинка - спектр с генератором после смены фильтра.

Какие есть версии её появления?

Эскизы прикрепленных изображений

 

[Самурай]

...
В обоих случаях результат одинаков: в спектре есть нужная и ожидаяемая гармоника на 1 МГц, но есть так же и какая-то левая гармоника в отрицательных частотах (-14.86 МГц).
...
Какие есть версии её появления?

1. А что собственно не так? Лично я пока вижу периодическое повторение спектра комплексной синусоиды, дискретизированной с частотой 15МГц. А вот зачем у Вас диапазон по оси частот от -15 до +15, так это уже к Вам вопрос. Никто же не знает толком, что Вы там делаете. И как.

2. К слову на первом графике у Вас основная гармоника явно больше 1МГц, да и «левая гармоника» невооруженным глазом видно, что ну никак не -14.86МГц.

3. Спектры у Вас безобразные, мягко говоря, причем все. Подозреваю, что и DDS и DDC работают через эээ... не совсем должным образом, скажем так.

Мой Вам совет – начните с модели в Матлабе. И поднимите теорию DDC. Без теории Вас так и будет бесконечно подводить собственная невнимательность.