В проекте есть глобальный клок.
Цепочка клока: Pad -> ClkIn -> IBUFG -> iClkIn -> DCM -> хаваем нужный клок.

В файле констрейнов сказано что ClkIn глобальный, указан его период. В проекте достаточно много клоков, > чем глобальных буферов в кристалле.
Так вот, трассировщик глядя, на маленький фаноут клока iClkIn (4), берет и делает его локальным. При етом пишет в репорте следующее:

Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|
+---------------------+--------------+------+------+------------+-------------+
ClkInFarb_p | Local | | 4 | 0.011 | 0.782 |

типа все хорошо. Проблема в том, что етим клоком кормится схема, чувстительная к джиттеру.


Мне бы хотелось сделать его глобальным. Посмотрел constrain guide, и синплифайский гайд, там написано лишь как сделать клок НЕ глобальным.

Может кто сталкивался с проблемой такой ?

Я что-то не понял, у Вас клок заводится на IBUFG, т.е. сразу на ножке он становится глобальным.
Что показывает FPGA Editor ?

Если интересно еще, то по-моему CLOCK становится глобальным после применения BUFG, например на выходах DCM

Должен быть глобальным... у меня стал локальным.

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

Вот репорт о клоках, ClkInFarb_p я пытался сделать глобальным




Исторически так получилось, что в одном из узлов блока я был вынужден пользоваться 2 клоками. Синхронными, частоты 96 и 48 мгц. Клоки получаются из одного DCM:



После долгих мытарств, я наконец-то додумался оцифровать встроенным в кристалл логическим анализатором, тактируемым 96 Мгц, клок на 48 Мгц.
Потом, когда не поверил своим глазам, оцифровал его еще раз, но на етот раз кормил его клоком 96 Мгц, сдвинутым на 90 градусов. Картина не изменилась. Я там увидел примерно такое: 011011011... а несколько раз было наоборот: 100100100.

Тогда я подумал что сошел с ума, вывел клоки на внешние пины и подключился осциллом:



Люди, скажите, я действительно сошел с ума, или так и должно быть ?
В настройках DCM CLKDV_DIVIDE => 2.0,
Выход DCM LOCKED = 1 все время.

Вас смущает осциллограмма, или что??

Меня смущает, что сгенерированные 1 DCM 2 клока, ClkOut и ClkDV, несинхронны, и их частоты относятся как 1 : 2.5 при заданном коэффициенте деления 2.

Это Вы откуда взяли?

На приведенной осциллограмме они соотносятся ровно 1:2, включите на осциллографе измерение частоты и убедитесь, а то линейкой измерять на мониторе периоды не удобно. А то что не синхронны - так это пути разные к пинам. Чтобы были синхронны нужно на выходе использовать что-то типа ODDR, где-то в ноутах читал когда-то. Уже не помню. И еще - судя по осциллограмме Вы используете щупы не правильно. У Вас скорее всего длинный корпусной провод от щупа прицеплен крокодилом где-то не краю платы. Я бы посоветовал взять специальную насадку на щупы в виде пружинки на корпус, и брать этот корпус рядом с измеряемым сигналом. И еще - если опустите ниже верхнюю осциллограмму то увидите что все там синхронно. Опять же трудно судить по изображению на мониторе.

Что-то меня качество сигналов очень смущает....
Терминации нет совсем что-ли?
Или земля щупа длинная?

Во первых для того чтобы сигнал стал глобальныс нужно пропустить его через BUFG после IBUFG. Во вторых насколько я помню для того чтобы пустить на клок на референсный сигнал ДЛЛ то достаточно IBUFG (хотя аппликешн ноут я читал давно и могу ошибаться - но вроде так). В третиьих мне не понравилась блок схема с длл выше - почему там два выхода CLK0(dll) и out(bufg) деруться между собой? В четвертых для того чтобы клок стал глобальным его достаточно завести в описании на BUFG. НА сем заканчиваю.

Товарищ, пишете более конструктивно. Так пишут только студенты в разгар диплома.


+не забывайте про возможности делителя на щупах.

Полностью согласен.... Заколебался, начал вести себя как емо.

Насчет 1 : 2.5 мой косяк также... в запаре уже и осциллограмму считал неправильно....

А вот насчет 011011011 и 100100100 один уважаемый товарищ сделал предположение, что ето модулированный джиттер... разберемся напишу





земля длинная была действительно

Возьмите специальный щуп (или оденьте наконечник на щуп в виде тонкой намотанной проволоки и тонкого окончания) Тогда хар-ки точно будут получше. Земля длинная, тут все правы.
На выходе с DCM поставьте Bufg. Должен быть глобальным. Чудес не бывает.


Попробуйте так!

CLK=>IBUF=>DCM=>BUFG-глобальный клок

В первом посте я написал:
Цепочка клока: Pad -> ClkIn -> IBUFG -> iClkIn -> DCM -> хаваем нужный клок.

Под "хаваем нужный клок" я подразумевал есно BUFG, который кстати и видно на картинке синтезированного проекта.



Спасибо за совет, но с клоком вроде все устаканилось. По репортам и измерениям, джиттер клока укладывается в требуемые границы и проект работает. Проблема, как несложно( догадаться была в логике, и в том, что некорректно написанный исходник на моделировании и в железе повел себя по разному.

Сухой остаток моего поста - кроме эмоций - уж простите, к исходу третьей недели отладки в железе я прошел все стадии - огорчение, озабоченность, разочарование, горечь поражения, отчаяние и безысходность - так вот сухой остаток, ето то интересное явление которое я наблюдал - а именно 001001001 или 110110110110 - колебательный процесс удвоенной частоты по отношению к единичной. Вот ето явление действительно забавное.... проблема лишь в том, что я по моему потерял бакап с версией, которая так загадочно себя вела(((

вы скорее всего видели отсутствие захвата... кстати частота входная дцм от 20 мгц и требования по джиттеру достаточно серьёзные

ни разу не видел за идентифаем отсутствия захвата.

что касается джиттера, то я работаю на совсем небольшой частоте для этого дизайна. Референс ксилинс запускается на 400 Мгц с 4 кратным оверсемплингом.

имелось ввиду отсутсвие захвата на длл

что значит на небольшой частоте? от частоты джиттер не зависит

DCM работает у меня напрямую, синтезатор отключен. На входе и на выходе 96 мгц. Джиттер опорного генератора SG8002 200 пкс.


не понял Вашего вопроса про джиттер. Я имел в виду баланс джиттера схемы. У меня условие работоспосбности схемы - суммарный джиттер системы передачи данных - менее четверти периода несущей частоты.

Я думаю ето изначально неправильно плодить клоки . Если два синхронных клока то надо кодировать на более высокий клок и использовать клок енабле для F/2 circuitry - no waist of GBUF.

вот как раз хилые, если судить по докам, и рекомендуют плодить клоки %) Если разобраться то дело это выгодное, но более геморойное

Изначально это правильно хотябы с точки зрения потребления - так в АЗИКах и делают - другое дело в ПЛИС где клоковые деревья определены заранее особо не выпендришься

я когда то давно пытался - в самом начале - получилось както криво и глюкаво....Возможно тогда изза неопытности налепил ошибок. В итоге все свелось к тому что есть сейчас.

В последующих релизах клокирование будет переработано, развязано, и возможно будет использование асинхронных клоков и с отношением более чем 1:2

Ето комплексная проблема все зависит от архитектуры:
- если один клок то:
ISE т легче делать тиминг дривен ПАР и не надо пересекать клок домаины
быльше гибкости в вуборе ЛУТ т.к нет ограничения от клоковые деревьев

о все ето хорошо если количество используемых FF небольшое на F/2
JMO


Гнилое ето дело клоки смотреть чипскопом.
Если в схеме есть синхронные FF то вроде как должны они получать клок с GBUF.

Чтобы наверняка бул GBUF в схеме введите его instance в РТЛ и введите директиву
/* synthesis syn_black_box syn_noprune =1 */;
Проверьте все параметры на ДЦМ т.к на разные частоты они могут быть разными

Вот как раз на f/2 вся логика и живет, там фаноут у меня 3500 из 5000 возможных. Логично ведь, лишь требуещее полной скорости поселить на полную скорость, а фсе остальное перевести на максимально пониженную частоту, чтоб кристалл не греть и тока не переедать ?



папробую, пасиб.

[/quote]
У вас утилизация очень небольшая - так что если тиминг ошибок нет то все должно работать без проблем. Проверьте как вы передаёте сигналы между клоковыми доменами. Там желательно надо указывать где фалсе путь. Проверйте input/output timing report.

небольшая ? 94% по логике ето немного ? Все сейчас вроде работает. Между клоковыми доменами у меня все развязано асинхронными фифо, везде кроме места, где я пользую fx и fx/2. Тайминг репорт вроде ни на что не ругается.
В предыдущем проекте, когда роутер не понимал где фалсе путь, в тайминг репорте такой крик стоял - не разобраться с этим было невозможно)))

LUT v vashem reporte 26%

Проект состоит из 2 ПЛИС. К тому же скрины я делал с версии, урезанной на 2/3. Она глючила тогда также, как и полная версия.