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

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

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

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


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

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


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

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

Для симуляции используйте модели, в которых приведены задержки.

В multicycle путях всегда есть инициирущее событие, и событие готовности результата. В голову приходит только "ручное" моделирование RTL с контролем этих событий и сопоставления с заданным контрэйнтом. Про подобные навороты в моделсиме не слышал.

Именно так оно и произойдет после синтезирования; GLS + SDF аннотации.
Вопрос был про симуляцию multicycle на RTL стадии проекта.

Ну или как вариант - если код написан на VHDL то использовать конструкцию after xxx- которая выдает на выход результат если вход стабилен в течениии xxx времени.

Спасибо, не знал о таком. Но тут, по-моему, не будет полезным: проблема именно в том что сигнал данных "слишком" стабильный в симуляции.

Иллюстрация:


P.S. и еще проект на Верилоге...

1 используйте модель после синтеза
2 используйте модели до синтеза но с задержками (использование конструкции типа "after xxx" в vhdl или похожую - не знаю какую - в верилоге)
имхо иного не дано

Видимо, мы друг друга не понимаем...
1. Как и писалось, речь идет о коде до синтеза.
2. Имеется в виду заменить всю функциональность RTL его моделями и их проверять?
Но тогда теряется сам смысл теста - я должен протестировать именно ТОТ код который потом будет синтезироваться.

Добавлено: возможно вы правы, если б это было единичное место и отдельная конкретная функция, которую можно смоделировать и протестировать только управляющие сигналы.
Я ищу метод который позволит автоматом / в скрипте находить сотни / тысячи таких мест, "подправлять" их и передавать результат дальше в симулятор.
При этом ни имею понятия о функциональности каждого проблемного места (не смогу сам смоделировать, даже вручную).

Вы пишете о верификации - так используйте SVA. Я отошел от RTL и сейчас на вскидку не вспомню синтаксис, но с помощью assert можно точно описывать поведение схемы и в частности - малтисайклы.

Спасибо за совет.
К сожалению, совершенно не разбираюсь в SVA. Видимо, придется почитать.
Наша среда верификации построена на SV+UVM+coverage collection.

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

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

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

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

Никак

А почему не попробовали просто в нужном месте в RTL вставить задержку эквивалентную задержке при multicycle.
На синтез это не повлияет, а тесты будут адекватней.
Единственное: не проверял, как ваш симмулятор отреагирует на задержку больше периода клока.
(по идеи он не должен выйти из always на новое событие фронта пока не выполнил текущий до конца )

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

Спасибо за ответ.

Это первое же над чем думали. Проблема автоматически, в существующем большом коде, найти "нужное место".
В начале поста я показал картинку для примера: один и тот же флоп может принимать данные и по multicycle контуру, и по обычному, без задержек (предположите что внутри облака просто mux).

Т.е. чтобы поставить на его вход задержку, нужно знать функциональность логики (состояние mux'a).
Автоматом (скриптом) пройтись по коду и добавить задержки очень сложно, я пока не представляю как.

А метод, подобный тому что вы описали, обязательно будем использовать на стадии написания кода.