Замучился и запутался в бурстах, авторефреше и т.д. Очень сложно увязать все с адресацией и данными. Устал тыркаться сам.
Посоветуйте ядро...
Проект такой: два буффера строк изображения поочередно заполняются и должны поочередно скидываться в DDR. Одновременно с этим из DDR читаются данные и пишется результат (вобщем обработка изображений).

Я работал с SDRовским Альтеровским ядром. Чтобы не путаться, очень рекомендую моделсимом пользоваться. Гораздо все проще и быстрее получается. Модели брал на сайхтах производителя.

Ч пользуюсь моделсимом, но управлять ядром надо же... Как Вы управляете? С помощью FSM? Мне сложно увязать бурсты, авторефреш и адресацию.

Я просто корку взял, дальше оно рефрешем само занималось. Бурсты я одинакогой длинны использовал, в страницу целиком.

А стандартной что, нету?
Какое семейство микросхем?

Использую корку, сгенерированную MIG-ом для Spartan-3E. Как раз это стандартное ядро и есть (ессесно не аппаратное ядро). Вот оно и требует при установке сигнала необходимости авторефреша закончить текущий бурст и ждать сигнала окончания авторефреша. При этом трудно (надеюсь только мне) увязать адресацию (сброс адреса или приостановка его инкремента).
Подскажите, что значит бурст длиной в страницу? Я вроде везде читал, что бурст может быть длиной 2, 4 или 8????
Сейчас есть уже мысль использовать три FSM для сигналов управления, для установки и снятия команд и общий автомат, отвечающий за выполняемую операция на уровне буффера (про буфферы выше писал).

Вы закончили бруст. Смотрите на флаг авторефреша. Если 1, то ничего не делаете. Если (на очередном такте) там 0, то начинаете новый бруст.



Деградация общего интеллектуального развития.... Раньше можно было поставить начало страницы и вычитать ее всю. Самый наибыстрый режим был.



Делайте все на satate -машинах.
posedge.....

case(state)
IDLE: begin end
PREPARE_BURST: begin end
GET_DATA_FROM_BURST: begin.... end
WAIT_REFRESH_PROCESSIGNG: ..
....
...
..

endcase

case(Это Вы про мое интеллектуальное развитие?)
ДА: begin ОСКОРБЛЕНИЕ end
НЕТ: begin NOP end
endcase

Вы под страницей понимаете банк? И если раньше можно было, то как сейчас с этим?

Я про вселенную. Она расширяется а кол-во интеллекта остается прежним.


ХЕЗ, Page называлось. В зависимости от битности оно было или 1024, или там 512 слов.

Пользовал Mig в Виртекс-4. Не обращал ровно никакого внимания на рефреши и прочие заморочки. Страничная запись не нужна - Mig умеет склеивать burst'ы при наличии данных в FIFO. Работал кстати тоже с изображением

Так вроде в MIG-е только данные надо засовывать/забирать по готовности... ну и окончания инициализации дождаться после POR-а. В чём мука-то?

А... Spartan3... тогда да... советую перейти на Virtex4 и далее, там всё именно так просто, как я описал.

Сообщение отредактировал o_khavin - Jan 6 2011, 12:24

Возня с авторефрешем - это конкретная фича реализации MIG под Spartan3.
Для виртексов таких заморочек нет.
У Xilinx есть и другой вариант контроллера памяти - MPMC.
Он входит в состав EDK, однако эго можно использовать и отдельно.
Главное отличиче от MIG - встроенная конфигурируемая "многопортовость".
Рано или поздно перед автором встанет такая проблема. Городить самодельные арбитры в наше время уже наверное
смысла не имеет, а в этом контроллере всё уже реализовано. Есть и некоторые недостатки - уж больно он до BRAMок прожорлив.
Но за всё в этой жизни, как известно, приходится платить...

Spartan-3 использую для снижения цены конечного устройства. Конечно, можно было бы использовать и Spartan-6 и Virtex какой-нибудь, но это путь западных разработчиков. Я пока верю, что мы способны победить по-другому... Практически все получилось. Использую три машины состояний. Сейчас работают восемь каналов записи/чтения. Разумеется используется буферизация. Сейчас ядро оптимизировано для записи/чтения больших последовательных блоков данных. Как все окончательно запущу - отпишусь.

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

Генерируемые MIG-ом конктрейны:
1. важны;
2. не должны быть проигнорированы по какой-либо причине;
3. не достаточны при смене размещения выводов, так как не покрывают пару критических сигналов, но при предлагаемой ядром конфигурации выводов само собой получается выполнение времянок.

Советую помоделировать после place&route с подключенным SDF-файлом и моделью памяти с сайта производителя.
Для spartan3 ядро написано с парой неприятных моментов из-за которых во-первых, не всегда корректно работает функциональная симуляция, во-вторых, быстрый клок используется как данные. Когда я ел свою собаку, то тупо переписал эти места в своем стиле.
И еще важно прочитать список чего там не работает в этом ядре в разныч версиях, он там пополняется понемногу.