Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Пересечение сигналом разных клоковых доменов
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
ig_f
Доброго времени суток!
Есть управляющий автомат работающий на частоте 400 кГц и есть логика обработки данных работающая на частоте 120 МГц. Соответственно автомат управления посылает различные сигналы в остальную логику. Частота 400 кГц формируется из основной частоты 120 МГц (без использования PLL, с помощью обыкновенного счетчика), т.е. клоки в общем-то связанные.
Вопросы:
1) Правильно ли я мыслю, что в моем случае можно обойтись без синхронизаторов(тех самых, что используются для борьбы с метастабильностью)?
2) Если так, то что для этого нужно сделать?

Заранее спасибо!

ps
Cyclone III
Kuzmi4
2 ig_f
вообще то всегда надо ставить переходники, это хороший тон.
Но в принципе бывают случаи когда вы точно знаете что управляющий строб идёт в логику тогда, когда данные, привязанные к этому стробу, уже устаканились 101%, тогда вам, в принципе, не надо синхронизатор на данные, нужен переходник на строб только.
TRILLER
Цитата(ig_f @ Dec 10 2014, 16:46) *
1) Правильно ли я мыслю, что в моем случае можно обойтись без синхронизаторов(тех самых, что используются для борьбы с метастабильностью)?

Нет, нельзя.
Можно обойтись лишь в том случае, если, к примеру, частоты сформированы одним DCM и используют одинаковые буферы - т.е. находятся жёстко в фазе.
В вашем же случае получаются фактически независимые домены.
И всё же я не понимаю в чём проблема поставить по лишнему триггеру, ведь управляющий сигнал относительно медленный и, скорее всего, не так уж важна погрешность в 1 такт быстрой частоты..
des00
Цитата(TRILLER @ Dec 11 2014, 00:08) *
Нет, нельзя.
Можно обойтись лишь в том случае, если, к примеру, частоты сформированы одним DCM и используют одинаковые буферы - т.е. находятся жёстко в фазе.

в данном случае нельзя потому что может потребоваться выравнивание длительностей управляющих сигналов. Но вообще клок 400кГц рожден из 120МГц, при правильном задании констрейнов софт правильно рассчитает задержки и соотношения частот и все будет норм.

ТС. лучше посадить управляющий автомат на клок 120МГц + сигнал разрешения работы на 400кГц
SM
Цитата(ig_f @ Dec 10 2014, 16:46) *
т.е. клоки в общем-то связанные.
Вопросы:
1) Правильно ли я мыслю, что в моем случае можно обойтись без синхронизаторов(тех самых, что используются для борьбы с метастабильностью)?
2) Если так, то что для этого нужно сделать?


1) можно, и даже нужно.
2) Ничего для этого не надо делать. Только корректно описать клок 400 кгц как generated из 120 MHz - остальное сделает PAR. Если сможет. А если не сможет, то наругается - в таком случае, как правило, надо перевести работу на пересечении в одном из доменов на negedge. Но обычно и сам справляется. И, потом, в отчете STA внимательно изучите отчеты о междоменных связях, какой там запас. А если та часть, которая работает на 400 кГц, физически может и на 120 МГц, то и клок описывать не надо, PAR сам увидит, из чего он сделал и на сколько один клок раньше другого.

UPD:
А советы про сигнал разрешения - правильные. Для фпга такой подход обычно более оптимален.

UPD2:
И еще, очень внимательно!!! Эти клоки ни в коем разе не должны объявляться независимыми или асинхронными (желательно, они должны быть в одной клоковой группе). Иначе PAR не будет анализировать междоменные пути и править там холды на них.
Maverick
Цитата(ig_f @ Dec 10 2014, 15:46) *
Доброго времени суток!
Есть управляющий автомат работающий на частоте 400 кГц и есть логика обработки данных работающая на частоте 120 МГц. Соответственно автомат управления посылает различные сигналы в остальную логику. Частота 400 кГц формируется из основной частоты 120 МГц (без использования PLL, с помощью обыкновенного счетчика), т.е. клоки в общем-то связанные.
Вопросы:
1) Правильно ли я мыслю, что в моем случае можно обойтись без синхронизаторов(тех самых, что используются для борьбы с метастабильностью)?
2) Если так, то что для этого нужно сделать?

Заранее спасибо!

ps
Cyclone III

честно, я бы делал автомат на основной частоте 120 МГц, который выдавал управляющие сигналы на частоте 400 кГц
TRILLER
Цитата(des00 @ Dec 10 2014, 19:30) *
..Но вообще клок 400кГц рожден из 120МГц, при правильном задании констрейнов софт правильно рассчитает задержки и соотношения частот и все будет норм.

Ну разумеется можно, но только при должном понимании проблемы. Исходя из формулировки вопроса предполагаю, что могут возникнуть проблемы.
Прошу прощения, если ненароком оскорбил ТС. Ну а в том случае что я описал выше не нужно ничего, кроме описания исходного клока - всё остальное сделает софт.
ig_f
Цитата
Прошу прощения, если ненароком оскорбил ТС. Ну а в том случае что я описал выше не нужно ничего, кроме описания исходного клока - всё остальное сделает софт.

Ненароком не оскорбили - я не волшебник, а только учусь biggrin.gif . Пока отношу себя к дилетантам sm.gif
Нет никакой проблемы поставить лишние пару триггеров. И, наверно, это было бы самым простым решением проблемы. В этом проекте не важно: есть этот синхронизатор или нет. А в каком-нибудь другом этот момент может оказаться критическим. Поэтому хочется все-таки разобраться.


Изначально автомат задумывался на основной частоте 120 МГц, но, во-первых ему ни к чему такая скорость обработки т.к. его входные сигналы медленные, во вторых у него достаточно долгие периоды выжидания переходов в следующие состояние, что на частоте 120 МГц выливается в длинющие счетчики. Поэтому было решено скинуть его на низкую частоту. В принципе можно попробовать работать на 120 МГц, но пугают LUTы в управляющем автомате, нагроможденные в четыре этажа(может зря пугают?). Сигналы выдаваемые автоматом не стробируют никаких данных, а лишь дают разрешение на запуск, остановку работы и т. п.

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

Начинаю понимать, что мой вопрос возник из-за недостаточного знакомства с Timing Analysis и задания констрейнов rolleyes.gif .

И как тут прилепить цитирование со ссылкой на автора, а не просто "Цитата"?
Bad0512
Делать клоки низкой частоты без использования PLL с помощью счётчика очень неправильно. Это называется gated clock и порождает в будущем массу разнообразных проблем. Тема не раз обсуждалась - поищите на форуме.
Правильно делать (как вам тут уже не один раз советовали) так : на счётчике формируем импульс в один такт 120МГц с периодом 400КГц. Этот импульс подаем на CE вход всех триггеров автомата (но ни в коем случае
не на клоковый вход!!!). Тактируем всё от одного 120МГц клока. В результате избегаем все CDC(clock dmain crossing) проблемы, а автомат у нас работает на 400кГц клоке.

P.S. Автоматы всегда должны переключаться по сигналам из клокового домена самого автомата, иначе - вечная битва с нестабильностью работы.

ig_f
Цитата
Делать клоки низкой частоты без использования PLL с помощью счётчика очень неправильно. Это называется gated clock и порождает в будущем массу разнообразных проблем. Тема не раз обсуждалась - поищите на форуме.
Правильно делать (как вам тут уже не один раз советовали) так : на счётчике формируем импульс в один такт 120МГц с периодом 400КГц. Этот импульс подаем на CE вход всех триггеров автомата (но ни в коем случае
не на клоковый вход!!!). Тактируем всё от одного 120МГц клока. В результате избегаем все CDC(clock dmain crossing) проблемы, а автомат у нас работает на 400кГц
Теперь понял. Сперва подумал, что предлагают чтоб автомат постоянно щелкал на 120 МГц. Думаю можно поправить автомат, добавить в него разрешающих сигналов. Наверное такое будет более красивым.

А вообще мне казалось, что gated clok это когда сигнал тактовой смешивается с некоторыми управляющими сигналами через комбинационную логику. В моем случае я формирую сигнал довольно низкой частоты с помощью восьмиразрядного счетчика и компаратора который формирует сигнал разрешения для T-триггера, на тактовый вход которого подается 120 МГц. То есть моменты переключения вполне детерминированы и связаны с основной тактовой. Далее выход триггера заводится на Clock Control Block и поступает на GCLK. В описании Clock Control Block такая схема тактирования подразумевается. Мне она видется вполне безопасной на частоте 400 КГц, разве нет?. Ни в коем разе не спорю, что предложенное вами решении выглядит лучше и порождает меньше проблем, как для меня, так и для САПРа. Просто хочу узнать возможно ли в принципе использовать такое тактирование?
SM
Цитата(ig_f @ Dec 11 2014, 00:37) *
Нет никакой проблемы поставить лишние пару триггеров. И, наверно, это было бы самым простым решением проблемы. В этом проекте не важно: есть этот синхронизатор или нет. А в каком-нибудь другом этот момент может оказаться критическим. Поэтому хочется все-таки разобраться.


Разница в том, что установка синхронизатора на асинхронных клоках лишь уменьшает вероятность прохождения метастабильности через него, но не обнуляет ее. А грамотное описание (а в Вашем случае, скорее всего, грамотное НЕописание) связанных клоков, без разницы, как сгенерированных, хоть с помощью PLL, хоть с помощью триггеров, гарантирует полное отсутствие метастабильных состояний. Поэтому предпочтительнее правильно описать клоки и не ставить синхронизаторы, нежели объявить клоки независимыми и поставить синхронизаторы.

И в Вашем случае это не gated clock, а generated клок. Gated clock, как Вы правильно заметили, это клок, прошедший через логический вентиль, чем-то там управляемый, а не взятый с выхода триггера. В отличие от generated clock-ов, с gated присутствуют еще дополнительные проблемы, надо обеспечивать отсутствие глитчей в моменты переключения управляющих сигналов.

Цитата(ig_f @ Dec 11 2014, 00:37) *
И как тут прилепить цитирование со ссылкой на автора, а не просто "Цитата"?

Кнопкой "reply" отвечать, которая под сообщением, на которое ответ пишете.
Bad0512
Цитата(ig_f @ Dec 11 2014, 14:36) *
А вообще мне казалось, что gated clok это когда сигнал тактовой смешивается с некоторыми управляющими сигналами через комбинационную логику. В моем случае я формирую сигнал довольно низкой частоты с помощью восьмиразрядного счетчика и компаратора который формирует сигнал разрешения для T-триггера, на тактовый вход которого подается 120 МГц. То есть моменты переключения вполне детерминированы и связаны с основной тактовой. Далее выход триггера заводится на Clock Control Block и поступает на GCLK. В описании Clock Control Block такая схема тактирования подразумевается. Мне она видется вполне безопасной на частоте 400 КГц, разве нет?. Ни в коем разе не спорю, что предложенное вами решении выглядит лучше и порождает меньше проблем, как для меня, так и для САПРа. Просто хочу узнать возможно ли в принципе использовать такое тактирование?

Про Gated clock вы всё правильно понимаете, однако ваш механизм как раз и является таким случаем (ведь с выхода T-триггера вы же потом через буфера подаёте на клоковые входы - так?). Главная тут неприятность вот какая :
Для клоковых цепей в ПЛИС предусмотрены специальные ресурсы. Главная особенность этих ресурсов в том, что время распространения сигнала по клоковым цепям значительно меньше, чем по обычным и очень мало отличается для синхронных элементов, расположенных в разных частях кристалла. Если в цепь распространения клока (в вашем случае от выхода Т триггера до клокового буфера) попадает обычный интерконнект, то во-первых сразу задержка по клоку увеличивается сильно, во-вторых при переходе с медленного клока (400кГц) на быстрый (120МГц) у вас сильно сокращается допустимая задержка за счёт задержки в цепи генерации медленного клока.
В итоге оба клока у вас фактически являются синхронными, но сдвинутыми по фазе за счёт вышеуказанной задержки. Все эти обстоятельства сильно усложняют жизнь тайминг аналайзеру, иногда это даже приводит к тому, что он не может свести тайминги в ноль.
Возможно что в вашем случае все тайминги сойдутся, однако принципиально этот путь тупиковый, когда вам придётся "выжимать из дизайна мегагерцы" это может стать большой проблемой.
SM
Цитата(Bad0512 @ Dec 11 2014, 14:53) *
это может стать большой проблемой.

Может, но не станет. Если задержка между клоками такова, что PAR не может свести концы с концами, то просто-напросто следует сделать "прокладку" в одном из доменов из триггеров, работающих по противоположному фронту, что обеспечит в таком случае выполнение времянок.
Bad0512
Цитата(SM @ Dec 11 2014, 18:01) *
Может, но не станет. Если задержка между клоками такова, что PAR не может свести концы с концами, то просто-напросто следует сделать "прокладку" в одном из доменов из триггеров, работающих по противоположному фронту, что обеспечит в таком случае выполнение времянок.

Работа по заднему фронту сразу в 2 раза уменьшает timing budget - поэтому борясь с одной проблемой можно наступить на другую.
SM
Цитата(Bad0512 @ Dec 11 2014, 15:09) *
поэтому борясь с одной проблемой можно наступить на другую.

Можно, но не в этом случае, так как тут нет никакой логики между триггерами, работающими по фронту, и триггерами, работающими по спаду, а, следовательно, есть достаточный запас на этот фортиль.
dxp
В каком-то альтеровском документе видел описание приёма с gated clock, с помощью которого боролись за энергопотребление - ну, чтоб не клокало по входам неработающего модуля. Вроде как декларировалось, что при правильном подходе всё корректно и хорошо. Под рукой нет этой доки, поищу на досуге.
SM
Цитата(dxp @ Dec 11 2014, 16:19) *
ну, чтоб не клокало

А вот кстати, у альтер есть такая штука, как у латиса - DCS (Dynamic Clock Select) - железные блоки - безглитчевые мультиплексоры/гейтилки, встроенные в распределительный узел клоковых деревьев?
des00
Цитата(SM @ Dec 11 2014, 20:26) *
А вот кстати, у альтер есть такая штука, как у латиса - DCS (Dynamic Clock Select) - железные блоки - безглитчевые мультиплексоры/гейтилки, встроенные в распределительный узел клоковых деревьев?

CLKCTRL блок
blackfin
Цитата(dxp @ Dec 11 2014, 16:19) *
В каком-то альтеровском документе видел описание приёма с gated clock, с помощью которого боролись за энергопотребление - ну, чтоб не клокало по входам неработающего модуля. Вроде как декларировалось, что при правильном подходе всё корректно и хорошо. Под рукой нет этой доки, поищу на досуге.

Это в Quartus II Handbook, стр. 13–11
Цитата
Recommended Clock-Gating Methods Use gated clocks only when your target application requires power reduction and when gated clocks are able to provide the required reduction in your device architecture.
If you must use clocks gated by logic, implement these clocks using the robust clock-gating technique shown in Figure 13–8 and ensure that the gated clock signal uses dedicated global clock routing.


Хотя ТСу, вероятно, нужен раздел "Internally Generated Clocks", стр. 13-8:
Цитата
Divided Clocks
Designs often require clocks that you create by dividing a master clock. Most Altera FPGAs provide dedicated phase-locked loop (PLL) circuitry for clock division.
Using dedicated PLL circuitry can help you to avoid many of the problems that can be introduced by asynchronous clock division logic.
When you must use logic to divide a master clock, always use synchronous counters or state machines. Additionally, create your design so that registers always directly
generate divided clock signals, as described in “Internally Generated Clocks”, and route the clock on global clock resources. To avoid glitches, do not decode the outputs
of a counter or a state machine to generate clock signals.
SM
Цитата(des00 @ Dec 11 2014, 16:40) *
CLKCTRL блок


Хм. А где он описан, сама железяка, а не соотв. ей мегафункция (в рамках Cyclone-ii, например)? Что-то не пойму, сколько их штук в EP2C8F256C8N.... Или это все таки мегафункция-генератор безглитчевого мукса на логике?
ig_f
Цитата(Bad0512 @ Dec 11 2014, 14:53) *
Про Gated clock вы всё правильно понимаете, однако ваш механизм как раз и является таким случаем (ведь с выхода T-триггера вы же потом через буфера подаёте на клоковые входы - так?). Главная тут неприятность вот какая :
Для клоковых цепей в ПЛИС предусмотрены специальные ресурсы. Главная особенность этих ресурсов в том, что время распространения сигнала по клоковым цепям значительно меньше, чем по обычным и очень мало отличается для синхронных элементов, расположенных в разных частях кристалла. Если в цепь распространения клока (в вашем случае от выхода Т триггера до клокового буфера) попадает обычный интерконнект, то во-первых сразу задержка по клоку увеличивается сильно, во-вторых при переходе с медленного клока (400кГц) на быстрый (120МГц) у вас сильно сокращается допустимая задержка за счёт задержки в цепи генерации медленного клока.
В итоге оба клока у вас фактически являются синхронными, но сдвинутыми по фазе за счёт вышеуказанной задержки. Все эти обстоятельства сильно усложняют жизнь тайминг аналайзеру, иногда это даже приводит к тому, что он не может свести тайминги в ноль.
Возможно что в вашем случае все тайминги сойдутся, однако принципиально этот путь тупиковый, когда вам придётся "выжимать из дизайна мегагерцы" это может стать большой проблемой.


Спасибо, что пояснили суть проблемы. В общем буду допиливать проект, а потом смотреть на тайминги и отчеты place and route. Если не сойдутся тогда буду смотреть на вариант с защелкиванием по заднему фронту.
А как можно проверить тайминги раньше, чем весь проект будет готов?

Цитата(blackfin @ Dec 11 2014, 16:44) *
Хотя ТСу, вероятно, нужен раздел "Internally Generated Clocks", стр. 13-8:

Что-то в моем хэндбуке на этих страницах совсем о другом написано и вообще нет таких разделов... может версии разные
PS
Нашлось в другой главе с другим названием. В целом я так и сделал, как там описано.
blackfin
Цитата(ig_f @ Dec 11 2014, 17:41) *
Что-то в моем хэндбуке на этих страницах совсем о другом написано и вообще нет таких разделов... может версии разные

Это из Quartus II Handbook Version 13.0.
des00
Цитата(SM @ Dec 11 2014, 21:46) *
Хм. А где он описан, сама железяка, а не соотв. ей мегафункция (в рамках Cyclone-ii, например)? Что-то не пойму, сколько их штук в EP2C8F256C8N.... Или это все таки мегафункция-генератор безглитчевого мукса на логике?

в сыклоне 2 такого нет. а сама железяка в хендбуке, часть хендбука вставлена в описание мегафункции http://www.altera.com/literature/ug/ug_altclock.pdf
Torpeda
Цитата(ig_f @ Dec 10 2014, 17:46) *
1) Правильно ли я мыслю, что в моем случае можно обойтись без синхронизаторов(тех самых, что используются для борьбы с метастабильностью)?
2) Если так, то что для этого нужно сделать?

1) правильно
2) ничего ненадо если.....
Если дизайн сделан синхронным - т.е. к каждому тригеру (и в той и другой части) подведён один и тот-же провод CLK


Цитата(SM @ Dec 10 2014, 20:55) *
2) Ничего для этого не надо делать. Только корректно описать клок 400 кгц как generated из 120 MHz - остальное сделает PAR.

..тоже можна...но зачем так сложно?

Цитата(ig_f @ Dec 11 2014, 01:37) *
В альтеровских руководствах сказано, что если клоки завязанные, то их можно считать синхронными и, соответственно, можно обойтись без синхронизатора. Поэтому вариант, который предложил уважаемый SM мне кажется более естественным для решения данной задачи.

для FPGA такой вариант противоестественный но можно запихнуть


Цитата(Bad0512 @ Dec 11 2014, 09:32) *
Правильно делать (как вам тут уже не один раз советовали) так : на счётчике формируем импульс в один такт 120МГц с периодом 400КГц. Этот импульс подаем на CE вход всех триггеров автомата (но ни в коем случае
не на клоковый вход!!!). Тактируем всё от одного 120МГц клока. В результате избегаем все CDC(clock dmain crossing) проблемы, а автомат у нас работает на 400кГц клоке.

да - это и называется синхронный дизайн!!!


Цитата(SM @ Dec 11 2014, 12:50) *
...А грамотное описание связанных клоков, без разницы, как сгенерированных, хоть с помощью PLL, хоть с помощью триггеров, гарантирует полное отсутствие метастабильных состояний. Поэтому предпочтительнее правильно описать клоки и не ставить синхронизаторы, нежели объявить клоки независимыми и поставить синхронизаторы.


какими клоками не описывай физически асинхронную схему - такой она и останется.
Другое дело - это написать правильные констрейны, чтобы они гарантировали правильную физическую реализацию изначально синхронной схемы.
SM
Цитата(Torpeda @ Dec 12 2014, 13:05) *
какими клоками не описывай физически асинхронную схему - такой она и останется.

Где Вы тут нашли асинхронную систему? Сами придумали?
Torpeda
Цитата(SM @ Dec 12 2014, 14:10) *
Где Вы тут нашли асинхронную систему? Сами придумали?


хмм.....
1) этот случай абсолютно тривиальный и синхронный по сути но...
2) автор его сделал на generated_clock и при этом тулзе не описал SDC констрейнами, как результат - получил асинхронную
SM
Цитата(Torpeda @ Dec 12 2014, 13:16) *
хмм.....
1) этот случай абсолютно тривиальный и синхронный по сути но...
2) автор его сделал на generated_clock и при этом тулзе не описал SDC констрейнами, как результат - получил асинхронную

2) в корне неверно, так как и синтез, и PAR сам видит все сгенерированные клоки, и без доп. SDC-описаний считает их клоками тех же частот, что и генерирующая сторона, но сдвинутых по времени на какое-то значение, определяемое физическими задержками генерации и разводки. И, соответственно, корректирует длины путей между этими клоками, и по сетапам, и по холдам. Дополнительные констрейны нужны только в том случае, если необходимо указать, что сгенерированный клок имеет другую частоту, нежели сторона, его сгенерировавшая.
Torpeda
Цитата(SM @ Dec 12 2014, 14:54) *
2) в корне неверно, так как и синтез, и PAR сам видит все сгенерированные клоки, и без доп. SDC-описаний считает их клоками тех же частот, что и генерирующая сторона, но сдвинутых по времени на какое-то значение, определяемое физическими задержками генерации и разводки. И, соответственно, корректирует длины путей между этими клоками, и по сетапам, и по холдам. Дополнительные констрейны нужны только в том случае, если необходимо указать, что сгенерированный клок имеет другую частоту, нежели сторона, его сгенерировавшая.


1) без доп. SDC-описаний тул видит все тригеры висящие на выходе FF.Q generated_clock как unconstrained
Собственно, всё чего нет в SDC - unconstrained
2) Я уже про констрейны для правильного построяния клок-три молчу в этом случае

Таким образом, ничего автоматически не происходит.
PS. Это я правда в Encounter проверил...
Как минимум от входных пинов FPGA тулза автоматически распознаёт клоки и даже назначение на пины предлагает, а вот generated_clock я не уверен.....
опять-же, функция автораспознавания некоторых тулзов не есть общее правило...
SM
Цитата(Torpeda @ Dec 12 2014, 17:44) *
PS. Это я правда в Encounter проверил...
Как минимум от входных пинов FPGA тулза автоматически распознаёт клоки и даже назначение на пины предлагает, а вот generated_clock я не уверен.....
опять-же, функция автораспознавания некоторых тулзов не есть общее правило...

Вот именно, что про энкаунтер, он тут не причем. Предупреждать надо, что в оффтопик уходим. С этим я спорить не буду, так там и есть. Синопсис DC/ICC/Astro тоже не распознает. И то, там есть set_propagate_clock для этого (кажется, или derive_clocks, плохо помню)

Но мы то говорим про FPGA, а там это беспрекословное правило для всех (известных мне) PAR-тулов. Да и синтезаторы тоже generated clock-и сами вытаскивают и автораспространяют, и квартус, и синплифай.
Torpeda
Цитата(SM @ Dec 12 2014, 18:34) *
Вот именно, что про энкаунтер, он тут не причем. Предупреждать надо, что в оффтопик уходим. С этим я спорить не буду, так там и есть. Синопсис DC/ICC/Astro тоже не распознает. И то, там есть set_propagate_clock для этого (кажется, или derive_clocks, плохо помню)

Но мы то говорим про FPGA, а там это беспрекословное правило для всех (известных мне) PAR-тулов. Да и синтезаторы тоже generated clock-и сами вытаскивают и автораспространяют, и квартус, и синплифай.

проверил в квартусе.
Он распознал 2 клока но....
В SDC записал 2 create_clock от CLK пина и соответственно от FF.Q делителя
Это означает что таки квартус лепит асинхронщину ибо... insertion_delay делёного клока начинает отсчёт с FF.Q, а не CLK пина!
Нам-же надо именно generated_clock от FF.Q и create_clock от CLK
SM
Он должен был туда и derive_clocks записать. Видимо, вопрос опций. А Synplify + Diamond все это делают сами молча и по умолчанию.

Отчет покажите таймквеста, про междоменный переход.
Torpeda
Цитата(SM @ Dec 12 2014, 19:23) *
Он должен был туда и derive_clocks записать. Видимо, вопрос опций. А Synplify + Diamond все это делают сами молча и по умолчанию.

Именно как create_generated_clock создаёт с root=CLK, и с такойже частотой как и root ?
Интересно...Quartus вот протупил....

А как оно generated_clock к глобальному клоковому дереву подключает? или не подключает....
SM
Цитата(Torpeda @ Dec 12 2014, 19:27) *
Именно как create_generated_clock создаёт с root=CLK, и с такойже частотой как и root ?
Интересно...Quartus вот протупил....

А как оно generated_clock к глобальному клоковому дереву подключает? или не подключает....


Вот по порядку:

1) исходный код.

CODE

module tst (clk, in, out);
input clk, in;
output reg out;

reg ckff;
always @(posedge clk)
ckff <= ~ckff;

reg ff_a;
always @(posedge clk)
ff_a <= in;

always @(posedge ckff)
out <= ff_a;

endmodule


Констрейны:
Код
BLOCK RESETPATHS;
BLOCK ASYNCPATHS;

FREQUENCY PORT clk 125 MHZ;


Синплифаю запретил clock conversion, иначе он, шибко умный, убьет второй клок и преобразует в работу с сигналом разрешения.
Смотрим лог синтеза:
CODE

#### START OF CLOCK OPTIMIZATION REPORT #####[

Clock optimization not enabled
1 non-gated/non-generated clock tree(s) driving 2 clock pin(s) of sequential element(s)
1 gated/generated clock tree(s) driving 1 clock pin(s) of sequential element(s)
0 instances converted, 1 sequential instance remains driven by gated/generated clocks

=========================== Non-Gated/Non-Generated Clocks ============================
Clock Tree ID Driving Element Drive Element Type Fanout Sample Instance
---------------------------------------------------------------------------------------
@K:CKID0002 clk port 2 ckff
================================================================================
=======
==================================================== Gated/Generated Clocks ====================================================
Clock Tree ID Driving Element Drive Element Type Fanout Sample Instance Explanation
--------------------------------------------------------------------------------------------------------------------------------
@K:CKID0001 ckff FD1S3AX 1 out_0io FF-derived clock conversion disabled
================================================================================
================================================


##### END OF CLOCK OPTIMIZATION REPORT ######]


Ага, он увидел генерацию клока триггером. Дальше PAR:

Код
WARNING - par: The following clock signals will be routed by using generic routing resource and may suffer from excessive delay and/or skew.
   Signal=clk_c loads=2 clock_loads=2
   Signal=ckff loads=2 clock_loads=1

Ну, логично. Чтобы ОНО его автозапихала в глобальное клокодерево, 1-2 load-ов это крайне мало. Надо 10-15 хотя бы. Но, уверяю, если будет достаточно разветвлений, оно его заведет в глобальное дерево.

Дальше. Самое главное!!!!

Код
Hold time optimization iteration 0:
There are 1 hold time violations, the optimization is running ...
End of iteration 0
8 successful; 0 unrouted;  real time: 10 secs

Hold time optimization iteration 1:
All hold time violations have been successfully corrected in speed grade M

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

Ну и, наконец, САМОЕ ГЛАВНОЕ, STA:
CODE

Passed: The following path meets requirements by 7.178ns

Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-)

Source: FF Q ff_a_0io (from clk_c +)
Destination: FF Data in out_0io (to ckff +)

Delay: 1.929ns (20.3% logic, 79.7% route), 1 logic levels.

Constraint Details:

1.929ns physical path delay in_MGIOL to out_MGIOL meets
8.000ns delay constraint less
-1.217ns skew and
0.110ns ONEG0_SET requirement (totaling 9.107ns) by 7.178ns

IOL_B7A attributes: FINE=FDEL0

Physical Path Details:

Data path in_MGIOL to out_MGIOL:

Name Fanout Delay (ns) Site Resource
C2OUT_DEL --- 0.391 IOL_B8A.CLK to IOL_B8A.INFF in_MGIOL (from clk_c)
ROUTE 1 1.538 IOL_B8A.INFF to IOL_B7A.ONEG0 ff_a (to ckff)
--------
1.929 (20.3% logic, 79.7% route), 1 logic levels.

Clock Skew Details:

Source Clock Path clk to in_MGIOL:

Name Fanout Delay (ns) Site Resource
PADI_DEL --- 1.063 36.PAD to 36.PADDI clk
ROUTE 2 1.653 36.PADDI to IOL_B8A.CLK clk_c
--------
2.716 (39.1% logic, 60.9% route), 1 logic levels.

Destination Clock Path clk to out_MGIOL:

Name Fanout Delay (ns) Site Resource
PADI_DEL --- 1.063 36.PAD to 36.PADDI clk
ROUTE 2 1.038 36.PADDI to R25C2C.CLK clk_c
REG_DEL --- 0.404 R25C2C.CLK to R25C2C.Q0 SLICE_0
ROUTE 2 1.428 R25C2C.Q0 to IOL_B7A.CLK ckff
--------
3.933 (37.3% logic, 62.7% route), 2 logic levels.

Report: 823.723MHz is the maximum frequency for this preference.


ВНИМАТЕЛЬНО смотрим Source Clock Path clk to in_MGIOL и Destination Clock Path clk to out_MGIOL !!!!
Первый идет от пада clk через разводку, и все.
Второй - тоже от пада clk, через разводку, регистр (REG_DEL), и опять разводку (ckff).

Короче, усё у полном у порядке!
Torpeda
Цитата(SM @ Dec 12 2014, 19:48) *
PADI_DEL --- 1.063 36.PAD to 36.PADDI clk
ROUTE 2 1.038 36.PADDI to R25C2C.CLK clk_c
REG_DEL --- 0.404 R25C2C.CLK to R25C2C.Q0 SLICE_0

Короче, усё у полном у порядке!

Похоже.... А SDC ваша тулза не пишет?

---
У квартуса таки не впорядке....
generated_clock с выхода делителя начинает отсчёт с НУЛЕВОЙ source_latency, если он create_clock
Тайминги считает как будто оба на одной частоте.

Если задать как положено - create_generated_clock, то в репорте generated_clock тоже с выхода делителя начинает отсчёт но с НЕНУЛЕВОЙ source_latency
Ну и тайминги считает как один быстрый а второй медленее.

---
Автоматическое распознавание чегото + констрейны по умолчанию = ЗЛО

SM
Цитата(Torpeda @ Dec 12 2014, 20:25) *
Похоже.... А SDC ваша тулза не пишет?

А хрен ее знает... Вроде, нет. И не моя она, а латисовская. Она наоборот может, взять SDC-констрейны (и то, немного своеобразные, это ж synplify), и экспортировать их в виде для PAR. Но я обычно и SDC-констрейны синтезатору, и констрейны для PAR, пишу сам, я не пользовался этой возможностью. В данном случае синтезатору вообще констрейнов никаких не дал, а для PAR задал входной клок только.

Что касается частоты этого generated clock, то да, конечно, если не писать на него констрейн, он будет считаться как клок той же частоты, какая его и генерировала. Но нам-то важна коррекция холдов на перекрестке доменов, то есть анализ задержки между source и destination clock. От частоты это не зависит. Если надо указать другую частоту, то надо писать констрейн руками. Я об этом, кстати, сразу сказал. И еще, добавлю - это ведь пришлось запрещать синтезатору clock conversion - а совсем-совсем по умолчанию он бы синтезировал бы систему с одним клоком и разрешением от ckff.


Вдогонку. К тому, что тулза все правильно поняла. Еще вырезка из отчета STA:

Код
Clock Domains Analysis
------------------------

Found 2 clocks:

Clock Domain: clk_c   Source: clk.PAD   Loads: 2
   Covered under: FREQUENCY PORT "clk" 125.000000 MHz;

Clock Domain: ckff   Source: SLICE_0.Q0   Loads: 2
   No transfer within this clock domain is found

   Data transfers from:
   Clock Domain: clk_c   Source: clk.PAD
      Covered under: FREQUENCY PORT "clk" 125.000000 MHz;   Transfers: 1


PS
К хорошему быстро привыкаешь. Я всегда считал квартус самым продвинутым тулом. А оказывается, не во всем.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.