Сигнал-тап и партишин Опции

[_Anatoliy]

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

[Raven]

Коллеги, от компиляции к компиляции не всегда выполняются констрейны для корки сигнал-тапа даже если в его структуре изменений не было.

P&R алгоритмы используют рандомизацию, завязанную на ряд параметров (включая время старта компиляции), так что и результат в 2-х последовательных placement'ах будет отличаться в каких-то деталях для любого нетривиального дизайна. Ничего удивительного. И некотрые варианты оказываются неудачными (даже если все констрейнты грамотно прописаны, но конструкция уже "на пределе").

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

В каком смысле "для каждого инстанса"? Инстанса SignalTap? Тогда да, рассыпуха Tap'а в partition не оформляется. Думаю, по идеологическим причинам. SignalTap играет обслуживающую роль, он должен показать, как работает основной дизайн, который можно и должно "заморозить" в процессе отладки, а сам механизм отладки (SignalTap) пытается расположиться на оставшихся ресурсах, как получится.

Кто нибудь сталкивался с такой проблемой, как решали?

Конечно, сталкивались. Способ решения - такой же, как и всегда: докапываться до сути проблемы, изучая критические пути и другие репорты Timing Analysis, и пытаться что-то изменить в системе SignalTap - Device_Under_Test, производя компиляции. И вот тут как раз, для сокращения времени цикла перекомпиляции, incremental compilation, partitions and Logic Lock очень кстати.