[Костян 0]

В ПЛИС захватываю поток lvds данных. Причем data меняется и по фронту и по срезу CLK.Проблема в следующем. CLK заведен на I/O (так получилось, изменить нельзя) , который не является GCLK.

Десериализатор lvds данных при помощи контрейнов я разместил возле I/O data. CLK же с I/O идет на DCM, где подстраивается его фаза для компенсации задержки.

Вопрос как вычислить эту задержку и подстроить фазу верно ?

В аттаче структурная схема.

камень Virtex FX12

частота CLK 300 МГц.

[DmitryR 0]

Поставить нулевую задержку в DCM, сделать timesim, посмотреть, насколько надо подвинуть (чтобы попало в середину окна данных). Однако, эта задержка может плыть от температуры и напряжения, поэтому, если частота на пределе - то стоит задуматься об автокалибровке.

[Beby 8]

Есть очень корявый путь: вручную назначить LOC для первого элемента, на который приходят данные с IBUFDS по ветке 'Data'. Так, чтобы задержки линий 'Data' и 'CLK' (от IBUFDS до DCM) были очень близкими - это позволит сделать менее температурнозависимой компенсацию...

[DmitryR 0]

Есть очень корявый путь: вручную назначить LOC для первого элемента, на который приходят данные с IBUFDS по ветке 'Data'. Так, чтобы задержки линий 'Data' и 'CLK' (от IBUFDS до DCM) были очень близкими - это позволит сделать менее температурнозависимой компенсацию...

Это может дать прямо обратный эффект - цепи данных и синхронизации организованы абсолютно по-разному, и плыть будут соответственно неодинаково. Затем, делая так, придется еще и разводку этой трассы зафиксировать. Вобщем, так делать можно только, если PLL/DCM кончились (используются в других местах, где без них совсем-совсем никак).

[Костян 0]

Есть очень корявый путь: вручную назначить LOC для первого элемента, на который приходят данные с IBUFDS по ветке 'Data'. Так, чтобы задержки линий 'Data' и 'CLK' (от IBUFDS до DCM) были очень близкими - это позволит сделать менее температурнозависимой компенсацию...

.

Спасибо. Идея интересная. Проскакивала как - то в голове , правда откинул.

LOC для десеализатора можно назначить, но сигнал DATA рутер может заводить от разводки к разводки по разным путям. В итоге разбежка. Можно ли назначить путь для сигнала с помощью констрейнов ?

Однако, эта задержка может плыть от температуры и напряжения, поэтому, если частота на пределе - то стоит задуматься об автокалибровке.

Пасиб. Впринипе так и представлял себе это. Но думал что ISE позволяет измерять задержку , вносимую на линиях. А об автокалибровке уже задумываюсь. :)

А можно ли моделировать после place&route учитывая температуру ?

 

p.s

 

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

Почему ? Если цепи дата и clk проходят одинакоывый путь, пробегают одинаковое кол-во переключательных блоков, из-за чего они будут плыть ? Или кристалл не симметричный нагрев может иметь ?

Затем, делая так, придется еще и разводку этой трассы зафиксировать.

Вот. А каким констрейном это сделать ?

[DmitryR 0]

Почему ? Если цепи дата и clk проходят одинакоывый путь, пробегают одинаковое кол-во переключательных блоков, из-за чего они будут плыть ? Или кристалл не симметричный нагрев может иметь ?

Они проходят не одинаковый путь, и не одинаковое количество переключательных блоков. Я говорил уже, что цепи данных и синхронизации организованы абсолютно по-разному: сделайте малюсенький проект, откройте в FPGA Editor и посмотрите, как трассы идут. Только не пытайтесь пустить синхронизацию по линиям, предназначенным для данных.

Затем, синхронизация периодична. Это значит, что при частоте синхронизации в, скажем, 100 МГц задержки данных и сихронизации относительно друг друга в 0, 10, 20 и т.д. наносекунд будут смотреться идентично. Однако, плыть они будут опять-таки по-разному.

[Beby 8]

Это может дать прямо обратный эффект - цепи данных и синхронизации организованы абсолютно по-разному, и плыть будут соответственно неодинаково. Затем, делая так, придется еще и разводку этой трассы зафиксировать. Вобщем, так делать можно только, если PLL/DCM кончились (используются в других местах, где без них совсем-совсем никак).

Ну, как я понимаю, задача сформулирована так: неудается использовать dedicated clk pin. И сейчас ветка 'CLK' идет от обычного IBUFDS к DCM, вот и вопрос, как бы скомпенсировать эту непредвиденную задержку... А DCM'ичиков вроде хватает... Просто так разведена плата.

 

Я думаю, что если сейчас от IBUFGS до DCM трасса проходит через 2 local lines, то можно оттащить в

ветке 'Data' первый триггер от своего IBUFDS так, чтобы путь к нему занимал 2 local lines.

Если надо больше Local lines, то уже могут понадобиться прыжки с бубном.

 

Если IBUFDS и обоих веток находятся "недалеко" друг от друга, то и термокомпенсация будет не плоха...Хотя опять таки повторюсь с чего начал: "это очень корявый вариант".

[dsmv 0]

Рекомендую использовть узел автоподстройки фазы тактовой частоты.

У меня подобная проблема возникает постоянно. В итоге появился вот такой узел автоподстройки.

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

Защёлкивание производится сигналом с DCM. Автомат управления должен вывести фазу сигнала DCM в то положение, при котором входной сигнал будет защёлкиваться нестабильно, то 0, то 1. Это положение и будет истиным положением тактового сигнала на входной ножке. А дальше для защёлкивания данных можно брать любой удобный сигнал DCM - например сдвинутый на 90 градусов, или на 180.

 

Предлагаю файл ctrl_dcm_phase_v1.vhd; В нём реализована постаянная подстройка фазы.

Если кто-нибуть будет его использовать, то большая просьба сообщить о результатах и ошибках.

ctrl_dcm_phase_v1.vhd