Помогите запустить MCB, Spartan6 + ddr3 Опции

[Nosss]

Здравствуйте! Есть ПЛИС Spartan-6 xc6slx150-3fgg484 и внешняя память DDR3 MT41J64M16LA-187E. Память подключена к третьему банку ПЛИС. Частота работы с памятью 300 МГц.

В ISE12.4 сделал проект контроллера памяти с помощью MIG. В проекте оставил один двунаправленный порт х32. Взял example_design. Отмоделировал - все в порядке. А вот при тестировании в железе начались проблемы, которые никак не удается победить. Проблемы двух типов:

1) При чтении пачки данных одно из данных застревает на выходе FIFO на несколько тактов. При этом часть данных теряется. Эта ситуация показана на картинке error1. Ошибка повторяется время от времени в процессе тестирования. Данная ошибка, как выяснилось, зависит от частоты работы. На 250 МГц ее вероятность намного меньше, а на 200 МГц она вообще пропадает. Также ситуация стала лучше после того, как поменял настройку Unused IOB Pins = Float на Pull Down в свойствах генерации программного файла.

2) Начиная с какого-то момента, контроллер просто перестает выполнять новые запросы. В результате переполняется командное FIFO и тест останавливается. Вероятность этой ошибки зависит от диапазона тестируемых адресов. Если значение параметра C3_HW_TESTING = "FALSE", то встречается она очень редко. Если же поставить "TRUE" - ошибка происходит тут же при начале тестирования. Такая ситуация повторяется на любой частоте от 200 до 300 МГц.

В чем тут может быть дело?

Эскизы прикрепленных изображений

 

[Shtirlits]

Что за плата?

[Nosss]

Плата dini-group DNBFC_S12_PCIe. Можно здесь посмотреть на этого зверя http://www.dinigroup.com/new/DNBFC_S12_PCIe.html

[Shtirlits]

С такими платами обычно поставляется reference design и тест.
Вообще-то, они пишут про 400 MHz.

[Nosss]

С такими платами обычно поставляется reference design и тест.

Да, действительно, есть и reference design и тест. Их тест тоже выдает ошибку, но понять что она значит довольно трудно. Документация у них, мягко говоря, очень скудная. А удовольствие ковыряться в чужом коде я оставил себе напоследок, решив, что проще будет самому сделать. Ведь на первый взгляд ничего сложного...

Вообще-то, они пишут про 400 MHz.

Если можно работать с памятью на 400, то и на 300 можно. Ограничений здесь ни со стороны памяти, ни со стороны ПЛИС я не вижу. Кстати, reference design у них как раз на 300 работает.

[Shtirlits]

Так он работает или выдает ошибку?
Запросто может быть что-то физически негодным и плату надо менять.
Она у вас одна? Другой экземпляр не пробовали?
Я не уверен, что контроллер в спартане поддерживает 400MHz - надо взглянуть в документацию.

[Bad0512]

Здравствуйте! Есть ПЛИС Spartan-6 xc6slx150-3fgg484 и внешняя память DDR3 MT41J64M16LA-187E. Память подключена к третьему банку ПЛИС. Частота работы с памятью 300 МГц.

В ISE12.4 сделал проект контроллера памяти с помощью MIG. В проекте оставил один двунаправленный порт х32. Взял example_design. Отмоделировал - все в порядке. А вот при тестировании в железе начались проблемы, которые никак не удается победить. Проблемы двух типов:

1) При чтении пачки данных одно из данных застревает на выходе FIFO на несколько тактов. При этом часть данных теряется. Эта ситуация показана на картинке error1. Ошибка повторяется время от времени в процессе тестирования. Данная ошибка, как выяснилось, зависит от частоты работы. На 250 МГц ее вероятность намного меньше, а на 200 МГц она вообще пропадает. Также ситуация стала лучше после того, как поменял настройку Unused IOB Pins = Float на Pull Down в свойствах генерации программного файла.

2) Начиная с какого-то момента, контроллер просто перестает выполнять новые запросы. В результате переполняется командное FIFO и тест останавливается. Вероятность этой ошибки зависит от диапазона тестируемых адресов. Если значение параметра C3_HW_TESTING = "FALSE", то встречается она очень редко. Если же поставить "TRUE" - ошибка происходит тут же при начале тестирования. Такая ситуация повторяется на любой частоте от 200 до 300 МГц.

В чем тут может быть дело?

Судя по картинкам - диаграммы вроде правильные у вас. Сигнал контроллера init_done вскакивает в 1 после сброса? А то может ваш контроллер калибровку пройти не смог, а вы его командами записи - чтения насилуете?

P.S. Оффтопик : когда я смотрю на подобные "лыжи" ( так называют платы монстроидальных размеров) - мне становится страшно... Неужели существуют задачи, которые можно решить только с помощью таких монстров? И при этом нагрузить все 12 спартанов с их памятью? Что-то я сомневаюсь...

[Nosss]

Тест, который поставляется вместе с платой выдает ошибку, которую мы понять не можем, так как нет нормального описания к этому тесту. Плата у нас одна, к сожалению. Но там 12 ПЛИС и все ведут себя примерно одинаково. Хотя можно среди них выделить те, которые работают чуть лучше остальных. Контроллер в спартане 400 поддерживает при выполнении определенных условий (MIG об этом говорит).

Просто я думал, может у кого было что-нибудь подобное...

Судя по картинкам - диаграммы вроде правильные у вас. Сигнал контроллера init_done вскакивает в 1 после сброса? А то может ваш контроллер калибровку пройти не смог, а вы его командами записи - чтения насилуете?

Что за сигнал init_done? Там есть сигнал calib_done. Он в 1, таким образом, я понимаю, что калибровка завершилась удачно.

[Shtirlits]

Покажите, если не лень, какие данные пишутся и читаются на минимальной частоте, на которой сбои еще происходят и на максимальной. По данным можно попытаться угадать, что за глюк.
Еще можно послать письмо об ошибке производителю платы - чего стесняться-то?

[Nosss]

Покажите, если не лень, какие данные пишутся и читаются на минимальной частоте, на которой сбои еще происходят и на максимальной. По данным можно попытаться угадать, что за глюк.

Сбой заключается в том, что одно из данных в потоке "залипает" на выходе FIFO. Вследствие этого часть данных теряется. И на максимальной, и на минимальной частоте это выглядит одинаково. Побитовых сбоев нет - то что пишу, то и читаю обратно. Если не лень, можете глянуть wlf файл. Я его получил из vcd файла, который вытащил из ChipScopa. Ошибка происходит в 343 нс и в 382 нс.

Еще можно послать письмо об ошибке производителю платы - чего стесняться-то?

Письмо отправили - отвечать не торопятся.

Прикрепленные файлы

 VCD_WLF.rar ( 16.01 килобайт ) Кол-во скачиваний: 17

 

[Victor®]

Здравствуйте! Есть ПЛИС Spartan-6 xc6slx150-3fgg484 и внешняя память DDR3 MT41J64M16LA-187E. Память подключена к третьему банку ПЛИС. Частота работы с памятью 300 МГц.

В ISE12.4 сделал проект контроллера памяти с помощью MIG. В проекте оставил один двунаправленный порт х32. Взял example_design. Отмоделировал - все в порядке. А вот при тестировании в железе начались проблемы, которые никак не удается победить. Проблемы двух типов:

1) При чтении пачки данных одно из данных застревает на выходе FIFO на несколько тактов. При этом часть данных теряется. Эта ситуация показана на картинке error1. Ошибка повторяется время от времени в процессе тестирования. Данная ошибка, как выяснилось, зависит от частоты работы. На 250 МГц ее вероятность намного меньше, а на 200 МГц она вообще пропадает. Также ситуация стала лучше после того, как поменял настройку Unused IOB Pins = Float на Pull Down в свойствах генерации программного файла.

2) Начиная с какого-то момента, контроллер просто перестает выполнять новые запросы. В результате переполняется командное FIFO и тест останавливается. Вероятность этой ошибки зависит от диапазона тестируемых адресов. Если значение параметра C3_HW_TESTING = "FALSE", то встречается она очень редко. Если же поставить "TRUE" - ошибка происходит тут же при начале тестирования. Такая ситуация повторяется на любой частоте от 200 до 300 МГц.

В чем тут может быть дело?

Не из этой оперы?
http://www.xilinx.com/support/answers/35978.htm

P.S.
и еще
http://www.xilinx.com/support/answers/33566.htm

[Nosss]

Не из этой оперы?
http://www.xilinx.com/support/answers/35978.htm

У меня ISE 12.4. В нем как бы обещали поправить уже этот глюк.

P.S.
и еще
http://www.xilinx.com/support/answers/33566.htm

И это не про меня. После загрузки конфигураций сброс подавал несколько раз - ситуация не меняется.


Хочу заодно спросить. Есть ли у кого-нибудь положительный опыт работы со связкой spartan6 + ddr3 ?

[billidean]

может дело не при чтении вовсе, а, например, когда идет режим записи данных, они снаружи переключаются на следующие, а уже в железо не записываются, какие-нибудь коллизии или задержки или недоустановка адресов например

[Shtirlits]

Да, данные перестают меняться, посмотрел первое из мест.
Может быть и проблема записи.

[Nosss]

А мне кажется что проблема там с чтением. Данные всегда теряются пакетами, насколько я заметил (1 пакет = 4 слова х32 = 8 слов х16). То есть память почему-то не понимает команду чтения, на шине стоит старая информация, которую контроллер всасывает и отдает мне.

[Nosss]

Нет, соврал я. Сегодня посмотрел внимательнее: может теряться 1, 2, 3, 4 и более данных х32.

[Nosss]

Немного прояснилась ситуация. Оказалось, что на плате установлены ES FPGA. IDCODE = 0401d093, Manufacturer's ID = Xilinx xc6slx150, version 0. На 99 процентов уверен в том, что контроллеры памяти на этих ПЛИС просто сырые. На этой же плате установлена интерфейсная ПЛИС Dataflow Manager xc6slx150t-2fgg676. Она оказалась тоже ES, но тот же самый проект в этой ПЛИС работает как часы на максимальной заявленной частоте 333 МГц (для sg2). Вот такие пирожки. А техподдержка dinigroup так и не ответила...

[VladimirB]

Немного прояснилась ситуация. Оказалось, что на плате установлены ES FPGA. IDCODE = 0401d093, Manufacturer's ID = Xilinx xc6slx150, version 0. На 99 процентов уверен в том, что контроллеры памяти на этих ПЛИС просто сырые. На этой же плате установлена интерфейсная ПЛИС Dataflow Manager xc6slx150t-2fgg676. Она оказалась тоже ES, но тот же самый проект в этой ПЛИС работает как часы на максимальной заявленной частоте 333 МГц (для sg2). Вот такие пирожки. А техподдержка dinigroup так и не ответила...

посмотрите в еррату

Прикрепленные файлы

 en115.pdf ( 169.5 килобайт ) Кол-во скачиваний: 407

 

[Nosss]

посмотрите в еррату

Я смотрел ее. Моя ситуация после этого яснее не стала. Написано, что должны работать, но не работают ведь. Если вы про hold time, то я пробовал поставить заплатку, которая рекомендована в AR34089 - стало еще хуже, посыпались просто не те данные. Вывод прежний - MCB сырые в этих ПЛИС.

[VladimirB]

Я смотрел ее. Моя ситуация после этого яснее не стала. Написано, что должны работать, но не работают ведь. Если вы про hold time, то я пробовал поставить заплатку, которая рекомендована в AR34089 - стало еще хуже, посыпались просто не те данные. Вывод прежний - MCB сырые в этих ПЛИС.

В еррате ещё про напряжение ядра написано, попробуйте его немного повысить перепайкой задающих резисторов у техасовских
DC-DC конвертеров.

[Nosss]

В еррате ещё про напряжение ядра написано, попробуйте его немного повысить перепайкой задающих резисторов у техасовских
DC-DC конвертеров.

Оно на ядре и так повышенное, изначально. Это сделано специально, чтобы контроллер мог работать на максимальной частоте в режиме extended. Об этом в документации на плату говорится, и так оно и есть. Кроме того, я пробовал работать и на более низких частотах, до 200 МГц опускался, не помогает.

[Nosss]

Ну вот, дождался ответа от техподдержки Xilinx. Мои догадки подтвердились.

You have rev 1.0 of the silicon (first engineering sample).There are several known issues with that version of the silicon. One is the one that you are describing. You need to get a newer version of the silicon and in all likelihood this will fix the issue. If you still have problems after that we can debug this further. The schematics and termination look fine.

[Victor®]

Ну вот, дождался ответа от техподдержки Xilinx. Мои догадки подтвердились.

You have rev 1.0 of the silicon (first engineering sample).There are several known issues with that version of the silicon. One is the one that you are describing. You need to get a newer version of the silicon and in all likelihood this will fix the issue. If you still have problems after that we can debug this further. The schematics and termination look fine.

Позвольте поинтересоваться как вышли из ситуации?
Перепаивали? Dini-Group хоть как-то отреагировала на это? Или им главное продать?

[Nosss]

Позвольте поинтересоваться как вышли из ситуации?
Перепаивали? Dini-Group хоть как-то отреагировала на это? Или им главное продать?

Dini-Group ответили примерно через неделю, после чего отвечали регулярно. Они нас заверили, что все платы у них проходят тестирование перед продажей и проблем быть не должно. Однако, после того, как переслал им диаграммы с чип-скопа, признали, что с платой что-то не так. Предложили отправить плату им на ремонт, либо, если у нас сроки поджимают, были согласны на обмен. У нас эта ситуация пока развития не получила - начальство думает.

Да, разобрался-таки с их reference design - ведет себя в железе точно так же, как и мой собственный проект. Большие сомнения у меня, что у них эта плата успешно прошла тестирование. Хотя, все может быть, конечно.

Еще спросил, почему Xilinx нигде не поместил информацию об этой проблеме с ES, любопытно, что они ответили:
Unfortunately this was one of those issues that we failed to mention in the errata. The rev 1.0 LX150 ES devices had been shipped to a limited number of customers and since we fixed the issue in subsequent revs we didn't think it warranted issuing an errata on this.

[Victor®]

Dini-Group ответили примерно через неделю, после чего отвечали регулярно. Они нас заверили, что все платы у них проходят тестирование перед продажей и проблем быть не должно. Однако, после того, как переслал им диаграммы с чип-скопа, признали, что с платой что-то не так. Предложили отправить плату им на ремонт, либо, если у нас сроки поджимают, были согласны на обмен. У нас эта ситуация пока развития не получила - начальство думает.

Да, разобрался-таки с их reference design - ведет себя в железе точно так же, как и мой собственный проект. Большие сомнения у меня, что у них эта плата успешно прошла тестирование. Хотя, все может быть, конечно.

Еще спросил, почему Xilinx нигде не поместил информацию об этой проблеме с ES, любопытно, что они ответили:
Unfortunately this was one of those issues that we failed to mention in the errata. The rev 1.0 LX150 ES devices had been shipped to a limited number of customers and since we fixed the issue in subsequent revs we didn't think it warranted issuing an errata on this.

Ясно, спасибо что уделили время на ответ.
А то, вроде Dini не делает ширпотреб по первому впечатлению... а тут...
Успехов Вам!