[AlphaMil 0]

Уважаемые Гуру, подскажите где посмотреть/почитать про определение и назначение тайминговых констрейнов. САПР Xilinx ISE 12.2, хотя это к делу отношения наверное не имеет.

Для конкретности - как правильно ограничивать MAXDELAY и MAXSKEW для шин.

[Beby 8]

Уважаемые Гуру, подскажите где посмотреть/почитать про определение и назначение тайминговых констрейнов. САПР Xilinx ISE 12.2, хотя это к делу отношения наверное не имеет.

Для ознакомления с работой самих временных constraint'ов, Вам необходимо прочитать %xilinx%/doc/usenglish/books/docs/cgd/cgd.pdf

 

Для конкретности - как правильно ограничивать MAXDELAY и MAXSKEW для шин.

Вот тут требуется уточнение: а для чего Вам это надо:

1. Если для задания временных соотношений на выходных I/O pins, то для этого необходимо использовать constraint offset out.

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

3. Если для задания временных соотношений на каких-либо внутренних линиях при переходах с одного clock domain в другой, то From to. Также в этом случае может понадобится constaint async_reg, облегчающий моделирование таких мерзких мест.

[AlphaMil 0]

Спасибо, указанный документ изучал, но осталось много непонятного.

Пока речь о внутренних сигналах.

Если я правильно понял, то указанием ограничений на тактовые сигналы можно решить проблему в пределах клокового домена?

С передачей сигналов между доменами сложней - как определить задержки сигналов между доменами?

А в случае шин отдельные биты могут быть не синхронизированы (перекос???)?

И еще один важный вопрос: если ограничение наложено на провод (например period), оно сохранится например после bufg???

[Shtirlits 0]

Констрейны наложенные на входной клок распространяются не только через BUFG, но и через DCM и PLL с учетом фаз, частот, скважности, джиттера и перекосов клоковых деревьев. Если все клоки происходят от одного опорного тактового сигнала, то его описания будет достаточно не только для одного домена, но и для анализа переходов между клоками.

Если зависимые клоки имеют неудобное сочетание частот и/или фаз, анализатор обнаружит ошибку, которая может возникнуть через некоторое количество тактов.

Независимые клоки нужно описывать отдельно, об этом написан раздел "Specifying Derived Clocks" в упомянутом Constraints Guide.

[AlphaMil 0]

Ув. Shtirlits, спасибо.

Но вот вопрос: работаю с обработкой видео в реальном маштабе времени. Оцифровываю и вывожу видео м/с-ми Analog Devices. От компиляции к компиляции бывает такое: в полутоновых переходах иногда возникают артефакты (неправильно светящиеся точки). Подозрение на то, что отдельный бит или два в шине, по которой идет видео немножко запаздывают или опережают остальные, соответственно во время фронта число, записанное в регистр не соответствует реальному. Вобщем откомпилировал, прошил - нормально, поменял что-то в другой части проекта, скомпилировал, прошил - артефакты...

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

Ведь если САПР просчитывает все относительно клока, то изменения в одной части проекта, не связанной функционально с другой частью, не должны влиять на эту дрегую часть...

[Beby 8]

Для локализации проблемы необходимы следующие уточнения:

1. Вы используете один источник частоты, или несколько ?

2. Если один - то constaint period задан на входную ножку/линию ? И правильно ли он проходит все PLL/DCM (см. timing report - Derived Clocks) ?

3. А заданы ли constaint'ы offset out для сигналов, поступающих на внешние микросхемы ? Используются ли output flip-flop для этих сигналов ? Как следствие: укладываются ли времянки этих сигналов в то, что требуется внешним микросхемам ?

 

Но даже не зная ответы на эти вопросы, могу посоветовать в Process->Implementation->Place & Route->Post Place & Route Static Timing Report Properties задать Report Unconstraint Paths ну хотя бы с 200. Соответственно появится определённая секция Post Place & Route Static Timing Report. Тут можно поглядеть, что Вы не указали, и что ISE разводит как попало.

[Intekus 0]

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

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

Пересечение многоразрядным сигналом границы некратных тактовых - особый случай. Рекомендую ставшую почти классической статью http://www.sunburst-design.com/papers/Cumm...SJ_AsyncClk.pdf Без специальных мер - вполне может быть то, что Вы подозреваете. Из решений - код Грея для произвольных данных не подходит, так что для описанного Вами случая, ИМХО, нужны либо схема "рукопожатия", либо асинхронное FIFO.

[Shtirlits 0]

Поделюсь одной мыслью, которую нахожу жутко умной :)

Пересечение границы независимых клоковых доменов всегда рискованное мероприятние. Вероятность неприятных последствий можно лишь снизить до допустимого уровня, но нельзя устранить совсем. Защита от метастабильных состояний всегда требует времени на прохождение последовательных регистров - часто вижу синхронизаторы на 2-3 такта, но для надежности можно и больше!

 

А что если по опасному пути передавать не всю широкую шину с полезными данными, а только информацию о соотношении клоков? Именно так делают в асинхронных FIFO. Полезные данные безопасно читаются из памяти по адресам, которые достаточно давно не менялись и не меняются, а информация о "клоке", то есть, о фактах записи и чтения, передается в коде Грея и защитные регистры - это указатель с противоположного конца.

Путь простого человека, не обремененного заботой о низкой задержке данных- применить готовое dual clock FIFO.

 

Сложный путь - развить идею FIFO на сам клок.

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

Это возможно, если поведение клоков можно предсказать на время прохождения информации через синхронизирующие регистры. Еще одно условие - плохие данные можно догнать и придушить, если клок "дрыгнется" когда нельзя.

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

Как это выглядит? Это может быть блок, который выдает разрешение для захвата сигналов с шины на данном такте или даже два разрешения - DDR. Наличие активного уровня на выходе означает, что на данном такте чтение безопасно.

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

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

[Intekus 0]

Сложный путь - развить идею FIFO на сам клок.

А можете подробнее пояснить свою идею? Пока по Вашему описанию в голову приходят только схемы анализа фаз, реализованные через синхронизаторы, работающие на удвоенных / учетверённых частотах.

[Shtirlits 0]

Попробую.

Допустим, что частоты примерно известны. Синхронизация может быть построена тупо, как у PLL.

В одном домене делается инвертируемый каждые несколько тактов регистр. Его значение передается через какой угодно длинный синхронизатор во второй домен и попадает в "цифровой детектор фазы", где сравнивается с выходом генератора. Поученный результат подгоняет или тормозит генератор, сообщает о критической ошибке и необходимости забраковать ранее принятые данные.

Все, во втором клоковом домене есть счетчик описывающий текущую фазу первого клока.

Можно делать выводы о допустимости чтения на том или ином фронте с учетом задержки на синхронизацию.

Наверное возможны нюансы и отличия при частотах ~1:1 и ~1:10

Честно говоря, я не могу придумать как верифицировать такое изделие, а написать-то можно всё.

 

[xvr 12]

Использовал подобную технику для elastic buffer'а. Входная и выходная частота были одинаковые, еще был отдельный строб, обозначающий окно данных.

Схема тактировалась входной частотой, умноженной на 4 и выходной. Пока сигнал окна данных не был установлен, работал фазовый детектор и определял сдвиг фаз между фронтами клоков (с точностью 90гр). Собственно данные, и исходный клок, подавались на сдвиговый регистр, отвод для снятия данных (длинна регистра) определялась спец. счетчиком, который инициализировался значением 1/2 длинны регистра +/- начальная фаза.

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

В модели работает, в железе еще не пробовал

[Shtirlits 0]

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

Для этого нужна такая разница и стабильность частот, чтобы был стробоскопический эффект, если делать "снимки" каждые несколько тактов.

 

[xvr 12]

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

Для этого нужна такая разница и стабильность частот, чтобы был стробоскопический эффект, если делать "снимки" каждые несколько тактов.

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

В принципе это в некоторых FPGA есть в чистом виде, а в остальных можно сделать на цепочках cell'ов, но это уже явно не будет 'простой дезайн'. Классическое FIFO будет попроще :smile3046: