Столкнулся со следующей проблемой. Есть некоторый дизайн, в нём одна 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, но такого ни разу не случалось.

Посмотрите в альтеровской базе, например, по ссылке http://www.altera.com/support/kdb/search?q...type=&sort=

У меня была проблема с DDR3 (Квартус 13.1, Арриа 5), после переноса клока на другую ногу проект просто перестал компилиться.
Выдавал ошибку <что-то там>Failed to find PLL reference clock.
В сообщениях квартуса также выводилась чертовщина с реф-клоком на pll, вроде я ему в sdc говорю, что он 100МГц, а квартус его воспринимает совсем другим (сейчас уже не помню цифру). Я и проект пересобирал с нуля, и танцы с бубенцами устраивал.
В конце концов вбил эту ошибку в гугл и получил ссылку http://www.altera.com/support/kdb/solution...282014_665.html.
Они предложили решить проблему с ошибкой компиляцией так: найти какой-то там их tcl файл, найти в нем такую то строчку, и заменить цифру 9 на большую цифру. Ну да, это помогло, проект скомпилился, только вот осадочек остался после нескольких дней мучений.

Quartus 14.1, Cyclone V, (5CEFA5F23), самостройная плата, LPDDR2 Controller with UniPHY, Enable hard external memory controller.

LPDDR2 - Banks 8A, 9A;
А вот вход клока - пин CLK3p, Bank 4A, 25MHz, сначала был подан на pll_0, выходы pll_0 125MHz подавал на весь QSYS и отдельный выход pll_0 - на вход pll UniPHY.

Использовал как основу проект из "Terasic Cyclone V GX Starter Kit", естественно со своим чипом и пинаутом.

Вообще не проходил fitter - не помню точно ошибку, но что-то с невозможностью развести реф клок pll UniPHY.
(пока как источник клока UniPHY использовался выход pll_0)

Помогло включение между пином CLK3p и входом pll UniPHY мегафункции ALTCLKCTRL.

Фиттер прошел.

В TimeQuest куча слаков. Пока в слаках не разбирался, т.к. в проект включен сгенерированный QSYS'ом неслабый "C5G_QSYS_mem_if_lpddr2_emif_p0.sdc".

NIOS_Memory_test (из базовых) на железе прошел.

Сообщение отредактировал sast777 - Jan 8 2015, 19:33

Спасибо, но этот этап я уже прошёл. У меня всё компилируется, но либо ошибка с трактовкой SDC, либо ошибка в самом SDC. То есть времянка неправильно считается.



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

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

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

2 DmitryR
тут без Qsys не получится,
выложите Qsys-шаблон где валится и версию Q - тогда можно глянуть..

У меня в проекте не используется Qsys.

Что самое интересное - сейчас обнаружил, что времянка разваливается, даже если в проект включить только контроллер, не включая его SDC.

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

Замечание вроде правильное, но почему-то не помогает. Разница, правда, есть: если поставить 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. Трэш какой-то.

А у меня такой ещё вопрос: в TimeQuest есть какой-нибудь способ выяснить, откуда он взял констрейн? Ну вот например он мне показывает, что период клока должен быть 3.2 вместо ожидаемых мной 8-ми. Можно его как-то попросить сказать, исходя из какой команды в каком файле он так решил?

а что происходит если убрать pll_0?
собирается?

Нет, не может DLL разместить (у меня вход с кварца и память на разных сторонах кристалла).

а с pll_0 получается только 125 или ещё какие-то частоты? это исходя из предположения что отводы от одной pll до другой имеются не на всех делителях, а только на первых двух (c0, c1)

можно пробовать перебирать варианты:
- пропустить refclock с одной стороны на другую через GCLK?
- пропустить refclock с одной стороны на другую через altiobuf_bidir на "пустом" (внешне электрически никуда не подключенном, если такой есть) CLKIN выводе, с той стороны где расположен контроллер?

можно пошагово запускать анализ, в ручную тыкая на этапы анализа. или посмотреть все клоки, которые объявлены в проекте