[qwa 0]

Всем привет.

 

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

 

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

 

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

 

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

 

ПЛИС: Xilinx Virtex 5

 

Ядра, которые я использовал:

-DDS Compiler (синтезатор частоты);

-FIR Compiler (КИХ фильтр);

-Multiplier (умножитель).

[rloc 57]

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

[qwa 0]

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

Есть понижение разрядности,что эквивалентно делению.

Как я понимаю,это не то что вы имеете в виду.

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

[rloc 57]

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

 

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

 

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

[qwa 0]

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

 

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;

 

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

 

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

Изменено 5 июля, 2015 пользователем qwa

[FatRobot 3]

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

 

Насчет вашей угадайки: показывайте спектры

Входной сигнал

Гетеродин

Смеситель

 

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

[qwa 0]

Округляете вы правильно, но описываете это коряво. Достаточно без всяких условий к разряду, предшествующему младшему для выхода, прибавить 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.

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

[FatRobot 3]

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

 

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

[qwa 0]

Итак,вот что я увидел.

На вход - синус,частота его в полосе пропускания фильтра.

Первый сигнал - клок.

Следующий - сигнал асинхронного сброса.

Далее - управляющий сигнал от процессора.

Далее - входной сигнал.

Следующие 2 сигнала - выход умножителей после умножения на син/кос с округлением.

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

 

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

 

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

 

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

 

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

Изменено 5 июля, 2015 пользователем qwa

[Golikov 0]

остаточно без всяких условий к разряду, предшествующему младшему для выхода, прибавить 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 0]

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

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

Думаю,там вы найдете ответ на свой вопрос.

 

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

[FatRobot 3]

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

 

-0.7 в вашем примере надо усекать, а не пытаться округлять к нулю дальше.

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

 

но для отрицательных

-1.2 + 0.5 = -0.7 -> 0

[Golikov 0]

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

 

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 0]

В общем,я обнаружил,что умножал просто на синус, а вообще надо бы на минус синус.

К улучшению результата это не привело....

[iiv 29]

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

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

 

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

 

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

 

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

 

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

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