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 поведенческого контроллера уже написано дальше видно будет.