Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Статическая синхронная память.
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
dxp
В проекте на ПЛИС используется аснихронная память. Минусы очевидны: проект синхронный, для работы с асинхронной памятью приходится городить задержки, из-за чего для достижения скорости приходится задирать тактовую частоту (которая, в общем-то, может быть не слишком высокой для решения всех остальных задач), результирующая скорость все равно невысока, усложняется контроллер памяти и т.д.

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

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

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

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

В общем, кто имеет реальный опыт, посоветуйте/отсоветуйте? Надо просто иметь снаружи ПЛИС хранилище данных на 1 мегаслово с возможностью писать и читать со скоростью 100 Мслов в секунду, т.е. при 100 МГц тактовой. Это, ессно, при обращениях блоком, задержки на загрузку адреса и переключение шины данных тут не принимаются во внимание. И чтобы, хоть обращение и блоком идет от 64 до 256 слов, можно писать/читать каждое слово по произвольному адресу. Подходит ли для данной задачи, например, CY7C1383C?
Serega Doc
А почему решили пользовать Статическую?
Какое время ваш кадр будет лежать в памяти?
dxp
Цитата(Serega Doc @ Jun 7 2005, 13:38)
А почему решили пользовать Статическую?
Какое время ваш кадр будет лежать в памяти?
*

Дело в не том, сколько он там будет лежать. Дело в том, что требуется обращение к произвольному адресу на КАЖДОМ такте. А SDRAM, afaik, может бодро только по последовательным адресам метать.
andrew_b
Цитата(dxp @ Jun 7 2005, 12:04)
А SDRAM, afaik, может бодро только по последовательным адресам метать.

Ну возьмите QDR.
Serega Doc
Неужели чаще чем 4-5 тактов вы хотите менять адрес?
Если обеспечить задержку (FIFO буфер) и применить DDR SDRAM
То можно я думаю получить тот поток который вам надо.
В фифо пишем на 100 MHZ а читаем на 200 MHZ (DDR)
dxp
Цитата(andrew_b @ Jun 7 2005, 14:16)
Цитата(dxp @ Jun 7 2005, 12:04)
А SDRAM, afaik, может бодро только по последовательным адресам метать.

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


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

Цитата(Serega Doc @ Jun 7 2005, 14:20)
Неужели чаще чем 4-5 тактов вы хотите менять адрес?

Именно!

Цитата(Serega Doc @ Jun 7 2005, 14:20)
Если обеспечить задержку (FIFO буфер) и применить DDR SDRAM
То можно я думаю получить тот поток который вам надо.
В фифо пишем на 100 MHZ а читаем на 200 MHZ (DDR)
*

Да не в потоке дело! У меня данные, в частности, поступают с линейчатого фотоприемника - т.е. столбец считывается. И надо их так и писать столбиком в память - чтобы кадр сформировать. Т.е. идет блок 288 слов данных, надо их прописать по адресам 0, 1*768, 2*768, 3*768.., 287*768. Каждое слово за такт. SDRAM не дает произвольного доступа без потери скорости.
des00
Цитата(dxp @ Jun 7 2005, 03:28)
Да не в потоке дело! У меня данные, в частности, поступают с линейчатого фотоприемника - т.е. столбец считывается. И надо их так и писать столбиком в память - чтобы кадр сформировать. Т.е. идет блок 288 слов данных, надо их прописать по адресам 0,  1*768,  2*768, 3*768.., 287*768. Каждое слово за такт. SDRAM не дает произвольного доступа без потери скорости.
*

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

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

http://www.qdrsram.com/
dxp
Цитата(des00 @ Jun 7 2005, 14:29)
Цитата(dxp @ Jun 7 2005, 03:28)
Да не в потоке дело! У меня данные, в частности, поступают с линейчатого фотоприемника - т.е. столбец считывается. И надо их так и писать столбиком в память - чтобы кадр сформировать. Т.е. идет блок 288 слов данных, надо их прописать по адресам 0,  1*768,  2*768, 3*768.., 287*768. Каждое слово за такт. SDRAM не дает произвольного доступа без потери скорости.
*

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

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

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

А вообще, что такая экзотическая задача, что-ли? Скорость не феноменальная. Объем тоже достижимый. Надо-то всего-то чтобы память была синхронной и по клоку работала. Примерно, как внутри тех же альтеровских ПЛИСин, только проще - два порта не надо.
des00
Цитата(dxp @ Jun 7 2005, 03:59)
smile.gif Дык когда кадр сформирован, его надо наружу выдавать. И уже по-человечески, по строкам. smile.gif

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

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

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

ЗЫ. можно транспонировать кадр на "лету" используя фифо. Правда размер фмфо нужно будет уточнить
Serega Doc
Абсолютно согласен с des00
Для вас что стоимость вашего чада вообще не важна?
andrew_b
Цитата(dxp @ Jun 7 2005, 12:23)
Цитата(andrew_b @ Jun 7 2005, 14:16)
Цитата(dxp @ Jun 7 2005, 12:04)
А SDRAM, afaik, может бодро только по последовательным адресам метать.

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

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

Смотрите здесь:
http://xgoogle.xilinx.com/search?btnG=Goog...t2=Search&site=
dxp
Цитата(des00 @ Jun 7 2005, 15:10)
Цитата(dxp @ Jun 7 2005, 03:59)
smile.gif Дык когда кадр сформирован, его надо наружу выдавать. И уже по-человечески, по строкам. smile.gif

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

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

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

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


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

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

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

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

прична всего этого гемороя в том, что быстрая одноклоковая память больших объемов, дешевой не бывает к сожалению. Поэтому и нужно под нее подстраиваться.
dxp
Цитата(andrew_b @ Jun 7 2005, 15:24)
Цитата(andrew_b @ Jun 7 2005, 15:24)

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

Цитата(dxp)
А что это такое? Где посмотреть?

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

Посмотрел на qdr. Насколько понял, там просто упор на пропускную способность. В смысле произвольного доступа она точно такая же, как и статическая синхронная. А пропускной способности хватает и так.

Цитата(Serega Doc @ Jun 7 2005, 15:19)
Абсолютно согласен с des00
Для вас что стоимость вашего чада вообще не важна?
*

С чем Вы согласны? То, что предлагается, вообще по требованиям функциональности не подходит. А что касается стоимости, то уже наличие такой сложной и недешевой приблуды, как прецизионный быстродействующий электромеханический сканер уже указывает на то, что сотня баксов рояли не играют. Фотоприемник, к слову, стОит такие пятаки, что там все остальное просто шум.
des00
Цитата(dxp @ Jun 7 2005, 05:10)
Цитата(Serega Doc @ Jun 7 2005, 15:19)
Абсолютно согласен с des00
Для вас что стоимость вашего чада вообще не важна?
*

С чем Вы согласны? То, что предлагается, вообще по требованиям функциональности не подходит. А что касается стоимости, то уже наличие такой сложной и недешевой приблуды, как прецизионный быстродействующий электромеханический сканер уже указывает на то, что сотня баксов рояли не играют. Фотоприемник, к слову, стОит такие пятаки, что там все остальное просто шум.
*


Скорее всего имелось в виду что нужно менять подход. ИМХО даже если стоимость разрабоки позволяет заложиться на дорогое решение проблемы, то это не факт что оно будет лучшее. Например вдруг вам потребуеться потом 266 МГЦ тактовой или памяти значительно поболее?
И потом решают же проблему случаного доступа к ДДР памяти в девайсах обработки видео smile.gif
например http://www.elphel.com/articles/AT3888835064_rus.html#77
dxp
Цитата(dxp @ Jun 7 2005, 04:26)
Сдается мне, что неправильно Вам сдается. smile.gif Представьте: линейчатый фотоприемник (линейка) стоит вертикально в поле зрения прибора. Перед объективом стоит зеркало, которое позиционируется с
...
Помимо всего этого просто есть необходиость считать, например, небольшой прямоугольный фрагмент или записать его туда. Словом, нужен быстрый произвольный доступ.
*

Цитата(des00 @ Jun 7 2005, 15:34)
smile.gif хмм ну представил. Имхо стоит просчитать такой вариант. Делать укладку кадра блоками кратными 4х4, накопление блоков сделать на фифо. И уже построчно/поколонно (ну в общем понятно как) укладывать это дело в память.
Если нужн просмотреть какой нибудь блок память то считать этот блок/блоки не составит особого труда.

Не понял. Вот приходит от сканера синхросигнал фрейма, по нему я вычитываю из ФПУ 288 слов-данных. Их нужно записать столбиком. Куда их писать, если нет произвольного доступа? В строку? А потом медленно и долго переформатировать? А следующий кадр? А через 19 мкс приходит следующий синхросигнал. И получаем новый столбик. И так они и валятся пока зеркало не сделает развертку полного кадра. 768 столбиков.

Записывая данные последовательно, получим повернутый кадр. А его надо тут же выдавать наружу, на монитор. В телевизионном формате. По строкам, т.е. чересстрочно. И как быть?

Цитата(des00 @ Jun 7 2005, 15:34)
прична всего этого гемороя в том, что быстрая одноклоковая память больших объемов, дешевой не бывает к сожалению. Поэтому и нужно под нее подстраиваться.
*

Геморроя тут я особого не вижу. Геморрой был с асинхронной памятью. Большой объем мне не нужен - полный кадр занимает порядка 442 килослова. И стоимость всей комплектухи просто меркнет перед стоимостью фотоприемника - вот под него и приходится постраиваться.

Меня просто исходно насторожило наличие режима burst, не было уверенности, что с этой памятью можно на каждом периоде клока метать данные по произвольным адресам. Но вот коллеги, вроде, утверждают, что все должно быть хоккей. smile.gif Скачал модель, буду пробовать.
Serega Doc
Почему вы сразу отбрасываете DDR как таковую!
Скажите с какой частотой вам надо считывать Ваше щастье уже из памяти!
И если для вас не имеет значения сколько будет стоить ваша приблуда то возьмите несколько двухпортовых памятей и пишите по столбцам а считывайте по сторкам
Но IMXO что если все правильно преобразовывать по времени то DDR 133 (266) - 16 бит очень даже перекроет ваш поток.
Теоретический предел 266 Mслов/s а у вас всего то 100 Mслов/s
А если еще поигратся с разрядностью Внутреннего буфера пишем по 1 слову а читаем по 2, 4 и т. д. то вообще можно получить такой прирост что буть здоров. Еще и аппаратную пост обработку мона успеть сделать!
dxp
Цитата(des00 @ Jun 7 2005, 16:33)
Скорее всего имелось в виду что нужно менять подход. ИМХО даже если стоимость разрабоки позволяет заложиться на дорогое решение проблемы, то это не факт что оно будет лучшее. Например вдруг вам потребуеться потом 266 МГЦ тактовой или памяти значительно поболее?
И потом решают же проблему случаного доступа к ДДР памяти в девайсах обработки видео smile.gif
например http://www.elphel.com/articles/AT3888835064_rus.html#77
*

Да не потребуется там никаких мегагерцев!!! Поток данных там известен - полтора десятка мегаслов в секунду, он НЕ ИЗМЕНИТСЯ. Это определяется САМОЙ ДОРОГОСТОЯЩЕЙ И УНИКАЛЬНОЙ ДЕТАЛЬЮ прибора - КРТ охлаждаемым фотоприемником! Под него и сканер сделан (там даже два сканера - строчный и кадровый), и оптика (германиевая). И ничего это меняться в обозримом будущем (по кр. мере еще лет 10) точно не будет - не та это область, где каждые полгода новая технология начинает рулить.

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

Цитата(Serega Doc @ Jun 7 2005, 16:51)
Почему вы сразу отбрасываете DDR как таковую!
Скажите с какой частотой вам надо считывать Ваше щастье уже из памяти!
И если для вас не имеет значения сколько будет стоить ваша приблуда то возьмите несколько двухпортовых памятей и пишите по столбцам а считывайте по сторкам
Но IMXO что если все правильно преобразовывать по времени то DDR 133 (266) - 16 бит очень даже перекроет ваш поток.
Теоретический предел 266 Mслов/s а у вас всего то 100 Mслов/s
А если еще поигратся с разрядностью Внутреннего буфера пишем по 1 слову а читаем по 2, 4 и т. д. то вообще можно получить такой прирост что буть здоров. Еще и аппаратную пост обработку мона успеть сделать!
*

Я уже устал твердить, что не пропускная способность меня ограничивает, не поток данных. А ФУНКЦИОНАЛЬНОСТЬ памяти... Хорошо. Вот Вам пример. Мне надо записать числа 1, 2, 3.., 287 по адресам 0, 768, 2*768, 3*768.., 287*768 соответственно. За максимально короткое время. Меня бы устроило 10 нс * 288 = 2.88 мкс.

За сколько Вы запишете этот блок по этим адресам на вашей мегапамяти?
des00
Цитата(dxp @ Jun 7 2005, 05:59)
Я уже устал твердить, что не пропускная способность меня ограничивает, не поток данных. А ФУНКЦИОНАЛЬНОСТЬ памяти... Хорошо. Вот Вам пример. Мне надо записать числа 1, 2, 3.., 287 по адресам 0, 768, 2*768, 3*768.., 287*768 соответственно. За максимально короткое время. Меня бы устроило 10 нс * 288 = 2.88 мкс. 

За сколько Вы запишете этот блок по этим адресам на вашей мегапамяти?
*


А вам уже устали твердить что то что вы хотите можно сделать на обычной ддр памяти, хотя именно в вашем случае, действительно ZBТ лучше и проще.
Если бы вам нужно было расширяемое решение, то я бы собрал на фифо 4 ваших столбца (я уже говорил про кратность блока блоку 4х4) и писал бы в память блоками(паралельно собирая блоки следующих 4-х столбцов), блоки бы уложил поколонно(для этого достаточно инкременировать RAS, при постоянном CAS). А при чтении пожалуйста читайте построчно.
Да этот подход не совсем то что вы хотите, но он универсален.
Кстати вы ничего не сказали про ширину шины данных она у вас == ширине одного слова ?
Serega Doc
Ну я допустим организую блок памяти как буфер скадем 4х288 слов внутри FPGA (18 kbit) - EP2C5 (119,808 kBit)
И писал бы туда как мне надо по столбцам - 4 столбца записал а потом выплюнул бы это в SDRAM (не DDR) за 288 циклов пакетной записи по 4 слова в пакете.
Далее простой расчет для SDRAM
3 такта установка активного банка и стороки
3 такта до подачи первых 4х слов и далее организовываем непрерывный поток данных
6+288*4+3=1161 такт
При частоте 133 MHz получаем 8,729 ms для 4 столбиков уже транспонированых

Для DDR это время должно быть процентов на 40 меньше.

У вас же 4 столбика
4*2.88=11.52 ms

Вот и считайте!
Только нужно помнить что динамическую память надо обновлять.
dxp
Цитата(des00 @ Jun 7 2005, 17:11)
Цитата(dxp @ Jun 7 2005, 05:59)
Я уже устал твердить, что не пропускная способность меня ограничивает, не поток данных. А ФУНКЦИОНАЛЬНОСТЬ памяти... Хорошо. Вот Вам пример. Мне надо записать числа 1, 2, 3.., 287 по адресам 0, 768, 2*768, 3*768.., 287*768 соответственно. За максимально короткое время. Меня бы устроило 10 нс * 288 = 2.88 мкс. 

За сколько Вы запишете этот блок по этим адресам на вашей мегапамяти?
*



Цитата(des00 @ Jun 7 2005, 17:11)
А вам уже устали твердить что то что вы хотите можно сделать на обычной ддр памяти, хотя именно в вашем случае, действительно ZBТ лучше и проще.
Если бы вам нужно было расширяемое решение, то я бы собрал на фифо 4 ваших столбца (я уже говорил про кратность блока блоку 4х4) и писал бы в память блоками(паралельно собирая блоки следующих 4-х столбцов), блоки бы уложил поколонно(для этого достаточно инкременировать RAS, при постоянном CAS).

Не понял. Как это поколонно? Как это инкрементировать RAS при постоянном CAS? Если метнуть команду RAS, то после нее надо метать и CAS. Сколько это времени займет? И причем тут фифо?

Я привел пример. Вопрос из него: за сколько времени можно записать DRAM столбик из 288 слов?

Цитата(des00 @ Jun 7 2005, 17:11)
А при чтении пожалуйста читайте построчно.
Да этот подход не совсем то что вы хотите, но он универсален.

В чем универсальность? И про какую расширяемость вы говорите? Я пока что вижу просто неслабое усложнение (со статической памятью работать попроще будет особенно если сравнивать с DDR) при сомнительном результате.

Цитата(des00 @ Jun 7 2005, 17:11)
Кстати вы ничего не сказали про ширину шины данных она у вас == ширине одного слова ?
*

Ширина слова 16 бит (даже 14 - разрядность АЦП).
NeoN
Чет я не понял ваших проблем... Любая синхронная SRAM (Cypress, Winbond, Allince etc.) позволяет устанавливать новый произвольный адрес на каждом такте чтения или записи. Единственное НО - задержка на такт между циклом чтения и записи. Но для борьбы с этим и сделали ZBT/NTD/или как ее еще там назовут SRAM. Суть этой супер-бупер технологии грубо говоря в раздельных шинах данных для записи и чтения. Есть, наконец, еще и двухпортовая память.

А вы - DDR... intelinside, блин, какой-то в головах у людей.
Serega Doc
Я смотредл DATASHEET для cy7c1383c и там на времянках видно что для последовательных адресов можно изменять а для разнобоя адрес данные адрес данные (2 такта на операцию)
dxp
Цитата(Serega Doc @ Jun 7 2005, 17:35)
Ну я допустим организую блок памяти как буфер скадем 4х288 слов внутри FPGA (18 kbit) - EP2C5 (119,808 kBit)
И писал бы туда как мне надо по столбцам - 4 столбца записал а потом выплюнул бы это в SDRAM (не DDR) за 288 циклов пакетной записи по 4 слова в пакете.
Далее простой расчет для SDRAM
3 такта установка активного банка и стороки
3 такта до подачи первых 4х слов и далее организовываем непрерывный поток данных
6+288*4+3=1161 такт
При частоте 133 MHz получаем 8,729 ms для 4 столбиков уже транспонированых

Для DDR это время должно быть процентов на 40 меньше.

У вас же 4 столбика
4*2.88=11.52 ms

Вот и считайте!
*


Вот теперь понял, что вы имеете в виду. Ок, считаем. При использовании быстрой SDRAM имеем 9 тактов на запись из 4-х слов. Итого, наши 4 столбика запишутся за время (возьмем тактовую 100 МГц) 9*288*10нс = 25920 нс или 25.92 мкс. При пересчете на один столбец - 25.92/4 = 6.48 мкс. А на SRAM при этой же тактовой я получаю 2.88 мкс. Более, чем в два раза. При вашем подходе я еще должен выделить буфер внутри под 4 столбца (18 кбит, как вы указали), только реально там должно быть два таких буфера - пока один заполняется, другой заливается во внешнюю память. Либо иметь 4 фифо - на каждый столбец. В принципе, это несложно. А ПЛИСка у меня не второй Циклон (которых реально еще, можно сказать, нет и которые только в коммерческом диапазоне температур, а мне надо индастриал), а EP1C6, где памяти всего 92 кбита. Жирновато получается. В общем, по всем пунктам на динамической памяти это решение выходит хуже: и сложнее, и толще, и геморройнее.

Универсальности, как раз, тут нет - универсальность на статической. А расширяемость тут гарантировано не нужна.
NeoN
вот тут на стр. 14 все показано.
dxp
Цитата(Serega Doc @ Jun 7 2005, 18:24)
Я смотредл DATASHEET для cy7c1383c и там на времянках видно что для последовательных адресов можно изменять а для разнобоя адрес данные адрес данные (2 такта на операцию)
*

Вот этот вопрос меня и интересовал больше всего. Но одно дело, когда на каждое обращение два такта, другое - когда просто задержка на такт или два. Т.е. выставил адрес, данные идут с задержкой. Но в это время уже можно следующий адрес пихать. Произвольный. Коль скоро это так, то и тормозов нет почти - один или два такта на блок - это копейки.
prototype
Может не надо блестеть ржавой стороной? Dxp совершеноо правильно говорит, что СДРАМ - МЕДЛЕННЫЙ. Полюбопытствуйте даташитом на какой нибудь Самсунг РС-166 - минимальное время цикла одиночной записи примерно 65..70 нсек. ДДР может в этом случае быть нужен ТОЛЬКО Интелинсайдерам - для записи одного слова его способность качать данные по двум фронтам до известного места дверца.
Записать то надо всего одно слово! Потому как переформатировать кадр потом - из разряда ... пыль глотать. Любая СДРАМ в любых реинкарнациях хороша только для ПОТОКОВЫХ операций. В отличие от синхронной статики - которая хороша и при произвольном доступе. tongue.gif
Serega Doc
В предыдущем посте есть даташит AS7C33128FT18B где новый адрес на каждый такт. Правда вам потребуется 8 таких микросхем.
А вы не смотрели двухпортовую память. Я знаю что такие микросхемы есть вот только 1 M слово это много.
Тогда все ваши проблемы решаются пишите с одной стороны читаете там где надо!
NeoN
Вам, что 288 Мбит надо? Или 144 разряда??? Они ж разного объема есть... И, повторяю, это - промышленный стандарт. Большинство sync SRAM так организовано.
prototype
Цитата(Serega Doc @ Jun 7 2005, 16:03)
В предыдущем посте есть даташит AS7C33128FT18B где новый адрес на каждый такт. Правда вам потребуется 8 таких микросхем.
А вы не смотрели двухпортовую память. Я знаю что такие микросхемы есть вот только 1 M слово это много.
Тогда все ваши проблемы решаются пишите с одной стороны читаете там где надо!
*

Имхо имея циклон и 133-х мегагерцовую статику dxp сам себе построит двухпортовку, причём за значительно меньшие деньги. Правда 18-ти мегабитная синхронная статика тоже весит будь здоров (хотя ранее dxp сказал что на фоне стоимости прибора плюс - минус 100 баксов ничего не значат).
Serega Doc
2 prototype

Заметте что dxp не делает случайных выборок из всей памяти. А задача как сами видите потоковая просто задачка преобразовать поток.
А пример я привел для SDRAM потому как не помню точных времянок DDR (сколько тактов на активацию строки и др.) но производительность там больше чем у SDRAM на вскидку процентов на 40 т. к. данные по двум фронтам.

Значит наши 4 слова из буфера будут прочитаны за 2 такта.
Так что считайте сами за какое время сможете записывать данные в память и потом за какое время сможете отдать эти данные наружу (уже преобразованные) Раза в 2 быстрее чем из статической памяти.
NeoN
Кстати, 1M x 18 SSRAM не так уж и дорого стоит...
Gate
Внесу и я свои 5 копеек в обсуждение:
Во-первых, мало какие фпга работают с qdr памятью, первые циклоны точно не работают.
Во-вторых, люди, которые советуют ddr - явно теоретики, и с ней сами не работали. Аргументирую:
1. ddr память требует непростого контроллера, кот. занимает ~1000 le в циклоне (альтеровский DDR SDRAM Controller Compiler 3.2.0)
2. ddr память требует на плате:
- питания 2.5в
- подтяжки около 1.6в (точно не помню) через резисторы
- согласования длинн проводников данных
- очень аккуратной разводки
- хорошего текстолита и хорошего изготовителя этой ПП

По сравнению с SSRAM применение в данной задаче DDR просто неумно.
prototype
Цитата(Serega Doc @ Jun 7 2005, 16:11)
2 prototype

Заметте что dxp не делает случайных выборок из всей памяти. А задача как сами видите потоковая просто задачка преобразовать поток.
А пример я привел для SDRAM потому как не помню точных времянок DDR (сколько тактов на активацию строки и др.) но производительность там больше чем у SDRAM на вскидку процентов на 40 т. к. данные по двум фронтам.

Значит наши 4 слова из буфера будут прочитаны за 2 такта.
Так что считайте сами за какое время сможете записывать данные в память и потом за какое время сможете отдать эти данные наружу (уже преобразованные) Раза в 2 быстрее чем из статической памяти.
*


Ага в том то и дело, но если в СДРАМ писать фуллпэйджем, то читать придется одиночные слова. И это реальность данная нам в ощущениях, так устроена матрица в динамической памяти. Короче хрен редьки не слаще. Проблема не в чтении потоком и не в записи, проблема в том что для динамики два эти режима не совместимы в данной задаче. А вот со статикой - проблем нет. На самом деле в этой задаче практически никакая динамика не сможет спорить даже с асинхронной статикой, не говоря о синхронной. Ну не крестятся в динамике два ортогональных потока tongue.gif .
des00
Цитата(prototype @ Jun 7 2005, 11:45)
Цитата(Serega Doc @ Jun 7 2005, 16:11)
2 prototype

Заметте что dxp не делает случайных выборок из всей памяти. А задача как сами видите потоковая просто задачка преобразовать поток.
А пример я привел для SDRAM потому как не помню точных времянок DDR (сколько тактов на активацию строки и др.) но производительность там больше чем у SDRAM на вскидку процентов на 40 т. к. данные по двум фронтам.

Значит наши 4 слова из буфера будут прочитаны за 2 такта.
Так что считайте сами за какое время сможете записывать данные в память и потом за какое время сможете отдать эти данные наружу (уже преобразованные) Раза в 2 быстрее чем из статической памяти.
*


Ага в том то и дело, но если в СДРАМ писать фуллпэйджем, то читать придется одиночные слова. И это реальность данная нам в ощущениях, так устроена матрица в динамической памяти. Короче хрен редьки не слаще. Проблема не в чтении потоком и не в записи, проблема в том что для динамики два эти режима не совместимы в данной задаче. А вот со статикой - проблем нет. На самом деле в этой задаче практически никакая динамика не сможет спорить даже с асинхронной статикой, не говоря о синхронной. Ну не крестятся в динамике два ортогональных потока tongue.gif .
*



Да и вообще поставить виртекс 4, до 10МБит встроенной рамы smile.gif) и сделать все внутре smile.gif
Хотя может я неправильно посчитал smile.gif
dxp
Кстати, объясните, кто знает, тонкую разницу между сигналами ADSP и ADSC (за исключением того, что ASDP приоритетнее). Зачем их два?

И накой там этот burst режим, если внутренний счетик всего на два бита. Все равно максимум через четыре обращения надо новый адрес метать. В чем глубокий смысл?
v_mirgorodsky
Метну ка и я свои пять копеек smile.gif Для Вашей задачи ничего кроме статической памяти не подходит, хотя предыдущие ораторы не раз это говорили Вам до меня. Даже в простейших случаях синхронная динамическая память чрезвычайно геморойна в управлении, а микросхем на два мегабита Вы сейчас нигде не найдете. Минимум начинается с 4-8 мегабит на корпус. И что Вы будете с этим объемом памяти делать?

По поводу burst режимов. На сколько я помню, их можно и не использовать. В зависимости от того, будете Вы использовать ADSP или ADSC и будет выбираться burst режим или одиночное чтение. По моему, так, точно не помню, поскольку давно уже дело было. Burst режим хорошо использовать для экономии мощности. Дернуть (перезарядить входные емкости входов и выходов) 18-20 линий адреса каждый такт намного менее выгодно, чем дернуть их же один раз в четыре такта.

Еще в Вашем случае могут быть вопросы с частой сменой с чтения на запись. Каждый такой переход потребует одного такта задержки. Избежать его можно используя ZBT SRAM. У нее этот вопрос решается за счет симметричной ковееризации в обе стороны.
dxp
Цитата(v_mirgorodsky @ Jun 8 2005, 16:56)
Метну ка и я свои пять копеек smile.gif Для Вашей задачи ничего кроме статической памяти не подходит, хотя предыдущие ораторы не раз это говорили Вам до меня. Даже в простейших случаях синхронная динамическая память чрезвычайно геморойна в управлении, а микросхем на два мегабита Вы сейчас нигде не найдете. Минимум начинается с 4-8 мегабит на корпус. И что Вы будете с этим объемом памяти делать?

Я ни секунды и не сомневался в том, что мне нужна статика. Более того, статика сейчас и используется. Только она асинхронная. Накувыркался с ней, теперь хочу синхронную поставить. Если посмотреть начало темы, то можно увидеть, что никакие динамические памяти я даже не рассматривал и, более того, наоборот вступил в спор с предлагающими делать на ней. И сам исходный вопрос содержал прямо и название микросхемы синхронной статической памяти 1Мх18.

Цитата(v_mirgorodsky @ Jun 8 2005, 16:56)
Еще в Вашем случае могут быть вопросы с частой сменой с чтения на запись. Каждый такой переход потребует одного такта задержки. Избежать его можно используя ZBT SRAM. У нее этот вопрос решается за счет симметричной ковееризации в обе стороны.
*

Да, спасибо, я в курсе. Но мне этот такт не критичен. Видимо, на Flow-through и остановлюсь.
Diod
У нас в проекте мы сталкивались с похожей проблемой (Обработка изображений). Выбрали ZBT SRAM производства IDT и нежалели. Запустился сразу, хотя плата была двухстороняя, протравленная в условиях близких к кухонным. Тестировали правда только до 40MHz (не было нужды подымать выше).

Data sheet:
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.