[dxp 53]

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

 

Требуемый объем - 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?

[Serega Doc 0]

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

Какое время ваш кадр будет лежать в памяти?

[dxp 53]

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

Какое время ваш кадр будет лежать в памяти?

<{POST_SNAPBACK}>

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

[andrew_b 15]

А SDRAM, afaik, может бодро только по последовательным адресам метать.

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

[Serega Doc 0]

Неужели чаще чем 4-5 тактов вы хотите менять адрес?

Если обеспечить задержку (FIFO буфер) и применить DDR SDRAM

То можно я думаю получить тот поток который вам надо.

В фифо пишем на 100 MHZ а читаем на 200 MHZ (DDR)

[dxp 53]

А SDRAM, afaik, может бодро только по последовательным адресам метать.

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

<{POST_SNAPBACK}>

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

 

Неужели чаще чем 4-5 тактов вы хотите менять адрес?

Именно!

 

Если обеспечить задержку (FIFO буфер) и применить DDR SDRAM

То можно я думаю получить тот поток который вам надо.

В фифо пишем на 100 MHZ а читаем на 200 MHZ (DDR)

<{POST_SNAPBACK}>

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

[des00 25]

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

<{POST_SNAPBACK}>

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

[scheme_ru 0]

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

 

Для требуемой конфигурации 1М*18 пример part-number K7N161801A-QC13,

где цифры в конце указывают частоту 133Мгц.

[Serega Doc 0]

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

 

http://www.qdrsram.com/

[dxp 53]

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

<{POST_SNAPBACK}>

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

<{POST_SNAPBACK}>

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

 

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

 

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

[des00 25]

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

 

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

 

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

<{POST_SNAPBACK}>

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

 

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

[Serega Doc 0]

Абсолютно согласен с des00

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

[andrew_b 15]

А SDRAM, afaik, может бодро только по последовательным адресам метать.

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

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

Смотрите здесь:

http://xgoogle.xilinx.com/search?btnG=Goog...t2=Search&site=

[dxp 53]

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

 

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

 

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

<{POST_SNAPBACK}>

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

 

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

<{POST_SNAPBACK}>

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

 

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

[des00 25]

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

 

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

<{POST_SNAPBACK}>

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

Если нужн просмотреть какой нибудь блок память то считать этот блок/блоки не составит особого труда.

 

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