Cкажется ли куда (row/col/bank) отправлять разряды адреса wb_шины?

Например, старшие разряды шины адреса -> col, младшие -> row при использовании контроллера типа des_00?

Соблюдать правильное подключение адресной шины (Старшие адреса -> row, младшие -> col) очень важно. Для обеспечения максимальной пропускной способности в SDARM используется режим конвеерного чтения строк. При этом сначала строку требуется открыть, а потом после чтения закрыть. Подключив адресную шину так как вы написали, при последовательной записи (т.е. с увеличением адреса на 1) вы будете вынуждены для записи каждой ячейки выполнять процедуру открытия/закрытия строки. На чем потеряете 80 - 90 % времени . Никогда не работал с контроллером типа des_00, но смею предположить, что при неправильном подключении он вообще не будет правильно работать.

в доке ведь написано всё


читаем в доке от создателя HSSDRC IP Core, уважаемого des00
http://www.opencores.com/projects.cgi/web/hssdrc/overview
дока тута Нажмите для просмотра прикрепленного файла
Table 4.5.4 Variants of the controller system address mapping on SDRAM bank, row and
column addresses
The address mapping function (bank, row
and column addresses concatenation)
Comment
sys_addr = {sys_ba, sys_rowa, sys_cola} it is recommended to use in case when application
have linear sequential access and data size
is less than capacities of one memory row.
sys_addr = {sys_rowa, sys_ba, sys_cola} It is recommended to use in all other cases.

Интересно как вы сами думаете ?

Все следует из характера работы сдрам памяти и используемого вами режима. Если вы будете всегда писать по 1 слову, вы вообще можете распихать адреса как вам будет угодно.

Обычно отображение адресов выбирают исходя из :

1. размер бурста
2. выравнивание бурста
3. частота обращений по адресам

Нужно смотреть ваш конкретный случай.
Оптимальное, рекомендуемое отображение приведено в документации.

Удачи !!!

Еще дилетантские вопросы:

Virtex2p, sodimm, в данной итерации пока нужен контроллер sdram (не ddr) т.к. плата уже изготовлена.


На rank (s0,s1) какой лучше отправить разряд wb_addr?
Какую opencore Вы порекомендуете (с учетом возможного downgrade ddr opencore)?
Контроллер des_00 при переделке его в контролллер sdram - возможны ли грабли?
Лучше ли core от altera || xilinx чем представленные на opencores?

Если работает с core от altera || xilinx и с opencore
Разница может быть только в том, что нужен ли в конечном итоге исходный код.

Все исходные тексты проекта нужно предоставить для проверки на отсутвие закладок.

Но, как я понял, у xilinx в appnotes есть free контроллеры sdram в исходных текстах:

ftp://ftp.xilinx.com/pub/applications/xap...134_verilog.zip
ftp://ftp.xilinx.com/pub/applications/xapp/xapp200.zip

Или эти примеры имеют худшие характеристики?

странно, вообще то переход с sdr sdram на ddr sdram это upgrate, а у вас наоборот. Я бы с ддр не рекомендовал вам связываться, сразу ставить ддр2.



Лучше/хуже без конкретизации параметров разговор на пустом месте, побольше конкретики.



вы вообще проект смотрели ? это и так sdr sdram. В названии же написано HSSDRC == HighSpeedSDRamController.

С ддр будут проекты HSDSDRC/HSD2SRD== HighSpeedDdrSDRController/ HighSpeedDdr2SDRController. Но это когда время будет, уже год зашиваюсь .

Увы, пока требуется не ddr, ddr2, ddr3 sdram котнроллер, а single data rate sdram контроллер для одного модулька sodimm.
- wb_bus 133 MHz.
- Две шины к контроллеру sdram (радиально) (1ая шина- от cpu (mips_rm7000), 2ая шина- dma от ide, pci платы). 2 шины - для исключения тактов ожидания от wb_arbiter (wb_req, wb_gnt).
- Шина от cpu к контроллеру sdram пока совсем не wishbone.

Какие характеристики cpu, dma_мастеров необходимы для сравнения характеристик sdram core?

Или Вы порекомендуете интегрировать в проект все core по очереди с запуском тестов пропускной способности на реальном железе?

Также вопрос: С Вашей точки зрения система с раздельными шинами [cpu- sdram], [pci, ide- sdram]
будет предположительно иметь лучшие характеристики, чем с единой шиной? Или это тоже стоит тестировать?

могу пару слов сказать про DDR Xilinx.
Очень хороший контролллер, если работать на уровне рефернес дизайна из AN.
из проблем только то что придется подбирать констрейны редактировать на предмет использования нестандартных ног.

2 gosha: вы случайно не спецвычислитель делает на rm7000 ?

Вы говорите о xapp_200?

Для SFx: Олег, мы знакомы или нет?

Для des_00 дилетантские вопросы: в случае wishbone_bus, будет необходим буфер по записи, принимающий пакет c wb_bus и подсчитывающий длину буста. После этого производится запись в sdram. Дополнительно за счет буферизации вро-де бы должна увеличиваться пропускная способность?

не те характеристики вы пишете,
полоса в память сколько требуется ? (100/200/300 МБ/с)
размеры и выравнивание бурстов ? их характер ? требуемая латентность доступа к памяти ?


всего 2 шины ? кого ждем ? однотактный арбитр вишбона(Wishbone classic only)





пока еще маловато данных



это вам решать



Вопрос о лучшести пока подвешен, но мне кажется что вы не представляете потенциальных проблем шины wishbone по работе с бурст транзакциями. Рекомендую вам почитать внимательно главу Wisnbone Register Feedback ее стандарта и попробывать на коленке сделать для этой реализации арбитр и слейв со случайным временем доступа Оччень увлекательное занятие.

Как уже говорил, у вишбона есть потенциальные проблемы :
1. нет стандартной возможности сообщить слейву размер буртса (обходится тегами, но нужен специальный арбитр и специальный мастер)
2. отсутствие разнесенных транзакций, т.е. мастер выставил первый запрос и держит его до посинения, пока не получит ответ, только потом идет смена адресса/данных/транзакйии(это обходится сложнее, тут нужен специфический арбитр).
3. отсутствие требований на выравнивание бурст транзакции, т.е. в транзакции Linear Burst вы можете легко перейти в другой ряд памяти и это вызовет "дырку" в тех же командах к сдрам (в общем виде не обходится, только соглашениями как в AMBA на размеры сегментов).

Вот это вы должны учитывать в своей системе.

Реализация с буфером требует наложения ограничений на размеры бурста и как вы будете решать проблему латентности записи/чтения если бурст относительно большой?

В моем мосту Wishbone/HSSDRC (выложить пока не могу, ибо не тестирован хорошенько) запись идет "транзитом", практически без кеширования. А вот чтение сделано с кешированием по запросу. Это позволяет работать как с WbClassic так и с WbRegisterFeedback шинами, с поддержками WS в обоих направлениях, при разумной тактовой частоте %)
Но в любом случае, без специального арбитра очень сильно падает полоса памяти, из-за латентности чтения и отсутствия разнесенных транзакций в шине.

PS. посмотрите AMBA AXI, у нее таких проблем нет, правда ее реализация сложнее.

ЗЗЫ. арбитра не того скопировал, поправил, теперь точно однотактный %)

Основной обмен данными cpu - sdram.
Загрузка кода- данных в кэш процессора/ сохранение кэша.
Происходит это пачками по 4x 32бит слова. Cpu cache line size=32 байта.- Как я понял, cpu периодически линейно заглатывает/выталкивает 2 burst по 4 32бит слова для заполнения/синхронизации кэша. Остальное, вероятнее всего, зависит от выполняемого кода.

ide-sdram dma: - по 2 32бит слова. Передается как правило, cтраница памяти (4096 байт), выравнена на границу 4096 байт.

Контроллер sdram должен работать с любыми модульками sodimm любого производителя.

Что такое характер бурстов?
Что такое требуемая латентность?

Требуется, чтобы контроллер sdram и sdram работала на чатоте 133 MHz, все остальное- сколько удастся добиться.

Также туплю- дилетанский вопрос: для работы контроллера hssdrc с модульком sdram (nranks > 1) требуется модификация кода hssdrc?

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

1. бурст 4 по 32 = 16 байт, странно ведь кеш 32 байта, это не сильно хорошо.
2. бурст 2 по 32 это очень плохо.
На запись еще куда не шло, на чтение (особенно режим по 2 слова), при использовании шины класса Wishbone это смерть всему. На каждой транзакции чтения вы потеряете ~5 тактов (CL + латентность контроллера). урезка полосы до 4/9 и 2/7 45% - 30 % соответственно.

Варианта 2 :
1. вместо 2х32 реализовать режим 16х32, все равно пишете/читаете линейный пакет.
2. сгоротить мини-кеш для линейных транзакций прямо на входе контроллера(я делал подобное, получается достаточно просто).

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

Вот и верхняя оценка полосы пропускания вашей системы. берем 64 бита на 133МГц, т.е. около 1 ГБ/с, в ваших режимах потери составят порядка 50-60 %, т.е. ваша система, при лобовой реализации, сможет прокачать не более 400-500 МБ/с.

Оптимизация в вашем случае возможна только за счет разумного управления банками, в виду отсутствия разнесенных транзакций на Wishbone разумное управление конвейером SDRAM команд результата почти не даст (правда выигрыш можно получить если сделать хороший wishbone арбитр, который будет разносить 2 мастера) .



не знаю, смотреть надо. Ограничения IP на память 4 банка, шина данных кратна байту (иначе будут неправильно расчитываться и обрабатываться маскирование байтов).

ЗЫ. Извините что долго не отвечал, работы много и как то вылетело из головы %)

Спасибо.

Рекомендации ре-дизайна сопряжения с cpu и ide_core принимаются. Т. к. основной обмен данными cpu-sdram, ide-sdram.

Но, кроме всего прочего, процессорка должна работать с любыми pci платами в режиме dma. Поэтому размер burst, кроме cpu и ide, должен поддерживаться любой.

Не срочно, но пожелания по контроллеру HSSDRC: хотелось бы, чтобы была возможность работать с модульками dimm, sodimm. (напр nranks=2; 4 bank в каждом rank), интересовал бы Ваш вариант сопряжения с HSSDRC wishbone bus.