Перейти к содержанию
    

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

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

 

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

 

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

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

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

 

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

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

post-59464-1395052634_thumb.png

 

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

 

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

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

 

 

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

post-59464-1395059711_thumb.png

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

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

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

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

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

 

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

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

 

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

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

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

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

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

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

 

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

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

 

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

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Никак

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...