[disel 0]

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

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

 

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

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

 

Кроме как использовать DCM (в Virtex-4) у вас нет большого выбора.

1. "Окошко" у вас довольно малое. Примено 3,5нс, если попасть надо между 0,8-4,37. При периоде 5,2нс у вас запас по неопределенности примерно 1,7нс.

DCM компенсирует задержку распространения синх. сигнала по кристалу (эта задержка как минимум зависит от температуры). В доках ксилинкса сложно понять величину разброса задержки синхросигнала (минимальных значений clock2pad в доках не вижу :( ), но есть такое ощущение, что разброс одного порядка с величиной вашего запаса. Вы его уже хорошенько "съели". Кстати - если бы вы выдавали клок на ЦАП из плиса а не с внешнего размножителя - этой проблемы бы не было, но теперь у вас выбора нет...

2. Время переключения сигнала на выходе ПЛИСа тоже имеет разброс (который ксилинкс тоже не привел, но вы его можете посмотреть проведя IBIS моделирование) - еще "съели" от запаса (он еще есть?).

3. Если используются выходные триггера - то сместить сигнал на паде Virtex-4 без DCM нельзя.

 

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

 

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

 

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

 

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

 

 

DCM сдвигает фазу (считается что сигнал у вас периодический). Причем с очень хорошим шагом (в районе 100пс).

Поскольку сигнал периодический, то сдвиг на -3 нс эквивалентен сдвигу на 2нс при периоде 5нс. (правда сдвиг задается в долях периода, но все же...)

Если у вас задержка больше периода - то сигнал будет принят через несколько тактов (сколько их укладывается в задержку), но на соотношение "полочки" данных относительно фронта не повлияет.

 

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

 

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

 

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

[RobFPGA 35]

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

 

Вот только что сделал тест для проверки. 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

[Beby 8]

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

 

Насколько я видел эксплуатацию 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 запушенного в цепь обратной связи.

[disel 0]

Вот только что сделал тест для проверки. 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

 

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

 

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

 

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

 

 

 

 

 

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

 

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

 

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

[RobFPGA 35]

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

 

Поменял 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.

TmpIse.zip

[Gothard 0]

У меня нет проблем с времянкой, существующая разводка кристалла меня полностью устраивает. Все работает. Безо всякого DCM

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

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

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

 

Извиняюсь за настойчивость по "впариванию" DCM и ответ не на тот вопрос, который вы задаете, но я вижу проблему и хочется помочь. Я ранее приводил 3 пункта и ИМХО вам бы проверить что первые 2 удовлетворяются без использования DCM.

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

 

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

 

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

 

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

Изменено 13 марта, 2009 пользователем Gothard

[disel 0]

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

 

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

Хотя и со сдвигом в заданные рамки проект у меня все равно не вписался. Нагрузка на клок достаточно большая.

 

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

 

Резюмируя данную тему можно сделать следующие выводы:

1. Констерйн OFFSET OUT может работать только со внутренним DCM или на невысоких частотах.

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

 

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

 

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

3

 

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

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

 

Извиняюсь за настойчивость по "впариванию" DCM и ответ не на тот вопрос, который вы задаете, но я вижу проблему и хочется помочь. Я ранее приводил 3 пункта и ИМХО вам бы проверить что первые 2 удовлетворяются без использования DCM.

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

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

 

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

 

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

 

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

 

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

[Gothard 0]

как DCM может нивелировать разброс задержки на кристалле и влияние температуры?

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

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

Способ компенсировать это влияние был предложен Boris_TS.

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

 

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

 

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

 

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

Изменено 13 марта, 2009 пользователем Gothard

[disel 0]

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

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

Но ведь ISE считает максимальное задержку для худших условий? Если в даташите например написано что какой нибудь Tiopi = 1,28 нс, то больше он быть не может. Если не так, то получается временной анализатор показывает расстояние до Луны или цены на апельсины в Африке?

А еще есть констрейн TEMPERATURE. Должен же ксалинкс его учитывать, раз его можно задавать?

Т.е. максимальную задержку оцененить можно. Нужно оценить минимальную, в этом и сложность. Понятно что при выччислении OFFSET OUT минимум это ноль.

 

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

 

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

 

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

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

 

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

 

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

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

 

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

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

[Gothard 0]

У меня разброс составляет 0,466 нс, если точнее.

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

Лучше два клоковых буфера завести

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

 

 

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

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

Что в Virtex-4 не известно....

[disel 0]

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

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

 

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

 

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

 

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

[Beby 8]

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

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

 

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

 

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

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

 

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

 

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

 

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

Не путайте Skew и jitter:

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

Jitter - это дрожания clock от такта к такту.

Просто так их складывать нельзя, они существуют в параллельных плоскостях.

 

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

 

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

[disel 0]

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

 

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

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

 

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

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

 

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

Разово такую работу провести можно, даже наверное нужно, чтобу убедиться в правильности задержек, но не после каждой же компиляции. Я же ищу метод автоматического контроля задержек.

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

 

Не путайте Skew и jitter:

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

Jitter - это дрожания clock от такта к такту.

Просто так их складывать нельзя, они существуют в параллельных плоскостях.

 

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

 

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

 

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

 

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

[Beby 8]

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

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

 

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

[disel 0]

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

 

Ищу :(