вся документация по Синопсису уже давно лежит на сервере - Sold2006.06

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

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

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

При автоматической генерации схема получается меньше это - раз. Можно раньше выловить ошибки ДФТ чекером. Во-вторых цепочки создаются на этапе логического синтеза см. мой пример, но в дальнейшем могут перегенерироваться в целях более компактной укладки. Могу вам для сравнения предоставить оба скрипта и исходника для сравнения или сгенерированные схемы. И если вы используете мультиплексированные скан-цепочки, я хотел бы попросить вас предоставить небольшой модулечек с ручными скан-цепочками для анализа.

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



не представляю, как предоставить цепочки ? есть единый нетлист (~6MGate), который был отправлен back-end-у без цепочек (и без скан-инсершина), потом для sign-off-а мы получили нетлист со скан цепочками (там же тактовые деревья, BIST-ы, всяческие буффера коррекции hold|setup и т.п.)
но цепочки мы никак не проверяли (управляющая нога во всех наших тестах в режиме scan-disable), это проверяли там

я могу скриптом вытащить какую-либо цепочку - но какой смысл?

мультиплексор цепочек (входы/выходы) также вставлялся back-end-ом, мы выделяли только ножки (как цепочек, так и управления (dedicated) )
тем более применялась метода сжатия патернов и OCC (то есть capture выполняется не по скан клоку (10МГц), а по боевому (200) )

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

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

Вот к примеру синтезированная схема со скан-цепочкой вставленной DFT и скан-флопами.
Белым выделены флопы (здесь со сканом и SCAN_EN заведен на входы SE сканирующих флопов)



А вот ручная вставка. DFT нашло цепочку, оценило приблизительно покрытие ATPG, но нету скан флопов.
Белым выделены флопы (здесь без и SCAN_EN заведен на логику)


Понятно что первая лучше.
А вот сделать ручную со скан-флопами это уже навязчивая идея

ну вот, я не поленился и кусок от АЗИКа отданого (!) в производство прорисовал
длинная колбаса буферов это скан енабле
вторая колбаска - это от входа (PAD) до начала цепочки
ну и несколько триггеров со сканами (тянуть всю цепь - не охота , там больше 100 флопов)



здесь поближе - тригер без скана - это кусок тестирующего IP
далее, интересный момент - первый триггер в цепочке - синхронизатор и его рабочий путь совпал с сканцепочкой (то есть тупость тула вставляющего сканы проявляется D==SI и мультиплексор не нужен)




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

может интересно интересно будет
--------------------
когда сами делаете размещение - возможно Ваша задача имеет смысл, но нас бэкендовцы уверяют, что автоматический time-driven P&R сильно лучше (я в этом сильно сомневаюсь, но нет возможности проверить)

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

Вообше-то в стандартной АСИК дизайне делается так:
1. Во время синтеза скан цепочки вставляются автоматически и очерёдность тригеров в цепочке определят DC по alphanumeric принципе (честно говоря я не понимаю что это значит). И генерируется так называемый SCAN DEF фаил для бак-енд тулов.
2. Бек-енд тулом читается SCAN DEF. Перед плайсмента все цепочки отрываются поскольку они будут мешать оптимизации схемы тулом для функциональной работы. После плайсмента и синтеза клок деревев и перед роутингом скан цепочки восстоновливаттся но уже очередность не тот как был после синтеза. В цепочке те же тригера но очередность другой. Для очередности уже учитываются местоположения тригеров. Тут цель роутинг ресурсы. Таким образом роутинг ресурсы использованными скан цепочками будут минимальны и это даст возможность более оптимальной реализации (роутинга) общей схемы. Вот по-этому time-driven P&R сильно лучше.

Делюсь скриптом для автоматической генерации скан-чейнов в Кыденсе. Может кому надо будет.



Верилог в аттаче.