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

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

Вкратце, есть большой 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).
Автоматом (скриптом) пройтись по коду и добавить задержки очень сложно, я пока не представляю как.

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

Я так понял, что вы писали в предположении, что есть те кто писал этот код и добавлял констрейны multicycle.
А если код пришел как есть, то в принципе по самому констрейну, если его перепроверить тоже можно добавить такие задержки руками.
Скриптом - не пройдет, тк он не проверит какой путь и где удобней вставить задержку.

Как минимум вижу два варианта, даже для случая, который вы описали

1. Внутри есть mux (если он описан не через assign, а через always * - то также можно вставить задержку перед нужным присваиванием в пути (подобно как в регистре). * assign при это надо будет переписать через always *

2. По констрейну multicycle - видно что есть инициирующий триггер.
И если он имеет только одно подключение через mux к нужному триггеру - то можно задержку присваивания перенести на инициирующий триггер, как задержку выдачи.

Это конечно, не сделать с помощью скрипта, но эти два варианта при ручной проверки частично реализуют задачу проверки multicycle уже на уровне RTL.

В этом все дело - отсутствии автоматического метода. Речь идет о тысячах констрейнов, руками оччччень не хочется это делать.

Как я уже и писал есть такой тул Cadence Conformal Constraints Designer (CCD)
Эта тулза может:
-проверяет коректность фалспасов (выявляет и проверяет пасы с негативными таймингами и правильность их задания в SDC)
-проверяет коректность SDC файла (что-то типа синтаксического чекера, плюс проверка по смыслу - типа есть -from должно быть -to)
-проверяет коректность мультисайклов на основании VCD (дамп времянок с симулятора) и SDC
-проверяет CDC (cross domain clock) на основаниии нетлиста и SDC
-сравнивает 2 похожих SDC (если их несколько версий например)
-верифицирует иерархичные SDC (проверяет соответствие SDC топа на непротиворечивость SDC встроенного модуля)
-SDC Adviser помогает создавать констрейны (как минимум находит root всех клоков)

Конечно голову не заменяет но всё-же...

Спасибо! Список выглядит многообещающе, попробую.

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

Это плохой совет. Особенно для low power, или когда есть ограничения по площади.