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

Требуемый объем - 1М слов (16 бит). Комфортная тактовая на ПЛИС - 100 МГц. (В текущем проекте тактовая 160 МГц, память асинхронная самсунговская на 10 нс, цикл обращения получается 3 такта - 6.25нс * 3 = 18.75нс. Не фонтан )

Разумным решением, вроде бы, является использование синхронной памяти. Посмотрел у Cypress и IDT. Есть ряд вопросов.

У Cypress подходящими выглядят CY7C1382C (1Mx18 Pipelined SRAM) и CY7C1383C (1Mx18 Flow-Through SRAM). Микрухи похожи очень, насколько понял, отличие только в том, что у pipelined выход с памяти идет через регистр, поэтому задержка на такт, но зато можно тактовую более высокую гонять. Поправьте, если ошибаюсь.

А главная непонятка следующая: не понял толком, возможо ли там обращение по произвольным адресам на каждом такте. Это очень важно для разрабатываемого устройства - требуется записывать поток по произвольным адресам (формировать кадр). Из диаграммы в даташите следует, что там идет загрузка адреса, потом уже данные пишутся или читаются, и приводится диаграмма для т.н. burst режима, когда внутренний счетчик адреса инкрементит. А нельзя ли просто на каждом такте новый адрес метать? И, кстати, не совсем понял смысл того, что счетчик этот внутренний всего 2-битный, т.е. через 4 обращения надо все равно новый адрес грузить. Зачем весь этот огород, что это дает?

В общем, кто имеет реальный опыт, посоветуйте/отсоветуйте? Надо просто иметь снаружи ПЛИС хранилище данных на 1 мегаслово с возможностью писать и читать со скоростью 100 Мслов в секунду, т.е. при 100 МГц тактовой. Это, ессно, при обращениях блоком, задержки на загрузку адреса и переключение шины данных тут не принимаются во внимание. И чтобы, хоть обращение и блоком идет от 64 до 256 слов, можно писать/читать каждое слово по произвольному адресу. Подходит ли для данной задачи, например, CY7C1383C?

А почему решили пользовать Статическую?
Какое время ваш кадр будет лежать в памяти?

Дело в не том, сколько он там будет лежать. Дело в том, что требуется обращение к произвольному адресу на КАЖДОМ такте. А SDRAM, afaik, может бодро только по последовательным адресам метать.

Ну возьмите QDR.

Неужели чаще чем 4-5 тактов вы хотите менять адрес?
Если обеспечить задержку (FIFO буфер) и применить DDR SDRAM
То можно я думаю получить тот поток который вам надо.
В фифо пишем на 100 MHZ а читаем на 200 MHZ (DDR)

А что это такое? Где посмотреть?


Именно!


Да не в потоке дело! У меня данные, в частности, поступают с линейчатого фотоприемника - т.е. столбец считывается. И надо их так и писать столбиком в память - чтобы кадр сформировать. Т.е. идет блок 288 слов данных, надо их прописать по адресам 0, 1*768, 2*768, 3*768.., 287*768. Каждое слово за такт. SDRAM не дает произвольного доступа без потери скорости.

А если позвать на помошь функцию транспонирования ? ну обзовите ряд - "столбиком" и пишите

Использовали синхронную память Samsung NtRAM (No Turnaround Random Access Memory ). Адреса можно на каждом такте новые ставить, равно как и переходить с операции чтения на запись. Правда, обработка конвейеризирована - фаза данных что на запись, что на чтение относительно фазы адреса и команды сдвинута на три такта. Частоты от 133 МГц.

Для требуемой конфигурации 1М*18 пример part-number K7N161801A-QC13,
где цифры в конце указывают частоту 133Мгц.

По поводу QDR но она помоему должна стоить много много денег!

http://www.qdrsram.com/

Дык когда кадр сформирован, его надо наружу выдавать. И уже по-человечески, по строкам.

Кроме того, формирование кадра - это частная задача. Еще надо быстро работать с произвольными фрагментами кадра, а для этого тоже нужен быстрый произвольный доступ.

А вообще, что такая экзотическая задача, что-ли? Скорость не феноменальная. Объем тоже достижимый. Надо-то всего-то чтобы память была синхронной и по клоку работала. Примерно, как внутри тех же альтеровских ПЛИСин, только проще - два порта не надо.

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

ЗЫ. можно транспонировать кадр на "лету" используя фифо. Правда размер фмфо нужно будет уточнить

Абсолютно согласен с des00
Для вас что стоимость вашего чада вообще не важна?

Смотрите здесь:
http://xgoogle.xilinx.com/search?btnG=Goog...t2=Search&site=

Сдается мне, что неправильно Вам сдается. Представьте: линейчатый фотоприемник (линейка) стоит вертикально в поле зрения прибора. Перед объективом стоит зеркало, которое позиционируется с помощью сканера - таким образом производится развертка изображения. Данные поступают по вертикали (столбиками), и укладываются в память. После полного прохода зеркала формируется кадр. Выдается кадр наружу уже как принято - по строкам. И что вы тут придумаете? Фотоприемник такой - он специально рассчитан на такую схему считывания. Кроме того, внутри него еще и ВЗН (временная задержка и накопление) реализовано, т.ч. способ формирования изображения тут даже не обсуждается. Все это замечательно работает в текущем варианте. Только память, как уже сказал, используется асинхронная, из-за чего имеется приличное количество геморроя, от которого хотелось бы избавиться в следующем варианте.

Помимо всего этого просто есть необходиость считать, например, небольшой прямоугольный фрагмент или записать его туда. Словом, нужен быстрый произвольный доступ.

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

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