Перейти к содержанию
    

Useful Skew без буферов задержки в линии синхронизации

Коллеги, доброго времени суток!

Предлагаю метод "Extended Useful Skew" - Useful Skew без буферов задержки в линии синхронизации. Искажения формируются только заданием правил (constreints). То есть для задержки определенного регистра во времени, создавать ему отдельный тактовый сигнал (create_generated_clock), на той же линии тактирования. А так как, для движка STA, в данном случае, будет присутствовать два тактовых сигнала, то останавливать командой "set_clock_sense -stop_propagation" на требуемых регистрах. После чего, задать взаимоотношения между этими "новыми" тактовыми сигналами через "set_clock_latency" самих клоков или  через "set_multicycle_path" между этими тактовыми сигналами.

Также для увелечения шагов сдвига использовать возможность регистра работать на инверсном клоке (если регистр так умеет, или имеется аналог в библиотеке и инверсным входом по клоку).

В итоге получится, что мы имеем возможность с шагом в 180° сдвигать регистры и в "прошлое" и в "будущее", на неограниченную величину, без использования буферов задержки, без использования дополнительных тактовых линий. При желании можно и комбинировать с оригинальным методом, и получить еще и тонкую подстройку к смещению.

Интересно, но  метод становиться более применим к FPGA

В рамках эксперимента подготовил репозиторий с примером искажённого древа, и примером скрипта для автоматического фикса временных нарушений с помощью этого метода: https://github.com/GentleFly/tardil

Очень интересно узнать мнение коллег. Может кто уже делал, что-то подобное? Мне не удалось найти в интернетах ничего подобного. Планирую публичное выступление по этой теме (30 ноября 2024), когда будет доступна видео запись приложу ссылку здесь, если модераторы позволят.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Извините, но из описания я так и не понял, как в "в кремнии" ASICа будет реализована задержка синхросигнала до конкретного триггера?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, oratie сказал:

Извините, но из описания я так и не понял, как в "в кремнии" ASICа будет реализована задержка синхросигнала до конкретного триггера?

Допустим нам надо "подвинуть" один регистр. Для него есть тактовый сигнал описанный как:

create_clock -name sclk -period 5.000 [get_ports clock]

Создаем дополнительный тактовый сигнал:

# Оригиналный сигнал с нулевым смещением
create_generated_clock -name sclk_p0000 \
    -divide_by 1 -add \
    -master [get_clocks sclk] \
    -source [get_pins clocks_inst/BUFG_inst0/I] \
    [get_pins clocks_inst/BUFG_inst0/O] 

# Новый тактовый сигнал со смещением фазы -180, на той же тактовой линии
create_generated_clock -name sclk_n0180 \
    -divide_by 1 -add -invert \
    -master [get_clocks sclk] \
    -source [get_pins clocks_inst/BUFG_inst0/I] \
    [get_pins clocks_inst/BUFG_inst0/O] 

Задаем новому тактовому сигналу требуемое смещение (с шагом равному периоду или полупериоду если есть регистры с инверсным входом по clk):

set_clock_latency -clock sclk_n0180 \
    -source \
    -2.5 \
    [get_pins clocks_inst/BUFG_inst0/O]

Далее, обходим все регистры и указываем движку STA, по какому клоку надо считать каждый регистр подключенный к одной и той же тактовой линии (у нас же уже объявлено два тактовых сигнала на одной линии):

# Сообщаем движку STA, что целевой регистр надо считать только по новому клоку. А старый игнорировать
set_clock_sense \
    -stop_propagation -quiet \
    -clocks { sclk_p0000 } \
    { path_to_target_register/C }

# Для всех остальных регистров, движку STA, сообщаем что бы не пытался обсчитывать по новому клоку 
set_clock_sense \
    -stop_propagation -quiet \
    -clocks { sclk_n0180 } \
    { another_register0/C another_register1/C another_register2/C }

Не забыв заменить регистр "path_to_target_register/C" на аналог с инверсным входом.

Таким образом,  мы определили правила по которым и будет вестись обсчет времянок.

А задержки синхросигнала, как таковой не будет, будет обсчет постоен таким образом, что бы удовлетворить заданным правилам. Будет "аля multicycle" или "логическая задержка"

Здесь важно заметить, что работа идёт только по фронтам (отрицательный, если есть регистр с инверсным входом по clk, или положительный). Откуда возможные создаваемые задержки кратны 0.5 периода (в случае использования только одной тактовой линии).

Изменено пользователем GentleFly

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В синтезе дерево клока не строится, методика такая. Дерево строится в P&R, да и то не по констрейнтам, а по спецификации, которая к констрейнтам отношения может вообще не иметь.
Так, где вы хотите все это использовать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, Yaahoo сказал:

В синтезе дерево клока не строится, методика такая. Дерево строится в P&R, да и то не по констрейнтам, а по спецификации, которая к констрейнтам отношения может вообще не иметь.
Так, где вы хотите все это использовать?

Такие констрейны (те что я предлагаю ) приведут к тому что будет изменения в имплементации "datapath", и обсчитываються будут очень похожем образом на "multicycle". Вся задумка в том что изменений в тактовую линию не вносим. Может я не понял , но как это противоречит тому что я предлагаю?

Использовать? Вы спрашиваете на каких этапах, или на fpga и asic, или в каких проектах и условиях? Прошу уточнить.

 

UPD: подозреваю что ворос "где использовать?" Был именно про S, P&R. Основной сценарий использования считаю следующим: После синтеза схемы, запускаем скрипт (в репо есть для FPGA) который генерирует требуемые новые констрейны, после чего заходим на имплементацию с этими дополнительными констрейнами.

То есть ни что не мешает оригинальному методу Useful Skew что то добавить в линии тактирования. Но здесь надо рассматривать ближе , не возникнет ли конфликтных мест.

Изменено пользователем GentleFly

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Современный синтез умеет делать виртуальный useful_skew (у Synopsys это называется CCD concurrent_clock_data opt)  и передавать полученные set_clock_latency (для конкретных регистров) далее по маршруту до CTS).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В генусе кеденс, я предполагаю (синтезом давно не занимаюсь), есть то же самое, поскольку генус запускает плейсер инновуса, который эти самые юзефул скью умеет генерить.

Вот только я очень давно не слышал чтобы кто то эти опции использовал.

 

Скажем так, это что то вроде холивара, когда фронтенд спихивает кривой дизайн бэкенду, говоря - юзефул скью все вытащит, а бэкенд отбивается тряпками, обьясняя что эти костыли (юзефул скью) лучше не использовать по целому ряду причин. Холивар заканчивается, когда приходит менеджмент и (делает свою работу) сдвигает все риски в начало проекта, т.е. заставляет фронтенд переписать код. А юзефул скью остается аварийной опцией "на самый крайний случай". У себя в проектах (p&r) я не включал юзефул скью уже лет наверное 5-8. Пробовал, разумеется, в режиме отладки дерева, но к тейпауты всегда шли настройки без скью.

 

Итого, полезность предлагаемого метода оценить не могу 1) т.к. синтезаторы (2 основных) и так умеют скьюить клок 2) на мой взгляд, в эсик это вообще не нужно

 

Ну а плисы - это лучше в соседний раздел форума писать, там другие задачи, другой подход. Для кежуал DIY разработчиков, которые оптимизацией кода не заморачиваются, эти юзефул скью фичи должны быть очень интересны. Тут как бы но оффенс, это рынок, задачи разные, потребители разные, все все понимают. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 30.11.2024 в 09:38, oratie сказал:

Современный синтез умеет делать виртуальный useful_skew (у Synopsys это называется CCD concurrent_clock_data opt)  и передавать полученные set_clock_latency (для конкретных регистров) далее по маршруту до CTS).

CCD, очень похоже на то что мне нужно. Я это как то упустил из виду. Большое спасибо! Буду разглядывать. Беглый поиск по интернету не дал особой информации. Интересно как выглядит set_clock_latency для отдельного регистра.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Просто выглядит:

set_clock_latency 0.1 [get_pins ff_reg/clk]

Где 0.1 это сдвижка относительно средней длины дерева, а ff_reg/clk - клоковский пин конкретного регистра.

А где почитать - например здесь https://semiwiki.com/eda/synopsys/280362-useful-skew-in-production-flows/

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 30.11.2024 в 11:06, Yaahoo сказал:

это что то вроде холивара,

Согласен, подобные подходы это скорее "Последней надежды". И в случае, когда есть возможность поправить HDL, надо править HDL! Однако, правка HDL не всегда допустима. А если у вас купленный IP ? Правка в этом случае приведет к потере всей верификации и обоснованности тото что этот блок вообще готов к имплементации. А если IP готовился из расчета одного тех процесса, а в проекте пришлось сделать шаг назад ?

В 30.11.2024 в 11:06, Yaahoo сказал:

синтезаторы (2 основных) и так умеют скьюить клок

Здесь есть вероятность не все ими пользуются, а пользуются теми в которых нет этих опций, или просто старой версией 🙂 

В 30.11.2024 в 11:06, Yaahoo сказал:

Для кежуал DIY разработчиков, которые оптимизацией кода не заморачиваются, эти юзефул скью фичи должны быть очень интересны.

FPGA прототипирование - основная идея имплементировать без изменений. Так что, не только ради интереса.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Дополню
1. В PNR дерево строится на основе спецификации. В спецификации можно прямо задать что и куда и на сколько скьюить. Если говорить о фазе плейса, то там (при включении) юзефул_скью вырабатывают автоматом. Итого, нет необходимости в дополнительных констрейнтах

2. В синтезе. Это соврешенно нормально, когда мне деливерят нетлист с отрицательным слэком. Не сильно отрицательным. Тул все вытянет, хотя бы потому что в синтезе специально выключены ULVT (низкопороговые селлы)

3. Есть (в природе) задачи, где действительно надо сильно скьюить клок.

Скажем, в биткоин майнере, где конвейер это пайплайн без обратных связей, т.е. чистый пайплайн. Как написали выше, можно использовать set_clock_latency для каждой стадии конвейера. Но гораздо проще просто синтезнуть пайплайн на одну частоту, а в PnR указать другую, выше. Так и делают.

Другой пример - пустой пайплайн для соединения ядер в больших СнК. Там синтез и так нормально работает, поскольку логики между флопами нет, и скьюинг производится только в PnR.

Кстати, если в конвейере направить клок противоположно данным, то холд будет всегда в плюсе, хотя марджин по сетапу окажется чуть меньше периода (обратный эффект). Лет 40-50 назад STA не было, поэтому так чипы и проектировали - клок скьюили не вперед, а назад. И это работало. Всякие 8080, r3000 так проектировали.


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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 02.12.2024 в 21:47, oratie сказал:

...

А где почитать - например здесь https://semiwiki.com/eda/synopsys/280362-useful-skew-in-production-flows/

Спасибо!
Видимо, в CCD сама задержка в результате все равно обеспечивается через элементы задержки (после того как отработает CTS). Особенно, учитывая что описано о Dynamic Power Shaping. Там сглаживаются пики потребления, что можно обеспечить только большим количеством разных, маленьких сдвигов фаз.

Я же предлагаю обеспечивать задержку сменой рабочего фронта (реальная задержка в тактовой линии отсутствует). И предложенный мною метод не будет настолько эффективен в плане сглаживания пиков потребления, хотя и окажет влияние (пиков станет в два раза больше, и старые пики будут немного меньше оригинальных)

Делаю вывод что CCD отличается от того,  что я предлагаю. То есть пока похожий, существующий метод в ASIC пока не вижу 🙂

 

 

 

21 час назад, Yaahoo сказал:

1. В PNR дерево строится на основе спецификации. В спецификации можно прямо задать что и куда и на сколько скьюить. Если говорить о фазе плейса, то там (при включении) юзефул_скью вырабатывают автоматом. Итого, нет необходимости в дополнительных констрейнтах

2. В синтезе. Это соврешенно нормально, когда мне деливерят нетлист с отрицательным слэком. Не сильно отрицательным. Тул все вытянет, хотя бы потому что в синтезе специально выключены ULVT (низкопороговые селлы)

Мне интересно, насколько "не сильно отрицательными" ? Может обеспечить решение для нарушения соразмерного целевому периоду ? Я предлагаю то, что даст шанс на решение нарушения соразмерного периода, без правки HDL. А может и больших, будет зависеть от "характеристик библиотеки" и конкретного дизайна.

21 час назад, Yaahoo сказал:

3. Есть (в природе) задачи, где действительно надо сильно скьюить клок.

Согласен и замечу, что на pipe образных дизайнах, предлагаемый метод, более применим. И я же не перелагаю менять устоявшиеся flow. Я предлагаю возможное решение для исключительных случаев.

21 час назад, Yaahoo сказал:

...клок скьюили не вперед, а назад...

Я предлагаю и назад и вперед, без разворачивания данных или клока

21 час назад, Yaahoo сказал:

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

Часто ваши менеджеры, не работая в Synopsys, заставляют поправить Synopsys те IP которые они продали вам ? 🙂

Изменено пользователем GentleFly

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не сильно отрицательными, это в переделах 5-10% от периода.

 

Касаемо, соскьюить клок на величину периода  и айпи синопсиса  ..  слишком уж очень много логики хотите добавить, аж на целую стадию, это перебор. Надо думать об углублении конвейра на 1+ стадию. Просто так соскьюить кусок конвейера, да еще и на такую величину - а вы о холде думали? Одну стадию вы опустите вниз, а что потом со следующей делать? В синтезе ведь холд не виден, это обычно вылезает в PnR на реальном дереве. Есть конечно решение для бесконечного скьюинга стадий - сделать выход конвейера асинхронным, что сьест все набежавшее летенси. Но cdc вносит пару-тройку тактов задержки, да и вставить такое в чужое айпи тоже надо уметь. В общем, возникает много вопросов по вашей задаче, выглядит как - хотите странного. Вам виднее, конечно

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

8 минут назад, Yaahoo сказал:

величину периода  и айпи синопсиса  ..  слишком уж очень

🙂 Согласен, в данном случае мог перегнуть ... Или нет ? 😁
Это предложение не на ровном месте возникло... Хотя и допускаю, что не могу донести всех условий на которых возникла потребность  ...

10 минут назад, Yaahoo сказал:

Одну стадию вы опустите вниз, а что потом со следующей делать?

Значит надо найти две, те стадии на которых есть "лишние пол стадии". Сам сдвиг в период можно обеспечить сдвигом startpoint в прошлое на -180° и endpoint на +180°, если соседние позволят (из прошлого и будущего). Если не позволяют, то "толкать" до тех пор пока не найдется. Или можно сразу в прошлое -360° или в будущее 360°... В общем "гашение искажения" проводить по древу...

16 минут назад, Yaahoo сказал:

В синтезе ведь холд не виден

Даже hold на пол периода не будет виден, при заданном set_clock_latency ? Такие холды можно гасить тем же методом (но много решить не удастся). Плюс классические методы.

21 минуту назад, Yaahoo сказал:

В общем, возникает много вопросов по вашей задаче

Я постараюсь ответить на них. Для этого и пришел с этим предложением. Может сам увижу чего, может кто ткнет носом.

25 минут назад, Yaahoo сказал:

выглядит как - хотите странного. Вам виднее, конечно

Я прекрасно осознаю, что метод за рамками стандартных flow 🙂

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

10 hours ago, GentleFly said:

Я же предлагаю обеспечивать задержку сменой рабочего фронта (реальная задержка в тактовой линии отсутствует). И предложенный мною метод не будет настолько эффективен в плане сглаживания пиков потребления, хотя и окажет влияние (пиков станет в два раза больше, и старые пики будут немного меньше оригинальных)

Я правильно вас понял, что в кремнии разница между обычным подходом и вашим будет в том, что некоторые флопы будут работать по инверсной фазе клока? Если это так, то придется править RTL, чтобы не ругался LEC (logic equiv checker).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...