Добрый день!

Никак не могу понять как правильно написать этот констрейн. Прошу направить на путь истинный

Задача:
Выдача данных с Virtex4 на ЦАП. Режим SYSTEM_SYNCHRONOUS. Клок на плис и на цап приходит в одной фазе с клочного дистрибьютера. Тактовая частота 192 Мгц (период соответсвенно ~ 5,2 нс). Данные должны быть достоверны во временном окне 0,8-4,37 нс относительно положительного клока.

По всем документам которые прочитал (wp237 и т.д.) нужно задать примерно такой констрен:
TIMEGRP "DAC_PAD_GRP" OFFSET = OUT 0.8 ns AFTER "DAC_Tx_CLK_P" TIMEGRP "DAC_RG_GRP" RISING;

OFFSET = OUT по сути проверяет условие: временя прохождения данных до выходного пада от регистров + временя прохождения клока от входного пада до регистров < меньше требумой.

У меня эта сумма получается больше периода, порядка 8,6-9,1 нс. Подвигать ее влево-вправо не проблема, вопрос в другом:
как правильно задать констрейн в случае, когда время прохождения сигнала от входного до выходного пада больше периода? Если прибавить период или два, т.е написать OFFSET = OUT 6 ns или OFFSET = OUT 11.2 ns, то окно валидности данных проверяется только по одной границе.

Как многоуважемые гуру поступают в таком случае?

Не скажу за гуру, но я в этих случаях поступаю так: ставлю выходные триггеры в пэды (чем навсегда фиксирую время от триггера до физической ножки), клок завожу через DCM, делаю timesim, и по результатам делаю в DCM fixed phase shift, чтобы клок был точно в центре окна данных.

А вообще этот вопрос IMHO пора в FAQ.

Могу ошибаться, но мне кажется эта цифра достаточно странной для Virtex-4... Поэтому задам ряд наводящих вопросов:
1. Используете ли Вы выходные триггеры по линиям данных для DAC?
2. Используете ли Вы DCM для DAC_Tx_CLK_P ?
3. Какой путь проходит DAC_Tx_CLK_P ?

К сожалению по OFFSET OUT подсказать не могу... т.к. в моих проектах особой пользы от этого constraint не было: частота выходных сигналов до 100МГц - т.е. можно без подстраховки, а время задержки получалось постоянным и определялось только параметрами ПЛИС; из-за того что CLK у меня проходили по следующему пути: IBUFG->(DLL) ->BUFG->C(OFF) - использовались только специально предназначенные для CLK линии связи, а данные с выхода OFF сразу (с 0 задержкой) попадают на OBUF.

А мнения по правильному применению OFFSET OUT сам бы с удовольствием послушал...

Почитайте WP237. OFFSET OUT нужен только тогда, когда между последним триггером и пэдом есть логика. Но сейчас так никто не делает. Поэтому по памяти (лень перечитывать) синтезатор умеет сам ставить фазу DCM на основании OFFSET OUT. Однако, мне лично спокойнее поставить ее самому.

1. Выходные регистры конечно используются
2. DCM не использую. Нужды в нем особенной нет, посколько возможно двигать клок в клочном дистибьютере. Причем без увеличения джиттера. А делить\множить частоту не нужно
3. DAC_Tx_CLK_P: входной лвдс-буфер IBUFDS, дальше BUFG

Мне тоже показалось что много, просинтезировал пробный проект для XtremDSP V4, приблизительно то же.

Первое: тот джиттер, что добавит DCM (150 ps) при таких частотах глубоко безразличен. Что касается "клочного дистрибьютора": если вы можете ее двигать отдельно для ЦАП и для FPGA - двигайте там, отличный вариант.

Читал, не помогло. Безо всякой логикой задержка от триггера до выходного пада получается больше 3 нс, т.е. требования не выполняются. Крутить фазу DCM никакой необходимости нет, я же написал что могу двигать фазу внешними средствами. К тому же кроме джиттера это ничего не изменит. Хотя конечно интерестно узнать как заставить синтезатор делать это.
Однако это не есть ответ на мой вопрос. Двигать фазу с помощью DCM возможно только в пределах такта, у меня задержка больше такта.



150 пс это 2% от 5,2 нс. не так чтобы совсем мало. И самое обидное, что это нужно делать чтобы удовлетворить кривизну софта.
Вопрос про то как ограничить время прохождения сигнала от входа до выхода. Например как задать следующее условие:

min < временя прохождения данных до выходного пада от регистров + временя прохождения клока от входного пада до регистров < max

Задержки больше такта не бывает Нарисуйте на бумаге и поймете, что при тактовой в 5ns например задержка в 8ns - то же самое, что задержка в 3 ns.


OFFSET OUT AFTER < X < OFFSET OUT BEFORE. Однако я повторю, что констрейн такой вы поставить можете, но средств его выполнить у синтезатора при отсутствии DCM не будет никаких, так как задержка от триггера в пэде до ножки фиксирована. Если же вы триггеры не поставите в пэды ... То не знаю что будет, я так не извращался.

Еще раз. Это Х у меня получается около 9 нс. И мне нужно его ограничить с двух сторон, сверху и снизу. Например в границах 8,6-9,1 нс. Сверху я могу отграничить констрейном OUT AFTER. Из wp237 про него : TQ + TClock2Out + TClock <= Toffset_OUT_AFTER. Т.е. это значит Х < 9,1 нс.
Вопрос как ограничить снизу? Т.е. как задать условие X > 8.6.

Констрейн OFFSET OUT BEFORE проверет условие:

TQ + TClock2Out + TClock <= TPeriod – Toffset_OUT_BEFORE

Он не может быть больше периода.

Трегера в падах конечно. И данные в цап правильно попадают. НО!!! Хочется же один раз написать констрейн и больше не думать про это, и не проверять каждый раз ручками.

А как заставить синтезатор крутить фазу DCM? Где про это можно прочитать?

Забейте тогда, при фиксированной распиновке времянка даного куска может измениться только либо если тактовая частота разведется в другое дерево (сейчас в региональном, а разведется в глобальное или наоборот) или если очень-чень сильно изменится нагрузка на тактовую частоту, что мне видится крайне маловероятным. Чтобы зафиксировать разводку тактовой - поставьте туда руками BUFR, BUFIO или BUFG и все. А когда изделие будет готово, все же посмотрите осцилографом, что приходит на ЦАП и с помощью клокера подвиньте частоту в середину окна.

Приветствую!

...
min < временя прохождения данных до выходного пада от регистров + временя прохождения клока от входного пада до регистров < max
...

Вот именно для таких случаев ТРЕБУЕТСЯ использование DCM.

В этом случае возможно сделать время "время прохождения клока от входного пада до регистров" нулевым или отрицательным чтоб скомпенсировать задержку от триггера до пада. Только в этом случае можно считать что FPGA работает в SYSTEM_SYNCHRONOUS режиме.
У xilinx есть wp237.pdf там более подробно по поводу OFSET.

Успехов! Rob.

Спасибо. Ну в принципе я так и делаю. А как все же заставить синтезатор самому DCM-ом управлять?



Не очень понял почему именно ТРЕБУЕТСЯ? Я уже писал что задержка получается 9 нс, а DCM может сдвинуть только на период, т.е. на 5 нс. И все равно при этом констрейны не выполняются!!!
Мне что, нужно поставить DCM чтобы сдвинуть на целый период и тем самым успокоить синтезатор? Ну тогда это кривизна синтезатора.
wp237 я читал.

кажется здесь противоречие . Зачем вам тогда вообще понадобилось накладывать ограничение плису?

Какой софт вы имеете в виду?

Кроме как использовать DCM (в Virtex-4) у вас нет большого выбора.
1. "Окошко" у вас довольно малое. Примено 3,5нс, если попасть надо между 0,8-4,37. При периоде 5,2нс у вас запас по неопределенности примерно 1,7нс.
DCM компенсирует задержку распространения синх. сигнала по кристалу (эта задержка как минимум зависит от температуры). В доках ксилинкса сложно понять величину разброса задержки синхросигнала (минимальных значений clock2pad в доках не вижу ), но есть такое ощущение, что разброс одного порядка с величиной вашего запаса. Вы его уже хорошенько "съели". Кстати - если бы вы выдавали клок на ЦАП из плиса а не с внешнего размножителя - этой проблемы бы не было, но теперь у вас выбора нет...
2. Время переключения сигнала на выходе ПЛИСа тоже имеет разброс (который ксилинкс тоже не привел, но вы его можете посмотреть проведя IBIS моделирование) - еще "съели" от запаса (он еще есть?).
3. Если используются выходные триггера - то сместить сигнал на паде Virtex-4 без DCM нельзя.

Я уже тоже писал, что при периоде тактовой частоты в 5ns задержка в 9ns эквивалентна задержке в 4ns. И вообще вы какой-то неверующий, вам уже несколько человек хором говорят, что надо либо внутри поставить DCM, либо внешней PLL фазу подвигать, а вы все свое.

DCM сдвигает фазу (считается что сигнал у вас периодический). Причем с очень хорошим шагом (в районе 100пс).
Поскольку сигнал периодический, то сдвиг на -3 нс эквивалентен сдвигу на 2нс при периоде 5нс. (правда сдвиг задается в долях периода, но все же...)
Если у вас задержка больше периода - то сигнал будет принят через несколько тактов (сколько их укладывается в задержку), но на соотношение "полочки" данных относительно фронта не повлияет.

А как мне быть уверенным в том что данные на выходе появляются в нужное время?


Синтезатор конечно.



Почему нет выбора? Работает же сейчас без DCM. Только констрейны красным горят, нервируют. Собственно вопрос как этого избежать. DCM как я уже писал не решит данной проблемы.

1. "Окошко" к сожалению задаю не я, а производитель цапа. Если тактировать цап той хернёй которую выдает DCM можно получить кучу других проблем, уже с плис не связанные. Сейчас джиттер ~ 1 пс, а будет 150. Выход цапа это точно не улучшит. Собсвенно для этого и есть режим SYSTEM_SYNCHRONOUS. По поводу задержек: для этого и хочу ограничить сверху и снизу. Сейчас разброс между разными линиями по отчетам 0.5 нс. Это устраивает. Но хочется чтобы он не зависил от фазы луны, положения звезд и т.д. А при нарушении кричал от этом. Сейчас кричит всегда.

2. Да, нужно проверить на модели. Или осциллографом посмотреть будет.

3. Я могу менять фазу между клоками цапа и плис




Да понимаю я это. Но сдвиг на величину меньше периода проблемы не решает, а сдвиг на период - это безумие. Ставить DCM только для того чтобы удовлетроворить запросы синтезатора? Ну не знаю..



У всех есть свои недостатки Никто же не показал как записать условие: X > MIN. Я же только это хочу узнать. А меня все зачем то убеждают что период - он периодический. Да верю я в это.

Приветствую!

Вот только что сделал тест для проверки. 3 регистра (шириной 8 бит) включены цепочкой ->InReg->MidlReg->OutReg->
Clk завел через DCM. пока CLKOUT_PHASE_SHIFT=NONE
задал

NET "Clk" TNM_NET = Clk;
TIMESPEC TS_Clk = PERIOD "Clk" 200 MHz HIGH 50%;
TIMEGRP "tg_dou" OFFSET = OUT 0.8 ns AFTER "Clk";

Естественно для 4vlx15-12 получил ошибку в PR. В post MAP TimeAnalisys ошибка для tg_dou = -1.4 ns
при этом вижу что DCM дает только -2.4 ns .

Ставлю DCM. mode CLKOUT_PHASE_SHIFT =FIXED, PHASE_SHIFT=-180 ~ -3.5 ns
Все проходит без проблем и без ошибок. - Худший вариант в группе для tg_dou = +0.05 ns. Лучший = +0.27 ns
При этом в post PR TimeAnalisys вижу что DCM дает уже -5.65 ns

Так что мне кажется что особых танцев с бубнами тут и не нужно

Успехов! Rob

Есть идейка, не совсем то, что Вам нужно, но может навести на полезные мысли:

Насколько я видел эксплуатацию Virtex-4 (у соседей) оный достаточно хорошо выделяет тепло, а значит и задержки в такой ПЛИС будут плавать от изменения температуры (в т.ч. и время распространения CLK). Такое безобразие можно компенсировать только использую цепь опбратной связи (а как Вы её воспользуетесь - это Ваше дело: может помучаться в внешним Clock Manager, можете использовать и встроенный DCM).

Как-то в стареньком проекте (на Virtex-E) мне понадобилось сделать почти тоже, что и Вам, с тем лишь отличием, что у меня частоты в 1.9 раза ниже, но и ПЛИС тоже заметно тормознее. Пришлось сделать следующею петельку для цепи CLK:
Нажмите для просмотра прикрепленного файла

Пара нижних триггеров используются для создания тактирующего сигнала с частотой равной частоте входного IN_CLK.
OUT_CLK_BF схемно подается на IN_CLK_BF. Триггеры выдающие сигнал на OBUF располагаются в IOB.
В итоге удалось полность скомпенсировать время задержек внутри ПЛИС... и соответственно смена выходного сигнала OUT_DATA была хорошо привязана (c jitter'ом от DLL конечно же) к положительному фронту IN_CLK.

У Вас Virtex-4, насколько я помню у него есть выходные DDR каскады - если это так, то Вы можете не уродоваться с удвоенной частотой, а просто воспользоваться DDR режимом: на вход одного триггера подать '1' на вход другого '0' и тогда должен получиться симпатичный CLK (совпадающий по частоте с тактирующим триггеры – по крайне мере так обещал Xilinx в одном из appnote для Spartan-3A).

Но такие шаманства можно использовать только если у CLK, тактирующего выходные триггеры, очень малый SKEW.

Расположение окошка с переходным состоянием выходных сигналов можно задавать фазой CLK запушенного в цепь обратной связи.

Вы можете выложить весь проект? Может у меня просветление наступит. Не понимаю почему у меня такой длинный путь. Вроде все то же. Правда у меня не 12, а только 10 спидгрейд. DCM тоже пробывал.

Но в целом это не решает проблемы. У меня нет проблем с времянкой, существующая разводка кристалла меня полностью устраивает. Все работает. Безо всякого DCM. Я только хочу чтобы ISE ее контролировал автоматически, а не я каждый раз вручную. А он контролирует только верхнюю границу. В этом только и вопрос. DCM же кроме джиттера еще увеличивает потребление питания и требует формирование ресета. И нужен он только потому, что ISE не может проверить условие X > min. Обидно до кончика хвоста когда софт ограничивает возможности железа.






Микросхема конечно греется, но не так страшно. Она радиатором прижата. Я задаю температуру в констрейнах, по логике ISE должен проверить задержки при худших условиях. Мне же главное чтобы эти задержки в заданных пределах оставались. Надо почитать подробнее что ISE с констрейном температуры делает.



Случай действительно не совсем мой, за совет спасибо!

Приветствую!

Поменял speed на -10. Тут конечно похуже будет но..

посмотрел времена. Без DCM задержка для Clk (pin-> C input) ~ 5.04ns, для выходных данных (Q out -> pin)~ 5.24 ns.
Естественно попытка назначить OFSET OUT 0.8 ns будет генерировать ошибку.
Включение DCM с CLKOUT_PHASE_SHIFT=NONE или
CLKOUT_PHASE_SHIFT =FIXED, PHASE_SHIFT=0 компенсирует задержку на Clk (pin-> C input).
Соответственно нам остается скомпенсировать только задержку для (Q out -> pin) : 5.24-0.8=4.44 ns для запаса возмем 4.7 ns
это будет CLKOUT_PHASE_SHIFT =FIXED, PHASE_SHIFT=-241
Синтезим - мапим - ПиаРим ;-) ошибок нет имеем +0.12:+0.139 запаса.

Собственно подопытное тело:

Успехов. Rob.

Сколько у вас экземпляров работает?

А что может КАРДИНАЛЬНО изменяться от трассировки к трассировке если у вас триггера в IOB? Клок разведется по другой ветке? сколько это - 100пс?

Извиняюсь за настойчивость по "впариванию" DCM и ответ не на тот вопрос, который вы задаете, но я вижу проблему и хочется помочь. Я ранее приводил 3 пункта и ИМХО вам бы проверить что первые 2 удовлетворяются без использования DCM.
Да - есть кривость софта (или это какое-то намерение ксилинкса, т.к. они минимум даже в даташите не написали), но, действительно, задержки приводятся МАКСИМАЛЬНЫЕ и вы можете контролировать только их. Максимум - это один крайний случай. Есть второй - минимальная задержка (да - ту которую вы хотите контролировать), но увы такое ощущение, что вам это не удастся (хотя буду рад, если кто-то опишет способ).

Без DCM вы можете "влипнуть" на каком-нибудь экземпляре устройства, даже если сейчас все работает (как я посчитал ранее - запас у вас не велик). Задержка зависит от температуры, напряжения и даже (что может быть самое главное) экземпляра кристалла. Использование DCM позволит вам нивелировать разброс задержки распространения клока на кристалле, что в моем понимании не мало. Осциллографом, да и тем более на одном экземпляре, вы не проверите крайние случаи - можно только опираться на цифры, которые приводит производитель.

P.S.: DCM решит только проблему по первому пункту, который я описывал (т.е. разброс времени распространения клока по кристаллу). Разброс выходного буфера особо не скомпенсировать...вот только если ток можно посильнее на выходе задать, но надо смотреть на согласование...если использовать DCI вроде бы неплохо выходит.

P.P.S: А уж как поставите DCM - задавайте на нем какой надо сдвиг и "вписывайтесь" хотя бы по максимальному OFFSET.

Rob, спасибо за проект!

Выяснилась интереснтая особенность: я вставлял DCM в свой проект ручками как DCM_BASE. При установленном нулевом сдвиге никакой компенсации синтезатор не делал. Попробывал вставить DCM сгенерированный коре генератором, он вставляет DCM_ADV. Действительно появился сдвиг. В чем дело пока понять не могу.
Хотя и со сдвигом в заданные рамки проект у меня все равно не вписался. Нагрузка на клок достаточно большая.

Впрочем поставленную задачу это все равно не решает.

Резюмируя данную тему можно сделать следующие выводы:
1. Констерйн OFFSET OUT может работать только со внутренним DCM или на невысоких частотах.
2. Констерйнов способных задать ограничения при работе с внешним клок менеджером не существует. Единственный путь - лочить разводку и руками проверять пределы.

Отрицательный результат конечно тоже результат, но как то грустно.


3


Может измениться нагрузка на клок при увеличении схемы. Соответсвенно вырастут задержки. Это может быть и не 100 пс. В любом случае хотелось бы чтобы это услови проверялось автоматически. Ради этого и была поднята данная тема.


Да, к сожаления ответа на свой вопрос я так и получил.



Я никак не пойму: как DCM может нивелировать разброс задержки на кристалле и влияние температуры? Без DCM у меня разброс 0,5 нс. Сейчас поставил DCM - разброс по прежнему 0,5 нс. И от температуры она будет также зависит как и без DCM. Способ компенсировать это влияние был предложен Boris_TS.

Может быть не понятно, что я имею ввиду? Задержка распространения клока на кристале зависит не только от нагрузки, но и как я уже выше писал, от температуры, напряжения (в данном случае ядра), экземпляра кристалла. Первые две зависимости дают разброс в задержке во время работы (плис нагрелся, открыли окно на улицу и т.п. - задержка изменилась). 3-я зависимость наблюдается от экземпляра к экземпляру кристалла. DCM подстраивает фазу (точнее свою внутреннюю линию задержки) так, чтобы эта задержка была постоянной с каким-то допуском (во времени и от экземпляра к экземпляру) => значит нивелирует разброс. В том числе и при изменении нагрузки на клок.
Разбросы, которые вы видите (в отчете трассировки, насколько я понимаю) - это то, что дает специфика разводки клока - на одни триггера синхросигнал подан с одной ветки, на другие - с другой ветки. Хотя 0,5нс это как-то много....Вот тут OFFSET_OUT действительно может пригодиться.

согласен, что так лучше (так еще будет в некоторой мере скомпенсирован разброс выходного буфера ПЛИСа), но насколько я вас понял у вас плата этого не позволит

P.S. для сигналов есть еще ограничение MAX_SKEW (на максимальный разброс) - может быть также поможет в сочетании с OFFSET_OUT? Если MAX_SKEW наложить на клок, тактирующий триггера - может быть у вас не будет такого большого разброса между ними?

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

Еще раз прошу извинения за настойчивость с DCM, но кажется, что именно это вам и надо.

Но ведь ISE считает максимальное задержку для худших условий? Если в даташите например написано что какой нибудь Tiopi = 1,28 нс, то больше он быть не может. Если не так, то получается временной анализатор показывает расстояние до Луны или цены на апельсины в Африке?
А еще есть констрейн TEMPERATURE. Должен же ксалинкс его учитывать, раз его можно задавать?
Т.е. максимальную задержку оцененить можно. Нужно оценить минимальную, в этом и сложность. Понятно что при выччислении OFFSET OUT минимум это ноль.

Насколько эффективно DCM нивилирует разброс зависит от того, какой величины этот разброс. И как он зависит от температуры, питания и т.д. Данных по ксалинксу у меня к сожалению нет. Если скажите где можно почитать, буду очень благодарен. Попадались данные по отечетвенным БИС. Нестабильность была в 4 знаке после запятой. Может все не так плохо?

У меня разброс составляет 0,466 нс, если точнее. А мне нужно попасть в окошко 1,6 нс. Запас в принципе есть. А вообще термоцикл покажет


Ну переделывать плату будем, можно об этом подумать будет.


У меня фанаут на клок 940, не гуманно такие ограничения на него накладыать. Это же весь дизайн зажмет. Лучше два клоковых буфера завести: для выходных буферов и для всего остального. На выходной клок наложить MAX_SKEW, тогда действительно разброс наверное можно уменьшить. Спасибо за совет.


Не убедили. Я не являюсь противником DCM, но в данном случае его применение имеет больше минусов, чем плюсов.

Вот величина у вас странная. Смотрел даташит на Virtex-4 - в нем параметр Tckskew (Clock tree skew) - как раз разброс для периферийных триггеров и худший случай. Для самых "тяжелых" ПЛИСин он 0,35нс.

Именно. Подстрахую еще свой совет: поскольку фронты будут очень близкие, но с небольшим разбросом, то неплохо бы от проскока подстраховаться - выдавать данные на периферийные триггера по заднему фронту а принимать на периферийные триггера по переднему (ну или наоборот, зависит что там у вас...). Не знаю какой разброс между фронтами если один синхросигнал сигнал распараллелить через 2 буфера, но вот при передаче сигналов из домена без DCM в домен фазы 0 после DCM (и наоборот) возникают проблемы, о чем ругается трассировщик



В даташите на Virtex-E приведена задержка буфера глобального сигнала: Min=0,11нс, Max=0,5нс для SpeedGrade -6 и Max=0,2нс для SpeedGrade -8. Выходит, что для медленных плисин один BUFG дает разброс 0,39нс.
Что в Virtex-4 не известно....

Это я привел разброс который выдает OFFSET OUT, т.е. суммарный для клоков и данных. Посмотрю что для клоков в отдельности.



Спасибо за совет.

Global Clock Tree Skew у моего кристалла 0,31 нс. Да, немало. С другой стороны DCM добавит джиттер 0,15 нс.

Обращаю внимание на то, что в мною предложенном варианте происходит компенсация не только задержки обычных цепей и OBUF, но также и IBUFG. Недостатком компенсации задержек для IBUFG и OBUF является то, что оба IBUFG должны иметь один и тот же стандарт ввода/вывода... Тоже относиться и к OBUF'чикам.

Кстати, эта схема компенсации успешно работает на железной дороге уже не менее 2.5 лет. А там условия эксплуатации немного "жестковаты" - зимой холодно, летом на солнышке как-то "жарковато".


Присоединяюсь к настойчивости - т.к. только использование обратной связи может компенсировать динамические изменения задержки распространения Clock в системе. Через что Вы заведёте обратную связь - не принципиально (через Ваш Clock Manager или через DCM), но на Вами используемых частотах компенсацию динамических изменений задержки распространения Clock обязательно необходимо проводить.

Касательно constraint TEMPERATURE - очень полезный constraint позволяющий ограничить максимальную температуру для которой будет производиться расчет задержек. Но есть одна тонкая деталь... он задаёт не внешнюю температуру воздуха или корпуса ПЛИС, а the operating junction temperature - как я понимаю - температуру транзисторов ПЛИС, вроде бы оную можно прикинуть при помощи Power Estimator.

Для выяснения минимальной задержки Вы можете воспользоваться временным моделированием, но брать из SDF файла не MAX задержки (как настроенно по умолчанию), а MIN задержки.


Не путайте Skew и jitter:
Skew - конструктивен, и не очень сильно зависит от температуры и питания ядра - это простая рассогласованность доставки clock.
Jitter - это дрожания clock от такта к такту.
Просто так их складывать нельзя, они существуют в параллельных плоскостях.

Кстати Skew кристалла Вас вообще не должен волновать - работает там внутри и хорошо. А волновать Вас должен только Clock Skew для использованных ножек ввода/вывода - если оные стоят кучно, то и SKEW получается маленький... Да и если вопрос упирается в пикосекунды, то тут уже надо учитывать и разводку печатной платы.

Ну а jitter от Xilinx мне самому очень не нравиться... Особенно после работы над системами синхронизации для систем передачи данных (аля междугородняя АТС). И чего они заразы не ставят аналоговые ФАПЧ (ну или более дорогие - гибридные) - в них с jitter гораздо лучше.

Эта схема же применяется ксалинксом в контроллере ДДР. По крайней мере в каком то из хаппов мне это попадалось на глаза. В отсутсвие внешнего клок менеджера другой альтернативы нет. Хотя кажтеся последняя версия MIG научилась проводить автоматическую калибровку.


Ну это можно просто померить будет. Плис же говорит свою температуру. Когда будет лежать в камере, проверю.


Разово такую работу провести можно, даже наверное нужно, чтобу убедиться в правильности задержек, но не после каждой же компиляции. Я же ищу метод автоматического контроля задержек.
Интерестно, если min задержки пишутся в SDF файл, значит ксалинкс их знает. Что же он посчитать их сумму не хочет?



Я не путаю и не складываю. Про то, что это разные параметры я знаю. Но оба они уменьшают временной бюджет, в этом их сходство. Я хотел показать что использование DCM добавляет нестабильность порядка, аналогичного разбросу в BUFG. Я думаю что изменения задержек от внешних параметров имеет ту же величину. И компенсация изменения задержек которую выполняет DCM ликвидируется джиттером, которую он вносит. Неясно что больше.

Все таки хочется найти информацию про то, какие величины имеет разброс задержек в зависимости от внешних факторов.

Могу только предложить разово попробовать поглядеть на максимальные/минимальные задержки при максимальном питании и минимальной температуре, и наоборот при минимальном питании ядра и максимальной (т.е. не заданной) температуре.

А вопрос что больше jitter от V4 DCM или изменение задержек в кристалле (IBUFG, время распространения clock. время срабатывания триггеров, OBUF) - на мой взгляд оооочень интересный.

Ищу

Была такая проблема - дикие времена (иногда даже отрицательные) на констрейнах типа OFFSET - временной анализ говорил что проблема в том, что задержка на клоковом буфере - 5-7 нс. Потом по совету одного товарища поставил на клоки DCM_ADV с обратной связью. После этого все вылечилось, DCM как то там это дело компенсирует - вносит свой сдвиг фаз, задержка распространения клока становится не более 0.3 нс в самом плохом случае, если верить анализатору времен. Теперь везде эти DCM сую и не нарадуюсь.
З.Ы. Сейчас приноровился наиболее ценные ресурсы типа DSP48 запускать на двойной скорости (240-300 мгц) - у DCM есть замечательный выход clk2x, синфазный с clk0, что позволяет без проблем переходить между доменами, при этом временной анализатор имеет возможность контролировать эти переходы, поскольку связь между клоками известна. Вобщем DCM - Рульная штука!

Вообще то вопрос был о другом, в названии темы же все написано.