Приветствую!
Вопрос знатокам. Помогите правильно задать SDC констрейн. В проекте есть 3 клоковых домена - 50 МГц, 25 МГц и 12.5 МГц. Частоты 25 МГц и 12.5 МГц получены путём деления исходной частоты 50 МГц со входа clk с помощью триггеров (см. картинку). С констрейном для частоты 25 МГц проблем нет, обычный generated клок. А для задания клока 12.5 МГц вижу 2 варианта:



либо



Какой вариант правильнее?

Не знаю как там у вас в асиках, а в плисине нужно делить не триггерами, а клок-буферами, и законстрейнить достаточно входной клок.

Вопрос, озвученный выше, возник как раз в процессе перевода чужого проекта из ПЛИС в ASIC.

а там дальше в проекте переходы между этими 50 - 25 -12.5 производятся в каких условиях?
если используется same edge, в расчете на деленный клок, - то это одно, если все развязано нормальными CDC-переходами - то другое.
в ASIC-е все это будет сильно на клоковые деревья влиять.

Дальше переходы между доменами производятся по rising edge. CDC-переходов нет, да и ни к чему они вроде бы при таком способе формирования клоков – источник клока один, сами клоки синхронные, задержка на триггерах при формировании 25 МГц и 12.5 МГц должна учитываться при STA, надо только правильно законстрейнить generated клоки.

Я бы задал так:

в результате все триггеры делителя должны быть "обконстрейчены" и на них должен просчитываться setup+hold.
Т.е. второй вариант.

Давно не заходил, а потому отвечу немного позже.

Если коротко, то делить так клоки принципиально нельзя. Ни в ASIC, ни в FPGA. Эта система сильно подвержена нарушению холдов при переходе из одного клокового домена в другой. Можно, конечно, попытаться скомпенсировать холды путем удлиннения ассинхронных путей между триггерами (IC Compiler, к примеру, начинает на такие пути гадить инверторами), но работать это будет только в сравнительно узких диапазонах изменения температур и напряжений и, обычно, только в симметричных корнерах.

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

Откуда переходы между доменами?
С такими констрейнтами строится общее клоковое дерево, т.е. клоки синхронные, а домен общий. Я бы выбрал деление на 4, так правильнее, мне кажется.

Схема формирования кратных сигналов тактовой частоты делается с помощью ячеек clock gating, управляемых от счетчика, работающего на основной частоте. Все построено так, что clock gating с нужной скважностью пропускает на выход 1 период основной тактовой. Т.о. если для основной частоты clk скважность 50%, то для clk_div_2 скважность будет 25%, а для clk_div_4 скважность будет 12.5%.

Если часть изначальной схемы для FPGA, тактируемой производной частотой, работает по отрицательному фронту, то используется аналогичная метода: для этой части схемы все списки чувствительности меняются на posedge, и c помощью счетчика на основной частоте, управляющего ячейками clock gating, формируется свой тактовый сигнал, сдвинутый по фазе.

Ограничивается это хозяйство с помощью create_generated_clock, как вы верно отметили.

Та схема, которая приведена в вашем в исходном сообщении, - боль для sta

Вообще обычно clock and reset manager для разных целевых технологий переделывается полностью.

Сделал ма-а-а-ленький эксперимент в качестве тренировки. Взял свой кастомный DFF на UMC 28HLP, извлек из него паразиты почти без редукции, также обработал несколько "боевых" топологий своих инверторов. Прикинул клоковое дерево, в каждый клоковый домен поставил по одному DFF и соединил их в виде сдвигового регистра. Соединил все в спайсе. Тут уж извините, делать полный эксперимент в лейауте было лениво, да и результаты бы это не изменило. Как критерий успешности выбранной топологии использовалась локальная MC-симуляция со свипом в 1000 ранов.

Если на 0.6V у моих триггеров в TT Tco составляет в районе 150ps, то при 0.8V Tco уменьшается до 60ps, а при 1.0V - до 30ps. Итого - разница в TT всего по одному параметру в моем диапазоне рабочих напряжений составила 120ps, а это надо как-то компенсировать.

Как результат, систему можно сравнительно просто настроить на конкретное рабочее напряжение и локальные вариации в пределах одного корнера. Линия SS-TT-FF тербует почти 50% увеличения количества инверторов в "клоковом дереве" и пары последовательных буферов с выхода одного триггера до входа другого для фикса холдов. Расширение зоны работоспособности до SF и FS потребовало очень много усилий и до конца я его не довел. В глобальных корнерах работало, в тотальных - нет, в монте-карло ошибались 3 эксперимента в SF и 7 экспериментов в FS из 1000. Потом уменьшил рабочее напряжение с 0.8 вольт до 0.6 вольт и повторил эксперимент без изменения топологии. Как результат получил больше 1000 фейлов из 5000 ранов.

Выводы.

1. Если делить клоки простыми триггерами, то нужно позаботиться о разнице фаз между активными фронтами клоков больше, чем Tco самого медленного триггера в системе во всем PVT диапазоне. Как самый простой вариант - поиграться с инверсиями клоков триггеров делителей. Если активные эджи клоков фиксированы на границахи все переходы известны, то решение найти, думаю, можно.
2. Если выполнить (1) не получается, то домены следует считать асинхронными и делать переходы между ними на синхронизаторах.
3. Если выполнять (1) и (2) не хочется, то лучше всего использовать триггера с клок-енейблами и отказаться от деления клоков в принципе.
4. Если все (1-3) выполнить не получилось, то следует быть готовым к абсолютно безобразному количеству инверторов в проекте и неэффективному использованию площади кремния.

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

Вариант из первого поста автоматически увеличивает высоту клокового дерева на две арки C-Q триггеров. Вариант с использованием клокгейтов чуть лучше, покольку арки у них имеют меньшую задержку, чем C-Q триггера.
Но в масштабах большого поректа, разница по clock_latency может оказаться несущественной. А проблем с кривой скважностью может оказаться больше. В общем, на вкус и цвет. Категорично чему то отдавать За и Против нельзя, мне кажется - все зависит от задачи. Конечно, самое лучше решение - PLL, все остальное будет иметь влияние на latency.

Вариант с асинхронными доменами вообще отличный, но автора он скорее всего не устроит :-)

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

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

У меня в широком спектре приложений со скважностью проблем не наблюдалось, но это та сфера, где у каждого свой опыт.

Я имел ввиду частный случай использования триггеров с тактированием по фронту и срезу, и пути между ними. Если скважность импульса 25/75, то и перекрестные пути сигналов тоже режутся как 25/75, вместо стандартных 50/50. И если частота на пределе, короткие пути в четверть периода могут стать узким местом, и лучше использовать традиционную схему, как у автора топика. Использование обоих фронтов одного клока встречается часто, к примеру - в JTAG.

Я ж описал, как делается тактирование по обоим фронтам для производной частоты:

например для clk_div_2 pe и ne
clkg_control_for_clk_div_2_pe = primary_clk_div_2_ff;
clkg_control_for_clk_div_2_ne = ~primary_clk_div_2_ff;

и для clk_div_2_pe, и для clk_div_2_ne скважность 25%, но имульсы для pe и ne сдвинуты по фазе на pi. Единственная, скажем так, особенность - это 2 тактовых дерева.

Но в конечном итоге, "куда ехать" решает тот, кто за рулем. В этом вы правы

Сразу не понял, прошу прощения. Решение не универсальное, поскольку тактовые сигналы необходимо разделять на прямой и инверсный в виде разных проводов - на уровне RTL. В иерархическом дизайне и использовании готовых IP блоков такое решение может быть вообще недоступно.

Можно конечно писать RTL с использованием Enable на каждом четвертом (и через два) такте у флопов, а потом пытаться вставлять c-gate автоматически, скажем - в DC. Но это может выйти боком в LEC, да и вообще не совсем корректно, покольку меняет синтезируемый дизайн, вставляя c-gates. Если ПЛИСовые САПР разруливают подобные места автоматически - апплодирую стоя. Но в эсике это будет выглядеть кривовато imho. Но, делают так делают, что ж

1-й
Подозревая типичную ошибку синхронно дизайна, таки спрошу - а зачем делить именно клоки понадобилось?


Можно. в FPGA немного труднее тулзе. Ничё подобного.

Даже не знаю, возможно за последнее время Квартус вместе с ИСЕ серьезно добавили в интеллекте, или проект в котором возможна такая манипуляция клоками крайне далек от предела возможностей выбранного кристала. На сколько помню, при заполнении кристалла под 90% и на максимум по частоте одновременно у меня провернуть такой финт уже не получилось - проект просто перестал компилироваться на заданную частоту и сильно "распух" в размере. Теперь я уже понимаю, что тулза начинала фиксить холды в корнерах, но много лет назад ответа на тот вопрос я так и не нашел - пришлось переделать пару блоков и вставить синхронизаторы.

Неоптимально и неправильно - это разные вещи.
Да - можно делать делёные клоки, но архитектура FPGA это плохо поддерживает (ибо клоковое дерево намертво и изначально встроено без учёта таких фокусов). В ASIC - никаких проблем (никакие "холды", подобно тем что Вы нашли там не возникают).
Да - FPGA тузы нормально понимают такое описание и делают правильно STA и всё остальное, но как Вы заметили уже выжать максимум в этом случае не выходит (тулза тратит дополнительные ресурсы на то чтобы выполнить заданное требование STA в своей архитектуре, которая на делёные клоки не заточена )

И главное. Ума не приложу нафига в дизайне на FPGA делить клоки?

Самой логичной причиной деления клоков может быть часть дизайна, которая не успевает работать на основном клоке Я так думаю. Ну и перевод сколь-нибудь значительной части дизайна на более низкий клок очень положительно сказывается на потреблении. Теперь-то я уже знаю, что клоковое дерево может потреблять до 15-20% мощности и эту цифру практически нельзя уменьшить.

З.Ы. Ну и в моем случае - неоптимально, это и есть неправильно. Потому как это значит, что дизайн мог бы потреблять меньше, или работать быстрее. Потому для меня и организаций, с которыми я сотрудничал, неоптимально и неправильно - синонимы. Хотя, строго говоря, неоптимально и неправильно действительно разные вещи.

Для этого в тригерах FPGA придумано FF.CE
Ну или это CE неявно выходит из описания функции переключения тригера....
Исходя из этого только ~20% тригеров меняют состояния на текущем клоковом эдже. Т.е. 80% дизайна работает реально медленнее системного клока....

приветствую.

у меня одного не отображается картинка-аттачмент, которая была в цитируемом сообщении?

Там не было картинки, насколько я помню

видимо сам себе в голове нарисовал...

отправил ссылку на тему коллегам, а она без воображаемой картинки

1. в asic где количество триггеров от 40% . Клоковое дерево может потреблять и 40-50% динамического потребления. Особенно 65нм и ниже.
2. Не надо делать деленные клоки для снижения потребления - лучше делайте везде по максимум gated clock
3. Если клок надо снизить по частоте - делите триггером. В asiс все нормально ляжет. Клоковое дерево можно построит и through (через) триггер (или несколько триггеров)
4. Клоки лучше по максимум define все - то есть первый master - порожденные gated

Тогда все триггера сидящие на всех клоках будут
а. считаться синхронными (то есть в одном clock domain)
b. будут обсчитываться в STA