Симуляция 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, и т.д.
И это иногда на код написанный много лет назад. Проблема - как убедиться что ничего не испортилось, еще ДО синтеза и аннотации (которые занимают массу времени).

[Kopart]

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

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

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

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

Код

always @(posedge clock)
...
reg <= #n value     //n= (multicycle-1)*clock_period - те задержку эквивалентную задержке при multicycle

[Cordroy]

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

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

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

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

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

[Kopart]

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

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

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

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

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

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

[Cordroy]

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

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