[Yuri124 1]

28 minutes ago, blackfin said:

Если Quartus увидит, что вся цепочка тактируется одним клоком, он может убрать вообще все эти регистры, а не только "лишние".

Обещают не трогать:

Quote

For example, if the Synchronization Register Chain Length option isset to 2, optimizations such as register duplication or logic retiming are prevented from being performed on the first two registers in all identified synchronization chains. The first two registers are also optimized to improve MTBF when the Optimize Design for Metastability option is turned on

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/qts/qts_qii51018.pdf

[blackfin 16]

11 minutes ago, Yuri124 said:

Обещают не трогать..

Еще раз: всё это работает, если Quartus видит переход из одного клокового домена в другой.

Если вся цепочка регистров расположена в одном клоковом домене (что собс-но и предлагает Alex), то не будет никаких "identified synchronization chains".

Так что Quartus может спокойно выкинуть все эти регистры, если они не зафиксированы атрибутами..

[Avex 1]

@dxp  по холду фалзпас - потому что задержки надо ограничивать только сверху (max). А холд не то чтобы не нужен, он может даже мешать, т.к. если тул увидит нарушение по холду, то попытается добавить в путь задержку. А это уже точно лишнее.

 

Проблема еще в том, что при синхронном описании асинхронных клоков нет гибкости в констрейнинге задержек в CDC. Как оно получается после построения деревьев, так и получается. Можно накинуть 1-2 периода через малтисайкл, но на этом все - либо подходит, либо нет, никакой гибкости. Поэтому, метод так себе, для ленивых (писал, когда это применяют) . А если в ПЛИС еще и куча сложностей с реализацией такого подхода, то наверно и вовсе так делать не надо.

[Yuri124 1]

13 minutes ago, blackfin said:

Если вся цепочка регистров расположена в одном клоковом домене (что собс-но и предлагает Alex), то не будет никаких "registers in all identified synchronization chains".

Да, спасибо за уточнение и пояснение, выпустил это из виду.

9 minutes ago, Aleх said:

Можно накинуть 1-2 периода через малтисайкл

Это слишком много - даже добавка одного периода в сумме с остаточным сдвигом фаз клоков дает право развести так, что разбежка сигналов на шине станет больше одного периода частоты приемника, что ИМХО добавляет проблем.

Изменено 22 апреля, 2020 пользователем Yuri124

[Nick_K 0]

Тут было много написано про синхронизации доменов, а также про истинные и псевдосинхронные частоты. Но одну вещь стоит упомянуть - если при синтезе на выходах PLL/DCM/MMCM/т.п. не было указано, что выходные частоты должны быть согласованными по фазе, то даже 2 выхода с одного клокового генератора одинаковой частоты будут работать как асинхронные. Я попался так раз, когда игрался с несколькими фазами. Посиму либо же стоит сделать удобную синхронизацию для допустимого разлёта клоков, либо же заморачиваться для "полного" синхрогнизатора с хендшейком и брать асинхронные любые клоки.

[dxp 32]

А на чём это вы так попали? Vivado при использовании корок pll/mmcm автоматом извлекает информацию о клоках, клоки по умолчанию считаются синхронными, и дальше STA всё просчитывает. В Quartus команда derive_pll_clocks делает то же самое.

[Nick_K 0]

5 hours ago, dxp said:

А на чём это вы так попали?

На очень смешном месте:

Основная схема работала от clk_wiz_1 на разных фазах, но запись всегда происходила на фазе 0. Записывались данные в RAM на частоте 200MHz, при том что основная схема работала на 400MHz. Синхронизатора у меня толком не было, ибо был ограничен очень сильно в ресурсах и таймингах, поэтому переход в более медленный домен происходил по следующему алгоритму:

1. Записать данные в выходной регистр для RAM.

2. Подождать 1 такт на частоте 400MHz.

3. Выставить сигнал WE для RAM на 2 клока на частоте 400MHz (2*2.5 = 5 ns).

4. Снять WE и ждать следующего изменения состояния регистра.

И всё выглядит хорошо, да вот галочка синхронности частот 400 и 200 в clk_wiz_0 в одной из итераций изменений пропала (экспериментировал или случайно снял - не помню). В результате проект стал записывать данные через раз, либо какую-то кашу. Не знаю как тул мог бы определить зависимость между фазовым соотношением clk_wiz_0 и clk_wiz_1, но когда явно указывать, что фазы в clk_wiz_0 должны быть выровнены, то сбоев нет никогда по записи (очевидно, что выравнивание по фазе обязательно должно присутствовать на clk_wiz_1).

[dxp 32]

41 минуту назад, Nick_K сказал:

И всё выглядит хорошо, да вот галочка синхронности частот 400 и 200 в clk_wiz_0 в одной из итераций изменений пропала

Но ведь клоки-то всё равно остаются синхронными - от общего источника тактируются, поэтому STA в любом случае, насколько понимаю тему, должен был вычислить все задержки (даже при съехавших клоках) и посчитать слаки (заругаться, что они отрицательные). 

[Nick_K 0]

1 minute ago, dxp said:

Но ведь клоки-то всё равно остаются синхронными - от общего источника тактируются, поэтому STA в любом случае, насколько понимаю тему, должен был вычислить все задержки (даже при съехавших клоках) и посчитать слаки (заругаться, что они отрицательные). 

Синхронными - да. И STA не ругался - всё было впорядке. Но не синфазными из-за чего упрощённая схема синхронизации не отрабатывала.

[dxp 32]

Так этот сдвиг фазы STA же тоже учитывает. Например, если у вас два клока с периодом 10 нс каждый, но один сдвинут относительно другого на полпериода, setup relationship у них будет не 10 нс (как было бы в случае если они были бы синфазными), а всего 5 нс. И STA это видит и будет вычислять слаки, исходя из этого значения.

[Nick_K 0]

7 minutes ago, dxp said:

Так этот сдвиг фазы STA же тоже учитывает. Например, если у вас два клока с периодом 10 нс каждый, но один сдвинут относительно другого на полпериода, setup relationship у них будет не 10 нс (как было бы в случае если они были бы синфазными), а всего 5 нс. И STA это видит и будет вычислять слаки, исходя из этого значения.

Немного не так. Если сдвиг фазы указан явно - тогда да, STA учитывает все задержки. У меня не указано никаких сдвигов, но получается, что первая PLL запускается быстрее и частота 400MHz устанавливается быстрее, так как у неё минимальные потери в линии, от чего начинает тактироваться clk_wiz_1 и тоже в какой-то момент устанавливает стабильную частоту. А вот частота на выходе 200MHz установится позже, так как там очень много потребителей (порядка 32*4 КБ памятей RAM). Посиму после установки 200, 400 может уже тикать и не обязательно синфазно, да ещё и потери во второй PLL. Вот так в моём понимании получались разбеги. При чём они были относительно рандомными - несколько включений было нормально, потом сбоило.

[Yuri124 1]

1 hour ago, Nick_K said:

галочка синхронности частот 400 и 200 в clk_wiz_0 в одной из итераций изменений пропала (экспериментировал или случайно снял - не помню)

Предполагаю - при этом фазе разрешалось плавать в пределах периода.

[dxp 32]

2 минуты назад, Nick_K сказал:

Если сдвиг фазы указан явно - тогда да, STA учитывает все задержки. У меня не указано никаких сдвигов

Ну, все временные параметры клоков STA извлекает из настроек PLL. Кстати, какая у вас САПР была? Quaartus/Vivado/ISE?

 

3 минуты назад, Nick_K сказал:

получается, что первая PLL запускается быстрее и частота 400MHz устанавливается быстрее, так как у неё минимальные потери в линии, от чего начинает тактироваться clk_wiz_1 и тоже в какой-то момент устанавливает стабильную частоту. А вот частота на выходе 200MHz установится позже, так как там очень много потребителей (порядка 32*4 КБ памятей RAM). Посиму после установки 200

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

[Nick_K 0]

7 hours ago, Yuri124 said:

Предполагаю - при этом фазе разрешалось плавать в пределах периода.

Не разрешалось, но строго не было ограничено.

6 hours ago, dxp said:

Quaartus/Vivado/ISE?

Vivado 19.1

6 hours ago, dxp said:

Всегда полагал, что время готовности клока с выхода PLL определяется самой PLL

Всё верно, вот только фанаут имеет самое непосредственное отношение ибо в любом PLL/DCM есть пин обратной связи, который как раз и служит для оценки выхода генератора в рабочий режим. Соответственно чем болше потребителей висит, тем больше понадобится итераций для калибровки и выхода в нормальный режим работы. Эти итерации могут составлять десятки фемтосекунд или сотни микро - этого точно я не знаю, но точно зависимость есть

[RobFPGA 27]

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

15 minutes ago, Nick_K said:

Не разрешалось, но строго не было ограничено.

Скорее всего проблемы в другом - у вас  cdc идет с кратных клоков - но не факт  что вы обеспечивали корректный начальный reset для оных - поэтому соотношение времянок зависело и от того в какой "фазе" относительное clk 200 MHZ выставился запроc.   

15 minutes ago, Nick_K said:

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

Мягкое с теплым -  скорость захвата  PLL определяется исключительно аналоговыми параметрами и  тем на сколько далеко (по частоте ) начальные условия. Fanout тут никаким боком - он влияет только на суммарную задержку и skew при разводке и STA. 

Удачи!.