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

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



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

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

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

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

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

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

В документе 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. Трэш какой-то.

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

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

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

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

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

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

Я уже попробовал пропустить частоту на DRAM через отдельную PLL, а все остальные частоты проекта формировать на другой. Не помогает.

В Timequest GUI при выполнении "Update Timing Netlist" в консоли появится строчка типа "Info:deriving PLL clocks", её надо развернуть, и там будут написаны все команды, которыми были автоматически заданы PLL клоки. Возможно, поможет ручное задание всех PLL клоков, если автоматическое неправильное.

Там всё правильно. Посмотрел весь лог - не нашёл ничего подозрительного. А команда Report Timing всё равно выдаёт ожидаемый период 3.2 вместо 8.

Вобщем, кроме отказа от derive_pll_clocks и описания клоков вручную решение такое: сделать референсную частоту контроллера DRAM равной референсной частоте PLL. Я смотрел отчёты TimeQuest и обнаружил, что констрейн на входную частоту оказывается равен референсной частоте контроллера DRAM почему-то. Туда шло 125МГц, а на вход PLL - 50МГц. Отсюда и 3.2нс вместо 8-ми.

У меня такая же проблема на плате стоит Cyclone V. Имеется два контроллера DDR2, собираю проект в Quartus 14.1.1, а Timing Analyzer не проходит. Хотя иногда получалось без ошибок, но почему так и не понял.
Нашли решение?

Подниму тему.
Чтение документации и форумов, моделирование и чтение отчетов Quartus привели к неожиданной для меня проблеме. Пытаюсь осилить DDR3 SDRAM Hard Controller для CycloneV на 333 МГц. Оказывается данные подающиеся на контроллер DDR3 тактируются с частотой, подаваемой на внешнюю ногу входа PLL контроллера DDR3. Т. е. по задумке разработчиков из Intel(Altera) я должен подавать данные синхронно со внешней частотой, а это жутко неудобно. Вот что, например, отвечает support. Quartus выдаёт сообщения типа такого. Предлагаются способы типа такого или использование примитива или The DDR3 clock hack. Последний способ, не разобрался как применить .
Не могу сообразить как всё таки правильнее писать данные в DDR3, получаемые с быстрого последовательного интерфейса скажем 830 Mbps. Т.е. тактовая частота 415 МГц. Есть ли какой-нибудь пример дизайна, разработанного самой Altera, чтобы посмотреть как они преодолевают созданную самой же Altera проблему. Ну или поделитесь собственным опытом в этом вопросе .

ну вроде как в описании написано
The ALTMEMPHY megafunction automatically generates a PLL instance, but you
must still provide the reference clock input (pll_ref_clk) with a clock of the
frequency that you specified in the MegaWizard interface

Она внутри сделает сама PLL и ей нужен опорный клок.

дальше написано

A clock output, which is half the memory clock
frequency for a half-rate controller and the same as the memory clock for a full-rate
controller, is provided (phy_clk or aux_half_rate_clk) and all inputs and
outputs of the ALTMEMPHY megafunction are synchronous to this clock

То есть вам выдадут наружу клок с добавленного PLL с половинной или полной частотой, и вся работа этого модуля синхрона этому клоку. Ничего не поделаешь, модуль который читает и пишет данные через эту корку должен работать на этом клоке.

Но я не вижу требований чтобы он работал на внешнем клоке....
в приведенном вами ответе супорта написано
The reference input clock signal to the PLL must be driven by the dedicated clock input pin located adjacent to the PLL, or from the clock output signal from the adjacent PLL.
это стандартное требование клок который идет на вход PLL должен заходить либо с близкой специальной клоковой ноги, либо с выхода близкой PLL. Так как внутри мем контроллера будет добавлено PLL, то опорный клок для нее подаваемый на ногу должен быть хорошим, который не тянули через весь кристалл. Но тут не сказано что вы должны всю схему строить на этом опорном клоке.

В том, то и дело, что при каскадировании PLL, слетают тайминги про что и говорится в этом топике. Т.е. получается клок pll_ref_clk должен идти только с внешней ножки FPGA. В emi.pdf написано, конкретнее в PLL Cascading:
The UniPHY IP does not support PLL cascading using the global and regional clock networks.
А это я так понимаю мой случай. Да и квартус ругается.
Или я чего-то не понимаю?

not support PLL cascading using the global and regional clock networks.

Ну значит это не мой случай. Но факт остаётся фактом. Квартус ругается. Тайминги слетают и не только у меня. Народ как-то пытается выкручиваться. Поэтому я прошу поделиться опытом.

Вы должны подавать данные синхронно с выходной частотой PLL(afi_half_clk или afi_clk), которая внутри DDR контроллера, а не с внешней частотой. Если у вас QSYS, то можете свой master тактировать от любой частоты, QSYS сам вставит логику для перехода между клоковыми доменами. Но я стараюсь все мастера на шине DDR заставить рабoтать на afi_half_clk, чтобы лишних переходов не было

Ещё раз проверил на тестовом примере. Данные пишутся и читаются синхронно с частотой pll_ref_clk. Вы точно говорите про Hard Controller? С soft насколько я помню при моделировании тестового примера у меня было всё по другому и скорее всего как вы говорите.

hard или soft не имеет значение, принцип тот же самый. Вы QSYS используете?

Нет QSYS не применяю. Странно. У меня имеет принципиальное значение. Вот нашел своё старое сообщение.

А, у вас видимо на mp_cmd_clk_xx заведен тот же клок что и на pll_ref_clk. Вот альтеровский реф дизайн, где они так же делают.
http://www.alterawiki.com/wiki/Reference_D...ed_for_User_ECC

Я для этого использую afi_half_clk, где-то в примерах работы с видео я именно такое решение видел

Промоделировал тестовый пример. Вы правы mp_cmd_clk_0_clk совпадает с pll_ref_clk. Спасибо за наводку. Буду дальше разбираться.

Burenkov Sergey
Большое спасибо! Всё получилось.
Не подскажете, как вы моделируете проект с DDR3? Я нашел только способ подсказанный в этом посте.