Просьба растолковать про SDRAM

Всем ДВС!
Вобщем как в кино: имею возможность прикрутить к ПЛИС память SROM, но не имею желания (мало), имею желание прикрутить SDROM, но не имею возможности:(
Любезно прошу цифроманяков разъяснить неразумному, если можно на конкретном примере, принцип работы с SDR SDROM. Читал я даташиты и на ISSI и на еще какую-то память, но утонул с головой в этих дебрях с рефрешами, пречарджами и прочей динамической мутью. Вот, например, что нужно сделать, чтобы записать байт? Как я понял выставить адрес и тупо подать строб там уже не получится ввиду мультиплицированной шины адреса (строка/колонка) + операции с подзарядками яйчеек. Правильно ли я понимаю, что чтобы записать 1 байт надо:
1. выставить адрес строки одновременно со стробом ROS
2. подождать 2-3 тика клока и выставить адрес колонки со стробом CAS
3. выставить данные на линию и подать строб WE.
4. WTF далее с этими deactivateами и прочими специфическими для динамики плясками?
Т.е. по моим подсчетам при 133 МГц-вой памяти цикл записи длится около 20нс? Или я чушь несу?
Да, еще абсолютно непонятен момент с обновлением каждые 64 мс. Т.е. если она просто стоит без дела, то каждые 64мс ее надо обновлять или по-любому даже при работе надо? А как быть если у меня идет непрерывный поток данных, надо получается поток прерывать?
Брать готовую корку на верилоге не хочу, потому как во-первых она такая не требуется в моем случае, во-вторых есть смысл самому сделать в учебно-образовательной цели.

0

есть burst когда один раз выставив адрес в пределах строки можно данные гнать непрерывно на 133МГц.
рефрешить не обязательно всё сразу за раз, можно по страничке каждые десяток-другой мкс, но через 64мс после рефреша / чтения / записи заряд просто разбежится из ёмкости которая хранит бит и данные превратятся в тыкву.
иногда можно и вовсе без рефреша обойтись, если например память является видеобуфером кадра который каждые 20-30мс заведомо весь будет прочитан.
an499 от альтеры там всего несколько страниц на верилоге причём очень размашисто, можно не брать готовое, а просто разобраться что там происходит.

0

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

0

Кроме того, современные чипы SDROM имеют встроенные средства self-refresh. В свободное время хост-программа просто говорит SDROMу, что он может позаниматься self-refreshем :-) Реализация зависит от SDROM. Например, метод "CAS перед ROS" был распространён, помнится.

0

напомнил поговорку студенческих времен - "рас на кас не приходится" :-)

0

ок, перейду на конкретный пример:
Вот есть у меня поток данных с частотой 50МГц, всего 4 мегабайта (фрейм с камеры), байт за 1 клок (20 нс), + всякие переходы, итого ~100 мс на фрейм чтобы положить его в буфер. Т.е. получается 64 мс прошло, я должен сделать refresh, в то время как данные все будут поступать с камеры (камера выдает свой синхроклок на фрейм)?

Пока читаю доку от ELPIDA "How to use SDROM".

0

за 64мс надо обновить все, пусть будет 8192, строки, ну или сколько там есть в зависимости от размера.
чтобы обновить одну строку нужно грубо говоря около десятка тактов (конкретные длительности команд в даташите). то есть около сотни нс, если 133МГц такт.
обновлять можно конечно всё сразу, но тогда память станет недоступна на всё это время, 8192 * 100нс = 800мкс, что с одной стороны довольно долго, но в среднем от 64мс не так уж и много всего 1-2%.
также никто не мешает размазать рефреши и делать их по одному каждые 64мс/8192 ~ 80мкс.
то есть если сделать в контроллере фифо на десяток байт, то можно каждые 80мкс отвлекаться на 100нс для рефреша очередной строки, а данные будут пока в фифо заполняться.

0

~8 мкс если мне не врет калькулятор. понятно, т.е. в ПЛИС надо будет фифо сделать на время рефреша. Или раз за 64 мс тратить ~820 мкс на рефреш. Я прально мыслю что в плисине заводить таймер-счетчик на это событие по его срабатыванию данные кидать в буфер пока рефреш идет? чей-та как-то это у меня пока плохо в голове укладывается...

0

да, 8 мкс.
данные на запись просто через фифо пропустить, они там сами автоматически накапливаться будут пока контроллер рефрешем занят.
ну и еще, раз данные с матрицы идут, рефреши можно к строчной синхронизации привязать и выдавать небольшими пачками по несколько штук пока у камеры horizontal blanking.

0

Очень подробно с картинками интерфейс расписан в микроновском даташите: 256MSDROM.pdf. Можт чем поможет. =)

0

Спс! буду изучать!
Но уже сейчас понимаю что задачка не из легких, т.к. поток непрерывный и времени впритык. Думается мне что надо конвейер городить с буферизацией..

0

посмотрите ещё:
Гук М.Ю. - Аппаратные средства IBM PC. Энциклопедия

там вроде тоже что-то было

0

Ну вот, за 3 дня я стал спецом в SDROM, теперь знаю что такое precharge, refresh и прочие нигические заклинания =) Вобщем с её 40нс циклом никак не подходит под мою задачу, а паять DDR3 я наверное вряд ли смогу... Придется разориться на статику.
Всем спасибо за помощь!:)

0

имхо херовато как-то разобрались. что за 40нс? burstами пропускная способность при последовательном доступе приближается к тактовой частоте.

0

Спору нет, я не претендуют на про-уровень, но писать для ПЛИС ещё application specific контроллер памяти нет желания (пока). Хотя можно взять и готовые корки, но там все у всех по-разному. А со статикой все куда проще, хоть и дороже. Я думаю что параллельно пока буду потихоньку свой скил в SDROM развивать:)

0

если нужно просто переложить картинку в память, без особо суровой обработки вроде сжатия видео на лету в какой-нибудь h264, то может проще взять арм/дсп с параллельным интерфейсом для камеры и встроенным контроллером памяти, правда в человеческих корпусах на ум только adsp-bf532 приходят, ну и наверное у тексаса еще что-нибудь есть из с5000 серии. возможно из недавно появившихся cortex-m4 что-нибудь да есть.

0

_pv, да, вы правы. хероватенько разобрался. я не учел такую весчь как burst write, она-то и спасает все. В принципе теперь проблем особых не вижу: fifo длинной в n-слов и вперед писать в sdram. осталось только разобраться как делать рефреш и можно скоро начать воплощать в железо. Со статикой несколько попроще, там рефреш не нужен, но цена мегабайта памяти... По поводу DSP: пока не вижу смысла, т.к. займет лишнее время (осовение архитектуры и т.д.). Делаю для себя, под рукой масса доступных железяк имеется:)

0

ну DSP был упомянут не из-за архитектурных ухищрений для более быстрого перемалывания данных, никто не мешает его использовать как МК общего назначения, просто из - за более подходящей под задачу периферии.
а исключительно потому что с тем же blackfymом при наличии нормального параллельного интерфейса и контроллера динамической памяти, если надо просто быстро прочитать десяток - другой мегабайт на скорости под сотню МБ/сек и сложить в память, чтобы потом медленно и печально передать куда-то дальше, будет проще/быстрее написания нормального контроллера динамической памяти для ПЛИС.

0

Да кто спорит, что Blackfym подойдет. К слову у меня есть Pomdaboard на TI OMAP 3530, но опять же для меня imbiddid linux пока на уровне черной нигии + дело упирается в драйвер камеры на уровне ядра. Пока ждет своего часа для детального изучения.
назрел еще такой вопрос из области теории: а если заявленную в 133 МГц частоту увеличить до ,скажем, 150 МГц - будет работать или уже нет?

0

Это как раз не теория, а практика overclockingа. Может заработать, а может и нет. От SDROM чипа зависит. Ну, и питание, возможно, придётся поддать.

0