[masverter 0]

Здравствуйте!

У меня есть АЦП ADS5404 и ПЛИС Kintex7 xc7k325tffg676-2. На данный момент получается принимать без искажений данные от АЦП со скоростью 400 Msps. Хочется 500.

В ПЛИС тактовые входы поступают на IBUFGDS, входы данных - на IBUFDS, затем на IDDR, защелкиваются глобальными клоками с IBUFGDS. Пробовал защелкивать каждый канал своим клоком, затем перещелкивал на общий клок. Это приводило к тому, что данные задерживались на такт в одном из каналов относительно другого. В итоге пришел к тому, что сразу защелкиваю данные одним клоком.

Во временном анализе большие hold slack’и.

Ограничения на интерфейс описывал по шаблону (Center-Aligned Double Data Rate Source Synchronous Inputs)

Spoiler

create_clock -period 4.000 -name ADC_CLK_I -waveform {0.000 2.000} [get_ports {RB_P[15]}]
create_clock -period 4.000 -name ADC_CLK_Q -waveform {0.000 2.000} [get_ports {RA_P[2]}]
# ADS540x Center-Aligned Double Data Rate Source Synchronous Inputs 
# Channel I
set chi_input_clock   ADC_CLK_I; # Name of input clock for channel I
set chi_clock_period  4.000;    # Period of chi_clock (full-period)
set chi_dv_bre        0.800;    # Data valid before the rising clock edge
set chi_dv_are        0.790;    # Data valid after the rising clock edge
set chi_dv_bfe        0.800;    # Data valid before the falling clock edge
set chi_dv_afe        0.790;    # Data valid after the falling clock edge
set chi_ports         [get_ports {RA_P[9] RB_P[8] RA_P[10] RB_P[9] RA_P[11] RA_P[12] RB_P[10] RB_P[12] RB_P[11] RA_P[14] RB_P[13] RA_P[15] RA_P[13]} ];     # List of I channel input ports
# Input Delay Constraint
set_input_delay -clock $chi_input_clock -max [expr $chi_clock_period/2 - $chi_dv_bfe] [get_ports $chi_ports];
set_input_delay -clock $chi_input_clock -min $chi_dv_are                              [get_ports $chi_ports];
set_input_delay -clock $chi_input_clock -max [expr $chi_clock_period/2 - $chi_dv_bre] [get_ports $chi_ports] -clock_fall -add_delay;
set_input_delay -clock $chi_input_clock -min $chi_dv_afe                              [get_ports $chi_ports] -clock_fall -add_delay;
# Channel Q
set chq_input_clock   ADC_CLK_Q; # Name of input clock for channel Q
set chq_clock_period  4.000;    # Period of chq_clock (full-period)
set chq_dv_bre        0.900;    # Data valid before the rising clock edge
set chq_dv_are        0.600;    # Data valid after the rising clock edge
set chq_dv_bfe        0.900;    # Data valid before the falling clock edge
set chq_dv_afe        0.600;    # Data valid after the falling clock edge
set chq_ports         [get_ports {RA_P[1] RB_P[1] RB_P[2] RA_P[3] RB_P[3] RA_P[4] RB_P[4] RB_P[5] RA_P[5] RA_P[7] RB_P[6] RB_P[7] RA_P[8]} ];     # List of Q channel input ports
# Input Delay Constraint
set_input_delay -clock $chi_input_clock -max [expr $chq_clock_period/2 - $chq_dv_bfe] [get_ports $chq_ports];
set_input_delay -clock $chi_input_clock -min $chq_dv_are                              [get_ports $chq_ports];
set_input_delay -clock $chi_input_clock -max [expr $chq_clock_period/2 - $chq_dv_bre] [get_ports $chq_ports] -clock_fall -add_delay;
set_input_delay -clock $chi_input_clock -min $chq_dv_afe                              [get_ports $chq_ports] -clock_fall -add_delay;

 

 

Подскажите, пожалуйста, что не так делаю?

Изменено 9 февраля, 2022 пользователем masverter

[MegaVolt 25]

500 Мгц это уже хорошо бы делать автоматическую подстройку задержки данных под клок. С фиксированной задержкой во всём диапазоне температур не потянет уже.
Плюс защёлкивать не в IDDR а на SerDes и понижать частоты до приемлемых.

[masverter 0]

500 много - а как понять сколько нормально без автоматической подстройки?

Подскажите, а что даст ISERDES? Позволит паковать данные по n слов, тем самым можно понизить частоту последующей обработки данных? Сейчас на IDDR приходит тактовая 250 МГц, данные 500 МГц. На выходе по одному каналу получаю два слова двойной разрядности. В принципе, 250 для последующей обработки нормально.

Провел эксперимент - задал в констрейнах частоту АЦП 125 МГц, в два раза увеличил время валидности данных - hold slack стал меньше примерно в два раза, но он все равно большой!
 

[MegaVolt 25]

7 минут назад, masverter сказал:

500 много - а как понять сколько нормально без автоматической подстройки?

Подскажите, а что даст ISERDES? Позволит паковать данные по n слов, тем самым можно понизить частоту последующей обработки данных? Сейчас на IDDR приходит тактовая 250 МГц, данные 500 МГц. На выходе по одному каналу получаю два слова двойной разрядности. В принципе, 250 для последующей обработки нормально.

Провел эксперимент - задал в констрейнах частоту АЦП 125 МГц, в два раза увеличил время валидности данных - hold slack стал меньше примерно в два раза, но он все равно большой!
 

Когда я решал похожую задачу у меня вышла граница где то в районе 250 Мгц. Т.е. выше 250 Мгц нужно применять подстройку. Ниже можно и без неё. Опять же речь про полный диапазон температур и Kintex :)
Если 250 Мгц нормальная частота для обработки то нет проблем. Как по мне это многовато.... 125 сильно лучше :))))

[neon416 0]

4 часа назад, masverter сказал:

Center-Aligned Double Data Rate Source Synchronous Inputs

А в настройках АЦП фаза клока так же выставлена?

1 час назад, MegaVolt сказал:

Т.е. выше 250 Мгц нужно применять подстройку. 

Какая-то странная проблема. 
Недавно так же заводил шину АЦП в спартан6. Тактирование через PLL и BUFPLL. Из констрейнов только глобальный на период клока. Граница получилась 1200 МГц (т.е. уже за пределами допустимой частоты PLL VCO и SERDES). В диапазоне температур 0..70.
 

Изменено 9 февраля, 2022 пользователем neon416

[masverter 0]

19 minutes ago, neon416 said:

А в настройках АЦП фаза клока так же выставлена?

Да, также. Фаза вроде через настройки не меняется.

[neon416 0]

Посмотрел даташит. Да, вроде клок жестко прибит к центру данных. 

Плата, надеюсь, корректно разведена по задержкам?

В целом история какая: вот это все dedicated routing

4 часа назад, masverter сказал:

В ПЛИС тактовые входы поступают на IBUFGDS, входы данных - на IBUFDS, затем на IDDR, защелкиваются глобальными клоками с IBUFGDS.

т.е. констрейнить задержки здесь бессмысленно. Они какие есть, такие есть и определяются кремнием.

Задержка пути данных и клока отличаются на величину задержки в BUFG. Вообще, в 7й серии для тактирования IDDR или SERDES надо использовать BUFR+BUFIO. Или ставить IDELAY по данным, но это колхоз и костыль.

В идеале стоит сделать тактирование через PLL, тогда все вопросы с температурами и т.п. будут закрыты полностью. Без бреда с IDELAY и уж тем более ее динамической подстройкой.

 

[Strob 0]

1 hour ago, neon416 said:

Или ставить IDELAY по данным, но это колхоз и костыль.

Сильно спорное утверждение.

5 hours ago, masverter said:

На данный момент получается принимать без искажений данные от АЦП со скоростью 400 Msps. Хочется 500

Скорее всего проблема именно в том, что надо подстраивать задержки на линиях данных

[neon416 0]

7 минут назад, Strob сказал:

Сильно спорное утверждение.

Скорее всего проблема именно в том, что надо подстраивать задержки на линиях данных

Не надо создавать проблему, а потом бороться с ней подпорками. Хотя это "модно и современно".

См. мое сообщение выше про достигнутую на древнем с6 частоту. Без IDELAY, разумеется. Вариант с BUFIO2 и IDELAY так же проверялся, с трудом дотягивает до 900 МГц. Потом начинаются всякие глюки по прогреву.

 

 

[MegaVolt 25]

18 часов назад, neon416 сказал:

Какая-то странная проблема. 
Недавно так же заводил шину АЦП в спартан6. Тактирование через PLL и BUFPLL. Из констрейнов только глобальный на период клока. Граница получилась 1200 МГц (т.е. уже за пределами допустимой частоты PLL VCO и SERDES). В диапазоне температур 0..70.

Ответ был в контексте вопроса. Там тактирование без PLL

У подхода с подстройками задержки есть свои плюсы. Например нет необходимости в выравнивании дифпар между собой.

На фотке слева сигналы с выравниванием. Влезло 7 диф пар. Справа 12 без выравнивания. Разница на лицо :)

18 часов назад, neon416 сказал:

Недавно так же заводил шину АЦП в спартан6. Тактирование через PLL и BUFPLL. Из констрейнов только глобальный на период клока. Граница получилась 1200 МГц (т.е. уже за пределами допустимой частоты PLL VCO и SERDES). В диапазоне температур 0..70.

Если не секрет как осуществляется компенсация задержек которые изменяются от температуры?

[masverter 0]

Всем спасибо за ответы!

16 hours ago, neon416 said:

Плата, надеюсь, корректно разведена по задержкам?

Да, длины проводников выровнены.

 

16 minutes ago, MegaVolt said:

Ответ был в контексте вопроса. Там тактирование без PLL

18 hours ago, neon416 said:

В идеале стоит сделать тактирование через PLL, тогда все вопросы с температурами и т.п. будут закрыты полностью. Без бреда с IDELAY и уж тем более ее динамической подстройкой.

Не принципиально, можно и с PLL - главное, чтобы работало. В чем преимущество подхода с ФАПЧ? Вы на нем фазу клока под данные в ходе экспериментов подстраиваете, затем константой забиваете? Почему не констрейните? И какой буфер использовать на 7 серии?

 

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

 

18 hours ago, neon416 said:

Вообще, в 7й серии для тактирования IDDR или SERDES надо использовать BUFR+BUFIO

Но для этого нужно было плату соответствующим образом разводить.

[neon416 0]

36 минут назад, masverter сказал:

Не принципиально, можно и с PLL - главное, чтобы работало. В чем преимущество подхода с ФАПЧ? 

PLL компенсирует задержку клокового дерева ко входу данных ПЛИС при любых температурах и т.п. В результате все работает четко при любых температурах и без ножного привода)

41 минуту назад, masverter сказал:

Вы на нем фазу клока под данные в ходе экспериментов подстраиваете, затем константой забиваете?

Ничего не надо подстраивать, забивать. Просто аккуратно использовать связку буферов и PLL, в документации xilinx это подробно описано.

43 минуты назад, masverter сказал:

Почему не констрейните?

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

46 минут назад, masverter сказал:

И какой буфер использовать на 7 серии?

Для работы с PLL? Не изучал, врать не буду.

48 минут назад, masverter сказал:

Но для этого нужно было плату соответствующим образом разводить.

Ее в любом случае нужно нормально разводить. Другое дело что в 6 серии для этого достаточно, чтобы клок и данные находились в одном банке, даже не в клок регионе. Не самые жесткие ограничения)

 

1 час назад, MegaVolt сказал:

Например нет необходимости в выравнивании дифпар между собой.

На фотке слева сигналы с выравниванием. Влезло 7 диф пар. Справа 12 без выравнивания. Разница на лицо :)

Что дает эта разница? Снижение себестоимости изделия? Вряд ли. Возможность привлечения менее квалифицированного тополога? Ну такое...

Так почему сразу не сделать плату нормально?

1 час назад, MegaVolt сказал:

Если не секрет как осуществляется компенсация задержек которые изменяются от температуры?

Компенсация задержек чего? Все, что значимо плывет по температуре (клоковые буфера и деревья) компенсирует DLL/PLL. Он для этого и придуман)

[MegaVolt 25]

14 минут назад, neon416 сказал:

Компенсация задержек чего? Все, что значимо плывет по температуре (клоковые буфера и деревья) компенсирует DLL/PLL. Он для этого и придуман)

Давайте разбираться.
Есть два варианта:

1. Клок идёт с пина через буффер сразу на входные триггеры (сердес). 

2. Клок идёт с пина на PLL и дальше по сути на тот же буффер после которого на входной триггер. 

 

Т.е. в той и той схеме всё что после буффера уже не скомпенсировано. Так в чём принципиальная разница?

[RobFPGA 27]

18 minutes ago, neon416 said:

PLL компенсирует задержку клокового дерева ко входу данных ПЛИС при любых температурах и т.п. В результате все работает четко при любых температурах и без ножного привода)

PLL компенсирует задержку между входами (точками взятия) референсной частоты и обратной связи. При это изменения и разброс задержек до реф. входа PLL и после точки обратной связи по клоковому дереву не учитывается,  либо учитываются опосредственно и усреднено. Ну и никто не отменял skew по клоковому дереву.     

19 minutes ago, neon416 said:

Вообще, если в проекте есть констрейны, отличные от глобальных клоковых это означает что вы что-то делаете не так. Должны быть очень веские и осмысленные причины, чтобы задавать иные констрейны.

Опять очень смелое (и очень спорное)  утверждение,  и судя по всему без понимания зачем это необходимо.  Как и  утверждение что IODELAY это "... это колхоз и костыль."

[neon416 0]

1 час назад, MegaVolt сказал:

Давайте разбираться.

Все описано в clocking guide. И в io guide вокруг темы с SERDES. В крупную клетку я выше все расписал, а наша с вами разница в достигнутых мегагерцах хорошо подтверждает теорию)) Без обид и серьезно, я ж не сам эту схему тактирования изобрел, все уже придумано и разжевано ксайлинксом. Я просто внимательно читал инструкцию))
 

 

1 час назад, RobFPGA сказал:

PLL компенсирует задержку между входами (точками взятия)

Эти входы же не от фонаря куда-то подключаются, см. выше)
А так, разброс задержек по dedicated routing PLL и буферов, разумеется есть. И его никак нельзя ни изменить, ни законстрейнить (потому и бесполезно констрейнить). Согласен, если скорости настолько высоки, что разброс упомянутых задержек вносит значительный вклад, одним PLL не обойдешься, НО. Это актуально начиная с частот значительно больших, чем 1000 МГц.
А у топик стартера и комментаторов числа 400, 250 и того порядка. Что толсто намекает на недопрочитанную документацию к ПЛИС).
 

1 час назад, RobFPGA сказал:

Как и  утверждение что IODELAY это "... это колхоз и костыль."

Костыль на сам IDELAY, он вполне нужен для выравнивания задержек в тех случаях, когда они неизбежны в физике. Прием HDMI с кабеля, например.
Костыль использовать IDELAY на плате, где локально разведен АЦП на ПЛИС причем на смешной скорости.
 

Изменено 10 февраля, 2022 пользователем neon416