Доброго времени суток!

Есть проект. В нем стоит PLL, которая выдает 3 целочисленно кратных частоты. В проекте есть
1. Модули которые работают с учетом этой кратности. Для корректного временного анализа эти 3 клока помещены в одну эксклюзивную группу.
2. Модуль который работает с клоком, мультиплексированным из этих трех. Ему для корректного анализа надо что бы эти 3 клока были помещены в разные эксклюзивные группы. Вот в нем валяться констрейны на группу. Т.е. идет анализ пар клоков, передача между которыми, в этом модуле, физически невозможна.

Соображаю плохо. Как констрейнят такие проекты? Прописывают set_false_path от клока на клок с указанием through всех цепей модуля работающего на мультиплексированном клоке ? или непосредственно цепей мультеплексированных данных?

Спасибо.

имхо.
модуль 2) придется развязать нормальным CDC от модулей 1).
после чего модуль 2) констрейнят на три используемых частоты, и плюс set false path между 1) и 2).

а иначе, какие констрейны могут вас спасти? ведь с точки зрения бэкенда моменты переключения мультиплексора частот для 2) - тоже принимаются в расчет.

Вот как раз этого и хотелось бы избежать. Модуль 2 это что-то вроде самодельного сигнал-тапа, со специализированным PC софтом. На входе у него буфер памяти и логика записи. Городить на пустом месте 3 буфера ИМХО может и правильно, но расточительно по ресурсам. Мультиплексор на лютах + немного логики решают проблему. Там это реально весит где то 40 плиток.


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

Я бы сделал так:
1. если есть мультиплексор, значит надо обьявлять generated_clock.
2. Мастером при обьявлении должен быть клок с максимальной частотой.
3. Обьявленный клок синхронен первым трем (одна группа).

Только вот не очень понятно, как ПЛИС учтет этот мультиплексор при построении дерева. Дерево ведь прибито гвоздями, его нельзя изменить. Может быть, есть какойто ресурс в ПЛИС для мультиплексирования клоков - изучите мануал.

p.s. можно обьявить flase_path через мультиплексор от оставшихся двух более медленных клоков. Но я думаю, что САПР и не будет считать через этот мультиплексор все клоки, эта опция по умолчанию всегда отключена. А вот фалзпасить пути сигналов между доменами нельзя - клоки то синхронные. Точнее можно и фалзпасить как вы предложили, но результат никто гарантировать не будет

Хмм, вот насколько помню, генерированный клок на комбинационную логику посадить нельзя (в свое время пытался). Попробую.

Вот как раз clkctrl тут не нужен, он потратит 2-4 нс тащить до него, потом 2-4 нс с него и все ради 50 плиток. Лучше сделать на лютах, благо такая возможность есть.

clkctrl к тому же имеет ограничение на количество входов с внутренних ресурсов. последний раз когда я пытался завести на сыклоне-4 три клока с одной PLL на clkctrl - ничего не вышло, получилось завести максимум два.

сработало. вырезало левые пути из анализа. проверил по нетлисту

Хорошо, что таких путей нет. Потому что если окажется что есть, случится беда.

К примеру, если модуль2 работает на частоте 250, и из него выходят данные в модуль1 на триггера по клоку 125. В этом случае можно получить нарушения, поскольку вы этот путь зафалзпасили. Или если в модуль2 (250) заходит сигнал из домена 125 -этот путь тоже не контролируется. С учетом наличия мультиплексора клоков, могу сказать что вы почти наверняка что то полезное выкинули этими фалзпасами.

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

Путей именно через эти цепи, для таких клоков нет.

Судя по отчетам TQ, всего в проекте было ~7400 таких путей, констрейном я вырезал ~2500. так что полезное осталось, а вот физически невозможное удалено.

Я честно говоря не понимаю, зачем объявлять руками то, что выходит из PLL. У меня derive_pll_clocks работает прекрасно, в том числе и после мультиплексора: он в таком случае считает, что за мультиплексором максимальная частота из возможных.

Имена клоков непривычны после derive_pll_clocks. При анализе приходится искать какой клок на каком выходе...

можете выполнить команду Report Clock Transfers проекта с таким мультиплексором и сделать скрин? не верю что TQ дошел до таких высот.

ЗЫ. Правильно я понимаю, мультиплексирование на выходе PLL, не на входе?