[Cordroy 0]

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

 

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

 

Вкратце, есть большой ASIC проект, много клоков, много констрейнов.

Проблема в том, чтобы на стадии RTL тестов выявить неправильные multicycle констрейны и/или несоответствие функционирования этим констрейнам.

То есть, заставить симулятор вставить соответствующую задержку там где есть m.c. (и только там).

 

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

Допустим, есть схема:

 

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

 

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

Или каким-то другим способм такое тестируется?..

 

 

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

 

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

 

[eugen_pcad_ru 0]

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

[madgarry 0]

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

[Cordroy 0]

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

 

Именно так оно и произойдет после синтезирования; GLS + SDF аннотации.

Вопрос был про симуляцию multicycle на RTL стадии проекта.

 

[madgarry 0]

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

[Cordroy 0]

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

 

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

 

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

 

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

[eugen_pcad_ru 0]

1 используйте модель после синтеза

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

имхо иного не дано

[Cordroy 0]

1 используйте модель после синтеза

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

имхо иного не дано

 

Видимо, мы друг друга не понимаем...

1. Как и писалось, речь идет о коде до синтеза.

2. Имеется в виду заменить всю функциональность RTL его моделями и их проверять?

Но тогда теряется сам смысл теста - я должен протестировать именно ТОТ код который потом будет синтезироваться.

 

Добавлено: возможно вы правы, если б это было единичное место и отдельная конкретная функция, которую можно смоделировать и протестировать только управляющие сигналы.

Я ищу метод который позволит автоматом / в скрипте находить сотни / тысячи таких мест, "подправлять" их и передавать результат дальше в симулятор.

При этом ни имею понятия о функциональности каждого проблемного места (не смогу сам смоделировать, даже вручную).

[Shivers 0]

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

[Cordroy 0]

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

 

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

К сожалению, совершенно не разбираюсь в SVA. Видимо, придется почитать.

Наша среда верификации построена на SV+UVM+coverage collection.

[topor_topor 0]

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

 

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

 

Вкратце, есть большой ASIC проект, много клоков, много констрейнов.

Проблема в том, чтобы на стадии RTL тестов выявить неправильные multicycle констрейны и/или несоответствие функционирования этим констрейнам.

То есть, заставить симулятор вставить соответствующую задержку там где есть m.c. (и только там).

 

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

правда это вам никак не поможет верифицировать правильность STA констрейнов....

 

В общем случае, STA констрейны верифицировать\доказать нельзя.

Есть правда некоторые косвенные возможности.

- Пост-роут симуляция с SDF. Если не работает - неправильные констрейны использованы при SP&R.

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

- кое что можно верифицировать... Например Cadence Conformal кое что проверяет в STA констрейнах, особенно в сложных проектах (на непротеворечивость этих констрейнов, на их непересекаемость и т.п., но не на функиональную адекватность реальности.)

- мой совет - имей ясное описание структуры проекта и тех мест где RTL дизайнер требует задать мультисайклы и т.п. (если он на это способен конечно :)).

Ну и дальше - не лепи констрейны куда попало.

Лутше вначале не иметь констрейнов (мультисайклов), а добавлять их по мере "всплытия" во время SP&R и по согласованию с RTL дизайнером.

Кстати... все STA констрейны нужны исключительно для коректного SP&R, а не для функциональной верификации

[Cordroy 0]

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

правда это вам никак не поможет верифицировать правильность STA констрейнов....

 

В общем случае, STA констрейны верифицировать\доказать нельзя.

Есть правда некоторые косвенные возможности.

- Пост-роут симуляция с SDF. Если не работает - неправильные констрейны использованы при реализации.

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

- кое что можно верифицировать... Например Cadence Conformal кое что проверяет в STA констрейнах, особенно в сложных проектах (на непротеворечивость этих констрейнов, на их непересекаемость и т.п., но не на функиональную адекватность реальности.)

- мой совет - имей ясное описание структуры проекта и тех мест где RTL дизайнер требует задать мультисайклы и т.п.

Ну и дальше - не лепи констрейны куда попало.

 

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

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

 

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

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

 

 

 

[topor_topor 0]

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

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

Никак

 

[Kopart 0]

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

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

 

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

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

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

На синтез это не повлияет, а тесты будут адекватней.

Единственное: не проверял, как ваш симмулятор отреагирует на задержку больше периода клока.

(по идеи он не должен выйти из always на новое событие фронта пока не выполнил текущий до конца )

 

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

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

[Cordroy 0]

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

 

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

 

Это первое же над чем думали. Проблема автоматически, в существующем большом коде, найти "нужное место".

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

 

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

Автоматом (скриптом) пройтись по коду и добавить задержки очень сложно, я пока не представляю как.

 

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