billidean 0 17 февраля, 2012 Опубликовано 17 февраля, 2012 · Жалоба Здравствуйте. Имеется проект под 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 меняется, и это не есть гуд. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 17 февраля, 2012 Опубликовано 17 февраля, 2012 · Жалоба в Q11 вроде как Classic TA нет, скрипты TQ написаны? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Adv 0 17 февраля, 2012 Опубликовано 17 февраля, 2012 · Жалоба Здравствуйте. Имеется проект под 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 меняется, и это не есть гуд. Этот контроллер более не поддерживается для выбранного Вами семейства. Предлагают использовать ТОЛЬКО 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 так не может. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sergey_Bekrenyov 0 18 февраля, 2012 Опубликовано 18 февраля, 2012 · Жалоба Здравствуйте. Имеется проект под 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 меняется, и это не есть гуд. Local_ready падает в '0' при записи и чтении в начале burst'а - это нормально для HPCII. Мне это тоже не нравится, но это объективная реальность. Local_ready может быть всегда нулю только в случае не прохождения инициализации (калибровки или грузите неправильные значения в регистры памяти). Посмотрите на local_init_done. Есть еще проблема при нецелостной записи/чтения burst'a - сигнал готовности падает в ноль навсегда. Это может случится если не обращаете внимания на local_ready. Читайте доку Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
billidean 0 21 февраля, 2012 Опубликовано 21 февраля, 2012 · Жалоба Спасибо всем за ответы. Буду думать, что дальше делать. Может обратно на Q9.1 перейду. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sergey_Bekrenyov 0 21 февраля, 2012 Опубликовано 21 февраля, 2012 · Жалоба Спасибо всем за ответы. Буду думать, что дальше делать. Может обратно на Q9.1 перейду. Не надо обратно на 9.1 DDR controller обновился очень существенно. Даже между 10-ыми версиями была большая разница - стал гораздо надежней. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
billidean 0 27 февраля, 2012 Опубликовано 27 февраля, 2012 (изменено) · Жалоба Не надо обратно на 9.1 DDR controller обновился очень существенно. Даже между 10-ыми версиями была большая разница - стал гораздо надежней. Ага, только теперь(в Квартусе11.1) нужно использовать контроллер с UniPHY, т.е. генерить не через МегаВизард (не генерится), а через qSys. После генерации ядра с UniPHY в qSys (только DDR3-ядро) я подключил полученный компонент к своему проекту, обвязал его и... получил ошибку, что фиттер не может сделать режим open-drain для ног mem_ck[0] и mem_ck_n[0], т.е. для тактовых ног. Может я что-то не так понимаю и делаю?? :help: З.Ы.: моя система в qSys: ошибки при компиляции: Изменено 27 февраля, 2012 пользователем billidean Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
billidean 0 27 февраля, 2012 Опубликовано 27 февраля, 2012 · Жалоба Установил СервисПак 2 для квартуса 11.1, теперь МегаВизард генерит ядро контроллера с UniPHY. Но при компиляции ошибка та же самая. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Adv 0 27 февраля, 2012 Опубликовано 27 февраля, 2012 · Жалоба Ага, только теперь(в Квартусе11.1) нужно использовать контроллер с UniPHY, т.е. генерить не через МегаВизард (не генерится), а через qSys. После генерации ядра с UniPHY в qSys (только DDR3-ядро) я подключил полученный компонент к своему проекту, обвязал его и... получил ошибку, что фиттер не может сделать режим open-drain для ног mem_ck[0] и mem_ck_n[0], т.е. для тактовых ног. Может я что-то не так понимаю и делаю?? :help: З.Ы.: моя система в qSys: ошибки при компиляции: Уважаемый 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 (!!) Будьте внимательны. emi_tut_qdr.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
billidean 0 28 февраля, 2012 Опубликовано 28 февраля, 2012 · Жалоба Я глубоко извиняюсь, но проблема с "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" нашел следующее: подкорректировал по их описанию, и, О ЧУДО, компилер не выдал ошибки. А мой проект заработал наконец. З.Ы.: если кому-то помогла моя тема, я буду рад. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Adv 0 28 февраля, 2012 Опубликовано 28 февраля, 2012 · Жалоба Вы ещё и в VHDL ядро генерировали..... Яcно. В VERILOG этой ошибки просто нет (при генерировании в мегавизарде выбрать VERILOG а не VHDL). Почти все (за редким исключением) ядра Алтеры - это Верилог. И для других языков - проблемы типа этой. К сведению. С уважением Adv. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
billidean 0 28 февраля, 2012 Опубликовано 28 февраля, 2012 · Жалоба Вы ещё и в VHDL ядро генерировали..... мы легких путей не ищем В VERILOG этой ошибки просто нет (при генерировании в мегавизарде выбрать VERILOG а не VHDL). Да уж, я это уже понял :laughing: Но я рад, что наконец победил эту проблему. З.Ы.: Спасибо за помощь всем, кто отозвался Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Adv 0 28 февраля, 2012 Опубликовано 28 февраля, 2012 · Жалоба мы легких путей не ищем Мудрость гласит - если уж совсем ничего не получается, то загляните, наконец, в инструкцию..... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
warrior-2001 0 7 марта, 2012 Опубликовано 7 марта, 2012 · Жалоба Сигнал Local_ready падает в ноль, когда забились внутренние фифошки контроллера. Псоле снятия внешнего сброса он почти сразу устанавливается в 1 задолго до понятия local_init_done. Такое поведение наблюдаю в модели. В железе советую сперва дождаться local_init_done, а уж подом совершать какие-то действия с контроллером. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
