При добавлении DDR2 UniPHY слетают тайминги, Cyclone V, Quartus 14 Опции

[DmitryR]

Столкнулся со следующей проблемой. Есть некоторый дизайн, в нём одна PLL (плюс ещё пачка CDR в трансиверах, но не о них речь). Эта PLL генерирует несколько частот, например 125 МГц. В SDC файле написано тупо:
- derive_pll_clocks,
- derive_clock_uncertainty,
- плюс ещё буквально несколько строк объявлений false paths between clocks.

Проект копмилируется и нормально укладывается во времянку.

Потом я добавляю в проект контроллер DDR2 UniPHY. И времянка всего проекта разваливается, так как TimeQuest начинает вдруг считать, что у клока, который в PLL объявлен, как 125МГц период должен быть не 8нс, а 3.2нс! Контроллер UniPHY синтезирован без шаринга PLL, в качестве референсной ему подаётся частота с отдельного выхода той же PLL. DRAM применяю далеко не первый раз, последний раз на Cyclone IV, но такого ни разу не случалось.

[des00]

Может быть эта корка свой sdc подсовывает после основного sdc. а там же тикл, он тупо переопределяет все. В логе не видно сообщения о переопределении tcl переменных ?

[DmitryR]

Очевиндно, но это явный косяк - не должна корка ничего переопределять за своими пределами. Собственно в этом и вопрос - как её заставить этого не делать, но сохранить работоспособность? Переменных в моём SDC, как я уже писал, никаких нет.

[blackfin]

Очевидно, но это явный косяк - не должна корка ничего переопределять за своими пределами. Собственно в этом и вопрос - как её заставить этого не делать, но сохранить работоспособность? Переменных в моём SDC, как я уже писал, никаких нет.

В документе emi.pdf на стр. 208 встречается вот такая фраза:
[attachment=89256:emi.jpg]

[DmitryR]

В документе emi.pdf на стр. 208 встречается вот такая фраза:

Замечание вроде правильное, но почему-то не помогает. Разница, правда, есть: если поставить dram.qip ниже SDC - времянка раскосячивается в том числе и в самом контроллере. Если же сделать, как написано - времянка dram анализируется нормально, но в остальном проекте тем не менее нет.

Хотят вот тут: http://www.altera.com/support/kdb/solution...032012_191.html написано, что этот фикс как раз влияет на DDR Timing, а у меня как раз сам контроллер в порядке.

Ещё момент - в директиву derive_pll_clocks поставил опцию -use_net_names. В результате ожидаемый период сократился ещё вдвое: он должен быть 8, при включении конроллера становится 3.2, при включении этой опции - 1.6. Трэш какой-то.