Экспериментируем с TG68 - Усовершенствуем контроллер SDRAM.
Предлагаю вам перевод цикла Experimenting with TG68 Part 14: Improving the SDRAM controller автора Alastair M. Robinson.
Одним из ограничений проекта MiniSOC до сих пор было то, что поддерживался только очень простой 16-битный экранный режим 640×480 при 60 Гц. Причина этого в основном заключается в пропускной способности оперативной памяти, так как платы, для которых я разрабатываю, имеют SDRAM с одинарной передачей данных.
Контроллер SDRAM, который я использую, является производным от контроллера Tobias Gubener, созданного для версий ядра Minimig на базе TG68. Оригинальный контроллер использовал 4-словные пакеты при чтении из SDRAM, писал одиночными словами и работал на фиксированном 16-тактовом цикле, что имело то преимущество, что гарантировало детерминированное время отклика для эмуляции Amiga.
 |
В работе, которую я проделал, улучшая ядро Minimig, я расширил его так, чтобы запись также работала в пакетном режиме, и воспользовался чередованием банков, чтобы добавить второй слот доступа к контроллеру SDRAM – при сохранении фиксированного 16-тактового цикла. Последовательность событий выглядит примерно так:
 |
Хотя это позволило значительно ускорить работу ядра Minimig и создать VGA-буфер кадров для проекта TG68MiniSOC, разрешение ограничено пропускной способностью памяти; стандартный экранный режим 640x480x16@60Hz в 16-битном цвете более или менее заполняет первый доступный слот, оставляя другой свободным для процессора (если позволяет чередование банков).
Однако в последнее время я хотел увеличить разрешение экрана до 800×600 или выше при 16-битном разрешении. Самый популярный экранный режим 800x600x16 работает на частоте 72 Гц и использует тактовую частоту 50 МГц (а не 25 МГц для 640×480 при 60 Гц), что означает, что мне нужно удвоить пропускную способность оперативной памяти, чтобы достичь этого.
Так как же к этому придти?
Первое, что мы можем сделать, это увеличить длину пакета с 4 до 8 слов. Заставить это работать оказалось более утомительной работой, чем я ожидал, потому что сам контроллер немного запутан, а увеличенная длина пакета вытряхнула несколько ошибок в других частях проекта, но в конце концов я заставил это работать стабильно. Однако для этого требовался цикл с 24 тактами, а не с 16, что означает увеличение пропускной способности только на 50%, а не на 100%.
 |
Тем не менее, после полной перестройки архитектуры кэша DMA этого было достаточно, чтобы реализовать что-то близкое к стандартному экранному режиму 800x600x16@56Hz. Обычно для этого требовались тактовый сигнал с частотой 36 МГц, а самое близкое, чего я мог легко достичь, было 33 МГц, но, тем не менее, мой монитор отображал картинку, и влияние на значение Dhrystone не было огромным, так что я был счастлив.
Однако я не мог отделаться от мысли, что поиски большей пропускной способности не должны быть напрасными. Если вы просто читаете из SDRAM, то, используя приемы чередования банков, можно передавать данные на каждом такте, в то время как моя 24-тактная кольцевая версия контроллера имеет теоретический максимум 16 слов на 24-тактовую цепь.
Одновременный доступ к разным банкам осложняется 3-тактовой задержкой CAS SDRAM, или, точнее, тем фактом, что задержка применяется только к чтению, а не к записи. В идеале мы хотим, чтобы операции чтения и записи занимали одно и то же “пространство” в подпрограмме, чтобы они могли более плотно перекрываться. В реальной работе оказывается, что кэш записи не имеет большого значения для конечной скорости процессора, потому что обычно процессор может записать в кэш только 2 слова до того, как запись будет обработана. Эти два слова обычно представляют собой просто длинную (32-битную) запись, объединенную в пару 16-бит слов для записи, поэтому уменьшение размера кэша записи до двух слов оказывает минимальное влияние на скорость. Это дает нам возможность задерживать записи так, чтобы они происходили через несколько циклов, и позволяет нам “свернуть” 24-цикловое кольцо в 16-цикловое кольцо того же размера, что и исходный контроллер, но с удвоенной пропускной способностью.
Конечная последовательность событий выглядит следующим образом:
 |
Используя эту версию контроллера SDRAM, проект TG68MiniSOC теперь способен отображать 16-битный кадровый буфер 800×600 с частотой обновления 72 Гц.
Как всегда, полный исходный код можно найти на моей странице GitHub с соответствующей меткой : https://github.com/robinsonb5/TG68_MiniSOC/releases/tag/20140505_Part14
Если вы хотите попробовать это, создайте один из файлов проекта в SOC/fpga/ затем скомпилируйте Apps/Demo или Apps/Screenmodes.
Файл S-record может быть либо обновлен по RS232, либо скопирована на SD-карту и загружена оттуда (переименуйте его в “boot.sre”).
В Demo app режим экрана можно выбрать с помощью F4-F9. Обратите внимание, что при изменении режима экрана демо в настоящее время не предпринимает никаких попыток, чтобы перерисовать то, что находится на экране, чтобы соответствовать новому размеру, поэтому оно будет выглядеть скремблированным.
В Screenmodes demo клавиши F1 – F5 выбирают экранный режим, и тестовая карта будет перерисована в соответствии с новым размером.
Адрес для контактов : imax9@narod.ru
Если вам понравились мои работы и вы желаете поддержать сайт - сделайте дотацию.
При копировании статьи – обязательна ссылка на авторство и источник. Без разрешения автора копирование запрещено.
© Максим Ильин 2022г.