SDF для верификации, сколько штук?, RC, OCV, PVT, corners и т.п. Опции

[yes]

делаем первый 90нм проект

и в отличие от более "толстых" технологий предлагается симулировать для сайн-оффа не 3 варианта (для библиотек worst, typical, best), а гораздо больше
----цитата---------
Actually we have 36 SDF
files in total for your simulation. Along with 3 library corners you
mentioned, we have 3 RC corners and 4 I/O voltage combinations.

ну если с IO комбинациями вроде бы понятно: маленькое VCCIO - задержки большие

то остается 18 вариантов (2 I/O voltage).

проблема в том, что прогон для 3 SDF занимает у нас неделю.
6 недель (а если брать 36 SDF - то вообще 12) - неприемлемо большой срок

хотелось бы узнать - как можно "оптимизировать" при минимизации проноса ошибки???
чего-то нагулить не получилось вразумительного

впринципе, конечно, есть представления, где будет вероятность на setup-ы нарваться, а где на hold-ы - то есть в этой табличке (RC/corners) 3x3 можно найти "реально" worst и best
но страшно

ес-сно STA и формальная верификация выполнены, но без симуляции как-то стремно...

==============

btw: для дип-субмикрона и библиотек не 3 corners, а 5 (+2 низкотемпературные - там какой-то inversion phenomena имеет место быть) но я особо не разбирался, так как нам эти режимы не нужны

[soshnev]

делаем первый 90нм проект

и в отличие от более "толстых" технологий предлагается симулировать для сайн-оффа не 3 варианта (для библиотек worst, typical, best), а гораздо больше
----цитата---------
Actually we have 36 SDF
files in total for your simulation. Along with 3 library corners you
mentioned, we have 3 RC corners and 4 I/O voltage combinations.

ну если с IO комбинациями вроде бы понятно: маленькое VCCIO - задержки большие

то остается 18 вариантов (2 I/O voltage).

По моим наблюдениям хорошо "проявляются" setup-ы hold-ы при наилучших условиях (best).

Я предлагаю сделать самим комбинированный lib-файл :
взять best, а setup-ы hold-ы например из typical (хоть какой-то запас по ним будет)
скомпилить, сделать sdf и промоделировать.

Для данной технологии существенно будет влияние межсоединений друг на друга.
Вообще-то cross-токи считать надо... (непредсказуемые завалы фронтов на длинных связях)
Простоe замечание - сделать очень хорошее клоковое дерево (во всяком случее обратить на это внимание)

При моделировании с комбинированным lib-файлом могут быть ложные hold-ы
(естественно-счётный триггер с Q на свой D и т.п.) в этом случае могу предложить
ручным способом (или это найти и составить список элементов заранее), подправить SDF-файл в этих
местах (уменьшить hold (напр. в 10 раз) - комментарий в SDF - //)

Есть ещё вариант - воспользоваться Synopsys PrimeTime или Cadence Perl, но задание
ограничений на проверки (констраинтов) - это искусство...
С другой стороны - это статический анализ и за день можно проверить хоть 100 вариантов.

[yes]

По моим наблюдениям хорошо "проявляются" setup-ы hold-ы при наилучших условиях (best).

Я предлагаю сделать самим комбинированный lib-файл :
взять best, а setup-ы hold-ы например из typical (хоть какой-то запас по ним будет)
скомпилить, сделать sdf и промоделировать.

SI проверки были выполнены back-end-ом с использованием PrimeTime или каких-то еще тулзов. это не наша забота.

а для верификации я не совсем понял - какой смысл изменять библиотеку?
собственно библиотека (верилог модель) не содержит временной информации
вся времянка (как элементов, так и соединений) генерится back-end-ом и присылается нам в виде комплекта SDF файлов (36 штук, перебор всех комбинаций)
если взять проверки (timing_check) из одного файла, а задержки путей из другого - то гарантировано получим нарушения (немерянный пессимизм), но какой в этом смысл - понять не могу...

ну и вроде бы быстрый путь/быстрый элемент - проверка на hold нарушения
а медленный путь/элемент - на setup

может я не правильно понял идею?

btw: для "крайних" SDF-ов тесты прошли - то есть наверняка и для "перекошенных" тоже пойдут

[soshnev]

SI проверки были выполнены back-end-ом с использованием PrimeTime или каких-то еще тулзов. это не наша забота.

а для верификации я не совсем понял - какой смысл изменять библиотеку?
собственно библиотека (верилог модель) не содержит временной информации
вся времянка (как элементов, так и соединений) генерится back-end-ом и присылается нам в виде комплекта SDF файлов (36 штук, перебор всех комбинаций)
если взять проверки (timing_check) из одного файла, а задержки путей из другого - то гарантировано получим нарушения (немерянный пессимизм), но какой в этом смысл - понять не могу...

ну и вроде бы быстрый путь/быстрый элемент - проверка на hold нарушения
а медленный путь/элемент - на setup

может я не правильно понял идею?

btw: для "крайних" SDF-ов тесты прошли - то есть наверняка и для "перекошенных" тоже пойдут

Вообще - а как получены 36 вариантов SDF? С применением каких tools-ов?
(Например, использовали что-то типа SignalShtorm и т.п.)

Вся суть в том, что в такой технологии могут появится "завалы фронтов" - это может быть связано
с тем что например, одна трасса "накрывается" другой длинным участком и образуется дополнительная ёмкость между трассами. Соответственно возможен завал фронта на таких трассах.

Cобственно, современный расчётчик SDF должен посчитать этот топологический довесок для
всех цепей. Причём ёмкость перекрытий зависит от сочетаний слоёв и т.п.

Смысл предложенной идеи исходит из одного нюанса.
Как правило, переменные setup hold - строго зависят от технологии. Улучшаешь технологию они уменьшаются и собственно ничего не видишь ( не видишь запаса).

Можно написать скрипт - добавить к setup-ам hold-ам (наилучший SDF) какую-то величину - получить новый SDF и посчитать с ним.


Утверждение
""для "крайних" SDF-ов тесты прошли - то есть наверняка и для "перекошенных" тоже пойдут""
в общем случае не очевидно.

Если схема синхронная - то вполне возможно.

[soshnev]

...
Если схема синхронная - то вполне возможно.

Как говорится, до кучи.

Это всё надо проделать (или что-то подобное), поскольку Вам могут
сделать не очень удачную раскладку шин земли и питания.


Клоковое дерево похоже не строилось и back_netlist-a нет...

[-=Vitaly=-]

Вопросик.

Как вы генерируете несколько SDF - синтезируете, а потом командой set_operating_condition задаете условия и сохраняете SDF файлы?

Имеет ли смысл использовать эти SDF для Prime-Time или это только для функциональных симуляторов?

У меня в *.db есть предопределенные условия, там есть напимер 2.6 Вольта, 150 degC, process 1.60 , могу я задать такие же условия но для -85degC??


Спасибо

Сообщение отредактировал -=Vitaly=- - Jan 17 2008, 08:41