Здравствуйте, форумчане!
Как выяснилось, выравнивание дорожек сигналов памяти на плате выполнено до 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. И как организовать параллельное запись/чтение в память, так называемый режим кольцевого буфера?