Правильно понимаете. По дефолту в DC клок идеальный, так что никто по дороге никаких задержек вносить не должен. Что касается резетов и прочих high-fanout-ов, так их DC при синтезе буферирует нормально. Там же нет требований к latency/uncertainty

Ан нет. Практика-то говорит о другом. Объявляю клок на выходе IO буфера - все нормально считается. Объявляю на входе - максимальная задержка становится в 10 раз больше.
Может dont_touch_network на клок не надо ставить?

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

Ясен пень не надо, это нужно только для propagated clock.

Добрый день...

подскажите пожалуста как можно сказать DC чтобы соединил TE (Test Enable) вход на всех FF со ScanTest на 0. А то он исползует эти флопы для обычных целей и поэтому вся симулация валится.

Всё это происчодит если я использую compile -inc, а если исползовать compile -scan то все TE флопов соединины на 0 и всё работает как надо.

заранее благодарю.

Pochemu v vashem designe DC postavil Scan FF esli vi ne delaite "compile -scan" ? V biblioteke net drugix FF? Mojete skazat podrobnosti?

Очень странно, с какого это перепугу он юзает эти FF для обычных целей... Попробуйте им поставить set_dont_use, чтобы DC забыл об этих ячейках. Но, вообще-то, он и не должен бы их ставить. Так что, присоединяясь к вопросу grigoryk - а что, в либе других FF нет?

Клок победить так и не удалось. dont_touch_network, set_ideal_network не влияют - DC все равно задержки в местах нестандартного использования клока расчитывает неправильно
Пока решил объявлять этот клок на выходе ИО буфера, это, вроде, ничему не противоречит.
Назрел еще один вопрос. Может, кто-нибудь подсказать как правильно работать с защелками или ссылку на методу дать. В частности, часть памяти предполагается реализовать на регистровых файлах, а они - защелки. Интересует их сопряжение с обычными тригерами, задание кострейнов, особенности выполнения STA и т. п.

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

Единственная особенность работы с защелками - их можно объявлять как transparent, если в данном месте важно время прохождения через открытую защелку, работающую как буфер, а не холды-сетапы защелки, как регистра, если, допустим, они априори выполнены. И то, если либа это поддерживает. Мне вот лично пришлось самому характеризовать защелку на транспарентный режим и править либу.

starley!

Poprobui eto. Dumayu pomojet.
set_ideal_network [all_fanout -flat -clock_tree ]

Все спосибо так и сделал.
Всё заработало.

Если напрямую с триггера брать - то понятно. А вот если между ними логика висит, ДЦ обеспечит стабильность данных к отрицательному фронту (для защелки с положительным разрешением)? Иными словами, в понимании ДЦ защелка в качестве регистра - это эдакий триггер запоминающий данные на полтакта? Причем если она не объявлена как прозрачная, то путь после нее в момент прозрачности в СТА не учитывается?

Подскажите пожалуста, почему STA не находит ни каких проблем в дизайне а симулатор постояно падает на холде.

Установил set_dont_touch, set_ideal_network.

Может еще чего нибудь надо добавить например

set_anotted_delay или еще чего.

например set_fix_hold. Как я понимаю по умолчанию DC холдами не занимается, это back-end-ово, холды фиксить. Так как непофиксенный холд на этапе синтеза запросто может оказаться корректным после разводки.

Esli u vas hold mejdu raznimi clock domainami to nichego STA ne pomojet poskolku vi zakrili glaza STA na pathi mejdu raznimi clock domainami.

foreach_in_collection clock [all_clocks] {
set_false_path -from $clock -to [remove_from_collection [all_clocks] [get_clocks $clock]]
}

Uberite set_false_path i plyus dobavte v DC (ili back end tool) to chto SM skazal.

1. Если она не объявлена, как прозрачная, то комбинаторный путь через нее не учитывается вообще, она чисто регистр.
2. Если она объявлена как прозрачная, то она не регистр, а чисто буфер.
3. Если она регистр, то "рабочим фронтом", для которого регламентированы Tsu/Th для входа данных является задний фронт открывающего импульса (т.е. для латча, открытого единицей, тайминги setup_falling и hold_falling), а для выхода данных описаны unate (для моего примера positive_unate) тайминг по переднему фронту открывающего импульса, а также тайминг типа _edge (в моем примере rising_edge) от входа Enable. Так что DC в курсе событий, что сигнал на выход проходит по одному фронту, а фиксируется по другому. И обеспечит стабильность записываемого сигнала в момент окончания импульса записи.

ЗЫ. Формат Liberty ни для кого не секрет, сами посмотрите на описание латча в вашей либе, в ее исходнике, и увидите все-все-все про него, что и увидит DC.

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

Так там речь шла о каком-то некорекктном подключении сигнала Test Enable, что валило симуляцию. Вот за эту инициативу и ругали. А так бы конечно, пусть все использует, что по speed или area выгодно. Кстати, возможно, просто кривизна либов.

Добрый день Господа,,

Помогите пожалуста запустить вот этот FOR в DC

set clocks [list host_clk sys_clk]
set resets [list host_resetn sys_resetn]
set clock_periods [list 19 9]

for {set i 0} {$i < {expr [llength $clocks] -1}} {incr i} {
create_clock -name [lindex $clocks $i] -period [lindex $clock_periods $i] [get_ports [lindex $clocks $i]]
}

а то постояно говорит что -period can't be ''.

заранее благодарю.

IMHO как-то так:

set clocks {host_clk sys_clk}
set resets {host_resetn sys_resetn}
set clock_periods {19 9}

for {set i 0} {$i < [llength $clocks]} {incr i} {
create_clock -name [lindex $clocks $i] -period [lindex $clock_periods $i] [get_ports [lindex $clocks $i]]
}

Большое спосибо,

вот так это работает

set clocks [list host_clk sys_clk]
set resets [list host_resetn sys_resetn]
set clock_periods [list 19 9]

for {set i 0} {$i < [llength $clocks]} {incr i} {
create_clock -name [lindex $clocks $i] -period [lindex $clock_periods $i] [get_ports [lindex $clocks $i]]
}


Тут у меня по ходу еще вопросик


почему он говорит что есть ФФ которые получают 2 клока, и что такое disable_timing?

заранее благодарю.

Дорогой СМ,

Подскожите пожалуста в чем разница между dc_shell-xg-t и dc_shell-t?

И почему DFT commands у них разные?

Спосибо.

Касаемо нескольких клоков - я конечно не телепат, но по ходу дела у Вас там мультиплексор на клоки стоит, и у DC крышу снесло от того, по какому клоку что констрейнить. Я бы объявил set_clock_groups с ключиком asynchronous, чтобы оно запретило междоменные тайминги на этих клоках.

Что касается xg - так это была попытка у синопсиса перейти на другой формат базы данных. На сколько я знаю, на сегодня разницы нет, и XG-mode считается устаревшей, юзайте dc_shell-t и не заморачивайтесь

PS.
Какого черта задание list-ов через фигурные скобки-то не работает? Обязано!

Спосибо большое за XG а то я думал что XG более продвинутая штука.

Они и сами по началу так думали

Если я правильно понимаю, то они по прежнему так и думают:

From DC 2007.03 version onwards, DCSH mode is no longer supported

Так что сейчас DC работает в XG моде без лишних раговоров и по умолчанию начиная с 2005.09.

Не в XG моде, а в TCL моде. А XG-mode / DB-mode это совсем другое. Сейчас (с версии 2008.03), как и раньше, DC по умолчанию работает в db-mode, соответственно используя внутри стандартный синопсисовский db-формат базы данных, а не XG-шный ddc-формат. Однако поддерживает при этом все XG-команды. Так что будет правомерно и то, что сейчас единственным возможным режимом остался tcl-mode + db-mode если брать за основу формат базы данных, и, одновременно, можно сказать, что единственным режимом остался tcl-mode + xg-mode, если брать набор команд. Что касается 2007.03 - там DCSH убрали, оставив DCTCL, но XG/DB еще было.

Ага, теперь понял есть разница... Спасибо за разъеснение.