Здравствуйте!
Была изготовлена плата на virtex6 xcvlx240t с подключенными чипами памяти Micron MT41J128M16-15E.
Далее для проверки памяти я использовал MIG 3.7 example design. Тактовая памяти 400Мгц.

Калибровка памяти проходит успешно, что подтвердил chipscope. Но в модуле traffic gen при чтении выставляется флаг data_error.
То есть, насколько я понимаю, возникают ошибки при чтении данных из памяти.

Интересен факт, что traffic gen на тактовой памяти 200 МГЦ работет корректно, то есть калибровка проходит успешно и флаги data_error, data_error_set не активны. Но при этом минимальная частота работы ddr3 303 МГц следуя ds186 или я не прав?

Пробовал в два раза участить REFRESH на память. На 400 МГц ошибки не исчезли.
Может ли быть ошибка в топологии и от чего оттолкнуться в данном случае?

Помимо стандартного теста MIG 3.7 была создана модель интерфейса пользователя.
Моделировал в Aldec 8.3.

Записал гигабайт памяти 16 разрядным счетчиком (пилой) затем считал из памяти 4 Мб. Сохранил результат в файл. Отрисовал в Matlabe и убедился что пила без разрывов и выбросов.

Затем зашил проект в железо. Плата с памятью ddr3 соединена оптикой с платой подключеной по pciex8 к ЭВМ.
Сомнений в работе оптичекого канала связи, ядра pcie нет.

Проделал те же действия:
1) Записал 1 Гбайт счетчика в память.
2) Считал 1Гбайт блоками по 256 кбайт.
3) Сохранил результат в файл.

Общий вид файла с пилой:
Нажмите для просмотра прикрепленного файла
Увеличим
Нажмите для просмотра прикрепленного файла

То есть "вылетает" каждый четвертый отчет.
А к ПЛИС подключено 4 16-ти разрядных чипа. То есть шина DQ в этом варианте 64 бита. Режим работы с памятью поточный (BL=8).

Поделитесь пожалуйста мыслями на этот счет?

просто интересно, а как по каше на 2 картинке вы определили что вылетает каждый 4 отсчет?

у вас клоки что идут на ДДР генерятся отдельным PLL, в спартане 6 можно память запустить от любого клок генератора на кристале, но стабильно работать будет только от определенного, того что находит в банке который с контроллером памяти, и того что к контроллеру максимально близки. И кроме клоков памяти на этот блок ничего вешать нельзя. Потому что в этом режиме он включается по специальной схеме мего синхронной выдачи прямого и обратного клоков.

Поглядите на этот счет в вашей ПЛИСине, архитектура другая, но симптомы схожи.
У меня проходили тесты памяти пока кристал не нагревался, после все начинало сбоить, добавил регистры на шину, стало чуть стабильнее работать, но больший нагрев и все опять упало, долго с охлаждением возились, потом решил еще раз пересобрать все глядя в инструкцию, и нашел приписку про генератор клоков, поправил, и без регистров все сразу заработало, и грей хоть до зависания проца (микроблайз)...

информации явно мало.
всё ли было выполнено по ug406? включая разводку платы с учетом задержек на чипе? (aka "partgen -v xc6vlx240tff1156")
нет ли типовых ошибок при разводке, типа split plane или выравнивания длины "тромбонами"?
использовался ли DCI Cascading или в каждом банке он свой, честный?
всюду ли заведен VREF?
проверьте качество тактового 200 МГц, который подключен к IDELAYCTRL. про него почему-то часто забывают.

если есть phy_init_done значит инициализация чтение-запись по каждому DQ в каждую м/с памяти (по отдельности) прошла калибровку PRBS-последовательностью, при этом
если после этой процедуры вся шина рассыпается - это очень плохой знак, и без соответствующего оборудования для отладки можно сразу сдаваться. Это к тому, что на втором рисунке - абсолютно неинформативная каша.
если пытаться плясать от физики, и пытаться что-то сделать осциллографом, то прочтите хоть это: http://www.fidus.com/downloads/signal_inte..._Whitepaper.pdf там хоть есть примеры того, что надо смотреть осциллом.
Однако без правильного проекта с ucf с правильной распиновкой, констрейнами и RLOC'ами бросаться врукопашную на осциллограф тоже никакого смысла нет.

Проверяйте констрейны и рекомендации по размещению/разводке.
У Альтеры есть хорошая программка - "External memory interface toolkit", позволяет смотреть работу памяти. У Xilinx может быть то же самое.

Для Krux:
Типовых ошибок на мой взгляд нет, но файл с топологией разводки памяти и принципиальная схема, ucf прикреплены.
Нажмите для просмотра прикрепленного файла
DCI Cascading используется. В качестве «Master» используется 26 банк с подключенными линиями dq. В ucf указано, что использованы банки:
DQ,DM,DQS 26, 27, 36.
ADDR/CTRL – 37 банк.
Объявлено CONFIG DCI_CASCADE = "26 27";
Пробовал разводить CONFIG DCI_CASCADE = "26 27 36"; MAP не выполнился. Сообщение «invalid constraint». С этим еще не разобрался.
Что касается тактовой, то используется схема с двумя MMCM.
На первую заходит сигнал с внешнего генератора 200 МГц. Этот сигнал используется как clk_ref для IDELAYCTRL. MMCM на выходе формирует 400 МГц, которые через bufg подключены на вход второй MMCM.
Вторая ММСМ используется для формирования тактовых контроллера 400МГц, 200 МГц, 400 МГц.



Для Golikov A.
"просто интересно, а как по каше на 2 картинке вы определили что вылетает каждый 4 отсчет?"
При увеличении картинки видно, что когда начинаются выбросы 3 отсчета пилы явно прослеживаются. 4 отсчет - "скачет". Зеленые линиии между отсчетами дорисовывает Cool edit. Пытается экстраполировать картинку. Логика у меня была такая)

1)
И всё таки, (как уже вас спрашивали) было ли выполнено выравнивание длин с учётом длины дорожек от шариков BGA корпуса ПЛИС до кристалла ПЛИС? Если вы сделаете в ISE "partgen -v xc6vlx240tff1156" - то увидите что разброс дорожек внутри BGA в пределах одного банка составляет порядка 20-30мм и даже внутри диффпары между линиями бывает по 1.5мм. Обычно любители выравнивать дорожки до 0.1мм про это забывают.

2) Там же вроде ODT - зачем дополнительные последовательные терминаторы на шине данных. У вас и так на 50 Ом всё нагружено а вы ещё 15 Ом последовательно добавляете - сигнал совсем затухнуть может. К тому же шина данных двунаправленная, а вы последовательные резисторы сдвинули к памяти.

Здравствуйте, форумчане.
Убрал по замечанию VladimirB резисторные матрицы 15 Ом с линий dq, dqs. Заменил их перемычками. К сожалению результат тот же. Данные на частоте 400 МГц бьются. Выравнивание линий выполнено с учетом разброса шариков BGA. Линии выравнены до 0.5мм. тест сигналов осциллографом пока ничем не помог. Всем спасибо за советы. Продолжаю поиск ошибок.

Обратите внимание на качество VREF - у меня тут вот недавно не хватило каких-то 10 мкф емкости по VREF (он генерировался резистивным делителем 2х270 Ом), глючило. Диагностика была простой - кол-во глюков возрастало с уменьшением импеданса терминирования по ODT (который по EMRS задается) - признак этого был таков, что ошибки были в том числе битовые, то есть в одном слове порченные отдельные биты (если глюки по DQS, то обычно происходит сдвижка на одно слово целиком).

Еще - чистоту VCCAUX, оно должно быть отдельно отфильтровано, оно тоже дает такие сбои, так как питает SSTL-компараторы.

Резисторы последовательные по клокам полезны.

Ещё неплохо бы поглядеть как ведёт себя VTT. Только смотрите этот сигнал не на выходе микросхемы, которая его генерит, а на резисторных сборках.
По краям сборок неплохо бы повесить парочку кондёров из low ESR 10-47 uF + 0402 100 pF. Это всё нужно для борьбы с провалами на VTT - там токи приличные текут.

Ещё интересно включен ли у вас ODT в управляющем регистре - это обычно при генерации коры указывается.
Кроме того интересно какой у вас в данной топологии слоёв рассчётный импеданс дорожек. Судя по терминаторам должно около 40 Ом быть.

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

Это да, естественно, но если он есть (при коротких дорожках и 1-2 ИМС памяти он не особо нужен).

"не особо нужны" - это не инженерный подход ;-)
бывает всего 4 варианта топологии для шины адреса/команды у ddr3
- Tree with VTT R
- Tree without series R
- Tree with series R
- Fly-by
www.micron.com/~/media/Documents/Products/Technical%20Note/DRAM/tn4113_ddr3_point_to_point_design.pdf
т.е. если например, вы делаете fly-by на 2 микросхемы но не ставите терминирующие резисторы на VTT за последней микросхемой - то это неправильно. Если уж выбрали конкретную топологию, то надо придерживаться её до конца.

если я делаю разводку на две микросхемы, допустим 8-битных, делая 16-битную шину (т.е. не объединяя данные), и все дорожки меньше дюйма по длине, то я сделаю разводку ВООБЩЕ без внешних терминаторов, ибо они не нужны, так как длина дорожек мала для того, чтобы в ней возникли значительные отражения. Адрес/управление будет разведет Т-разводкой, данные точка-точка, последовательные резисторы по всем клокам (CLK, DQS) - и на этом ВСЕ. И будет отлично работать без VTT, что можно даже подтвердить осцилограммками... Кстати DDR2 от DDR3 в этом не отличаются.

Об этом в микроновских pdf не пишут, однако это решение имеет полное право на жизнь, и неплохо живет, и температурные и EMI тесты все индустриальные проходит, просто для этого не надо себя ограничивать рамками документации в части рекомендаций проектирования схемы.

То, что вы только что описали как раз и называется "Tree without series R".
Забыли правда упомянуть о том, что длины дорожек надо выравнивать в плечах Т-образного соединения, а это - тот ещё геморрой.
У ТС 4 чипа, каждый по 16 бит (если кто не смотрел приаттаченные ПДФки). Там используется fly by.

Я описал не только без последовательных терминирующих резисторов, а еще и без параллельных терминаторов тоже. ВООБЩЕ БЕЗ каких либо [внешних] терминаторов. Правда, честно говоря, я в англоязычной терминологии в части DDR не сильно силен, может так оно и называется.

Выравнивать плечи в T на 2 чипа или в звезде на 4 чипа проблем нет, если дорожки меньше примерно 3/4 дюйма в плече, то на выравнивание следует забить, сделав его, конечно, максимально возможным, но без пристрастия.

Здравствуйте, форумчане!
Как выяснилось, выравнивание дорожек сигналов памяти на плате выполнено до 0.5 мм, без учета задержек на чипе. ("partgen -v xc6vlx240tff1159").
Собственно как это понять? Ознакомился с файлом xc6vlx240tff1159.pkg напрашивается пока только вывод, что "правильно" взять и укоротить дорожки конкретных линий на величину trace_length.
Можно ли используя trace_length по ug 406 посчитать отклонения(skew) dq\dqs, adr\cmd \ CK?

Еще раз по методике xilinx_mig_hardware_debug стр. 29-30 протестировал память на частоте 333 МГц

С помощью traffic_gen выявлена особенность при использовании режима запись\чтение по фиксированному адресу калибровка проходит успешно и ошибок данных нет во всех режимах генерации данных. Начинаю увеличивать диапазон используемых адресов от 0 до x"ffffff" получаю ошибки данных. Адресное пространство rank_bank_row_col.
col 0_9 бит
row 10_23 бит
bank 24_26 бит
rank 27 бит
Может ли это быть связано с выравниванием?

Нет, точнее, крайне вряд ли. Выравнивание до 0.5 мм, это выравнивание, выполненное со зверским перепристрастием и маниакальной паранойей . Отличное выравнивание - это 0.5 см, а не мм. 99%, что это проблемы или SSO, или питания (в основном, VCCAUX, или кто там в Вашей серии питает компараторы SSTL, проверьте, чтобы оно было ОЧЕНЬ хорошо отвязано от VCCIO, ну и VCCIO тоже чтобы в норме было), или грязи на Vref/Vtt (если терминаторы снаружи есть), или несоответствия Vref/Vtt требованиям. Скорее всего, или Vref, или VCCAUX, или оба.

Насчет vccaux, vtt, vref. Измерялась пульсация vtt, vref. Отклонения в пределах значений указанных в даташите на мс памяти. VCCAUX, VCC_O заведено от DC/DC преобразователя ltm4601 20А.


Есть ли какие-то конкретные требования к VCC_AUX?

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

В совсем недавнем прошлом была история - в DDR2 идут сбои, и все тут. Сделали итерацию платы - завели VCCAUX через отдельный LC-фильтр (до этого была грубая ошибка, завели ее единой цепью с питанием I/O), глюки значительно уменьшились, но не прекратились. Затем добавили емкости на Vref - глюки прекратились совсем (об этом я сразу писал). Еще - чем формируются Vref и Vtt, обеспечивается ли жесткая привязка Vref к Vtt и к VCC/2?

И SSO, все таки, проверить стоит, убедиться, что все ОК, а если не ОК, добавить пинов VCC/GND путем корочения на землю и VCC I/O пинов ПЛИС между пинами данных/адреса/управления, и подключения их к земле/VCC внутри ПЛИС.

Питание памяти VCC 1,5 В формирует мс lt1764a. vref и vtt формируются tps51200 из VCC. Привязка такая. Пробуем добавлять конденсаторы на VTT

Спасибо за совет, только где можно о методике проверки SSO почитать?

и на Vref! От него сбои вероятнее, чем от Vtt, хотя и тот и этот может неприятности доставить. С привязкой тут все в порядке, микруха надежная. По Vref обязательно обеспечьте по 0.1 мкф у каждого пина Vref (у TPS, DRAM, ПЛИС) и общую емкость микрофарад 50-70. По VTT - общую емкость считайте исходя из тока, там токи ой-ой, из них не меньше, чем 20 мкФ, лучше 30 из трех по 10, непосредственно у пина TPS.

по SSO - это должен trace уметь, делать отчет по SSO.

"по SSO - это должен trace уметь, делать отчет по SSO."

под trace понимаем среду разводки? В нашем случае это PCAD 2004)

да, только у xilinx. http://www.xilinx.com/itp/xilinx10/isehelp...so_analysis.htm

Возможно, это не trace делает (анализатор времянок), а отдельная утилита

Похоже у нас тоже самое. Одна цепь 2,5 В и VCCAUX и VСCIO. А в чем природа ошибки?

с SSO проблем не оказалось. Проверял в PlanAhead 14.7.

VCCAUX питает компараторы входных SSTL-сигналов с VREF, и цепь эта довольно чувствительная, грязное питание от I/O, заведенное туда, приводит к сбоям

А разве туда не 3.3 надо?

доп. емкости на Vref/Vtt не помогли?

На VTT рядом стоят 3x10 мкф - керамика.
Допаяли 10 мкф тантал, 100 пф керамика, 3х0,1 мкф. Ошибки не исчезли.

На Vref стоит со стороны ПЛИС по 0,1мкф на каждый банк. Со стороны памяти по 0,1 на каждую мс.
Возле TPS на Vref 0,1мкф. Пробовали добавлять 220 мкФ тантал. Ошибки остались.

На virtex 6 согласно ds152 должно быть 2.5В на VCCAUX.

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

Нажмите для просмотра прикрепленного файла

Нажмите для просмотра прикрепленного файла

Не может сбоить шина команд/адресса? С чем это может быть связано?

С проблемами с DQS и временем прихода данных - например, несоответствии реальной read latency той, что ожидает корка, и предыдущее данное защелкивается как будто бы текущее. Или ошибками в блоках, отвечающих за прием (по какому фронту DQS - положительному, или отрицательному), или в блоке выравнивания принятых данных (сборке длинных слов из байтов)

Итак, в результате удалось запустить тест traffic_gen во всех режимах на частоте 400 МГц.
Проблема решилась путем предустановки линий ADDR, RAS, CAS с последующим защелкиванием CS.

Также на некоторых платах напояли дополнительные конденсаторы (спасибо SM).

Вопрос собственно в следующем. Есть ли какие - то примеры организации User interface для mig 3.92. И как организовать параллельное запись/чтение в память, так называемый режим кольцевого буфера?