Вид для печати
Вычищать мусор из всего проекта не хватает моральных сил, вот контроллер сдрама, его будет достаточно для оценки нововведений :)
Странные манипуляции с адресными линиями вызваны тем, что при обращении к контроллеру адреса перепутываются (A[14:13] помещаются в самые младшие разряды) для облегчения/ускорения чтения видео.
Никто не успел заметить - а я успел доработать. Теперь кеш (теперь 4 Кб) обновляется не только при записи, но и при чтении.
Сейчас еще более "агрессивный" вариант попробую.
---------- Post added at 21:50 ---------- Previous post was at 21:35 ----------
Время прогона оптимизированного эксисайзера для SDRAM 144/CPU 48:
без кеша - 9:30
с кешем (первый вариант) - 9:10
Тут я подумал - WTF? Что ж такая низкая эффективность?
После вышеописанной доработки
с кешем (второй вариант) - 8:20
Это уже на что-то похоже.
Если не бояться кеш-промахов, то можно не начинать параллельно чтение из SDRAM (которое в случае кеш-попадания долго завершать), а сначала попробовать найти в кеше и только если там нет тогда читать из SDRAM. При кеш-промахе будем терять 2 такта, но, как известно из литературы, кеш-промахи д.б. не очень частыми (это если не делать как я в первом варианте).
с кешем ("агрессивный вариант") - 7:10
Вот это я понимаю! У меня на стареньком атлоне оригинальный эксисайзер только чуть быстрее в emu работал :)
---------- Post added at 22:17 ---------- Previous post was at 21:50 ----------
Но все равно пока что кеш туповатый, можно и сам контроллер улучшить и снаружи.
SDRAM 162/CPU 81 с кешем - 5:26
Можешь в двух словах описать работу кеша?
Сейчас реализован самый простой вариант - кеш прямого отображения со сквозной записью.
Адрес, по которому обращается процессор делим на две части - младшая будет индекс в кеше, старшая хранится в теге кеша и при обращении сравнивается с тем, что сейчас дает проц. Пишем в кеш при чтении из сдрам (то, что я в первом варианте не сделал) или при записи.
Причем я вчера попробовал сделать перекос в сторону чтения еще сильнее - обновлять кеш при записи только если данный адрес уже там есть. Это не изменило время прогона эксисайзера и амбала3д, так что пока под вопросом, как оставить.
Выложенный вариант "консервативный" - читаем из кеша и проверяем тег параллельно с чтением из сдрам. Так мы никогда не будем терять такты в случае кеш-промахов, но и выигрыш маловат. После тестов сам я однозначно за "агрессивный" вариант - сначала читаем из кеша, и только если там нет - начинаем обращение к сдрам. В худшем случае потеряется два такта, но кеш-попадания заметно чаще промахов, т.ч. игра стоит свеч.
Что стоит доделать для более серьезного применения - увеличить размер строки кеша. У меня сейчас каждой записи тега соответствует один байт из памяти. Это очень неэффективно. Надо как минимум 2, а лучше 4-8-16 и читать пакетом.
Да, еще надо не забывать инициализировать кеш при ресете. В векторе я загрузчик чуть доработал для этого.
В векторе, раз нет дма и видео всегда в одном месте (плохо для программера, хорошо для кеширования), то сравнительно несложно доработать до обратной записи. Т.е. по видеоадресам сквозная запись, а по остальным - обратная.
Эффективнее был бы наборно-ассоциативный кеш (хотя бы двухвходовый), но заморочек там больше, может кто знает готовый вариант, желательно на верилоге?
А не будет проблем в случае, когда при серийном доступе к памяти пересекается граница банка? У меня после чтения даташита что-то такое засело в мозгу насчет precharge.
Просто не надо ее пересекать. "Нарезаем" банк на части по 2-4-8-16 или сколько надо байт и читаем их. Видео же я читаю по 4 байта, все ОК.
---------- Post added at 13:18 ---------- Previous post was at 13:16 ----------
А если вдруг очень надо пересечь, то с precharge, но я лично необходимости в этом не вижу.
Интуитивно чувствую, что для оценки работы кэша нужна другая тулза. Типа читать-писать разные количества данных из одних и тех же/прилегающих/разных мест.
Когда у меня сначала кеш совсем слабо работал я подумал - неужели придется эмулятор вымучивать?
Еще хочу уточнить - когда я писал про "нарезаем банк..." вобще-то я имел в виду страницу (т.е. row), предполагаю, что ты тоже.
Можно ещё в качестве хеш-функции попробовать не только набор младших бит адреса, а например комбинацию младших бит, пары средних и пары старших бит адреса. В большинстве программ можно выделить сегмент кода и сегмент данных, младшие биты адреса могут (и скорее всего будут) совпадать, отсюда снижение эффективности. Добавив другие биты адреса мы значительно снизим вероятность совпадения.