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


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



Почему нет выбора? Работает же сейчас без 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.

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

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, но кажется, что именно это вам и надо.

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

Но ведь 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) - на мой взгляд оооочень интересный.

Ищу