делаем первый 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 имеет место быть) но я особо не разбирался, так как нам эти режимы не нужны

Don't use typical corner for RC and STD cell library timing.
Best and worst cases for RC and STD cell library timing are enough.

Just do STA for all possible corners.

Я тоже советую уповать на STA, только. Использование SDF - это становится анахронизмом. Например, в Интеле, в маршруте проектирования не применяется логическое моделирование на уровне std cells.

А у Вас либа синопсисовская? NLDM или CCS?

Интересно, а кто-нибудь уже держал в руках synopsys lib в CCS формате?

я не разбираюсь в либах - вот список расширений в design kit-e

ls -1 | awk -F \. '{print $NF}' | sort | uniq
clf
db
etlf
lib
sdb
tim
tlf

если внутре где-то нужно смотреть - скажите - посмотрю

------------------------

c STA есть некий страх -
несколько синхронных тактов со всякими
set_multicycle_path 2 -setup -end ****
set_multicycle_path 1 -hold -end ****
и т.п.

заданых для синтеза внутренних блоков, которые переносились на уровень чипа через write_sdc и awk-скрипт

set_case_analysis вовсю используется - часть путей работает на одной частоте, часть на другой и т.п.

то есть понятие "синхронный" дизайн весьма условно соотносится с нашим проектом - поэтому страшно только STA

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

------------------------

модные статейки я просматриваю, про новые подходы,
но, имхо, за 4-5 лет пока я "не брал в руки шашки" DC и NCSIM очень мало поменялись (может где-то внутри, но снаружи и не заметно).
единственно, формальные чекеры развились до коммерческого применения...

Как определить CCS? Внутри LIB файлов должны быть что-нибудь из этого списка: output_current, receiver_capacitance, compact_ccs...

Цитата из UserGuide: "Composite current source modeling supports additional driver model complexity by using a time- and voltage- dependent current source with essentially an infinite drive resistance."

CCS is unified current source model for comprehensive, accurate and efficient modeling of nanometer effects. CCS models enable designers to perform complete timing, noise, and power sign-off using a SINGLE, open library model.
Variation-Aware Extensions, built on the proven CCS technology, facilitate variation-aware design, allowing engineers to control design margins, improve design robustness, and increase parametric yield.

Это новая фишка от Синопсиса (на смену SPDM (polynomial) формату, который провалился). Теперь, можно все corner либы в одну комбинировать.

----------
Если есть страх с STA - тогда не смею настаивать. А typical corner можно смело исключить из прогонов.
----------
DC может и не так сильно менялся, а вот PrimeTime они апдейтят.

Variation Aware STA.

First, the Liberty™ Composite Current Source (CCS) modeling technology provides accurate timing models based on device variation. Second, the new Star-RCXT VX package enables sensitivity-based extraction for efficient and accurate parasitic models based on interconnect variation. And third, the new PrimeTime VX package brings together device and interconnect models with statistical timing analysis technology to improve the clarity of timing results for sub-65nm design.

не CCS - таких слов внутри нету

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

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

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

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

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

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-ов тесты прошли - то есть наверняка и для "перекошенных" тоже пойдут""
в общем случае не очевидно.

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

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

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


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

Вопросик.

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

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

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


Спасибо

эти SDF я не знаю как генерятся. это задача back-enda и я даже не знаю каким тулом это делается.
полагаю так : с топологии реального чипа (той базы данных, что будет использоваться для генерации фотошаблонов) экстрактируются различные RC и т.п. технологические параметры соединений.
к ним добавляются (комбинаторно) различные (wc,tc,bc)

после этого получается SDF-ы, которые засовываются в PrimeTime и выполняется STA (тем же праймтаймом выполняется проверка Signal Integrity - то есть то что один провод над другим проходит и из-за взвимной емкости гадит друг на друга (как это делается без доступа к топологии - не знаю, возможно есть еще этап с другим тулом) )

также при primetime STA они закладывают некий пессимизм (OCV) - например, сигнал по тактовому дереву пойдет медленнее, чем сигнальный.

для STA они (backend) используют еще больше SDF-ов (72), а 36 - это некоторое подмножество, которые мы должны симулировать для Sign-off

видимо, разброс параметров технологического процесса (TSMC 90нм) не позволяет ограничится проверками 3х (wc,tc,bc) характеризаций библиотек, а требуется проверка дополнительных вариантов для Sign-off

Кстати, а не слишком ли долго?
Симулятор какой? Проблема в тестах или в рабочих станциях?
Или в размере кристалла?
нетлист 60+ к триггеров, 1ns/100fs
На десктопе под win-хр НЦ у меня моделируется ~0.5 мс/час (что на атлоне 64Х2dual, что на core2duo 6400 на 2х гигах памяти).
2 процесса одновременно моделируются без проблем. На рабочих станциях быстрее.

быстрее не получается

станции по 2 core2duo-шных (2 или 4 ядра) xeon-a (они раза в два быстрее AMD64x2 по-моим измерениям) по 32Гб на каждой (симуляционный снапшот 5-8Гб)
станции под линухом (что-то под редхатом/федорой, что-то под дебианом)
сильно считаю, что для нераспределенных задач это самое быстрое железо (причем на удивление дешевое)

тесты написаны не очень оптимально - оптимизировать их по покрытию (togglecount) не стали для уменьшения времени разработки, представляют собой куски реально работающего фирмваря (десятки ms)
правильно это или нет - отдельный вопрос

размер проекта весьма большой - почти квадратный сантиметр при 90нм

Я согласен с grigorik - для уверенности проведите моделирование для 4х сочетаний BestTiming-BestRC, BestTiming-WorstRC, WorstTiming-BestRC, WorstTiming-WorstRC. Для всех остальных корнеров пользуйтесь STA. Должно хватить. Эти дополнительные корнеры просто позволяют убедиться в высоком выходе годных, т.е. даже если у вас будут нарушения в каком то сочетании - это еще не означает, что у вас не будет рабочих схем, просто выход годных будет меньше.

Если боитесь перезапуска то еще раз внимательно поглядите на все виды coverage RTL модели и постарайтесь добить его ближе к 100 процентам. Может быть, добавьте функциональный coverage в важные блоки, например полезно проверить производилась ли запись и чтение из всех регистров и т.д.

Просто была упомянута coverage RTL есть ли у кого-то документация про это или знает где скочать заранее спасибо?

Начните с книжки WritingTestbenches for SystemVerilog. А дальше либо начинайте копать в сторону Functional Verification либо смотрите доки на САПРы. В Cadence это немного нетривиально устроено, т.к. симулятор и средство анализа покрытия разбиты на 2 продукта. В Mentor'e попроще, т.к. все интегрировано.

спасибо

мы приблизительно так и делали - последовательность тестов (у нас еще IO) c этих 4х (8). но затем и все остальные.

для особенно длинных тестов ограничили только 4-мя.

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