Jump to content

    
Sign in to follow this  
scorp

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

Recommended Posts

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

Вопрос знатокам. Помогите правильно задать 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]

 

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

 

7113890.jpg

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
в плисине нужно делить не триггерами, а клок-буферами

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites
а там дальше в проекте переходы между этими 50 - 25 -12.5 производятся в каких условиях?

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

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

 

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

Share this post


Link to post
Share on other sites

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

# 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.

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
Я ж описал, как делается тактирование по обоим фронтам для производной частоты:

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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this