Jump to content

    

Cross clock domain переходы

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites
А ставить тройные фифо или по пять триггеров на сигнал никто не будет.

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

 

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

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

Мужики-то не знают, что можно делать надежные схемы!..

 

Share this post


Link to post
Share on other sites
Не понял формулировку вопроса, что значит "сильно ли нагружают частоты". Мы ж не со спектром имеем дело.

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

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

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

Share this post


Link to post
Share on other sites

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

 

Могу представить такой вариант: было два блока, питались они одним клоком, синхронно обменивались данными.

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

Речь об этом?

 

Share this post


Link to post
Share on other sites
...При развитии дизайна их клоки стали разными, на границе ничего не предпринималось, частоты стали меньше, чем исходная.

Речь об этом?

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

 

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

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

 

Или я чего-то не понимаю?

Вы говорите об общем опорном клоке, который в DCM превращается в два различных зависимых?

Тогда будут предсказуемые периодические нарушения setup и hold, о чем и расскажет анализатор.

 

Share this post


Link to post
Share on other sites
Тут никто ничему не возмущается, даже безобразия нарушить не удается для привлечения внимания.

 

 

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

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

 

Или я чего-то не понимаю?

Вы говорите об общем опорном клоке, который в DCM превращается в два различных зависимых?

Тогда будут предсказуемые периодические нарушения setup и hold, о чем и расскажет анализатор.

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Допустим есть две частоты в схеме на них заданы констрейны.

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

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

Share this post


Link to post
Share on other sites
Расскажите, какая предполагается схема организованного перехода?

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

Share this post


Link to post
Share on other sites

Безусловно, уменьшение частоты схемы из-за добавления 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

 

Share this post


Link to post
Share on other sites
Вы говорите об общем опорном клоке, который в DCM превращается в два различных зависимых?

Тогда будут предсказуемые периодические нарушения setup и hold, о чем и расскажет анализатор.

 

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

... Кстати, применяя DCM, в проекте не явно присутствует констрейн по всем порожденным линиям частот. Это я увидел случайно в отчете. Так что такой ход немного может снять напряжение проблемы...

Share this post


Link to post
Share on other sites

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

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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this