[KMC 0]

Может кто-то может выложить в закрома толковые доки по SYNOPSYS, а то у меня только UG на Physical Compiler и то 2002 года. Или подскажите где качнуть по-свеже. Я позже документов 2004 года почти ничего не встречал. Во всех остальных то уже таких комманд нету, то еще чего.

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

[yes 8]

Единственное что так и осталось загадкой это как написать верилог и скрипт, чтобы был свой порядок в скан-цепочке и скан-флопы в одно и то же время.

И еще может кто-то знает как посадить порт TE гейтед-клок елемента на SCAN_EN.

 

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

 

это все делается на этапе генерации патернов после размещения.

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

 

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

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

[VitalyM4 0]

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

 

это все делается на этапе генерации патернов после размещения.

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

 

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

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

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

[yes 8]

Могу вам для сравнения предоставить оба скрипта и исходника для сравнения или сгенерированные

 

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

 

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

 

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

но цепочки мы никак не проверяли (управляющая нога во всех наших тестах в режиме scan-disable), это проверяли там

 

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

 

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

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

 

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

но в деталях (до вентилей) я на это не смотрел

[VitalyM4 0]

не представляю, как предоставить цепочки ?

 

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

 

Вот к примеру синтезированная схема со скан-цепочкой вставленной DFT и скан-флопами.

Белым выделены флопы (здесь со сканом и SCAN_EN заведен на входы SE сканирующих флопов)

 

 

А вот ручная вставка. DFT нашло цепочку, оценило приблизительно покрытие ATPG, но нету скан флопов.

Белым выделены флопы (здесь без и SCAN_EN заведен на логику)

 

Понятно что первая лучше.

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

[yes 8]

Посмотрите мой пример в этом топике по-выше. Где на в RTL описании последовательного делителя

 

ну вот, я не поленился :) и кусок от АЗИКа отданого (!) в производство прорисовал

длинная колбаса буферов это скан енабле

вторая колбаска - это от входа (PAD) до начала цепочки

ну и несколько триггеров со сканами (тянуть всю цепь - не охота :), там больше 100 флопов)

 

 

здесь поближе - тригер без скана - это кусок тестирующего IP

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

 

 

 

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

 

может интересно интересно будет

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

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

[VitalyM4 0]

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

так и я тоже пришел к этому выводу.

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

А при ручной немного лажовато, но я смотрю что иначе сделать не получится.

[grigorik 0]

так и я тоже пришел к этому выводу.

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

А при ручной немного лажовато, но я смотрю что иначе сделать не получится.

 

Вообше-то в стандартной АСИК дизайне делается так:

1. Во время синтеза скан цепочки вставляются автоматически и очерёдность тригеров в цепочке определят DC по alphanumeric принципе (честно говоря я не понимаю что это значит). И генерируется так называемый SCAN DEF фаил для бак-енд тулов.

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

[VitalyM4 0]

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

 

set_message_verbosity VLOGPT-035 off

read_verilog ./src/${RTL_FILE}


issue_message -type info "--> Start synthesis"
do_build_generic -module ${TOP_LEVEL}

set_current_module ${TOP_LEVEL}
set_top_timing_module ${TOP_LEVEL}

#PKS insert scan_chains

#Select scan_type
set_scan_style mux_scan

set_global dft_scan_avoid_control_buffering true

set_global dft_scan_path_connect tieback

set_scan_mode SCAN_EN 1

report_dft_assertions -all_modules

check_dft_rules

report_dft_registers

check_netlist

set_clock SCLK -period 80 -waveform {0 50}

do_optimize 

set_global dft_scan_path_connect chain

set_number_of_scan_chains 1

set_scan_data -clock SCLK -rise  SCAN_IN  SCAN_OUT -enable SCAN_EN 

do_xform_connect_scan

 

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

frame_counter_no_scan.v