Прогрессивный DMA

[maaaaaad]

Кто что посоветует для реализации прогрессивного DMA контроллера.

Что есть :
1. 1 базовый адрес (аппаратные трансферы до 4к)
2. Управляемые берсты 0-16 DWORD и часло DWORD для закачки, статус
3. Read/Write транзакции


Что придумал или нужно.
1. Прерывание по завершению закачки.
2. 8 базовых регистров (аппаратные трансверы до 32к)
3. 2 ядра (для безостановочной работы) т.е. пока одно ядро далает трансфер, второе ядро подготавливается к трансферу.


Хотел сделать Разбор MDL на аппаратном уровне, но для этого требуется отдельно выкачивать списки страниц, что приводит к накладным расходом весьма вероятно больших, т.е. PCI 133 мегагерцовый а кристалл FPGA 250 мегагерцовый.

Какие идеи? 

[Ochkarik]

прерывание для 4к буферов - слишком часто при высоких скоростях передачи(при потоках)... для единичных блоков пойдет. если только отключаемое делать?
рекомендую доступ к счетчику транзакций сделать и попроще желательно) - хорошая альтернатива прерываниям.
MDL - в общем... хлопотное дело, а удовольствие только в системах с небольшой памятью или когда часто размер буферов меняешь. больше 16-32 МБ смыла выделять наверное не бывает а 32М и так можно при загрузке оттяпать)

а вообще от специфики задачи все зависит...

[maaaaaad]

ну да....походу уже больше ничего не придумаешь..

кстати никто не задумывался об архитектуре процессора с аппаратной сжатией страниц? Запихать в процессор простенький LZF кмпрессор с менеджером - дело не хитрое, а совтверный вариант компрессора памяти есть под другие ос.

[Finch]

maaaaaad, а смысл? Любые лишние телодвижения влекут к уменьшению скорости работы. И не всегда тебе удастся сжать данные. Данные хорошо сжимаются, когда есть явные пики в распределении. Когда данные равно распределеннные, сжатие не работает. Так что овчинка выделки не стоит.

[maaaaaad]

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

[Finch]

maaaaaad, на wintel (windows + Intel) машинах одна страница памяти 4096 байт. Покажи ка алгоритм, который будет сжимать такой объем за один тик? Да кстати тик чего Центрального процессора, шины данных ..... ?

[maaaaaad]

я же говорил о процессоре. за процессорный тик.

[Finch]

maaaaaad, Скажем процессор работает на частоте 3 Ггц. Память работает на частоте 533 Мгц (DDR2). Шина данных допустим 256 бит. Подсчитай ка, сколько тиков процессора тебе потребуется, чтобы только считать страницу памяти, я уже не говорю о компрессии. И еше чтобы реализовать данную идею, нужно буферизировать данные в кэшэ 1 уровня хотя бы. И потом это всё слить в СВОП. Также и обратный процесс.

[maaaaaad]

ты не совсем понял.

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

[Finch]

maaaaaad, Я насколько читал про классические алгоритмы сжатия. Наиболее эффективные из них работают основываясь на блоках. Считывается блок, считаются пики (наиболее часто встречаюшиеся комбинации). Потом тем или иным способом эти комбинации заменяются на более короткие. Я уже не говорю про алгоритмы математического сжатия. Там не отделаешся одним тиком.
Поэтому пожайлуста алгоритм в студию, который сжимает данные, даже не зная что он сжимает.

[maaaaaad]

Любой алгоритм распаралеливается. Вопрос в конечной цене.
LZF на кристалле может займет миллион триггеров и несколько миллионов ячеек памяти (несколько мб) и будет стоить в массовом производстве пусть 200$
А что мешает коду, который исполняется параллельно использовать блоки я не понял.