[Yaahoo 3]

Я писал о том, что обычно холд, кроме как в IO, никто в синтезе не смотрит, ведь дерево идеальное по умолчанию. А так да, конечно STA гонется и early и late, и с set_clock_latency либо вашим методом вы нарушения в холде можете получить/увидеть, надо только выписать соотвествующий репорт.

Конкретно в вашем случае, если скьюить флоп с большим логическим конусом на входе, холда можно не бояться. Ну разве что конус будет сильно не выровненным - часть путей длинная, а часть очень короткая, что вполне себе легко чинится вставкой баферов. Я же писал скорее на общий случай, чтобы не забывали что двигая сетап вы двигаете и холд. Это как бусы на нитке - где то сделаете больше, и тогда в другом месте окажется меньше. У скьюинга очень много нюансов: надо заботиться чтобы этот самый флоп не попал в малтибит во время мэппинга, надо заботиться чтобы в фанауте не было ICG или другой критичной логики, управляющей тактированием. Ну и т.д.

[GentleFly 0]

13 часов назад, oratie сказал:

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

Да. Все верно. Здесь, я исходил что не правлю HDL, а правку netlist должен допускать инструмент. Правка заключается в замене регистра, на аналогичный инверсным входом, или включение параметра "инверсии" как это позволяет Vivado(и как показано в репозитории). LEC это желательный минимум, но не уверен, что достаточный. Может GLS (gate level simulation) сможет дать уверенность, что ничто не поломано. GLS с контролем, что "смещенные" и их соседи переключались во время теста.

В данном случае стандартных инструментов нет, что влечет за собой вариации по валидации и оценки этих валидаций ....

 

 

13 часов назад, Yaahoo сказал:

чтобы не забывали что двигая сетап вы двигаете и холд

Да, это я не упустил. Спасибо! В репозитории, который дал в начале, скрипт пытается разрешить и нарушения по hold таким методом, но не очень настойчиво 🙂

13 часов назад, Yaahoo сказал:

чтобы этот самый флоп не попал в малтибит во время мэппинга

Возможно, в этом месте надо аккуратно обрабатывать руками, так как предложенный метод не запрещает двигать весь такой массив во времени. Главное в что бы в результате сдвиг фазы вернулся в 0.

13 часов назад, Yaahoo сказал:

другой критичной логики, управляющей тактированием

Здесь полностью согласен. Вероятно, работу стоит ограничить только с простейшими регистрами. Иначе, все рискует очень сильно усложнится.

13 часов назад, Yaahoo сказал:

У скьюинга очень много нюансов

Согласен, что даже тот простой пример скрипта нельзя считать автоматизированным и самостоятельным решением, все равно придется "разглядывать руками" ... Или хотя бы выбирать/искать метод валидации изменений. Может GLS (gate level simulation)  будет решением.

Edited December 4, 2024 by GentleFly

[Yaahoo 3]

Посмотрел ваше выступление на ютубе. Конечно, слэк в полтора периода звучит не просто жестко, а даже уже асбсурдно. Но, что дали, с тем и работаем, понимаю. В процессе просмотра возник вопрос: а ретайминг (retiming) вы делать не пробовали?

Если вивадо/квартус ретайминг делать не умеет, есть еще читерский метод синтезнуть RTL в диси или генусе - с ретаймингом, а потом закачатъ получившийся нетлист в вивадо, используя RTL описания селлов в качестве библиотеки. Когда то давно я генерил таким образом житаг/тап контроллер в диси, используя встроенные айпи синопсиса, потом выгружал в виде нетлиста, и патчил RTL, чтобы смакетировать это в плис. Проблем никаких, но лучше весь дизайн через диси не пропускайте, только проблемный блок. И в синтезе советую открыть минимальный базис селлов, чтобы потом большую библиотеку не писать. Я понимаю, что вы за свой метод зацепились, но ретайминг как раз для таких кейсов и был придуман.

Единственное, я не знаю как потом LEC делать, после ретайминга, не приходилось

Edited December 6, 2024 by Yaahoo

[GentleFly 0]

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

а ретайминг (retiming) вы делать не пробовали?

Vivado умеет в retiming. Заметного результата не дало, в данном случае. Я же позже увидел путь которой не позволит отработать ни retiming, ни методу предложенному мной. Он был не с таким большим нарушением, спрятался 🙂.  Это путь с нарушением, особенность которого заключалась в том что startpoint и endpoint это один и тот же регистр. В данном случае, эти методы не помогут. Retiming не поможет, так как движение регистра по "кольцу комбинационной логики" бесполезно, так как оно останется кольцом с тем же временным путем, вроде 🤔. В любом случае результата не было. То что я предлагаю, в данном случае, тоже не поможет, так как куда не сдвигай этот регистр - мы одновременно двигаем и startpoint и endpoint ... В данном, конкретном, случае у меня остается надежда только на то что мне удастся найти регистры (программные регистры доступные для программистов, по системной шине) которые я "зажму в константу", а дальше VIvado сократит используемую логику и как следствие проблемные пути... Но там работа фоне идет, медленно, посмотрим ... 🙂

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

читерский метод синтезнуть RTL в диси или генусе - с ретаймингом, а потом закачатъ получившийся нетлист в вивадо,

Звучит интересно, но в моем случае думаю не поможет, как retiming и в Vivado есть. Место сложное и для ASIC. Там в "генераторе корки", в логе, предупреждение о том что на целевой частоте, после того как закончите с разводкой, луче проконсультироваться с ними (авторами IP), перед производством. Мне даже стало интересно как так получилось что, потребовалось синтезированный нетлист затягивать в Vivado? Vivado синтаксис какой-то в корке не прожевал ? Спасибо за идею! Может как-нибудь пригодиться 🙂

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

Единственное, я не знаю как потом LEC делать, после ретайминга, не приходилось

Не уверен что он пройдет, может SEC (Sequential Equivalence Checking) будет уместнее.

 

Обещал приложить ссылку на запись публичного выступления с докладом по предложенному методу:

Намеренное искажение тактового древа для увеличения рабочей частоты дизайна

Edited December 7, 2024 by GentleFly

[topor_topor 0]

On 11/28/2024 at 4:20 PM, GentleFly said:

# Оригиналный сигнал с нулевым смещением
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] 

 

Чисто уточнить, а что по вашому появится в схеме когда написать такую конструкцию?

[GentleFly 0]

9 часов назад, topor_topor сказал:

Чисто уточнить, а что по вашому появится в схеме когда написать такую конструкцию?

Ничего. Если использовать только эти инструкции.

[topor_topor 0]

11 hours ago, GentleFly said:

Ничего. Если использовать только эти инструкции.

В клок три будет вставлено это:

BUFG_inst0

А вообще к какому эфекту должны привести предложенные манипуляции? Вы их уже проверили в PnR?

Чем они лучше default useful skew? 

On 11/28/2024 at 4:20 PM, GentleFly said:

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

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

Судя по всему PnR ещё не опробован......

[RobFPGA 99]

7 hours ago, topor_topor said:

В клок три будет вставлено это:

"Это"  уже  присутствует в нетлисте и в клок tree.  

[Yaahoo 3]

Небольшой коммент. Не знаю как у синопсиса, а PnR тул кеденса когда видит баффер (да и любой селл) в цепи клока, в процессе CTS всегда вставляет сразу после него еще один баффер (два инвертора), так работает алгоритм. А два баффера уже ощутимо увеличивают летенси дерева.
Я понимаю, что иногда эти бафферы необходимы, но часто это просто следствие assign. И в моей практике были случаи, когда после переписывания RTL эти assign уходили, и высота дерева уменьшалась сразу на треть. Чем хорошо маленькое летенси дерева, обьяснять, думаю, не надо.

[GentleFly 0]

В 18.01.2025 в 21:28, topor_topor сказал:

В клок три будет вставлено это:

Здесь, все будет зависеть от конкретного инструмента. И каждая попытка реализовать это, в каждом инструменте, будет отличатся реализованной в другом инструменте. Возможно, придется поискать путь/опцию которая позволит не вставлять того что не надо вставлять. Но это придется контролировать и наблюдать "руками"

В 18.01.2025 в 21:28, topor_topor сказал:

А вообще к какому эфекту должны привести предложенные манипуляции?

К тому, что P&R будет происходить с целью удовлетворить правила, которые мы переопределили.

В 18.01.2025 в 21:28, topor_topor сказал:

Чем они лучше default useful skew? 

Как изменится таковое древо когда вы попробуете сдвинуть регистр на 1.5 периода при default useful skew ? В том, что я предлагаю, тактовое древо меняться не должно (не должно появляться новых элементов задержки). И за этим надо внимательно следить. Нельзя допускать что бы инструмент попытался "исправить" эти действия, так как, с большой вероятностью инструмент просто не поймет что автор хочет.

В 18.01.2025 в 21:28, topor_topor сказал:

Судя по всему PnR ещё не опробован......

Для ASIC инструментов не опробован. Для Xilinx я привел репозиторий, в первом сообщении, в котором можно посмотреть простой пример.

Готового и универсального (для всех ASIC/FPGA) инструмента нет и маловероятно что появится. Универсальным может быть только подход.

Edited January 20, 2025 by GentleFly

[topor_topor 0]

вцелом... это помогает разобраться в STA.....

[GentleFly 0]

3 часа назад, topor_topor сказал:

вцелом... это помогает разобраться в STA.....

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