Cross clock domain переходы, Нагружают ли частоты Опции

[D-Luxe]

Меня интересует сильно ли нагружают частоты cross clock domain переходы и соответственно просаживают эти частоты при Timing Analysis ? Если да, то почему.

[tAmega]

Не понял формулировку вопроса, что значит "сильно ли нагружают частоты". Мы ж не со спектром имеем дело.
Но в общем могу сказать, что переходами между клок доменами увлекаться не стоит по другой причине. Каждый такой переход имеет надежность меньше 100%. И чем больше переходов, тем больше шансов что через несколько часов дизайн будет валиться словив нехорошую комбинацию сигналов. Так как каждый переход это по сути асинхронная брешь в синхронном дизайне.
А ставить тройные фифо или по пять триггеров на сигнал никто не будет. Поэтому по возможности надо избегать. А тайминг анализ как раз при переходе между доменами намеренно отключается разработчиком в ucf. Так как он в принципе невозможен, если мы говорим о setup, hold.

[Shtirlits]

А ставить тройные фифо или по пять триггеров на сигнал никто не будет.

Интересно, почему?

Если стоит задача получить требуемый MTBF всего дизайна, то разработчик обязан ставить столько регистров подряд, сколько нужно и размещать их подобающим образом и за разводкой следить, чтобы обеспечить требуемую емкость соединений.
Возможно, вы имели в виду, что эти "никто", которые "не будет" - это основная масса разработчиков, из-за которых так нужны watchdog-и и первый совет службы поддержки "вынуть-вставить питание".
Мужики-то не знают, что можно делать надежные схемы!..

Причина редактирования: ненужное цитирование

[D-Luxe]

Не понял формулировку вопроса, что значит "сильно ли нагружают частоты". Мы ж не со спектром имеем дело.
Но в общем могу сказать, что переходами между клок доменами увлекаться не стоит по другой причине. Каждый такой переход имеет надежность меньше 100%. И чем больше переходов, тем больше шансов что через несколько часов дизайн будет валиться словив нехорошую комбинацию сигналов. Так как каждый переход это по сути асинхронная брешь в синхронном дизайне.
А ставить тройные фифо или по пять триггеров на сигнал никто не будет. Поэтому по возможности надо избегать. А тайминг анализ как раз при переходе между доменами намеренно отключается разработчиком в ucf. Так как он в принципе невозможен, если мы говорим о setup, hold.

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

[Shtirlits]

По сравнению с чем итоговый минимум уменьшается?

Могу представить такой вариант: было два блока, питались они одним клоком, синхронно обменивались данными.
При развитии дизайна их клоки стали разными, на границе ничего не предпринималось, частоты стали меньше, чем исходная.
Речь об этом?

[Мур]

...При развитии дизайна их клоки стали разными, на границе ничего не предпринималось, частоты стали меньше, чем исходная.
Речь об этом?

Пол дня висит это высказывание и никто не возмущается!

DCM, если взять предельный(могочастотный) вариант, соотношение частот держит железно, по ФАПЧ. Частоты меняться не могут никак! Фазы, по причине расположения в разных доменах, могут. Видимо это имелось ввиду... Некая систематическая, нестационарная(температура!) задержка. Её можно выразить в градусах или во времени. Но никак в частотах

[Shtirlits]

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


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

Или я чего-то не понимаю?
Вы говорите об общем опорном клоке, который в DCM превращается в два различных зависимых?
Тогда будут предсказуемые периодические нарушения setup и hold, о чем и расскажет анализатор.

[D-Luxe]

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


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

Или я чего-то не понимаю?
Вы говорите об общем опорном клоке, который в DCM превращается в два различных зависимых?
Тогда будут предсказуемые периодические нарушения setup и hold, о чем и расскажет анализатор.

Допустим есть две частоты в схеме на них заданы констрейны.

Есть вариант схемы без перехода между доменами. Сильно повлияет на схему организованный cross clock domain переход? Сильно ли ухудшатся результаты временного анализатора?

[Shtirlits]

Расскажите, какая предполагается схема организованного перехода?

[bogaev_roman]

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

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

[D-Luxe]

Расскажите, какая предполагается схема организованного перехода?

Coregen'овское fifo двухчастотное.

[Shtirlits]

Безусловно, уменьшение частоты схемы из-за добавления fifo может быть,
особенно на стороне чтения, но обычно держит не логика fifo, а память.
И сам по себе переход между клоками тут тоже не главное.

Я бы не злоупотреблял режимом first-word fall-through, флагами almost* и счетчиками.

Как законстрейнить сегодня уже писал в другой теме, но повторюсь:
NET "*BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc(*)" MAXDELAY = 450 ps; # или сколько получится, чем меньше - тем лучше
NET "*BU2/U0/grf.rf/gcx.clkx/wr_pntr_gc(*)" MAXDELAY = 450 ps;

NET "*BU2/U0/grf.rf/gcx.clkx/wr_pntr_gc(*)" TIG;
NET "*BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc(*)" TIG;

Понадобится keep hierarchy и, возможно, подправить путь в соответствии с версией fifo
(анализатор на эти сигналы должен ругаться при зависимых клоках)
В примере пути и сигналы взяты из 11.5

[Мур]

Вы говорите об общем опорном клоке, который в DCM превращается в два различных зависимых?
Тогда будут предсказуемые периодические нарушения setup и hold, о чем и расскажет анализатор.

А не проще, как вариант, привязать проект к конкретным доменам, а затем, получив на DCM набор частот с нужным фазовым сдвигом, явно запитать эти домены(-кусочки проекта) с учетом удаления от опорного? Получите минимальные расхождения!
... Кстати, применяя DCM, в проекте не явно присутствует констрейн по всем порожденным линиям частот. Это я увидел случайно в отчете. Так что такой ход немного может снять напряжение проблемы...

[Shtirlits]

Мур, вы напомнили мне про частный случай зависимых клоков - одинаковые частоты, но разные фазы.
В этом случае анализатор снизит fmax, так как время на распространение сигнала будет равно не периоду, а сдвигу.