[new123 0]

Форумчане привет.

Помогите пжлст с ситуацией. 
1) Имею отрицательные слаки. Ну имею и имею, не в первой.
2) Начинаю проводить оптимизации существенные. 
3) И что делает квартус? Он уменьшает Data Arrival Time в пути, а слаки остаются теме же.

К примеру. Имею путь со slack -100ps, Data Arrival Time 7ns. Ладно, я смирился уже с этой цифрой. 
Провожу оптимизацию, он берет у всех путей уменьшает Data Arrival Time до 5ns и оставляется абсолютно те же слаки ~ -100ps

Могу я как то квартус попросить, пусть он уже оставляет эти задержки в 7ns, но зато уберутся слаки? может какой sdc прописать? типа set_min_delay? Я просто в нем немного плаваю.

Заранее спасибо.

Изменено 12 июля, 2021 пользователем new123
опечатки

[dvladim 0]

Arrival - это то что получилось. Required - то во что нужно уложиться. Slack = Required - Arrival.

Лучше бы подробнее:  что было, что стало. Какие констрейнты, путь один и тот же?

[new123 0]

25 minutes ago, dvladim said:

Arrival - это то что получилось. Required - то во что нужно уложиться. Slack = Required - Arrival.

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

28 minutes ago, dvladim said:

что было, что стало. Какие констрейнты, путь один и тот же?

Путь один и тот же. В основном это сигнал от clock_enable до потребителей. Пример
 

always @ (posedge clk) begin
	if (clk_en) begin
  	end
end

Констрейнов у меня полно, но в основном одни мультициклы, проходящие через этот clk_en (setup 2, hold 1)

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

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

[dvladim 0]

Я про подробности спрашивал, потому что вы пишете ахинею:

12.07.2021 в 20:31, new123 сказал:

И что делает квартус? Он уменьшает Data Arrival Time в пути, а слаки остаются теме же.

И как же? Required измениться не должен, Arrival уменьшился, а как Slack мог остаться тем же?

12.07.2021 в 22:23, new123 сказал:

Ну раз тебе стало легче роут делать, оставь ты 7нс, но убери слаки.

Required измениться так же не должен, Arrival останется 7нс, а с чего бы Slack должен быть другим??

[new123 0]

11 hours ago, dvladim said:

Required измениться не должен, Arrival уменьшился, а как Slack мог остаться тем же?

вот в том и дело. Что Required так же уменьшается параллельно Arrival. То есть квартус предпочел уменьшить общую задержку всей схемы, всего проекта. Я думал, может есть какие методы, чтобы Required оставить константным, задать где нибудь. У меня тут опыта и знаний не хватает.

[dvladim 0]

А за счет чего Required уменьшился? Он определяется прежде всего констрейнтами.

Сравните один и тот же путь: до и после.

[bogaev_roman 0]

Доброго дня.
1. Вы используете сигнал чип енэйбл, какой фанаут у него и по какой линии его пустил фиттер? (compilation report - fitter - resource section - и либо global&other fast signals, либо non-global high fan-out signals).

2. Скриншоты из таймквеста с подробными путями для двух случаев - data path (arrival/required)

3. Слаки рассчитываются намного сложнее, чем вы думаете и даже таймквест подробно вам не распишет. Даже если брать одну угловую модель, то при рассчете слака для setup в arrival и requeired data path время распространения сигнала тактовой частоты (сlock network delay) будет разным (для данных берут максимальное, для частоты минимальное) и различие будет наибольшим, если клокконтрол и анализируемый триггер находятся на разных концах чипа, так вот required time меняется по этой причине - фиттер поставил плл в другое место банально. 

ЗЫ. Вангую - ваш чип енайбл имеет дикий фанаут (да еще и квартус пускает его по обычной сигнальной линии) и решит проблему ограничение на него для автоматического дублирования. А прибить гвоздями и ограничить все можно, только времязатраты будут слишком большими.

[new123 0]

On 7/15/2021 at 1:25 PM, bogaev_roman said:

Вангую - ваш чип енайбл имеет дикий фанаут

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

Изменено 20 июля, 2021 пользователем new123

[bogaev_roman 0]

On 7/20/2021 at 2:59 PM, new123 said:

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

 

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

[RobFPGA 27]

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

У меня  с Qu (Standard, чип StratixV) тоже  были странные слаки ~50-100 ps. Причем казалось бы  в цепях  в которые  должны бы развестись  без проблем. Эти слаки возникали и пропадали случайным образом. Типа  весь дизайн развелся  но пара цепей появилась с таким слаком, а в этой цепи  регистр источник и регистр/память получатель и никакой логики между ними!  
Пришел к  выводу  что это  глюк  самого  Qu.

Боролся  с этим разными констрейнами для этапов FIT и Time analyze.  Если констрейн видит что идет FIT то автоматом времянки ужесточались на 1-3% по сравнению с целевыми которые использовались при Time analyze. 

Удачи! Rob.