задание OFFSET OUT, как контролировать минимальные значения? Опции

[disel]

Добрый день!

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

Задача:
Выдача данных с 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, то окно валидности данных проверяется только по одной границе.

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

[disel]

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]

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

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

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

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

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

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

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

Сообщение отредактировал Gothard - Mar 13 2009, 08:40

[Boris_TS]

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

Обращаю внимание на то, что в мною предложенном варианте происходит компенсация не только задержки обычных цепей и 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 гораздо лучше.