Я уже попробовал пропустить частоту на 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, где-то в примерах работы с видео я именно такое решение видел