Вектор-06Ц: Altera DE1

[ivagor]

Насчет архиваторов - совсем забыл, что контроллер дисковода то у меня со всеми этими супер-турбами не работает. В крайнем случае можно грузить ОС для квазидиска и потом грузить в квазидиск.

---------- Post added at 22:47 ---------- Previous post was at 22:44 ----------

Если у svofski даже вариант 120 МГц не заработал, то что говорить о 168, тем более на старых DE1 SDRAM на 133 МГц. Варианты на 120 (турбо там умеренное, т.ч. даже "вг93" работает) лежат в ревизиях 395-396, думаешь их кто-нибудь будет твикать?

[Advertiser]

[ivagor]

Результаты варианта 144/36 заставили задуматься о кеше, хотя раньше не собирался пробовать его в 8битках. Организовал очень простенький и неэффективный двухкилойбайтный (полезный объем) кеш. Время прогона оптимизированого эксисайзера сократилось до 11 минут, т.е. всего на минуту.

[tnt23]

Результаты варианта 144/36 заставили задуматься о кеше, хотя раньше не собирался пробовать его в 8битках. Организовал очень простенький и неэффективный двухкилойбайтный (полезный объем) кеш. Время прогона оптимизированого эксисайзера сократилось до 11 минут, т.е. всего на минуту.

Сорцы?..

[ivagor]

Вычищать мусор из всего проекта не хватает моральных сил, вот контроллер сдрама, его будет достаточно для оценки нововведений
Странные манипуляции с адресными линиями вызваны тем, что при обращении к контроллеру адреса перепутываются (A[14:13] помещаются в самые младшие разряды) для облегчения/ускорения чтения видео.

[ivagor]

Никто не успел заметить - а я успел доработать. Теперь кеш (теперь 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 ----------

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

[ivagor]

SDRAM 162/CPU 81 с кешем - 5:26

[tnt23]

Можешь в двух словах описать работу кеша?

[ivagor]

Сейчас реализован самый простой вариант - кеш прямого отображения со сквозной записью.
Адрес, по которому обращается процессор делим на две части - младшая будет индекс в кеше, старшая хранится в теге кеша и при обращении сравнивается с тем, что сейчас дает проц. Пишем в кеш при чтении из сдрам (то, что я в первом варианте не сделал) или при записи.
Причем я вчера попробовал сделать перекос в сторону чтения еще сильнее - обновлять кеш при записи только если данный адрес уже там есть. Это не изменило время прогона эксисайзера и амбала3д, так что пока под вопросом, как оставить.
Выложенный вариант "консервативный" - читаем из кеша и проверяем тег параллельно с чтением из сдрам. Так мы никогда не будем терять такты в случае кеш-промахов, но и выигрыш маловат. После тестов сам я однозначно за "агрессивный" вариант - сначала читаем из кеша, и только если там нет - начинаем обращение к сдрам. В худшем случае потеряется два такта, но кеш-попадания заметно чаще промахов, т.ч. игра стоит свеч.
Что стоит доделать для более серьезного применения - увеличить размер строки кеша. У меня сейчас каждой записи тега соответствует один байт из памяти. Это очень неэффективно. Надо как минимум 2, а лучше 4-8-16 и читать пакетом.

Да, еще надо не забывать инициализировать кеш при ресете. В векторе я загрузчик чуть доработал для этого.
В векторе, раз нет дма и видео всегда в одном месте (плохо для программера, хорошо для кеширования), то сравнительно несложно доработать до обратной записи. Т.е. по видеоадресам сквозная запись, а по остальным - обратная.
Эффективнее был бы наборно-ассоциативный кеш (хотя бы двухвходовый), но заморочек там больше, может кто знает готовый вариант, желательно на верилоге?

[tnt23]

А не будет проблем в случае, когда при серийном доступе к памяти пересекается граница банка? У меня после чтения даташита что-то такое засело в мозгу насчет precharge.

[ivagor]

Просто не надо ее пересекать. "Нарезаем" банк на части по 2-4-8-16 или сколько надо байт и читаем их. Видео же я читаю по 4 байта, все ОК.

---------- Post added at 13:18 ---------- Previous post was at 13:16 ----------

А если вдруг очень надо пересечь, то с precharge, но я лично необходимости в этом не вижу.