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

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

ps
Cyclone III

Сообщение отредактировал ig_f - Dec 10 2014, 13:47

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

Нет, нельзя.
Можно обойтись лишь в том случае, если, к примеру, частоты сформированы одним DCM и используют одинаковые буферы - т.е. находятся жёстко в фазе.
В вашем же случае получаются фактически независимые домены.
И всё же я не понимаю в чём проблема поставить по лишнему триггеру, ведь управляющий сигнал относительно медленный и, скорее всего, не так уж важна погрешность в 1 такт быстрой частоты..

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

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

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

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

UPD2:
И еще, очень внимательно!!! Эти клоки ни в коем разе не должны объявляться независимыми или асинхронными (желательно, они должны быть в одной клоковой группе). Иначе PAR не будет анализировать междоменные пути и править там холды на них.

честно, я бы делал автомат на основной частоте 120 МГц, который выдавал управляющие сигналы на частоте 400 кГц

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

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


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

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

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

И как тут прилепить цитирование со ссылкой на автора, а не просто "Цитата"?

Сообщение отредактировал ig_f - Dec 10 2014, 21:40

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

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

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

А вообще мне казалось, что gated clok это когда сигнал тактовой смешивается с некоторыми управляющими сигналами через комбинационную логику. В моем случае я формирую сигнал довольно низкой частоты с помощью восьмиразрядного счетчика и компаратора который формирует сигнал разрешения для T-триггера, на тактовый вход которого подается 120 МГц. То есть моменты переключения вполне детерминированы и связаны с основной тактовой. Далее выход триггера заводится на Clock Control Block и поступает на GCLK. В описании Clock Control Block такая схема тактирования подразумевается. Мне она видется вполне безопасной на частоте 400 КГц, разве нет?. Ни в коем разе не спорю, что предложенное вами решении выглядит лучше и порождает меньше проблем, как для меня, так и для САПРа. Просто хочу узнать возможно ли в принципе использовать такое тактирование?

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

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


Кнопкой "reply" отвечать, которая под сообщением, на которое ответ пишете.

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

Может, но не станет. Если задержка между клоками такова, что PAR не может свести концы с концами, то просто-напросто следует сделать "прокладку" в одном из доменов из триггеров, работающих по противоположному фронту, что обеспечит в таком случае выполнение времянок.

Работа по заднему фронту сразу в 2 раза уменьшает timing budget - поэтому борясь с одной проблемой можно наступить на другую.

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