Koluchiy 0 26 июля, 2022 Опубликовано 26 июля, 2022 · Жалоба Здравствуйте, уважаемые гуры. Замыслил тут простейшую вещь - интерфейс между 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 26 июля, 2022 Опубликовано 26 июля, 2022 · Жалоба А может воспользоваться выводом клока через oddr, без создания двух клоков с 0 и 180 фазой. Мне кажется проблема в разных клоках. P. S. Можно ещё проще и воспользоваться готовой коркой chip2chip Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Koluchiy 0 26 июля, 2022 Опубликовано 26 июля, 2022 · Жалоба Хочу сделать так, как описал выше. В моем понимании, должно работать. 2 частоты не являются главное проблемой. Когда была 1 частота, анализ времянок был в целом такой же - "я посчитаю прохождение 1 фронта, а что там раньше и позже, не мое дело". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slkhome 0 27 июля, 2022 Опубликовано 27 июля, 2022 · Жалоба On 7/26/2022 at 4:01 PM, Koluchiy said: Хочу сделать так, как описал выше. В моем понимании, должно работать. Приведите весь текст констрейнтов. Так будет проще понимать чего вы хотите. А еще лучше и часть кода, где реализованы выходные буферы интерфейса. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Koluchiy 0 27 июля, 2022 Опубликовано 27 июля, 2022 · Жалоба Констрейны, касающиеся вопроса, привел. Какие еще Вы бы хотели увидеть? Выходные буферы вот, не знаю что это дает. 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 3 августа, 2022 Опубликовано 3 августа, 2022 · Жалоба 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 8 августа, 2022 Опубликовано 8 августа, 2022 · Жалоба Честно говоря, плохо понимаю эту ситуацию. Чем она отличается от стандартной "тактирование внешнего ЦАП"? Да ничем. Большая задержка по пути передачи выходного тактового сигнала ломает весь алгоритм расчета времянок? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
user_fpga 0 9 августа, 2022 Опубликовано 9 августа, 2022 (изменено) · Жалоба а как тогда ODDR законстрейнить? (синхронизация по переднему фронту). как не пытался но вивадо по обеим фронтам считает Изменено 9 августа, 2022 пользователем user_fpga Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gosha 0 16 августа, 2022 Опубликовано 16 августа, 2022 · Жалоба 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 19 августа, 2022 Опубликовано 19 августа, 2022 · Жалоба В 16.08.2022 в 13:52, gosha сказал: У меня, задание ручками output_delay только ухудшило ситуацию. Из-за тупости, не смог расчитать верные изначения.. Задание только частот всех синхросигналов - оказывалось всегда достаточным, если топология не кривая. Убрать set_output_delay совсем не пробовали ? в set_output delay и есть смысл что бы понять как фронт клока смещен относительно данных на выходе. без него это только задержка внутри логики между регистрами, например в 8 разрядном счетчике. там всегда все гуд будет в отличие от выхода который не использует ODDR регистры Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться