Здравствуйте, уважаемые гуру.

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

Вот есть входные и выходные сигналы, временные характеристики которых не нужно анализировать.
Светодиоды всякие и прочие кнопки.
Альтера требует, чтобы для таких сигналов в явном виде было задано false path, иначе ругается в отчете Time Quest'а и вообще работает криво, если есть необконстрейненные пути.

По Xilinx cкладывается впечатление, что оно по умолчанию эти сигналы не анализирует, если на них не задано ограничений.
Так ли это, и где про это в явном виде написано?

ISE 12.3.

Всем заранее спасибо за ответы.

2 Koluchiy
Вам нужно Timing Ignore (TIG) Constraint.
Детальнее здесь на странице 34/45

Спасибо за ответ. Что такое 45 в выражении 34/45?

Я в общем в курсе, что такое TIG.
Но в упомянутом Вами документе он рассматривается применительно к путям между регистрами, а не между регистрами и пинами.

Соответственно, есть 2 вопроса:
1) Применяется ли TIG для обозначения False Path между триггерами и пинами.
2) Нужно ли это делать в явном виде, т.е. прописывать TIG для каждого пина. Или среда сама считает, что если этих констрейнов нет, то оно без разницы?

2 Koluchiy
Касательно 34/45 - опечатался - имелось ввиду страницы 34 и 35 (в количестве 2х штук )

Касательно вопроса№1 - да, вам никто не мешает сделать так:
В данном конкретном примере сказано что не нужно анализировать все пути от лап до FF-ов и от FF-ов до лап. Чтобы выбрать какую т оконкретную группу лап или FF-ов нужно сделать свою группу. Примерчик можете глянуть вот тут на странице 29.

Касательно вопроса№2 - вы можете использовать * и другие методы чтобы не писать всё ручками.
На сколько я понял главное отличие временного анализа у хилых от альтеры - если ты не задал какой-то констрейн - это твои личные проблемы - никто тебе об этом в отдельной табличке не скажет(если это не частота конечно ).

То есть, правильно - делать
,
а для тех ног, которые не без разницы, задавать дополнительные констрейны?


Не, сделать репорт необконстрейненных путей можно .

Касательно

нет, так будет много крика на счёт constraint resolve - как он сделает этот самый constraint resolve утверждать не берусь (для примера, делал макетный дизайн недавно для V7 на ISE 14.1 - не указал там что у меня exclusive clock-и и он мне начал писать что "от я ща отрезолвлю тебе это всё дело", так как железа нет под рукой - хз что она там может нарезолвить, потому указал стандартно:

желание "отрезолвить" пропало ). Правильно будет создать группы сигналов на которые хочется наложить разные false_path и с ними работать. Или же просто не констрейнте те лапы которые должны быть TIG.

Касательно что то не припоминаю сходу, может подскажете?

И чего она с ними сделает, с необконстрейненными лапами?
Это ж главный вопрос всей темы .


В Generate Post P&R Static Timing - настройка "Unconstrained Paths" должна содержать максимальное число путей.
Сам отчет - в Plan Ahead.
По крайней мере, в 12.3 так.


Пользуясь случаем, как в 14.1 с глюками?

Хилые с необконстрейнеными лапами делают то же самое что и альтеры - ничего. В принципе эту ситуацию можно рассматривать как некоторый виртуальный TIG на все необконстрейненые лапы.

Касательно "Unconstrained Paths" (определился с ключиком, инфа для последующих жаждущих инфы) - ключик -u для trce. Отчёт можно глянуть и в ISE. (2 Koluchiy - Спасибо)

А вот на счёт глюков 14.1 - как для меня, так работает всё так же, только медленней (засекал относительно одного и того же проекта в 14.1 и 13.2 для S6). Довольно неплохой "с той же канистры" Vivado - у меня на тачке он правда собирает дизайн медленней чем в ISE и for 7-Series only, но за то есть XDC - это большой плюс, можно делать финты ушами

А как отчет глянуть в ISE?
Я не нашел, полез в грузящийся полчаса PlanAhead.


Мне без разницы, дольше или быстрее.
Финты ушами тоже непринципиальны.
Мне важно, чтобы ничего не висло в самый неподходящий момент, чтобы были правильные модели, и чтобы для всего этого не надо было ставить 10000 патчей .
Как с этим в 14.1? 13е версии не пробовал, не знаю как там.

2 Koluchiy

Касательно ISE и репорта - там после генерации отчёта имеем всё наше хозяйство в текстовом виде в *.twr - там и смотреть можно.
Но гораздо удобнее через xml и ISE - это будет файло *.twx. Смотреть через Design Summary - Static Timing - Timing Constrained - Unconstrained ...

Касательно 14.1 и вяческих падений - те дизайны что собирал и симулировал с использованием евойных либ - работали нормально. Правда это 3-4 дизайна для S3/S6 и V5. Касательно V6 - не подскажу, не было реального железа на проверку. Касательно же симуляции для V6 - симулил DS_DMA проект для V6(с либами от 14.1) - полёт нормальный

Продолжим воспоминания Xilinxовых констрейнов и борьбы с ними .

Имеем Virtex 6.

В этом самом Virtex 6 есть FIFO, запись в которое осуществляется на частоте Clk320, чтение - Clk311 (цифра - частота в мегагерцах).

Частоты, понятное дело, несинхронные, соответственно написаны констрейны:
TIMESPEC TS_C30 = FROM "Clk311" TO "Clk320" TIG;
TIMESPEC TS_C40 = FROM "Clk320" TO "Clk311" TIG;

Translate к констрейнам претензий не имеет.
Тем не менее, после P&R мне пишет, что "1 constraint not met".

Ну, нот мет и нот мет, чего тут такого.
Но дальше интереснее.
В табличке мне рисует:

TS_PLL_IntClocksPLL_clkout0 - это Clk320.

Открываю отчет .twx, а там картина совсем другая:

В общем, ругается на несоблюдение hold'ов как раз между доменами Clk320 и Clk311.
Несмотря на то, что заданы констрейны, чтобы эти пути не анализировать.

Что не так?

Как заданы Clk311 Clk320? Должны быть через TIMESPEC. Если через NET, то такой констрейн не продет через ПЛЛ.
Посмотрите отчет транслятора, там анализ ucf идет, и если ise кладет на констрейны, то там это должно быть.

Вот так:



Ну а вообще, Clk320 - выход PLL, Clk311 - выход опорного клока GTX'а (REFCLKOUT).


Не кладет.
Более того, про них есть в табличке:


P.S. Ах да, ISE 12.3.

В свойствах синтезатора Cross Clock Analysis галка стоит?

Ах да №2 .

Синтезатор - Synplify 2010.09.

Так же столкнулся с интересным поведением ISE касательно TIG для V7.
Имею 2е частоты - системную и частоту на которой работает память. Задаю через TIG TIMESPEC для них. Однако системная частота заходит на MCM и после него используется в некотрой логике. Generated clock делает сама ISE:
Нажмите для просмотра прикрепленного файла
(Source - *.ngd)

Так вот проблема заключается в том, что TIG TIMESPEC не распространился на Generated clock и синтезатор мне выкидывает вот такой слак:
Нажмите для просмотра прикрепленного файла
Вот собственно частоты:
Source Clock: U_SOPC/qdr2p_slave_0/qdr2p_slave_0/U_USER_LOGIC/s_qdr2p_sys_clk rising at 4.000ns
Destination Clock: U_SOPC/clk_100_0000MHz rising at 4.000ns
(clk_100_0000MHz - это частота после MCM, s_qdr2p_sys_clk - системная частоат памяти)
Вот табличка производной частоты:
Нажмите для просмотра прикрепленного файла

При чём во время PAR получаю вот такое сообщение:
WARNING:Route:522 - Unusually high hold time violation detected among 1 connections.The router will continue and try to fix it
как раз связанное с тем что нет TIG TIMESPEC для кросс-клока.

Может кто сталкивался с такой ситуацией - когда TIG не распространяется на generated clock?
И где посмтреть список констрейнов, которые "were not applied"? Сходу не нашёл (в Design Overview - Timins Constraints моего TIG-а не нашёл)...

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

Что? Нужно.

2 Koluchiy
Добавил руками TIG TIMESPEC для generated clock исходя из моей текущей реализации. Так сказать "вручную" derive constraint.

Приветствую!

Вот сам на это нарвался - но для BUFGCTRL (v14.1 - Virtex5) - ну ни как ни удавалось один из клоков на входе BUFGCTRL указать как TIG.

Решилось только дублированием констрэйна нужного клока назначенного непосредственно на выход BUFGCTRL.

Успехов! Rob.