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

Ну я встречал крики на констрейны лишь на сам сигнал тап. Тоесть это он у себя внутри не тянет - значит некорректная времянка будет, и только. Поэтому ставлю set_false_path и не парюсь.
Другое дело, если в сигнал тапе сигналы из разных клоковых доменов - это много хуже. Подчищал за менее опытными коллегами и убедился, что не просто влияет, а рушит проект от компиляции к компиляции! При этом set_false_path был на весь сигнал тап и вполне ожидаемо компилятор раскидывал выводимые сигнал кое-как.
При использовании инкрементной компиляции существенно падают частоты и растет размер проекта. Посему не пользуюсь.
Однако компиляции для 10 серии уже весьма длительны. Видимо придется опять ковыряться с этим делом, по другому не скажешь.

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


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


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

Честно говоря не понял - как это? Что значит и только? Если не тянет времянка значит и доверия к сигнал-тапу не будет при отладке проекта. Я с таким вариантом не согласен.


Это всё понятно, я не говорил что для меня это удивительно. А вот насчёт предела - это как раз мой случай.


Если не оформляется то похоже что моя задача не решается.


Как можно что либо изменить во внутренностях сигнал-тапа??? Например, мне сообщают что не тянет счетчик адреса для записи в память внутри сигнал-тапа. В своём проекте я разберусь, а там как?

Возможностей действительно мало. Но уж что остается. Действовать косвенным методом:

1) просто перекомпилировать проект (ведь иногда же времянка сходится, верно), плюс, возможно, иногда что-то в параметрах компиляции полезно пошевелить (кстати, тот же seed, используемый для рандомизации);
2) облегчить SignalTap'у "сходимость" - сузить круг наблюдаемых сигналов и вообще уменьшить "вес" SignalTap'а, а может, и освободить какие-то ресурсы за счет основного дизайна, наконец, выбросив несущественное для отлаживаемого узла/протокола обмена, и т.п.
3) попробовать подключиться к другим сигналам, к которым потенциально SignalTap'у легче будет проложить свои сигналы, но которые позволяют решить главную задачу наблюдения.
И т.п., и т.д.

Вообще, в ситуациях "на грани" все всегда сильно индивидуально, думаю, это не секрет для всех. Как-то так. Может, коллеги и еще какие-то how-to порекомендуют.

Ясно, спасибо! Подождём. А сид я уже второй день кручу.....

Ну вот же и пример. Если не утаптывается по частоте ТОЛЬКО этот счетчик, то глючить будет времянка сигналтапа и только она. Сам проект в рамках основного функционала будет работать штатно, а времянка показывать ерунду.
А если этот счетчик потянет и другие ресурсы - то поплывет времянка и основного проекта.

Если честно, на больших частотах я обычно убирал часть функционала и исследовал только нужную мне часть схемы. Много у меня бывает проектов с загрузкой 100%. И тогда уже никак без резки проекта на части!
С большими проектами сложнее, ибо на крутых кристаллах частота такая, что сигналтап никогда не осилит запись в память большого потока на высокой частоте. А смотреть однобитные сигналы не всегда удобно.
П.С. Есть у меня на работе целый ряд кит-модулей. Иногда приходилось и на них проверять работу какого-то узла. Это если железо запаздывает или схему без моего ведома разводили и поставили ПЛИС маленькую по емкости.

Спасибо! С основным проектом у меня проблем пока нет, только с сигнал-тапом. Уж очень информативный кусочек хотел вывести для контроля. Ну что-ж, основная идея борьбы с явлением понятна, будем двигаться дальше.

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

Спасибо конечно, но как это поможет в этом случае?
Например, мне сообщают что не тянет счетчик адреса для записи в память внутри сигнал-тапа


Я по возможности стараюсь избегать такой ситуации.

Если fanout большой в критической цепочке, то можно попробовать настройками и assignement продублировать логику (можно ли отдельные настройки назначить только для партиции ST не знаю). Еще может быть вариант, что сама память, используемая ST находится физически далеко от пинов и из-за большого IC остальная логика рушится.