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

[_Anatoliy]

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

[warrior-2001]

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

[_Anatoliy]

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

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

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

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

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

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

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

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

[Raven]

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

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

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

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

[_Anatoliy]

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

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

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

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