Для своего проекта я сам устанавливаю требования и разрабатываю ТЗ. Так что же это за критика?! ;-) Правильнее было бы сказать: "А что если рассмотреть возможность применения платформы как игровой?" :-)Не сошлись во мнениях.
Теперь по существу. На русском хорошее описание SDRAM доступно, например, здесь http://www.epos.kiev.ua/pubs/pm/pc133.htm (хотя лучше пользоваться даташитом производителя, в моём случае - Samsung). Полоса пропускания SDRAM при последовательном к ней доступе - 133МГц*2байта = 266Мб/сек (первое слово читается за 7 тактов, последующие 2/4/8/256 - по 1 такту). При произвольном доступе зависит от параметров CAS latency + RAS to CAS delay + 1 - 5 или 7; у используемой памяти этот параметр 7 (133MHz) или 5 (100MHz), т.о. скорость уменьшается в семь раз и составит 266/7 = 38Мб/сек (попрошу заметить - для 100МГц - 200/5=40Мб/сек).
Итак, подитожим быстродействие SDRAM PC-133 16 bit:
1) Последовательный доступ - порядка 266Мб/сек
2) Произвольный доступ - 38Мб/сек
Теперь о возможных неприятностях:
1) Доступ чередуется: основная-видеопамять. Ведь это приведёт к срыву последовательного доступа отдельно для каждой памяти?
Архитектура системы оптимизирована для возможности не прерывать последовательный доступ в случае чередования операций память-видео. Это достигнуто подключением основного ОЗУ к встроенному контроллеру SDRAM, а видеоозу - к контроллеру SDRAM внутри ПЛИС. При этом сама ПЛИС подключается к "системной шине", то есть к выводам подключения ROM/SRAM процессора (которые имеются не только у выбранной модели камня, но и у многих других). Что выбрано в текущий момент - определяется адресом доступа и не требует тактов ;-). Поэтому при чередовании операций оба модуля SDRAM работают в режиме последовательного доступа, если в каждом отдельном блоке (основном/видео) адреса увеличиваются на единицу.
Скорость при этом, естественно, падает в два раза (т.к. обращения чередуются; тактовая частота ПЛИС берётся с SDRAM clk) - до 133МБ\сек.
2) Хватит ли производительности процессора?
Для процессора 230MIPS при скорости 133Мб/сек отношение "количество тактов CPU"/"прочитанных/записанных слов (16бит) памяти" составит примерно 2. При этом если копирование выполняется програмно, то локальные переменные процедуры и сама процедура помещаются в кеш (до 16Кб), и не мешают работать SDRAM в последовательном режиме, то есть скорость доступа к памяти не падает.
Конечно, 2 RISC команды - маловато будет ;-) Но не стоит забывать о встроенном DMA, который поддерживает в том числе 2 канала память-память. Для сохранения последовательного режима SDRAM (если эксперименты покажут, что произвольный доступ ведёт к падению быстродействия, что ещё не факт) можно использовать один канал.
Таким образом, спрайты могут копироваться построчно - всё, что требуется от процессора - составить для кадра список (FIFO) копируемых строк спрайтов (с учётом границ спрайтов). Потом надо лишь обрабатывать прерывания от DMA и подкидывать ему новые данные. Нагрузка на CPU минимальна, и у него ещё будет куча времени для остальных операций.
3) Когда CPU читает команды, использует переменные, он нарушает режим последовательного доступа к памяти. Как быть?
Процессор имеет кеш. И если процедура (цикл) со всеми переменными поместилась в 16Кб+16Кб - то она не даст нагрузки на SDRAM. Если не поместилась, тогда, конечно, будут иметь место конфликты процессор/DMA.
Небольшое ускорение возможно, учитывая, что основная память делится на два банка (32+32Мб; в случае 128Мб - 4 банка). Для сохранения режима последовательного доступа можно размещение видеоданных в одном банке, программы - в другом. Тогда DMA и процессор хоть и будут делить шину, но дополнительных тактов (CAS latency) им не потребуется.
Вообще, в этом вопросе многое зависит от программы, от объёма вычислений и объёма копируемых данных. Тут будет место применению всяких программистских "хитростей" ;-)
Самый простой (и быстрый) случай игрового движка - сформировать очередь DMA запросов, вызвать DMA и до окончания DMA "уснуть". Это обеспечит производительность 133Мб/сек при доступе основная-видеопамять (1-й такт - чтение, 2-й такт - запись, по 16 бит за такт, частота 133 МГц).
Итак, что мы имеем? 133Мб/сек. Это не пиковая, а обычная (гарантированная) производительность при копировании блоков (не только экранов, но и спрайтов). Возможно, данная производительность будет гарантирована и при произвольном доступе (CAS latency=2). Можно было бы ускорить и до 266Мб/сек, используя встроенный в ПЛИС DMA (с отключением процессора от памяти на момент DMA) - это вариант расширения платформы. При этом схема дизайнится с учётом такой возможности. Если в ПЛИС останется достаточно свободных элементов, то такой DMA "основная-видеопамять" будет иметь место. В этом случае спрайтовые движки реализуются очень просто, а гарантированная скорость копирования - 266Мб/сек (правда, при этом процессор не может обращаться с памяти во время цикла передачи). А ещё можно использовать 32 битную шину (AT91RM9200) и достичь 533Мб/сек... Но спустимся с небес и рассмотрим возможности 133Мб/сек.
Распространённая операция, требующая в 2D "перерисовки экрана" - это скроллинг. Ещё одна из распространённых - двумерная свёртка с некоторым фиксированным окном (размер которого меньше размера кеша). Свёртка может использоваться для изменения яркости, для шейдерных эффектов (по аналогии с 3D) и т.п. Скроллинг в спрайтовом движке сводится к копированию спрайтов из основной памяти в видео-озу в нужные места. На это будет "заточен" режим DMA с запросами в FIFO: положения спрайтов заносятся в FIFO и далее копирование производится в "автоматическом" режиме. Для свёртки нам потребуется изменить уже "собранную" картинку и затем скопировать (вывести) её на экран. При этом простейшая свёртка может быть выполнена за 3 RISC команды (чтение, перемножение, запись) и максимальная скорость обмена с ОЗУ составит 266/3 = 88Мб/сек.
Возьмём приведённый Valen пример - 640х480х8бит@75Гц можно организовать, использовав пересылку 640*480*75 = 23 040 000 байт в секунду, или около 23Мб. Процессор будет занят на 23/133*100 = 17.3%, то есть свободен более чем на 80%.
О частоте обновления. С частотой 75Гц нет смысла перерисовывать графику. 75Гц имеет смысл только для обновления экрана, чтобы не было заметно мерцаний. Для игр достаточно, чтобы время одного кадра было меньше времени реакции человека (1/20 сек). Для кино, например, было выбрано 24 кадра - при этом человек не замечает, что изображение состоит из кадров. То, что в 3D играх показатель FPS более 30 считается комфортным - тоже показатель ;-) Вообщем, иметь более 30FPS не имеет смысла. В этом случае для 640х480х8бит процессор будет свободен более чем на 90% для выполнения расстановки спрайтов, обработки звука и т.п.
Режим 8 бит оставлен лишь для демонстрации. Основной режим будет 16/32 бит. И разрешение будет больше, чем 640х480. Так как игры - это лишь дополнительная возможность, а в случае большинства программ экран каждую 1/30 секунды не обновляется ;-)
Посмотрим, какой максимальный видеобуфер можно использовать при 30FPS и 100% загрузке шины памяти и только лишь обновлении экрана. 133Мб/сек/30кадр/сек = 4.4Мб/кадр. То есть половину имеющегося видеоозу или разрешение порядка 1600х1200 16 бит (займёт только 87% процессорного времени обмена с SDRAM). И это - при 30 обновлениях в секунду! А ведь в отличие от Спека можно выставить и 320х240 16 бит и реализовывать программную 3D графику не хуже, чем это делает ПК с ускорителем. На телевизоре смотреться будет нормально ;-)
Почему размер видеопамяти выбран не 4Мб, а именно 8Мб? Микросхемы 4Мб стоят дороже, чем 8Мб. Поэтому и установлены 8-ми Мб микросхемы. Дополнительно на ПЛИС можно реализовать DMA-режим видео-видео, то есть без каких-либо ожиданий со стороны CPU (то есть CPU в это время сможет работать с основной памятью). Хотя такой DMA не планируется - из-за того, что процессор вполне справится сам. Кроме того, иногда требуется и 1600х1200х32 бит - я уже сказал, что платформа предназначена не для игр. А для текста и т.п. важна возможность использовать в том числе и высокие видеорежимы.
Прошу комментарии.
