Цитата(gosha @ Dec 18 2008, 01:32)

Увы, пока требуется ...
Какие характеристики cpu, dma_мастеров необходимы для сравнения характеристик sdram core?
не те характеристики вы пишете,
полоса в память сколько требуется ? (100/200/300 МБ/с)
размеры и выравнивание бурстов ? их характер ? требуемая латентность доступа к памяти ?
Цитата
2 шины - для исключения тактов ожидания от wb_arbiter (wb_req, wb_gnt).
всего 2 шины ? кого ждем ? однотактный арбитр вишбона(Wishbone classic only)
Код
module rrarb_1(request, grant, reset, clk);
input [1:0] request;
output [1:0] grant;
input reset;
input clk;
reg [1:0] grant;
reg last_winner;
always_ff @ (posedge clk) begin
if (reset) last_winner <= 0;
else if (request) last_winner <= get_winner(request);
end
always_comb begin
grant <= 2'b00;
grant[get_winner(request)] <= 1'b1;
end
function automatic bit get_winner(input reg [1:0] request);
case (request)
2'b01: get_winner = 1'b0;
2'b10: get_winner = 1'b1;
2'b11: get_winner = last_winner+1'b1;
default : get_winner = last_winner;
endcase
endfunction
endmodule
...
rrarb_1 rra ({wbm_cyc_0, wbm_cyc_1}, {wbm_grant_0, wbm_grant_1}, reset, clk);
assign wbs_cyc = (wbm_cyc_0 & wbm_grant_0) | (wbm_cyc_1 & wbm_grant_1);
...
Цитата
Какие характеристики cpu, dma_мастеров необходимы для сравнения характеристик sdram core?
пока еще маловато данных
Цитата
Или Вы порекомендуете интегрировать в проект все core по очереди с запуском тестов пропускной способности на реальном железе?
это вам решать
Цитата
Также вопрос: С Вашей точки зрения система с раздельными шинами [cpu- sdram], [pci, ide- sdram]будет предположительно иметь лучшие характеристики, чем с единой шиной?
в случае wishbone_bus, будет необходим буфер по записи, принимающий пакет c wb_bus и подсчитывающий длину буста. После этого производится запись в sdram. Дополнительно за счет буферизации вро-де бы должна увеличиваться пропускная способность?
Вопрос о лучшести пока подвешен, но мне кажется что вы не представляете потенциальных проблем шины wishbone по работе с бурст транзакциями. Рекомендую вам почитать внимательно главу Wisnbone Register Feedback ее стандарта и попробывать на коленке сделать для этой реализации арбитр и слейв со случайным временем доступа

Оччень увлекательное занятие.
Как уже говорил, у вишбона есть потенциальные проблемы :
1. нет стандартной возможности сообщить слейву размер буртса (обходится тегами, но нужен специальный арбитр и специальный мастер)
2. отсутствие разнесенных транзакций, т.е. мастер выставил первый запрос и держит его до посинения, пока не получит ответ, только потом идет смена адресса/данных/транзакйии(это обходится сложнее, тут нужен специфический арбитр).
3. отсутствие требований на выравнивание бурст транзакции, т.е. в транзакции Linear Burst вы можете легко перейти в другой ряд памяти и это вызовет "дырку" в тех же командах к сдрам (в общем виде не обходится, только соглашениями как в AMBA на размеры сегментов).
Вот это вы должны учитывать в своей системе.
Реализация с буфером требует наложения ограничений на размеры бурста и как вы будете решать проблему латентности записи/чтения если бурст относительно большой?
В моем мосту Wishbone/HSSDRC (выложить пока не могу, ибо не тестирован хорошенько) запись идет "транзитом", практически без кеширования. А вот чтение сделано с кешированием по запросу. Это позволяет работать как с WbClassic так и с WbRegisterFeedback шинами, с поддержками WS в обоих направлениях, при разумной тактовой частоте %)
Но в любом случае, без специального арбитра очень сильно падает полоса памяти, из-за латентности чтения и отсутствия разнесенных транзакций в шине.
PS. посмотрите AMBA AXI, у нее таких проблем нет, правда ее реализация сложнее.
ЗЗЫ. арбитра не того скопировал, поправил, теперь точно однотактный %)