[Koluchiy 0]

Здравствуйте, уважаемые гуры.

 

Замыслил тут простейшую вещь - интерфейс между 2мя FPGA Kintex US+.

Делаю интерфейс на LVDS, и состоит от из:

1) Линии передачи клока 150 Мгц;

2) Нескольких линий данных.

 

Никакие oserdes не использую, прямо с регистров передаю в OBUFDS.

Тактовая частота передается с выхода PLL. При этом, выходной регистр тактируется 150МГц с фазой 0, а на выход подается с той же PLL 150 МГц с фазой 180 (инвертированный).

Вот мои констрейны:

set_output_delay -clock [get_clocks o_lvds_clock] -min -3.300 -add_delay [get_ports {o_lvds_p[*]}]
set_output_delay -clock [get_clocks o_lvds_clock] -max 3.300 -add_delay [get_ports {o_lvds_p[*]}]

 

В чем проблема.

Когда Vivado считает временные характеристики, например для hold она мне посчитала, что для данных на выход Arrival time 4.081 нс.

А для выходного клока время на выход 7.8 нс. К этому она прибавляет 3.3 нс с моего констрейна и выдает, что Required time 11.104 нс, и слак -7.023 нс.

При этом, совершенно не учитывает, что у клока есть период, и он равен 6.667 нс, и это значит, что данные, которые пришли в 4.081 нс, надо проверять по предыдущему фронту, который был 7.8нс - 6.667 = 1.1 нс.

 

Подскажите, как объяснить Vivado, что клок периодический? В списке клоков всё в порядке, частоты нормальные.

 

Всем заранее спасибо.

[quato_a 3]

А может воспользоваться выводом клока через oddr, без создания двух клоков с 0 и 180 фазой. Мне кажется проблема в разных клоках. 

P. S. Можно ещё проще и воспользоваться готовой коркой chip2chip

[Koluchiy 0]

Хочу сделать так, как описал выше.

В моем понимании, должно работать.

 

2 частоты не являются главное проблемой. Когда была 1 частота, анализ времянок был в целом такой же - "я посчитаю прохождение 1 фронта, а что там раньше и позже, не мое дело".

 

[slkhome 0]

On 7/26/2022 at 4:01 PM, Koluchiy said:

Хочу сделать так, как описал выше.

В моем понимании, должно работать.

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

[Koluchiy 0]

Констрейны, касающиеся вопроса, привел. Какие еще Вы бы хотели увидеть?

Выходные буферы вот, не знаю что это дает.

  for (NumBuf = 0; NumBuf < 8; NumBuf = NumBuf + 1)
    begin:OBUFDS_ForBlock
      OBUFDS o_data_out (.I(tx_data8[NumBuf]), .O(o_lvds_p[NumBuf]), .OB(o_lvds_n[NumBuf]));
    end
...
OBUFDS o_clk_out (.I(iclk_lvds_inv), .O(oclk_lvds_p), .OB(oclk_lvds_n));

 

[des00 25]

On 7/26/2022 at 4:30 PM, Koluchiy said:

Когда Vivado считает временные характеристики, например для hold она мне посчитала, что для данных на выход Arrival time 4.081 нс.

А для выходного клока время на выход 7.8 нс. К этому она прибавляет 3.3 нс с моего констрейна и выдает, что Required time 11.104 нс, и слак -7.023 нс.

При этом, совершенно не учитывает, что у клока есть период, и он равен 6.667 нс, и это значит, что данные, которые пришли в 4.081 нс, надо проверять по предыдущему фронту, который был 7.8нс - 6.667 = 1.1 нс.

все правильно она делает, как вы написали в однотактовой модели так и делает)

On 7/26/2022 at 4:30 PM, Koluchiy said:

Подскажите, как объяснить Vivado, что клок периодический? В списке клоков всё в порядке, частоты нормальные.

чтобы подвинуть нужные вам фронты сигнала тактирования приемника/источника, нужно воспользоваться командой set_multicycle_path и задать сдвиг фронта, сохранив однотактную модель. Причем надо помнить (!!!), т.к. это сдвиг на N тактов, то подвинется и фронт для setup и фронт для hold)

PS. как то много 7.8 нс для пути. Вангую что тактовая пошла до спец.блока, который поднял его на логику, протащил по плисе и подал на выход. Это еще и в температуре плывет прилично. ИМХО ODDR ваше всё.

[Koluchiy 0]

Честно говоря, плохо понимаю эту ситуацию.

Чем она отличается от стандартной "тактирование внешнего ЦАП"? Да ничем.

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

[user_fpga 0]

а как тогда ODDR законстрейнить? (синхронизация по переднему фронту). как не пытался но вивадо по обеим фронтам считает

 

Изменено 9 августа, 2022 пользователем user_fpga

[gosha 0]

On 7/26/2022 at 12:30 PM, Koluchiy said:

Здравствуйте, уважаемые гуры.

 

Замыслил тут простейшую вещь - интерфейс между 2мя FPGA Kintex US+.

Делаю интерфейс на LVDS, и состоит от из:

1) Линии передачи клока 150 Мгц;

2) Нескольких линий данных.

 

Никакие oserdes не использую, прямо с регистров передаю в OBUFDS.

Тактовая частота передается с выхода PLL. При этом, выходной регистр тактируется 150МГц с фазой 0, а на выход подается с той же PLL 150 МГц с фазой 180 (инвертированный).

Вот мои констрейны:

set_output_delay -clock [get_clocks o_lvds_clock] -min -3.300 -add_delay [get_ports {o_lvds_p[*]}]
set_output_delay -clock [get_clocks o_lvds_clock] -max 3.300 -add_delay [get_ports {o_lvds_p[*]}]

 

В чем проблема.

Когда Vivado считает временные характеристики, например для hold она мне посчитала, что для данных на выход Arrival time 4.081 нс.

А для выходного клока время на выход 7.8 нс. К этому она прибавляет 3.3 нс с моего констрейна и выдает, что Required time 11.104 нс, и слак -7.023 нс.

При этом, совершенно не учитывает, что у клока есть период, и он равен 6.667 нс, и это значит, что данные, которые пришли в 4.081 нс, надо проверять по предыдущему фронту, который был 7.8нс - 6.667 = 1.1 нс.

 

Подскажите, как объяснить Vivado, что клок периодический? В списке клоков всё в порядке, частоты нормальные.

 

Всем заранее спасибо.

У меня, задание ручками output_delay только ухудшило ситуацию. Из-за тупости, не смог расчитать верные изначения..

Задание только частот всех синхросигналов - оказывалось всегда достаточным, если топология не кривая.

Убрать set_output_delay  совсем не пробовали ?

[user_fpga 0]

В 16.08.2022 в 13:52, gosha сказал:

У меня, задание ручками output_delay только ухудшило ситуацию. Из-за тупости, не смог расчитать верные изначения..

Задание только частот всех синхросигналов - оказывалось всегда достаточным, если топология не кривая.

Убрать set_output_delay  совсем не пробовали ?

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