В проекте есть глобальный клок.
Цепочка клока: 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 мгц и требования по джиттеру достаточно серьёзные