Здравствуйте.

Имеется проект под StratixIV на Q9.1, который качает данные в DDR3 и из нее.
Используется HPC II.
Все работает отлично.

Далее, взял этот проект и вставил его как компонент в другой проект, который создан в Q11.1.
Здесь-то и началось все веселье.
Сначала Квартус потребовал перегенерить ядро HPC II, ладно сделал, проект вроде скомпилился.
Заливаю в кристалл, обмена с DDR-кой нет.
Смотрю на SignalTap'е, сигнал local_ready='0' с самого начала, т.е. он даже не был в '1'.
Перекомпилил проект, залил, обмен есть, но поведение сигнала local_ready мне не нравится, при записи данных в DDR-ку он иногда падает в '0'.
Такого поведения от него я не видел при отладке начального проекта в Q9.1, там этот сигнал падал в '0' только при вычитывании большого объема данных из DDR-ки, когда буфер контроллера HPC II заполнялся.

Кто может что-нибудь посоветовать, как победить проблему в Q11.1???

З.Ы.: после каждой перекомпиляции поведение конртоллера HPC II меняется, и это не есть гуд.

в Q11 вроде как Classic TA нет, скрипты TQ написаны?

Этот контроллер более не поддерживается для выбранного Вами семейства. Предлагают использовать ТОЛЬКО UNI PHY.
Ниже - таблица из документа Introduction to ALTMEMPHY IP (http://www.altera.com/literature/hb/external-memory/emi_altmemphy_ref_intro.pdf)

Table 13–3. Device Family Support
Device Family
Protocol
DDR and DDR2 DDR3
Arria® GX Final No support
Arria II GX Final Final
Cyclone® III Final No support
Cyclone III LS Final No support
Cyclone IV E Final No support
Cyclone IV GX Final No support
HardCopy II Refer to the What’s New in Altera
IP page of the Altera website. No support
Stratix® II Final No support
Stratix II GX Final No support
Other device families No support No support Почёркнуто мной.

Предупреждаю - тот с ещё большими причудами. Там процессорная система для калибровки (в самом ядре). Особенно если у Вас высокая частота (на прим. 533МГц)
И причуды - сама версия 11.1. Со вторым сервиспаком, вроде получше, а до этого - регенерировать систему (использую QSYS) было просто невозможно - всё падало. Пересоздавал проект - работает как часы. Регенерирую - всё валится снова....

Однако, было бы несправедливо не сказать - эта самая система "вытягивает" почти безнадёжные (с точки зрения правильности трассировки - их бракует HL2010, море красного...) платы. Работают без сбоев. HPC II так не может.

Local_ready падает в '0' при записи и чтении в начале burst'а - это нормально для HPCII. Мне это тоже не нравится, но это объективная реальность.
Local_ready может быть всегда нулю только в случае не прохождения инициализации (калибровки или грузите неправильные значения в регистры памяти). Посмотрите на local_init_done.
Есть еще проблема при нецелостной записи/чтения burst'a - сигнал готовности падает в ноль навсегда. Это может случится если не обращаете внимания на local_ready.

Читайте доку

Спасибо всем за ответы.
Буду думать, что дальше делать. Может обратно на Q9.1 перейду.

Не надо обратно на 9.1 DDR controller обновился очень существенно. Даже между 10-ыми версиями была большая разница - стал гораздо надежней.

Ага, только теперь(в Квартусе11.1) нужно использовать контроллер с UniPHY, т.е. генерить не через МегаВизард (не генерится), а через qSys.
После генерации ядра с UniPHY в qSys (только DDR3-ядро) я подключил полученный компонент к своему проекту, обвязал его и... получил ошибку, что фиттер не может сделать режим open-drain для ног mem_ck[0] и mem_ck_n[0], т.е. для тактовых ног.

Может я что-то не так понимаю и делаю??

З.Ы.: моя система в qSys: Нажмите для просмотра прикрепленного файла
ошибки при компиляции: Нажмите для просмотра прикрепленного файла

Установил СервисПак 2 для квартуса 11.1, теперь МегаВизард генерит ядро контроллера с UniPHY.
Но при компиляции ошибка та же самая.

Уважаемый billidean! Вы скрипты запускали перед компиляцией? Пожалуйста, почитайте это - www.altera.com/literature/hb/external-memory/emi_tut_qdr.pdf.
Это - пример использования UNI PHY, рабочий. Проверял .
В .qsf файле проекта должны быть такие (или похожие, эти - из моего проекта...) строки (это выдержка - там их много после запуска скрипта *_pin_assignments.tcl):

.................
set_instance_assignment -name INPUT_TERMINATION "PARALLEL 50 OHM WITH CALIBRATION" -to ddr3_mem_dqs_n[1] -tag __pr_16_ddr3_p0
set_instance_assignment -name OUTPUT_TERMINATION "SERIES 50 OHM WITH CALIBRATION" -to ddr3_mem_dqs_n[1] -tag __pr_16_ddr3_p0
set_instance_assignment -name IO_STANDARD "DIFFERENTIAL 1.5-V SSTL CLASS I" -to ddr3_mem_ck -tag __pr_16_ddr3_p0
set_instance_assignment -name OUTPUT_TERMINATION "SERIES 50 OHM WITHOUT CALIBRATION" -to ddr3_mem_ck -tag __pr_16_ddr3_p0
set_instance_assignment -name IO_STANDARD "DIFFERENTIAL 1.5-V SSTL CLASS I" -to ddr3_mem_ck_n -tag __pr_16_ddr3_p0
set_instance_assignment -name OUTPUT_TERMINATION "SERIES 50 OHM WITHOUT CALIBRATION" -to ddr3_mem_ck_n -tag __pr_16_ddr3_p0
set_instance_assignment -name IO_STANDARD "SSTL-15 CLASS I" -to ddr3_mem_a[0] -tag __pr_16_ddr3_p0
set_instance_assignment -name CURRENT_STRENGTH_NEW "MAXIMUM CURRENT" -to ddr3_mem_a[0] -tag __pr_16_ddr3_p0
..........

и т.д.

Нет там открытого коллектора (open-drain) и близко. Используется динамическая терминация (Dynamic ODT). Полагаю - и у Вас тоже используется.
Заранее прошу прощения , если Вы это уже читали.

p.s. На всяк случай прикрепляю пример. И вот что - если у Вас ранее отработал скрипт от Altmemphy (*_pin_assignments.tcl) - то всё равно запускайте его по-новому (от uni PHY, разумеется).
Порядок запуска скрипта ОТЛИЧАЕТСЯ от запуска в Altmemphy (!!) Будьте внимательны.

Я глубоко извиняюсь, но проблема с "open-drain" была по моей причине. Дело в том, что в Квартусе 9.1 DDR3-ядро после генерации имело для выводов mem_ck и mem_ck_n тип "inout", а в Квартусе 11.1 они имеют уже тип "out". Поэтому пользуясь старыми скриптами, я подключал ядро к прежнему проекту, где тип выводов был описан как "inout", и при компиляции появлялись эти ошибки.

Создал новый проект в Квартусе 11.1, создал МегаВизардом DDR3-ядро с UniPHY, подкорректировал типы выводов, запустил компиляцию... и опять мимо...
ошибка получилась такая, что фиттер не смог развести две диф-пары(это уже обуждалось в одной из моих тем Проблема с пинами в Q_11.1).

Из документа "MegaCore IP Library - Release Notes and Errata" нашел следующее:
Нажмите для просмотра прикрепленного файла
подкорректировал по их описанию, и, О ЧУДО, компилер не выдал ошибки. А мой проект заработал наконец.

З.Ы.: если кому-то помогла моя тема, я буду рад.

Вы ещё и в VHDL ядро генерировали.....
Яcно. В VERILOG этой ошибки просто нет (при генерировании в мегавизарде выбрать VERILOG а не VHDL). Почти все (за редким исключением) ядра Алтеры - это Верилог. И для других языков - проблемы типа этой. К сведению.
С уважением Adv.

мы легких путей не ищем


Да уж, я это уже понял

Но я рад, что наконец победил эту проблему.

З.Ы.: Спасибо за помощь всем, кто отозвался

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

Сигнал Local_ready падает в ноль, когда забились внутренние фифошки контроллера. Псоле снятия внешнего сброса он почти сразу устанавливается в 1 задолго до понятия local_init_done.
Такое поведение наблюдаю в модели. В железе советую сперва дождаться local_init_done, а уж подом совершать какие-то действия с контроллером.