scorp 0 23 мая, 2015 Опубликовано 23 мая, 2015 · Жалоба Приветствую! Вопрос знатокам. Помогите правильно задать 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 23 мая, 2015 Опубликовано 23 мая, 2015 · Жалоба Не знаю как там у вас в асиках, а в плисине нужно делить не триггерами, а клок-буферами, и законстрейнить достаточно входной клок. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scorp 0 24 мая, 2015 Опубликовано 24 мая, 2015 · Жалоба в плисине нужно делить не триггерами, а клок-буферами Вопрос, озвученный выше, возник как раз в процессе перевода чужого проекта из ПЛИС в ASIC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
krux 8 24 мая, 2015 Опубликовано 24 мая, 2015 · Жалоба а там дальше в проекте переходы между этими 50 - 25 -12.5 производятся в каких условиях? если используется same edge, в расчете на деленный клок, - то это одно, если все развязано нормальными CDC-переходами - то другое. в ASIC-е все это будет сильно на клоковые деревья влиять. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scorp 0 24 мая, 2015 Опубликовано 24 мая, 2015 · Жалоба а там дальше в проекте переходы между этими 50 - 25 -12.5 производятся в каких условиях? если используется same edge, в расчете на деленный клок, - то это одно, если все развязано нормальными CDC-переходами - то другое. в ASIC-е все это будет сильно на клоковые деревья влиять. Дальше переходы между доменами производятся по rising edge. CDC-переходов нет, да и ни к чему они вроде бы при таком способе формирования клоков – источник клока один, сами клоки синхронные, задержка на триггерах при формировании 25 МГц и 12.5 МГц должна учитываться при STA, надо только правильно законстрейнить generated клоки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sleep 0 25 мая, 2015 Опубликовано 25 мая, 2015 · Жалоба Я бы задал так: # 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 18 июля, 2015 Опубликовано 18 июля, 2015 · Жалоба Давно не заходил, а потому отвечу немного позже. Если коротко, то делить так клоки принципиально нельзя. Ни в ASIC, ни в FPGA. Эта система сильно подвержена нарушению холдов при переходе из одного клокового домена в другой. Можно, конечно, попытаться скомпенсировать холды путем удлиннения ассинхронных путей между триггерами (IC Compiler, к примеру, начинает на такие пути гадить инверторами), но работать это будет только в сравнительно узких диапазонах изменения температур и напряжений и, обычно, только в симметричных корнерах. Хорошим признаком такого рода ошибок является финальный репорт тулзы. Если количество инверторов или буферов в дизайне неоправданно большое, то где-то есть проблемы с клоком. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 18 июля, 2015 Опубликовано 18 июля, 2015 · Жалоба Откуда переходы между доменами? С такими констрейнтами строится общее клоковое дерево, т.е. клоки синхронные, а домен общий. Я бы выбрал деление на 4, так правильнее, мне кажется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 3 18 июля, 2015 Опубликовано 18 июля, 2015 · Жалоба Схема формирования кратных сигналов тактовой частоты делается с помощью ячеек 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 19 июля, 2015 Опубликовано 19 июля, 2015 · Жалоба Сделал ма-а-а-ленький эксперимент в качестве тренировки. Взял свой кастомный 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 19 июля, 2015 Опубликовано 19 июля, 2015 · Жалоба Вариант из первого поста автоматически увеличивает высоту клокового дерева на две арки C-Q триггеров. Вариант с использованием клокгейтов чуть лучше, покольку арки у них имеют меньшую задержку, чем C-Q триггера. Но в масштабах большого поректа, разница по clock_latency может оказаться несущественной. А проблем с кривой скважностью может оказаться больше. В общем, на вкус и цвет. Категорично чему то отдавать За и Против нельзя, мне кажется - все зависит от задачи. Конечно, самое лучше решение - PLL, все остальное будет иметь влияние на latency. Вариант с асинхронными доменами вообще отличный, но автора он скорее всего не устроит :-) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 3 20 июля, 2015 Опубликовано 20 июля, 2015 · Жалоба Проблемы, как мне кажется, могут возникуть на каких-то околопредельных случаях: околопредельные частоты вместе с околопредельными нагрузками на ветки дерева. Автор верхнего поста пока далек от вступления на эту зыбкую почву, судя по характеру его вопросов. latency в схеме со счетчиком и clkg легко подровнять, принудительно поставив буфер или всегда разрешенную ячейку clkg на тактовый сигнал основной частоты, поступающий на часть схемы за пределами модуля генерации сетки частот. Эта ячейка и так там будет, чтобы развязаться с ограничениями между асинхронным reset и clk. У меня в широком спектре приложений со скважностью проблем не наблюдалось, но это та сфера, где у каждого свой опыт. А проблем с кривой скважностью может оказаться больше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 20 июля, 2015 Опубликовано 20 июля, 2015 · Жалоба У меня в широком спектре приложений со скважностью проблем не наблюдалось, но это та сфера, где у каждого свой опыт. Я имел ввиду частный случай использования триггеров с тактированием по фронту и срезу, и пути между ними. Если скважность импульса 25/75, то и перекрестные пути сигналов тоже режутся как 25/75, вместо стандартных 50/50. И если частота на пределе, короткие пути в четверть периода могут стать узким местом, и лучше использовать традиционную схему, как у автора топика. Использование обоих фронтов одного клока встречается часто, к примеру - в JTAG. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 3 20 июля, 2015 Опубликовано 20 июля, 2015 · Жалоба Я ж описал, как делается тактирование по обоим фронтам для производной частоты: например для 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 21 июля, 2015 Опубликовано 21 июля, 2015 · Жалоба Я ж описал, как делается тактирование по обоим фронтам для производной частоты: Сразу не понял, прошу прощения. Решение не универсальное, поскольку тактовые сигналы необходимо разделять на прямой и инверсный в виде разных проводов - на уровне RTL. В иерархическом дизайне и использовании готовых IP блоков такое решение может быть вообще недоступно. Можно конечно писать RTL с использованием Enable на каждом четвертом (и через два) такте у флопов, а потом пытаться вставлять c-gate автоматически, скажем - в DC. Но это может выйти боком в LEC, да и вообще не совсем корректно, покольку меняет синтезируемый дизайн, вставляя c-gates. Если ПЛИСовые САПР разруливают подобные места автоматически - апплодирую стоя. Но в эсике это будет выглядеть кривовато imho. Но, делают так делают, что ж Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться