18.04.2016 Вот теперь он синхронный

Материал из SRNS
Перейти к: навигация, поиск
(Новая страница: «<summary [ hidden ] > Кажется, это победа! </summary> {{TOCright}} 400px == Зачем? ==»)
 
 
(не показаны 15 промежуточных версий 2 участников)
Строка 1: Строка 1:
 
<summary [ hidden ] >
 
<summary [ hidden ] >
 +
 +
[[File:20160418 CorrDiff RegData80 v1a.png|400px|center]]
  
 
Кажется, это победа!
 
Кажется, это победа!
 +
 
</summary>
 
</summary>
 +
 +
Кажется, это победа!
 +
 +
UPD: после почти двухнедельного тестирования в СПП победа подтверждается. Текущий софт попросили назвать "Версия 1.0".
  
 
{{TOCright}}
 
{{TOCright}}
  
−
[[File:20160418_KDPV.gif|400px]]
+
== Предыстория ==
 +
 
 +
Была [[Blog:Boldenkov/05.04.2016_А_вы_думали,_коррелятор-синхронное_устройство%3F! | проблема с измерениями]]
 +
 
 +
== Симптомы ==
 +
 
 +
Если настроить все каналы на один и тот же сигнал и посмотреть разность измерений псевдодальности, получится что-то в этом роде:
 +
 
 +
[[File:20160415_CorrDiffRange_1.png|400px]]
 +
 
 +
В правой части - распределение разности измерений задержек по каналам коррелятора. Картинка повторяемая.
 +
 
 +
== В чём дело? ==
 +
 
 +
Для выяснения причин нужно углубиться в исходники коррелятора. Входные сигналы поступает в ПЛИС в последовательном виде по интерфесу LVDS. В ПЛИС стоит блок десериалайзера, преобразующий последовательный поток данных в параллельный. При этом десериалайзер также является источником тактового сигнала для остальной схемы:
 +
 
 +
<source lang="Verilog">
 +
zynq_deser_main #(
 +
  .D(`NUMBER_OF_LANE),
 +
  .REF_FREQ(200.0),
 +
  .CLKIN_PERIOD(8))
 +
  DESER (
 +
.refclk        (clk_200_buf), // Reference clock for input delay control
 +
.reset_delay  (!prog_reset),
 +
.CLK_LVDS_P    (clkin_p),
 +
`ifndef SINGLE_CLK_DESER
 +
.CLK_LVDS_N    (clkin_n), // lvds channel 1 clock input
 +
`endif
 +
.DAT_LVDS_P    (datain_p),
 +
.DAT_LVDS_N    (datain_n), // lvds channel 1 data inputs
 +
.gclk          (clk_adc_ext),
 +
.fpga_dat      (fpga_dat),
 +
.clk_dat      (),
 +
.dat_lock      (dat_lock),
 +
.debug        (debug)
 +
);
 +
</source>
 +
 
 +
Здесь данные - линии fpga_dat, а тактовый сигнал - clk_adc_ext.
 +
 
 +
Далее тактовый сигнал поступает на мультиплексор тактовых сигналов BUFGMUX:
 +
 
 +
<source lang="bash">
 +
  BUFGMUX #(
 +
    .CLK_SEL_TYPE("ASYNC")  // Glitchles ("SYNC") or fast ("ASYNC") clock switch-over
 +
  )
 +
  BUFGMUX_MUX0 (
 +
      .O(pclk),  // 1-bit output: Clock buffer output
 +
      .I0(aclk), // 1-bit input: Clock buffer input (S=0)
 +
      .I1(clk_adc_ext), // 1-bit input: Clock buffer input (S=1)
 +
      .S(clksource)    // 1-bit input: Clock buffer select
 +
  );
 +
</source>
 +
 
 +
Сигнал clksource выбирает, какой из тактовых сигналов будет поступать на pclk - либо clk_adc_ext, либо aclk. При этом BUFGMUX создаёт новый тактовый сигнал pclk.
 +
 
 +
Что происходит с данными десериалайзера? Они по-прежнему находятся в домене clk_adc_ext. И хотя тактовый сигнал pclk формируется из clk_adc_ext, с точки зрения Vivado они находятся в другом домене.
 +
 
 +
Что происходит дальше? Источник pclk - буфер BUFGMUX, находится в середине ПЛИС. Источник данных - десериалайзер - находится с краю ПЛИС. Эти сигналы (и pclk, и данные) распределяются между каналами коррелятора по всей ПЛИС.
 +
 
 +
Т.к. Vivado не рассматривает данные fpga_dat, как относящиеся к домену pclk, видимо, контроль задержек этих сигналов отсутствует. В результате этого сигналы, распространяясь по ПЛИС, приобретают разные задержки, которые мы и видим в измерениях.
 +
 
 +
На своём пути сигналы fpga_dat имеют кучу комбинационной логики - мультиплексоры сигналов в каждом из каналов и таблицы, осуществляющие перемножение на опорных сигнал. Первая синхронная операция - накопление в накопительном сумматоре. Неудивительно, что возникли проблемы.
 +
 
 +
== Попытки преодоления проблемы ==
 +
 
 +
Сначала был исключён мультиплексор тактовых сигналов. Казалось бы, это должно решить проблему, но нет.
 +
 
 +
Результаты для четырёх каналов:
 +
 
 +
[[File:20160418_CorrDiff_AssignPclk4_v1.png|400px]]
 +
 
 +
Разница в задержках исчезла!
 +
 
 +
Результаты для 80 каналов:
 +
 
 +
[[File:20160418_CorrDiff_AssignPclk80_v1.png|400px]]
 +
 
 +
Разница есть! Картинка отличается от той, что была раньше, но проблема осталась.
 +
 
 +
== Решение ==
 +
 
 +
Окончательным решением мне казалось не избавление от мультиплексора, а защёлкивание данных в тактах pclk.
 +
 
 +
<source lang="Verilog">
 +
  wire [7 * `NUMBER_OF_LANE - 1 : 0] fpga_dat;
 +
  reg  [7 * `NUMBER_OF_LANE - 1 : 0] fpga_dat_pclk;
 +
 
 +
  ...
 +
 
 +
  always @(posedge pclk) begin
 +
      fpga_dat_pclk <= fpga_dat;  // Transit from clk_adc_ext to pclk domain
 +
  end
 +
 
 +
  ...
 +
 
 +
  assign adc_sig0 = fpga_dat_pclk[0];
 +
  assign adc_mag0 = fpga_dat_pclk[7];
 +
  ...
 +
</source>
 +
 
 +
В результате этих изменений проблема была решена.
 +
 
 +
== Результаты ==
 +
 
 +
Работа 80 каналов коррелятора:
 +
 
 +
[[File:20160418_CorrDiff_RegData80_v1.png|400px]] [[File:20160418_CorrDiff_RegData80_v1a.png|400px]]
 +
 
 +
Собран коррелятор на 100 каналов. Если использовать только 80 из них, результат такой:
 +
 
 +
[[File:20160418_CorrDiff_RegData100_v1.png|400px]] [[File:20160418_CorrDiff_RegData100_v1a.png|400px]]
 +
 
 +
При использовании всех 100 каналов коррелятор работает, но производительности процессора на данный момент не хватает. Результаты при 100 каналах:
 +
 
 +
[[File:20160418_CorrDiff_RegData100_v2.png|400px]]
 +
 
 +
== Проблема стабильности работы ==
 +
 
 +
Новая прошивка плохо отработала в СПП - через некоторое теряла спутники по мере их ухода за горизонт.
 +
 
 +
В программу внесены некоторые изменения, связанные с отладочным выводом. Полученная прошивка запущена на 161 и 165 приборах. Ниже приведены графики количества занятых каналов.
 +
 
 +
[[File:20160425_Nch_161_1.png|400px]] [[File:20160425_Nch_165_1.png|400px]]
 +
 
 +
Вот совмещённые графики для двух приборов:
 +
 
 +
[[File:20160425_Nch_161_165_1.png|400px]]
 +
 
 +
Приборы ведут себя идентично, сигналы не пропадают. Принимались только сигналы ГЛОНАСС L1/L2/OF/SF. Длительность наблюдаемого интервала - 61 час.
 +
 
 +
Результаты работы прошивки в СПП
 +
 
 +
[[File:20160426_Nch_1.png|400px]]
 +
 
 +
Добавил перезагрузку раз в час, результат:
 +
 
 +
[[File:20160427_Nch_1.png|400px]]
 +
 
 +
28 апреля: сравнение приборов 161, 164, 165.
 +
 
 +
[[File:20160428_Nch_all1.png|400px]]
 +
 
 +
Результаты работы всех трёх приёмников:
 +
 
 +
[[File:20160428_Nch_161_164_165.png|800px]]
  
−
== Зачем? ==
+
{{wl-publish: 2016-04-18 11:26:03 +0300 | Boldenkov }}

Текущая версия на 12:08, 13 мая 2016

Кажется, это победа!

UPD: после почти двухнедельного тестирования в СПП победа подтверждается. Текущий софт попросили назвать "Версия 1.0".

Содержание

[править] Предыстория

Была проблема с измерениями

[править] Симптомы

Если настроить все каналы на один и тот же сигнал и посмотреть разность измерений псевдодальности, получится что-то в этом роде:

20160415 CorrDiffRange 1.png

В правой части - распределение разности измерений задержек по каналам коррелятора. Картинка повторяемая.

[править] В чём дело?

Для выяснения причин нужно углубиться в исходники коррелятора. Входные сигналы поступает в ПЛИС в последовательном виде по интерфесу LVDS. В ПЛИС стоит блок десериалайзера, преобразующий последовательный поток данных в параллельный. При этом десериалайзер также является источником тактового сигнала для остальной схемы:

        zynq_deser_main #(
                .D(`NUMBER_OF_LANE),
                .REF_FREQ(200.0),
                .CLKIN_PERIOD(8))
        DESER (
                .refclk        (clk_200_buf),                   // Reference clock for input delay control
                .reset_delay   (!prog_reset),
                .CLK_LVDS_P    (clkin_p),
                `ifndef SINGLE_CLK_DESER
                .CLK_LVDS_N    (clkin_n),                       // lvds channel 1 clock input
                `endif
                .DAT_LVDS_P    (datain_p),
                .DAT_LVDS_N    (datain_n),                      // lvds channel 1 data inputs
                .gclk          (clk_adc_ext),
                .fpga_dat      (fpga_dat),
                .clk_dat       (),
                .dat_lock      (dat_lock),
                .debug         (debug)
        );

Здесь данные - линии fpga_dat, а тактовый сигнал - clk_adc_ext.

Далее тактовый сигнал поступает на мультиплексор тактовых сигналов BUFGMUX:

        BUFGMUX #(
        .CLK_SEL_TYPE("ASYNC")  // Glitchles ("SYNC") or fast ("ASYNC") clock switch-over
        )
        BUFGMUX_MUX0 (
        .O(pclk),   // 1-bit output: Clock buffer output
        .I0(aclk), // 1-bit input: Clock buffer input (S=0)
        .I1(clk_adc_ext), // 1-bit input: Clock buffer input (S=1)
        .S(clksource)    // 1-bit input: Clock buffer select
        );

Сигнал clksource выбирает, какой из тактовых сигналов будет поступать на pclk - либо clk_adc_ext, либо aclk. При этом BUFGMUX создаёт новый тактовый сигнал pclk.

Что происходит с данными десериалайзера? Они по-прежнему находятся в домене clk_adc_ext. И хотя тактовый сигнал pclk формируется из clk_adc_ext, с точки зрения Vivado они находятся в другом домене.

Что происходит дальше? Источник pclk - буфер BUFGMUX, находится в середине ПЛИС. Источник данных - десериалайзер - находится с краю ПЛИС. Эти сигналы (и pclk, и данные) распределяются между каналами коррелятора по всей ПЛИС.

Т.к. Vivado не рассматривает данные fpga_dat, как относящиеся к домену pclk, видимо, контроль задержек этих сигналов отсутствует. В результате этого сигналы, распространяясь по ПЛИС, приобретают разные задержки, которые мы и видим в измерениях.

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

[править] Попытки преодоления проблемы

Сначала был исключён мультиплексор тактовых сигналов. Казалось бы, это должно решить проблему, но нет.

Результаты для четырёх каналов:

20160418 CorrDiff AssignPclk4 v1.png

Разница в задержках исчезла!

Результаты для 80 каналов:

20160418 CorrDiff AssignPclk80 v1.png

Разница есть! Картинка отличается от той, что была раньше, но проблема осталась.

[править] Решение

Окончательным решением мне казалось не избавление от мультиплексора, а защёлкивание данных в тактах pclk.

   wire [7 * `NUMBER_OF_LANE - 1 : 0] fpga_dat;
   reg  [7 * `NUMBER_OF_LANE - 1 : 0] fpga_dat_pclk;

   ...

   always @(posedge pclk) begin
      fpga_dat_pclk <= fpga_dat;  // Transit from clk_adc_ext to pclk domain
   end

   ...

   assign adc_sig0 = fpga_dat_pclk[0];
   assign adc_mag0 = fpga_dat_pclk[7];
   ...

В результате этих изменений проблема была решена.

[править] Результаты

Работа 80 каналов коррелятора:

20160418 CorrDiff RegData80 v1.png 20160418 CorrDiff RegData80 v1a.png

Собран коррелятор на 100 каналов. Если использовать только 80 из них, результат такой:

20160418 CorrDiff RegData100 v1.png 20160418 CorrDiff RegData100 v1a.png

При использовании всех 100 каналов коррелятор работает, но производительности процессора на данный момент не хватает. Результаты при 100 каналах:

20160418 CorrDiff RegData100 v2.png

[править] Проблема стабильности работы

Новая прошивка плохо отработала в СПП - через некоторое теряла спутники по мере их ухода за горизонт.

В программу внесены некоторые изменения, связанные с отладочным выводом. Полученная прошивка запущена на 161 и 165 приборах. Ниже приведены графики количества занятых каналов.

20160425 Nch 161 1.png 20160425 Nch 165 1.png

Вот совмещённые графики для двух приборов:

20160425 Nch 161 165 1.png

Приборы ведут себя идентично, сигналы не пропадают. Принимались только сигналы ГЛОНАСС L1/L2/OF/SF. Длительность наблюдаемого интервала - 61 час.

Результаты работы прошивки в СПП

20160426 Nch 1.png

Добавил перезагрузку раз в час, результат:

20160427 Nch 1.png

28 апреля: сравнение приборов 161, 164, 165.

20160428 Nch all1.png

Результаты работы всех трёх приёмников:

20160428 Nch 161 164 165.png


— Болденков Евгений • 12:26, 18 апреля 2016 • нет комментариев

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

Источник — «https://server.srns.ru/index.php?title=Blog:Boldenkov/18.04.2016_Вот_теперь_он_синхронный&oldid=18166»
Персональные инструменты
Пространства имён

Варианты
Действия
SRNS Wiki
Рабочие журналы
Приватный файлсервер
QNAP Сервер
Инструменты