Симуляция multicycle на стадии RTL верификации, вопрос Опции

[Cordroy]

Здравствуйте,

Подскажите, пожалуйста, статью / методологию / инструмент по теме.

Вкратце, есть большой ASIC проект, много клоков, много констрейнов.
Проблема в том, чтобы на стадии RTL тестов выявить неправильные multicycle констрейны и/или несоответствие функционирования этим констрейнам.
То есть, заставить симулятор вставить соответствующую задержку там где есть m.c. (и только там).

Написал туманно, попробую на примере пояснить.
Допустим, есть схема:


Во время симуляции вся комбинаторная логика работает за 0 сек. И если сигнал enable придет раньше чем нужно (из-за какой-либо ошибки), результат в регистре Flop_B будет все равно валидным. Значит тест ошибку не выявит.

Вопрос, как, например в ModelSim, автоматически добавить в такой контур, Flop_A-->Flop_B, задержку эмулирующую multicycle.
Или каким-то другим способм такое тестируется?..


Буду благодарен за любой совет

(на всякий случай отмечу, что знаю о том что это не заменяет GLS и последующие проверки; задача - выявить баги в проекте ДО синтезирования)

[Torpeda]

Здравствуйте,

Подскажите, пожалуйста, статью / методологию / инструмент по теме.

Вкратце, есть большой ASIC проект, много клоков, много констрейнов.
Проблема в том, чтобы на стадии RTL тестов выявить неправильные multicycle констрейны и/или несоответствие функционирования этим констрейнам.
То есть, заставить симулятор вставить соответствующую задержку там где есть m.c. (и только там).

при симуляции вставлять задержку не проблема... Правда это "не симулятор заставить", а вручную в RTL написать на сколько и что задерживать....
правда это вам никак не поможет верифицировать правильность STA констрейнов....

В общем случае, STA констрейны верифицировать\доказать нельзя.
Есть правда некоторые косвенные возможности.
- Пост-роут симуляция с SDF. Если не работает - неправильные констрейны использованы при SP&R.
Правда, какой у вас при этом тест каверидж - никому не известно....и посчитать его нечем (т.е все ли тайминг пасы проверены во время прогона вашего тесбенча).....
- кое что можно верифицировать... Например Cadence Conformal кое что проверяет в STA констрейнах, особенно в сложных проектах (на непротеворечивость этих констрейнов, на их непересекаемость и т.п., но не на функиональную адекватность реальности.)
- мой совет - имей ясное описание структуры проекта и тех мест где RTL дизайнер требует задать мультисайклы и т.п. (если он на это способен конечно ).
Ну и дальше - не лепи констрейны куда попало.
Лутше вначале не иметь констрейнов (мультисайклов), а добавлять их по мере "всплытия" во время SP&R и по согласованию с RTL дизайнером.
Кстати... все STA констрейны нужны исключительно для коректного SP&R, а не для функциональной верификации

[Cordroy]

при симуляции вставлять задержку не проблема... Правда это "не симулятор заставить", а вручную в RTL написать на сколько и что задерживать....
правда это вам никак не поможет верифицировать правильность STA констрейнов....

В общем случае, STA констрейны верифицировать\доказать нельзя.
Есть правда некоторые косвенные возможности.
- Пост-роут симуляция с SDF. Если не работает - неправильные констрейны использованы при реализации.
Правда, какой у вас при этом тест каверидж - никому не известно....и посчитать его нечем (т.е все ли тайминг пасы проверены во время прогона вашего тесбенча).....
- кое что можно верифицировать... Например Cadence Conformal кое что проверяет в STA констрейнах, особенно в сложных проектах (на непротеворечивость этих констрейнов, на их непересекаемость и т.п., но не на функиональную адекватность реальности.)
- мой совет - имей ясное описание структуры проекта и тех мест где RTL дизайнер требует задать мультисайклы и т.п.
Ну и дальше - не лепи констрейны куда попало.

Спасибо за ответ.
Да, пост-роут с аннотацией делается, конечно, потом. Это и была методолоия до сих пор.

Просто из-за сложностях в бэкенде, мы добавляем много "облегчающих" констрейнов, типа multicycle, false path, unbalanced clocks, и т.д.
И это иногда на код написанный много лет назад. Проблема - как убедиться что ничего не испортилось, еще ДО синтеза и аннотации (которые занимают массу времени).

[Torpeda]

Просто из-за сложностях в бэкенде, мы добавляем много "облегчающих" констрейнов, типа multicycle, false path, unbalanced clocks, и т.д.
И это иногда на код написанный много лет назад. Проблема - как убедиться что ничего не испортилось, еще ДО синтеза и аннотации (которые занимают массу времени).

Никак