[Doka 1]

- Какие особенности синтеза дизайна с двумя независимыми доменами синхронизации? Вроде как по логике достаточно определить клоки, задержки входных и выходных сигналов для соответствующего клока, ну и констрейны на асинхронные пути между доменами. Но, судя по документации, как-то все не так просто.

 

думаю гуру согласятся с тем, что это лучшее что есть по теме CDC

Clock.Domain.Crossing.Design.and.Verification.Techniques.pdf

[starley 0]

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

 

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

Изменено 13 апреля, 2009 пользователем starley

[SM 0]

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

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

[starley 0]

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

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

[grigorik 0]

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

 

starley mojet set_ideal_network na vixode IO bufera pomojet?

[SM 0]

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

 

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

[starley 0]

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

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

[grigorik 0]

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

 

ubedites chto u vas v constraintax net set_propagated_clock komandi.

[SM 0]

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

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

[starley 0]

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

Ну раз пошли такие варианты... Сreate_clock надо делать для входа или для выхода ИО буфера клока?

Если я вас правильно понимаю, - то для входа, а у DC достаточно сообразительности, что бы проигнорировать в расчетах ИО буфер клока и при расчетах использовать то значение transition_time, которое я установил в set_clock_transition?

А как тогда быть с ресетом? Дерево буферов для него обычно генерится на этапе реализации или в DC?

 

ubedites chto u vas v constraintax net set_propagated_clock komandi.

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

[SM 0]

Если я вас правильно понимаю, - то для входа, а у DC достаточно сообразительности, что бы проигнорировать в расчетах ИО буфер клока и при расчетах использовать то значение transition_time, которое я установил в set_clock_transition?

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

[starley 0]

По дефолту в DC клок идеальный, так что никто по дороге никаких задержек вносить не должен.

 

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

Может dont_touch_network на клок не надо ставить?

 

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

[SM 0]

Может dont_touch_network на клок не надо ставить?

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

[Quater 0]

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

 

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

 

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

 

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

[grigorik 0]

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

 

подскажите пожалуста как можно сказать 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?