Imax9
NEWS   ARTICLES   MINIMIG   FILES   ABOUT

Меняем регенерацию...

Предлагаю вам перевод цикла Writing a new SDRAM controller Part 4 автора Alastair M. Robinson.

Контроллер SDRAM, который я описал до сих пор в этой серии, в основном работает хорошо – не так хорошо, как тот, для замены которого он был предназначен, но есть еще один трюк, который мы можем использовать, чтобы выжать немного больше производительности…

Одной из трудностей использования SDRAM вместо, скажем, SRAM является то, что содержимое памяти необходимо периодически обновлять, иначе заряд в ячейках памяти со временем утечет и содержимое памяти будет потеряно. Чтобы избежать этого, каждая строка каждого банка должна обновляться не реже одного раза в 64 мс. (Я не уверен, что такого особенного в 64 мс, но, похоже, это стандартный интервал обновления для SDRAM всех типов, кроме тех, которые предназначены для использования в автомобилестроении , они обычно имеют интервал обновления 16 мс. Я не уверен, связано ли это с повышенными требованиями к надежности, когда отказ может быть опасным, или с тем, что он работает в среде с большим количеством тепла, или с то и другое.)

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

Но как часто чтобы было достаточно? Интересующие нас чипы SDRAM обычно имеют 8192 строки, поэтому нам нужно 8192 обновления каждые 64 мс, то есть 128 000 обновлений в секунду, то есть одно обновление каждые 7,8125 мкс. Если мы используем наш контроллер SDRAM на частоте 128 МГц, то это одно обновление каждые 1000 циклов. Если контроллер SDRAM работает на частоте 96 МГц, то это одно обновление каждые 750 циклов. На самом деле это довольно много, если учесть, что обновление обычно занимает от 7 до 9 циклов в зависимости от тактовой частоты. Поскольку весь чип фактически отключен во время цикла обновления, это около 1% пропускной способности, потерянной для обновления.

Является ли это проблемой на практике? Это зависит от обстоятельств. Для любой подсистемы в ядре, вероятно, будет некоторое время простоя, в которое вы можете вставить обновления, не влияя на производительность – периоды обратного хода луча видеосистемы являются ярким примером. Кроме того, не жизненно важно выполнять обновление по фиксированному графику ровно в 7,8125 мкс: до тех пор, пока 8192 из них произошли в течение 64 мс, не имеет значения, были ли они собраны вместе в пакеты с более длинными промежутками между ними. (DDR RAM в этом отношении строже.) Однако найти время простоя для всех подсистем одновременно может быть непросто. В частности, в ядре PC Engine я не смог найти достаточных слотов обновления, которые не повлияли бы ни на видео, ни на задержку ПЗУ, поэтому потребовался другой подход.

Обычный доступ к строке внутри микросхемы SDRAM вызывает извлечение содержимого ячеек памяти, а затем немедленную перезапись, и именно эту операцию команда Autorefresh запускает внутренне. Как я уже сказал, чип выполняет эту операцию одновременно со всеми четырьмя банками, но вполне возможно выполнить ту же операцию вручную, просто активировав и затем закрыв каждую строку по очереди. (Для простоты я фактически выполняю фиктивное чтение с помощью Autoprecharge и игнорирую результат – с тех пор я могу использовать те же командные слоты, что и для обычного чтения и записи. Я также мог бы закрыть строку с помощью явной команды предварительной зарядки – однако это должно было бы произойти на несколько циклов позже, чем обычные операции чтения и записи, что усложнило бы планирование и чередование.)

Есть два недостатка: во-первых, мы можем обращаться только к одному банку за раз, поэтому, если мы решим обновить его вручную, мы будем выдавать в четыре раза больше команд обновления в общей сложности, а во – вторых, мы должны поддерживать наш собственный счетчик строк для каждого банка, чтобы убедиться, что мы выбираем каждую строку по очереди.

Выигрыш заключается в том, что нам не нужно переводить весь чип в автономный режим для обновления – мы можем обновить один банк, пока другой используется в обычном режиме. Таким образом, для банков, содержащих видеоданные, мы можем выполнять многократное обновление во время интервалов видео гашения, оставляя банк чистым для бесперебойного доступа во время сканирования, в то время как ПЗУ обновляется более регулярно в промежутках между обычными обращениями.

Есть и еще одно преимущество (хотя я не могу отделаться от ощущения, что обращаться с чипом таким образом “невежливо”!). Если мы знаем, что используем, скажем, только четверть строк в банке, мы можем просто оставить остальные три четверти незаполненными. Конечно, они потеряют свое содержимое, но поскольку мы ими не пользуемся, нам все равно.

Если вам интересно увидеть “готовый” контроллер SDRAM, описанный в этой серии, его можно найти здесь как часть исходного кода порта ядра PCEngine для Turbo Chameleon 64.


Адрес для контактов : imax9@narod.ru

Если вам понравились мои работы и вы желаете поддержать сайт - сделайте дотацию.

При копировании статьи – обязательна ссылка на авторство и источник. Без разрешения автора копирование запрещено.

© Максим Ильин 2021г.

Яндекс.Метрика