Очень странно, с какого это перепугу он юзает эти 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 или еще чего.

Сообщение отредактировал Quater - Apr 30 2009, 18:46

например 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?

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

Сообщение отредактировал Quater - Jul 29 2009, 03:46