Помогите правильно задать constraint

[scorp 0]

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

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

 

create_generated_clock -name i_clk_12_5MHz \
    -source [get_ports clk] \
    -divide_by 4 \
    [get_pins clk_12_5_reg/q]

 

либо

 

create_generated_clock -name i_clk_12_5MHz \
    -source [get_pins clk_25_reg/q] \
    -divide_by 2 \
    [get_pins clk_12_5_reg/q]

 

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

 

[Dr.Alex 0]

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

[scorp 0]

в плисине нужно делить не триггерами, а клок-буферами

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

[krux 0]

а там дальше в проекте переходы между этими 50 - 25 -12.5 производятся в каких условиях?

если используется same edge, в расчете на деленный клок, - то это одно, если все развязано нормальными CDC-переходами - то другое.

в ASIC-е все это будет сильно на клоковые деревья влиять.

[scorp 0]

а там дальше в проекте переходы между этими 50 - 25 -12.5 производятся в каких условиях?

если используется same edge, в расчете на деленный клок, - то это одно, если все развязано нормальными CDC-переходами - то другое.

в ASIC-е все это будет сильно на клоковые деревья влиять.

 

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

[sleep 0]

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

# main source clock
# define clock period here
create_clock -name i_clk_50MHz \
    [get_ports clk] \
    -period 20

# first div 2 clock
create_generated_clock -name i_clk_25MHz \
    -source [get_ports clk] \
    -divide_by 2 \
    [get_pins clk_25_reg/q]

# second div 2 clock
create_generated_clock -name i_clk_12_5MHz \
    -source [get_ports clk_25_reg/q] \
    -divide_by 2 \
    [get_pins clk_12_5_reg/q]

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

Т.е. второй вариант.

[v_mirgorodsky 0]

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

 

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

 

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

[Shivers 0]

Откуда переходы между доменами?

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

[FatRobot 0]

Схема формирования кратных сигналов тактовой частоты делается с помощью ячеек 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 для разных целевых технологий переделывается полностью.

[v_mirgorodsky 0]

Сделал ма-а-а-ленький эксперимент в качестве тренировки. Взял свой кастомный 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 не в силах обойти физику процессов в кремнии.

[Shivers 0]

Вариант из первого поста автоматически увеличивает высоту клокового дерева на две арки C-Q триггеров. Вариант с использованием клокгейтов чуть лучше, покольку арки у них имеют меньшую задержку, чем C-Q триггера.

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

 

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

[FatRobot 0]

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

 

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

 

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

 

А проблем с кривой скважностью может оказаться больше.

[Shivers 0]

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

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

[FatRobot 0]

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

 

например для 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 тактовых дерева.

 

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

 

Я имел ввиду частный случай использования триггеров с тактированием по фронту и срезу..

[Shivers 0]

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

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

 

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