думаю гуру согласятся с тем, что это лучшее что есть по теме CDC
 Clock.Domain.Crossing.Design.and.Verification.Techniques.pdf ( 566.49 килобайт ) Кол-во скачиваний: 932

2Doka спасибо за доку.

И все-таки, как правильно работать с ИО буферами? Куда и когда их добавлять? В ХДЛ код или в отсинтезированный нетлист?

Сообщение отредактировал starley - Apr 13 2009, 13:00

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

Вот и я так думал. Но тогда загвоздка с синхросигналами и ресетом получается. DC при выполнении STA берет drive ио буфера и рассчитывает исходя из него, например, transition time для клока, Значение, разумеется, получается охрененно большим. Какой тут обходной путь предполагается?

starley mojet set_ideal_network na vixode IO bufera pomojet?

Ну во первых - возможно вы всунули клоковый буфер. Который вовсе не I/O, а специальный клокодрайвер сверхмощный. Так как драйв у обычных буферов как правило соответствует драйву обычного элемента логики.

Нет, совершенно точно обычный ио буфер.

ubedites chto u vas v constraintax net set_propagated_clock komandi.

Тогда остается лишь подозрение, что Вы его туда вставили не той стороной PAD-ом к ядру...

Ну раз пошли такие варианты... Сreate_clock надо делать для входа или для выхода ИО буфера клока?
Если я вас правильно понимаю, - то для входа, а у DC достаточно сообразительности, что бы проигнорировать в расчетах ИО буфер клока и при расчетах использовать то значение transition_time, которое я установил в set_clock_transition?
А как тогда быть с ресетом? Дерево буферов для него обычно генерится на этапе реализации или в DC?


Точно нет, вместо него set_clock_latency и set_clock_uncertainty.

Правильно понимаете. По дефолту в 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?