[vitaly_n 0]

Имеется Spartan 6 LX9 + IS42S81600F-7TL. Используются следующим образом. Извне прилетают пакеты по 332 байта, каждый из этих байтов нужно индивидуально задержать от 0 до 480 пакетов. Для этого они запоминаются в SDRAM, из SDRAM вычитываются ранее принятые байты с выборкой по карте, и отдаются дальше. Между пакетами - авторефреш. Т.е. когда начинается пакет данных, авторефреши прекращаются. Частота клока - 128 МГц.

Циклограмма такая. Для первого байта активируем строку 0 для банка 0. Пишем байт в столбец N. Читаем+ precharge байт из столбца N+MAP(i) , где i - номер байта. Для следующего байта активируем строку 0 банка 1, пишем в столбец N, читаем + precharge из столбца N+MAP(i). И так по всем 332 байтам. По окончании пакета инкрементируем N и начинаем циклически крутить авторефреши.

CL = 3, если интересно.

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

@des00

Изменено 11 марта, 2021 пользователем vitaly_n

[des00 25]

ИМХО окно врядли плавает, причин для этого нет. Одна тактовая, обычный SDRAM. Судя из описания вы пишете байт и сразу же читаете закрывая банк, если бы окно плавало то были бы свои в другом месте.

Саму систему вы скорее всего моделировали в симуляторе с моделью памяти и соответствующей нагрузкой, если там все хорошо, тогда я бы попробовал вот такие варианты:

1. Понизить частоту работы памяти, посмотреть будет ли проявляться такой эффект.

2. Вставить первое холостое запись/чтение, на той же частоте и проверить все тоже самое.

3. Поймать ситуацию в отладчике, может быть у вас MAP(0) не правильно определяется, например иногда читается из таблицы переадресации с бОльшей задержкой и дело не в бобине памяти?

 

[vitaly_n 0]

53 minutes ago, des00 said:

ИМХО окно врядли плавает, причин для этого нет. Одна тактовая, обычный SDRAM. Судя из описания вы пишете байт и сразу же читаете закрывая банк, если бы окно плавало то были бы свои в другом месте.

Саму систему вы скорее всего моделировали в симуляторе с моделью памяти и соответствующей нагрузкой, если там все хорошо, тогда я бы попробовал вот такие варианты:

1. Понизить частоту работы памяти, посмотреть будет ли проявляться такой эффект.

2. Вставить первое холостое запись/чтение, на той же частоте и проверить все тоже самое.

3. Поймать ситуацию в отладчике, может быть у вас MAP(0) не правильно определяется, например иногда читается из таблицы переадресации с бОльшей задержкой и дело не в бобине памяти?

 

Да, разумеется отлаживал с симулятором mt48kc8m8a2.v - очень полезная штука!

1. 128 МГц - и так низко...

2. Дык последующие чтения/записи идеально ведь работают, а код один и тот же для всех циклов!

3. Точно нет. MAP(0) выставляется ещё задолго. Там именно глюки с шиной. В частности я баловался вот какой ерундой. Выставляю код операции NOP или даже INHIBIT и при этом на шину данных выставляю нули или единицы в такте, предшествующем такту с чтением данных - в глючных 10% читается именно то, что я выставлял на шине.

Изменено 11 марта, 2021 пользователем vitaly_n

[zombi 0]

Между последним и первым зп/чт кроме рефреша ничего нет, как я понял.

Вот туда я и смотрел бы.

[des00 25]

42 minutes ago, vitaly_n said:

1. 128 МГц - и так низко...

для SDRAM это довольно высокая скорость.  Да и в любом случае этож класика, запустить проект на низкой частоте, убедится что все работает и потом поднимать.

Quote

2. Дык последующие чтения/записи идеально ведь работают, а код один и тот же для всех циклов!

А вы попробуйте)

Quote

3. Точно нет. MAP(0) выставляется ещё задолго. Там именно глюки с шиной. В частности я баловался вот какой ерундой. Выставляю код операции NOP или даже INHIBIT и при этом на шину данных выставляю нули или единицы в такте, предшествующем такту с чтением данных - в глючных 10% читается именно то, что я выставлял на шине.

ну не верю я в глюки с шиной из двух регистров работающих на одной частоте по одному фронту. Со стороны SDRAM у вас два регистра и Z-буфер, на стороне плис тоже самое. Если все переходные укладываются в период тактовой частоты, выдержаны требования по BTA, нет нарушений времянок то откуда проблемы в обмене между двумя регистрами? Я бы понял если бы сбоило постоянно и в разных местах, может у вас SSO сказывается или еще что, а у вас сбоит всегда только в одном месте. Чип скоп или что там под шестой спартан и поймать ситуацию.

ЗЫ. а если читать два раза подряд один адресс, будет правильное чтение?

20 minutes ago, zombi said:

Между последним и первым зп/чт кроме рефреша ничего нет, как я понял.

Вот туда я и смотрел бы.

ну там, ЕМНИП надо 4к рефрешей за 20мс поставить, уж это скорее всего проверили) хотя мой PS к этому относился)

[des00 25]

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

Quote

Выставляю код операции NOP или даже INHIBIT и при этом на шину данных выставляю нули или единицы в такте, предшествующем такту с чтением данных - в глючных 10% читается именно то, что я выставлял на шине.

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

[vitaly_n 0]

20 hours ago, des00 said:

ну там, ЕМНИП надо 4к рефрешей за 20мс поставить, уж это скорее всего проверили) хотя мой PS к этому относился)

Авторефреши идут каждые 93,3 нс.

17 hours ago, des00 said:

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

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

Вот сделал скриншот из симуляции, чтобы циклограмму лучше видно было:

 

[des00 25]

1 hour ago, vitaly_n said:

Вот сделал скриншот из симуляции, чтобы циклограмму лучше видно было:

Это моделирование или чипскоп?

И так разве можно делать? сразу после read ставить write с данными? Вот из даташита на ваш чип:

Quote

Data from any READ burst may be truncated with a sub-sequent WRITE command, and data from a fixed-length READ burst may be immediately followed by data from a WRITE command (subject to bus turnaround limitations). The WRITE burst may be initiated on the clock edge im-mediately following the last (or last desired) data element from the READ burst, provided that I/O contention can be avoided. In a given system design, there may be a possibility that the device driving the input data will go Low-Z before the SDRAM DQs go High-Z. In this case, at least a single-cycle delay should occur between the last read data and the WRITE command.

Тут конечно не совсем чисто все расписано, но, если мой английский меня не подводит, команда write может следовать только после первых принятых данных, а не перед ними. Ну и рисунки RW1/RW2 - READ to WRITE как бы говорят что так нельзя

[vitaly_n 0]

12 minutes ago, des00 said:

Это моделирование или чипскоп?

И так разве можно делать? сразу после read ставить write с данными? Вот из даташита на ваш чип:

Тут конечно не совсем чисто все расписано, но, если мой английский меня не подводит, команда write может следовать только после первых принятых данных, а не перед ними. Ну и рисунки RW1/RW2 - READ to WRITE как бы говорят что так нельзя

Это моделирование. Симуляция в ISE 14.7.

Пардон, что сразу не написал. Во время LOAD_MODE_REGISTER A9=1, что означает "Single Location Access". Соответственно, никакой обрезки READ burst не может возникать в принципе. Там абзац идёт о том, что когда данные читаются, нужно дать SDRAM возможность перевести DQs в High-Z состояние, чтобы не было конфликта на шине при команде WRITE. У меня, как легко заметить, пустые такты есть как перед тактом с чтением данных, так и после него.

[des00 25]

30 minutes ago, vitaly_n said:

Пардон, что сразу не написал. Во время LOAD_MODE_REGISTER A9=1, что означает "Single Location Access". Соответственно, никакой обрезки READ burst не может возникать в принципе.

Вам виднее конечно, но из даташита я вынес другое определение. single location это burst=1, поэтому все правила Read-Write должны соблюдаться, там еще есть специфическая оговорка что маской DQM в этом случае тоже нужно хитро крутить. Способ который используете вы я не пробовал, последовательность read-write формировал с условиями обозначенными в даташите.

UPD. Еще, безотносительно размера блока, в таблице истиности последовательности команд, Read-Write указано 2 сноски

7. Must satisfy burst interrupt condition.

8. Must satisfy bus contention, bus turn around, and/or write recovery requirements.

И нигде не написано что в случае Single Location Access требования 7/8 можно игнорировать.

В общем, ИМХО, я бы сначала понизил частоту и проверил двойное чтение с одного адреса. Если снижение частоты поможет, значит где-то не верно рассчитан временой бюджет, если нет и данные в памяти сломаны в приницпе, то искал бы ошибку записи, если сломано только первое чтение, а второе норм то искал бы ошибку в реализации разворота шины. Регенерация, фаза тактовых и все такое, это точно не в этом случае.

[vitaly_n 0]

22 minutes ago, des00 said:

Вам виднее конечно, но из даташита я вынес другое определение. single location это burst=1, поэтому все правила Read-Write должны соблюдаться, там еще есть специфическая оговорка что маской DQM в этом случае тоже нужно хитро крутить. Способ который используете вы я не пробовал, последовательность read-write формировал с условиями обозначенными в даташите.

Тут нет никакого нарушения никаких ограничений. Симулятор mt48kc8m8a2.v не возражает, а он много разных таймингов и условий контролирует.

Если бы проблема была в циклограмме, то она бы проявлялась и на других чтениях, а с ними как раз всё в порядке. Проблема выскакивает только с первыми прочитанными данными, и то не всегда.

Маску DQM я вообще не трогаю, она насмерть в 0 сидит.

[zombi 0]

А нет ли нарушения tRC>=60нс после выполнения последней команды AUTO REFRESH и прилётом первого байта пакета?

[vitaly_n 0]

15 hours ago, zombi said:

А нет ли нарушения tRC>=60нс после выполнения последней команды AUTO REFRESH и прилётом первого байта пакета?

Точно нет. После каждого авторефреша я вставил 62,5 нс ничего не делать. Первая команда ACTIVATE случится не быстрее, чем через 93,3 нс после последнего авторефреша.

[zombi 0]

У Вас после первой команды ACT две команды NOP, а при следующих ACT один NOP и один READ с AUTO-PRECHARGE ранее открытого банка.

А что если после первой ACT добавить какой же но фиктивный READ пусть даже и для не открытого банка.

Понятно что эти данные игнорировать.

 

Ещё я бы проверил закрытие всех банков после приёма всего пакета.

[Flip-fl0p 4]

А что если взять виртуальную модель SDRAM от MICRON, подправить её, чтобы настройки соответствовали вашей памяти и просимулировать ?