|
|
  |
проблема с DDR3 local_ready(StratixIV), проблема с сигналом local_ready |
|
|
|
Feb 17 2012, 06:55
|
Местный
  
Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925

|
Здравствуйте.
Имеется проект под 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 меняется, и это не есть гуд.
|
|
|
|
|
Feb 17 2012, 22:51
|
Частый гость
 
Группа: Свой
Сообщений: 108
Регистрация: 6-08-05
Из: Винница
Пользователь №: 7 407

|
Цитата(billidean @ Feb 17 2012, 10:55)  Здравствуйте.
Имеется проект под 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 так не может.
|
|
|
|
|
Feb 18 2012, 13:47
|

Местный
  
Группа: Свой
Сообщений: 323
Регистрация: 14-12-10
Из: Королёв
Пользователь №: 61 599

|
Цитата(billidean @ Feb 17 2012, 10:55)  Здравствуйте.
Имеется проект под 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. Читайте доку
|
|
|
|
|
Feb 27 2012, 07:55
|
Местный
  
Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925

|
Цитата(Sergey_Bekrenyov @ Feb 21 2012, 11:43)  Не надо обратно на 9.1 DDR controller обновился очень существенно. Даже между 10-ыми версиями была большая разница - стал гораздо надежней. Ага, только теперь(в Квартусе11.1) нужно использовать контроллер с UniPHY, т.е. генерить не через МегаВизард (не генерится), а через qSys. После генерации ядра с UniPHY в qSys (только DDR3-ядро) я подключил полученный компонент к своему проекту, обвязал его и... получил ошибку, что фиттер не может сделать режим open-drain для ног mem_ck[0] и mem_ck_n[0], т.е. для тактовых ног. Может я что-то не так понимаю и делаю??  З.Ы.: моя система в qSys:
ошибки при компиляции:
Сообщение отредактировал billidean - Feb 27 2012, 08:40
|
|
|
|
|
Feb 27 2012, 22:24
|
Частый гость
 
Группа: Свой
Сообщений: 108
Регистрация: 6-08-05
Из: Винница
Пользователь №: 7 407

|
Цитата(billidean @ Feb 27 2012, 11:55)  Ага, только теперь(в Квартусе11.1) нужно использовать контроллер с UniPHY, т.е. генерить не через МегаВизард (не генерится), а через qSys. После генерации ядра с UniPHY в qSys (только DDR3-ядро) я подключил полученный компонент к своему проекту, обвязал его и... получил ошибку, что фиттер не может сделать режим open-drain для ног mem_ck[0] и mem_ck_n[0], т.е. для тактовых ног. Может я что-то не так понимаю и делаю??  З.Ы.: моя система в 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_p0set_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 (!!) Будьте внимательны.
|
|
|
|
|
Feb 28 2012, 10:11
|
Местный
  
Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925

|
Я глубоко извиняюсь, но проблема с "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" нашел следующее:
подкорректировал по их описанию, и, О ЧУДО, компилер не выдал ошибки. А мой проект заработал наконец. З.Ы.: если кому-то помогла моя тема, я буду рад.
|
|
|
|
|
Feb 28 2012, 12:55
|
Местный
  
Группа: Свой
Сообщений: 247
Регистрация: 4-10-10
Из: г. Екатеринбург
Пользователь №: 59 925

|
Цитата(Adv @ Feb 28 2012, 15:01)  Вы ещё и в VHDL ядро генерировали.....  мы легких путей не ищем Цитата(Adv @ Feb 28 2012, 15:01)  В VERILOG этой ошибки просто нет (при генерировании в мегавизарде выбрать VERILOG а не VHDL). Да уж, я это уже понял Но я рад, что наконец победил эту проблему. З.Ы.: Спасибо за помощь всем, кто отозвался
|
|
|
|
|
  |
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|