Хотелось бы опробовать альтеровский ddr2 контроллер, а как скачать с альтеры не ясно.
Если я правильно понял, то теперь только целиком установка megacore library требуется.
Кто пользовался - какие впечатления? 400 МГц Stratix II потянет?

Есть ли у кого сам контроллер или вся megacore library, поделитесь, pls.

На ихнем фтп все что нужно лежит

Чего-то не нашел я там ничего.
Есть University Program IP cores, но DDR2 там нет.
Поделитесь у кого есть.

Заранее благодарен.

там есть например 70_ip_windows. 98M
Там два контроллера ddrII
Что в 71 еще не знаю.

А можно ссылку, пожалуйста !!!
То ли я не там ищу, то ли нет этого уже...

на фтп альтеры
удаленный каталог набирать все сразу
/o_utg_oing/re_lea__se

Спасибо большое!

Если это про контроллер SDRAM DDR2 - то это ни о чем. Версия что распространяется как Megacore - покоцанная, по документам 266 Mhz, реально запускал на 300 - работает... Для полного варианта с динамическим обновлением DLL - говорят обращяйтесь лично в оффис ALTERы. Логика динамического обновления DLL мне не понятна, интересно было б узнать как.
Минусы Megacore:
1. Схема ресинхронизации - совсем не очень, у меня получилось гораздо проще и совсем не проблеммно по фазе.
2. Выборка полосы пропускания памяти - никакая (работаем только с одним банком, откупорим - закупорим. При линейной записи - считывании нормально, при разбросанных запросах - (как память процессора) будут проблеммы с производительностью). А к примеру для 4 банковых устройств можно сделать одновременное открытие всех 4 банков, хранить можно до 4 открытых банков и тд - этого в Megacore нет.
Плюсы:
Быстрая проверка дизайна PCB и целостности чипов.

Итого: Покупать это чудо не стоит, непонятно за что Altera деньги берет. Демо можно использовать для первоначального ознакомления с DDR SDRAM. Реально за неделю -полторы сделать самому контроллер DDR и не заморачиваться с Megacore.
На Stratix 2 - с3 TOP с DLL легко получается 300 MHz, при увеличении длинны конвейеров можно натянуть на 333 MHz. Ключевая особенность при разработке - ручное размещение входных регистров (capture) и указания времени распространения от пинов до них (при большом времени обратите внимание на входные программируемые задержки)...

За это время реально сделать контроллер DDR ничем не лучше, чем контроллер от Altera. А чтобы сделать "нормальный" контроллер, нужно значительно больше времени. Не все так просто.

можно у вас узнать, для повышения образованности, а какую вы схему синхронизации реализовали ?



А вы представляете во что выливаеться реализация логики обработки 4-х банков ? думаю что ни о каких 333 МГц в этом случае речи не будет, а будете конвейеризировать тогда либо просядете по латентности доступа либо не уложитесь в конвейер памяти.

в свободное время я разрабатываю подобный контроллер, НО для сдрам 133МГц CL=3. логика занятная получаеться. Потом планирую выложить его в опенсорс.

А не подскажите-ли номер фичи (FEATURE хххх_yyyy) для ddr из ихнего ip-пака. а то квартус ругается , что таймлимит.

можно у вас узнать, для повышения образованности, а какую вы схему синхронизации реализовали ?

Я в контракте подписывался о собственности заказчика на все мои поделки. Но тонко намекну: 2-x клоковое FIFO+сдвиговый регистр для передачи разрешения приема из генератора адреса в приемную часть. Так я делал в контроллере SSRAM DDR2 300MHz, так и в 2 - контроллерах SDRAM DDR2 . Метастабильности не замечено, но легкая заморочка при подборе длинны сдвигового регистра, что легко решаемо с SignalTap. Секретное комбо - сброс FIFO от задержанного сигнала готовности PLL.

А вы представляете во что выливаеться реализация логики обработки 4-х банков ? думаю что ни о каких 333 МГц в этом случае речи не будет, а будете конвейеризировать тогда либо просядете по латентности доступа либо не уложитесь в конвейер памяти.

Представляю. 4 банка выливаются не во много, и не понятно при чем тут латентность, наверно слово понравилось? Логика как у ALTERA'ы в моей поделке - это простенький автомат на 10 состояний + автомат инициализации на 19 состояний + 2 таймера с конвейерными входами управления и выходами. Обработка одновременно 4-х банков несложно. У меня ето реализовано как стек регистров с номерами банков, кол-во состояний базового автомата не изменилось, 310 тянет контроллер тянет, больше пока не надо, но резервы есть....
Одно но, я в своем контроллере не использую режим Power-down.

по датафлоу понятно, спасибо



похоже вы меня не так поняли. Если бы просто держать банки открытыми проблем бы не было но сдрам в момент act получает адресс ряда банка.

и при доступе в разные строки одного банка все равно потребуеться закрыть и открыть банк. что например у сдрам cl = 3 занимает 6 тактов (на precharge + 3 act.).

держать 4 банка открытыми хорошо когда идет доступ в пределах 1 ряда всех банков с редкой сменой номера ряда. Есть и такие апликации (особенно с длинным бурстом). Но рано или поздно банки все равно придеться закрыть, а закрыть их можно либо по очереди, либо все сразу.

ИМХО при полностью случайном доступе держать открытым имеет смысл только 1 банк + очередь команд и логика конвейеризации команд act + prech.

Про латентость доступа : контроллеры с подобной логикой имеет смысл делать только при наличии очереди команд + логика окна просмотра очереди команд на 1 и более команды. без такой очереди коэффициент увеличения полосы пропускания контроллера будет случайным, зависящим от кол-ва смены адреса ряда в банке .

Про конвейеризацию : если распаралеливания обработки act+pre нет, то времени на декодирование следующей команды вагон, а если есть то желаемое время принятия решения для этого 2-3 такта, лишний такт конвейризации может сломать грамотно придуманый конвейер комманд.

ЗЫ. Вы подали мне хорошую идею, надо сделать реализацию с 1 банком и всеми и погонять на симуляторе со случайным набором адресов и бурстов. и померить коэффициент использования полосы пропусания.

Stas, то есть в Вашей реализации контроллера DDR2 SDRAM оптимизация пропускной способности осуществляется только лишь поддержкой параллельного открытия до 4-х банков?

А вообще, все зависит от характеристик конкретной системы, в которой используется контроллер: где-то возможность поддержки параллельно открытых банков дает выигрыш по производительности, а где-то и существенный проигрыш.

Так что поддержка параллельно открытых нескольких банков - далеко не панацея для увеличения производительности, существует еще масса достаточно нетривиальных способов.

Понятие же "латентности" вполне применимо для случая контрллера DDR2 SDRAM. Кстати, если не секрет, какова латентность у Вашего контроллера, допустим по чтению? (т.е. количество тактов от момента принятия контроллером запроса на чтение с внешней стороны, до предоставления первых прочитанных данных внешней же стороне)

Используем SDRAM c 8 банками, page 1 kB, режим работы с burst =8, шина 64 бит, линейное считываниие и запись, латентность значения не имеет. 4 открытых банка - специфика работы и есть ограничение ИМС на одновременное открытие более 4 банков. ИМХО в этом смысле 4 банковые устройства веселее. Собирается шина адреса в виде row_bank_col, по precharge открывается строка во всех 4 банках (есть такая малоописанная фича) и пишется/читается область в page*4, но опять же это удобно при линийных операциях.
А вот про оптимизацию по пропускной способности было интересно услышать, но не с "академических позиций" а от реального опыта, ибо в новых работах предстоит...

des00

Какие знакомые и приятные темы Мы с товарищем делали подобное чудо и держали открытыми ВСЕ четыре банка памяти. Немного поделюсь опытом Мож будет интересно.

Короче, в нашем случае наш контроллер SDRAM при случайном наборе адресов/бурстов/банков обеспечивал утилизацию полосы памяти выше 99%. Все было завязано на командную систему по принципу "выстрелил и забыл" - в команде указывался адрес, количество даных на чтение/запись и уникальный идентификатор команды. В ответ контроллер выставлял на шину идентификаторов предварительно сохраненыый идентификатор и данные, сопровождая их сигналом "валид". Это чудо поддерживает бурсты от 1 до 16 слов за команду, конфигурируемо в момент запуска команды и внутренне работает с памятью с бурстом 8. Поддержисает любые CL, параметры рефрешей и все остальное.

Немного о реализации. В реализации две (!) дата машины, активационная машина и машина для рефрешей. Контроллер просматривает вперед до трех команд, одна находится на активном исполнении в одной дата машине, вторая готовится к исполнению во второй дата машине, а под третью активационная машина выполняет необходимые активации банков, если это возможно в тот момент. Дата машины немного знают о работе друг друга, а потому могут продолжать бурсты друг друга при необходимости. Занимает это чудо порядка 1000 альтеровских ячеек и работает на частотах порядка 120MHz в самом медленном Cyclone II. Добавляет около четырех тактов задержки к латентности самой памяти, но может брать новую команду каждый такт.

Если кто поверит, то это была с товарищем наша самая первая серьезная разработка, написанная на VHDL До этого мы пользовались исключительно схемным вводом и ничего подобного ни по размерам ни по быстродействию не создавали

Единственное, что могло бы дополнительно ускорить контроллер - это пересортировка записей и чтений, идущих на вход контроллера. Я видел реализацию подобных алгоритмов, но они оказывались слишком сложными и применимыми только для ASIC'ов с их быстродействием.

Сейчас уже, с высоты опыта, делали бы немного по другому. Очень большое количество усилий было затрачено именно для поддержки режимов с размером бурста, равным единице. Фактически в этом режиме контроллеру каждым тактом необходимо обновлять адрес на шине и вести синхронную передачу/прием данных. Сейчас в планах есть построение контроллера на DDR2 с похожими принципами работы. Как будет чем похвастаться - обязательно расскажу

BTW, разработка заняла почти месяц времени Одной из главных неприятностей была ее полная параметризация под любой тип SDRAM памяти - каждый блок имеет целый список констант на входе.

а можно узнать как вы померили что 99% полосы использовалось ? т.к. по результатам предварительных экспирементов на модели памяти от микрона все портят 3 параметра :
tras + twr и возможный t_bta. Из за этого необходимо вставлять дополнительные выравнивающие nop в командах со сменой адресса колонки и перехода от чтения к записи.



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

Ориентируюсь на CL = 1..3, burst = 4 (для совместимости конвейера комманд с DDR/DDR2), не использование burst_terminate(все на масках).

Сечас исследую возможности конвейера комманд СДРАМ, и делаю поведенческое описание контроллера, потом перетяну его на РТЛ с использованием МПА. Пока по прикидкам все должно уместиться на 1МПА на блочной памяти (!!!).

Я не зря сказал о просмотре очереди команд на три команды в глубину. Если необходима активация неактивной строки, то она прячется внутри бурстов, выполняемых в данный момент. Неприятность представляют только запросы идущие в один банк и в разные строки. Однако и здесь мы немного схитрили, использовав по возможности команды записи/чтения с активированным автопречарджем.

А по этому поводу я говорил, что дата машины могут продолжать бурсты друг друга. Таким образом смена адреса колонки в активной строке и сохранении направления передачи даных вообще не требует ни одного лишнего такта. Контроллер учтет все необходимые задержки распространения по тактам и выйдет на шину в строго детерминированный момент. Немного хуже обстоят дела с изменением направления передачи даных, однако и это ограничивается только возможностями протокола самой памяти.

Вообще говоря, под функциональными блоками самой памяти лежит блок моделирования контекста памяти, который вырабатывает разрешения на каждую конкретную операцию в каждый конкретный момент. Потому логика работы контроллера в подавляющем большинстве случаев ограничивается только протоколом работы памяти. Есть только одно место, сейчас уже точно не вспомню какое, которое можно было бы сделать на такт быстрее, но у нас не получилось - слишком длинными становились ассинхронные пути разрешения операций с блока физического моделлирования контекста памяти.

В нашем дизайне мы использовали burst_terminate и совсем не использовали маски. Теперь есть небольшие проблемы, поскольку такая модель совсем не ложится под DDR/DDR2 Под новую разработку придется некоторые вещи переделывать.

Спасибо за разьяснение! Постепенно до меня доходит как и что происходит в вашем контроллере.




да именно по этому я и решил тренироваться на "кошках" (SDRAM), что бы потом логику команд можно было просто перетянуть на DDR )

Была и у нас и такая идея - в самом начале, но в конце пришлось все же делать на дискретных FSM, поскольку не обеспечивался требуемый уровень гибкости и быстродействия всей системы.

des00
Не поделитесь технологией создания и отладки МПА?

Думаю что лучше Кена Чапмена

http://www.xilinx.com/xlnx/xweb/xil_tx_dis...mp;languageID=1

Иосифа Каршенбойма
www.iosifk.narod.ru

Мика и Брика "Проектирование устройств с разрядно-модульной организацией"

я не раскажу, могу лишь только описать тонкости и особенности.
Статью про особености реализации ассемблеров и генераторов для таких штук смотрите в следующей статье Иосифа К. (скоро должна выйти в свет),

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

Я в том смысле каким ПО (ассемблером) пользуетесь...

свои пишу + интегрирую туда код для генерации, что бы за собой верилог файлы не таскать.
в последнее время пишу на Python получаеться быстро и очень просто.

Подробнее об этом в "заседании клуба экспертов" №2.

Очень хотелось оставить без внимания подобные заявления, но все же выскажусь.

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

P.S. ничего личного, просто не могу пройти мимо такого заявления

Поскольку наш контроллер использует команды авто-рефреша строк памяти, то это время теряется безвозвратно. Была идея прятать рефреш в средину работы активных команд, однако она показалась на тот момент слишком сложной. Просто это разумелась само собой в нашем тестировании, а потому время рефрешей в расчетную полосу и не закладывалась. BTW, время рефрешей составляет около 1% всей полосы работы памяти. Еще момент, при тестировании не менялось направление передачи данных. Вот это единственные неточности и оговорки в этой цифре.

Теперь, идем дальше. При случайном наборе адресов/бурстов/банков средняя длинна бурста составляет 8 трансферов данных за команду. Могу вас уверить, что просмотр очереди команд на три команды вглубь дает широчайшие возможности для манипуляций с банками во время активных трансферных операций. В нашем дизайне спрятанные пречрджи/активации банков становятся возможными при длинне непрерывного бурста равным три и более. Как я уже говорил, единственными неприятностями для контроллера являются последовательные доступы в один и тот же банк, но в разные строки. Возможно в нашем тестировании таких случаев было мало.

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

P.S. При определенных прочих равных, если есть гарантия доступа во все строки памяти в пределах окна рефреша и достаточной длинне бурстов (начиная где-то с 8 трансферов за команду) можно получить и все 99.9% утилизации всей теоретической полосы памяти. Без скидки на рефреши. Надо только чтобы направление передачи данных менялось достаточно редко. Или вы снова скажете, что это невозможно?

хорошо, давайте рассмотрим след. ситуацию:
последовательность: запись-чтение из разных строк одного и того же банка
при таком сочетании вам требуется: закрыть банк, tRP, открыть банк на новой строке, tRCD, выполнить команду чтения, tCL = итого 1+2+2(в лучшем), и 2+3+3(в худшем случае) холостых тактов.
Чтобы получить 99%, вам нужно чтобы такая ситуация встречалась не чаше чем 1 раз в 500 тактов!
И это только одна из 10 ситуаций, требующих холостых тактов на шине данных.

да, снова скажу - невозможно!

все, не продолжаю дискуссию..

2 Loki5000

простите что вмешиваюсь в дискуссию насчет 99.9% но полагаю что вы не заметили пометки v_mirgorodsky:

>> Без скидки на рефреши
>> направление передачи данных менялось достаточно редко
>> гарантия доступа во все строки памяти в пределах окна рефреша

полагаю что к этому списку все же следует добавить "смена адреса ряда в пределах банка происходит достаточно медленно", т.к. хуже ситуации read->write different rows same bank не придумаешь.

Вы просто говорите о разных вещах!!!
2 mirgorodsky

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

получили без учета рефрешей > 90%. Но это частности, а не общности. Интересно было бы померить пропускную способность именно на рандомных адресах/бурстах и последовательносях read->write )

Если есть интерес, то могу скомпилить до EDIF'а наше ядро под CL=3, написать под него небольшой тестбенч в качестве хелпа и выложить здесь для посмотрения

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

Спасибо большое, пока в этом нет необходимости. Для начала я хочу все подходы проверить, процентов 25 поведенческого контроллера уже написано дальше видно будет.

Добрый день господа!

На этих НГ праздниках я нашел время доделать контроллер, который разрабатывал для души, и набросать для него пока простой тестбенч, что бы убедиться в его работоспособности.

Сейчас в разработке полный тестбенч функциональности и тестбенч на измерение полосы пропускания для различных случаев последовательности команд.

После разработки полного тестбенча проект будет выложен либо на

http://code.iprium.ru/

либо на opencores (если будет не лень делать перевод доки на английский язык).

В атаче описание разработанного контроллера. С исходниками немного нужно обождать, их нужно почистить и доделать тестбенч (правда работать он будет только в софте с хорошей поддержкой систем верилога, т.е. в альдеке не заработает).


ЗЫ. Вопрос модераторам может стоит перенести обсуждение вопросов по сдрам, ддр, ддр2 в этой теме в отдельную ветку форума ?

Пишите, помогу с переводом, если нужно...

Спасибо, буду иметь в виду.

По проекту тест правильности работы отлажен и работает. Сейчас занимаюсь тестами на измерение производительности.

Не подскажите где можно найти достаточно понятную информацию по использованию памяти и модулей памяти (схемы, разъемы, вр. диаграммы, ip блоки). Информация нужна для студентов. Просто самому писать довольно много не хочеться, а хорошей статьи не нашел.
Прошу прощенья за оффтоп.

Не подскажите где можно найти достаточно понятную информацию по использованию памяти >>>>>>>>>>>>

http://www.elpida.com/en/products/documents.html

Написал в личку.


Уфф, последняя стадия публикации на опенкорес : перевод документации.


Кому интересно смотрите доку в атаче.

Добровольные помощники в нелюбимом мной деле документирования приветствуются ))

Добрый день всем!!!

Свершилось, извините за опоздание конечно. Много времени ушло на перевод.

Спасибо большое уважаемому ReedCat за помощь !!!


http://www.opencores.org/projects.cgi/web/hssdrc/overview


Обсуждение, порицание, предложения (хотя пара модификаций у меня на уме) приветствуются !!!


Копия документа в атаче

нескромный вопрос - а предполагается ли модуль(тестовая система) для быстрого запуска на nios2-devkit-2c35?

А русское описание сохранилось?)

Аппаратная проверка заложена в план TODO. Но в наличии у меня платы на спартан 3е и циклон2, разработанные у нас, поэтому изначально проект будет протестирован на них.

Плату nios2-devkit-2c35 ни разу не видел, ничего сказать не могу.

Планов сделать проект SOPC Builder compatible нет, из-за недостатка времени и ламерстве в кухне NIOS и SOPC Builder. Ближайшее это создание оберток для контроллера на шины Wishbone (burst oriented) и AMBA AXI и потом тестирование их в тестовых системах на платах.

Но, контроллер идет под MIT лицензией, можете сами собрать любую угодную для вас тестовую систему и модернизировать контроллер

Кстати не подскажите идей о том, как такие системы тестирования делают (у меня есть пара своих идей, но может не очень удачных).

2 torik



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

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

А варианты с САМ кэшем ( ассоциативной памятью) не рассматривали ? Я так предпологаю , что большие скорости обмена с памятью (DDR2) , выбраны исходя из того , чтобы минимизировать простои со стороны ядра (которое может работать сущесвенно быстрее) . Т. е. возможно имеет место проблема "Бутылочного горла" , когда работа быстрого устройства тормозиться более медленными. Бурцева В.С. читайте
НОВЫЕ ПРИНЦИПЫ ОРГАНИЗАЦИИ ВЫЧИСЛИТЕЛЬНЫХ ПРОЦЕССОВ ВЫСОКОГО ПАРАЛЛЕЛИЗМА
Институт проблем информатики РАН,

Спасибо за ссылку, мне эта тема достаточно интересна.

По гуглу это описано здесь ? http://lvk.cs.msu.su/old/mco/part11.html

Если вопрос насчет КАМ адресовался мне, то поясните пожалуйста каким местом к контроллеру памяти предлагается использовать ассоциативный кеш ? %)

Контроллер внешней памяти это последняя инстанция хранения данных (берем систему без других внешних носителей информации ака винт). Т.е. по сути это последний слой работы с данными.

Кеш это один из предварительных слоев обработки информации и следуя принципу модульности построения: контроллер с кешем это система из отдельного контроллера памяти и кеш контроллера )
Сделайте кеш контроллер и подключите его к контроллеру сдрам.

мне было интересно выжать в контроллере именно максимум полосы пропускания внешней памяти, за счет использования ее возможностей.

Полученные латентности доступа к данным это ФПГА компромис между латентностью и тактовой частотой.

С помошью небольшой модификации контроллера, латентность может быть уменьшена на 2 такта, но в этом случае гарантировано сильно упадет тактовая частота. Это несложно проверить.

Элементарно Ватсон. Предположим хотя-бы 8 потоков даных от восьми независимых шин данных (блоков или процессоров) стучаться в единое адресное пространство. Вот этим боком и касаеться. Т.Е мысля спрятать сам внутрь контроллера. Ну и соответственно время выборки из Сам на внешюю шину меньше чем время чтения записи SDRAM DDR. В качестве данных ассоциативного кэша например можно использовать адреса по которым происходили последнии обращения к контроллеру памяти и соответствующие этим адресам данные. возможно предварительое заполнение с упреждением для чередующихся адресов

Нет позвольте.

То, про что вы говорите, не имеет никакого отношения к контроллеру памяти. Это обычный кеш, последнего уровня, который стоит перед контроллером памяти и формирует нужные к контроллеру запросы, исходя из политики своей работы (тип кеша, политики управления кешем, упреждающее чтение и т.д.).

Нет никакого смысла вносить эту логику в контроллер памяти, т.к. задача контроллера памяти сформировать требуемые последовательности комманд для записи/чтения в память.

Кеш про который вы говорите специфичен для каждого конкретного применения и нет никакого смысла включать его в универсальный контроллер.

Если хотите контроллер с таким кешем, то разработайте кеш, и заверните его, вместе с контроллером в отдельный врапер. и назовите этот врапер my_super_controller, про который вы ведете речь.