Я работаю над цифровой схемой, использующей дискретные компоненты для управления VGA-дисплеем 640x480 в текстовом режиме 80x30.
Для дисплея 640x480 тактовая частота пикселя составляет 25,175 МГц с периодом около 40 нс. Я не понимаю, как я должен быть в состоянии предоставить новый пиксель для дисплея так часто.
Основная архитектура для моей схемы выглядит следующим образом:
Двоичный счетчик для горизонтальных пикселей считает до 25,175 МГц до 800 (640 видимых пикселей + 160 для передней панели, синхронизации, задней части). На 800 увеличить счетчик вертикальной линии (и сбросить на 525 строк)
Используя горизонтальное и вертикальное положение, выведите координаты x, y текущего символа.
Используя координаты x, y символа, внесите индекс в видеопамять для получения символа ASCII.
Используйте символ ASCII для индексации в символьном ПЗУ, чтобы получить битовый шаблон для символа
Используйте регистр параллельного к последовательному сдвигу, чтобы преобразовать 8-символьную строку символов в отдельные биты с тактовой частотой пикселей
Если вы следуете по цепочке, она выглядит так: Счетчик -> ОЗУ -> ПЗУ -> Параллельно регистру последовательного сдвига
Используя самые быстрые компоненты, которые я могу найти, задержки распространения и время доступа составляют около 15 нс + 20 нс + 70 нс + 15 нс = 120 нс, что намного больше, чем период 40 нс для 25 МГц.
При еще более высоком разрешении и частоте обновления у вас могут быть тактовые импульсы, значительно превышающие 100 МГц, что составит 10 нс.
Как можно предоставлять новые пиксели на дисплей каждые 10 нс, когда время доступа к ОЗУ / ПЗУ уже значительно превышает его, даже не учитывая все остальные сигналы в вашей системе?
источник
Ответы:
Есть две основные причины, по которым вы находите это сложным.
Во-первых, вы используете более старые и более дискретные части (с меньшим масштабом интеграции), чем те, которые использовались бы для этого в эпоху VGA.
Но затем вы используете их нетипичным способом. В частности, ваш подход не
pipelinedозначает, что вам нужно добавить несколько задержек при определении вашего интервала и, следовательно, оценить.Напротив, синхронные цифровые конструкции, которые пытаются достичь скорости, стараются делать как можно меньше между регистрами.
Хотя детали, вероятно, будут немного отличаться, грубо говоря, это будет работать примерно так:
Когда вы разбиваете задачу следующим образом, вы получаете только одну комбинаторную задержку плюс некоторую задержку распространения и настройку регистра и время удержания, необходимое для согласования между часами.
Конструкция, построенная таким образом, потребует много часов для получения результата - задержка будет на самом деле выше, чем чисто комбинаторный дизайн. Но он производит новый правильный вывод на каждом цикле гораздо более быстрых часов.
И эй, это видео, на самом деле не имеет значения, рисует ли ЭЛТ дюжину пикселей за счетчиком пикселей - вы, конечно, учитываете это при синхронизации сигналов синхронизации, чтобы они были правильными по сравнению с моментом, когда данные на самом деле выходит из ЦАПа.
На практике почти все сложные цифровые системы работают таким образом, и это хорошая идея - вплоть до тех пор, пока конвейерный ЦП не достигнет зависимости от более раннего результата вычисления или условного перехода ... Тогда все становится интересным, когда они говорят о в следующей лекции по классу цифровых систем - но, к счастью, ваша ситуация с VGA намного проще, особенно если вы еще не беспокоитесь о разрывных эффектах, если буфер символов изменяется во время рисования экрана.
На практике, если вы хотите построить это, сделайте это в ПЛИС. Это в значительной степени навязывает вам синхронную память, если вы используете внутренние, или регистры синхронного ввода-вывода, если вы используете внешнюю память. Вы получите толчок к правильному дизайну, сама ткань будет быстрее, чем ваши отдельные детали, и, конечно, если вы допустили ошибку, вам нужно всего лишь перевернуть пальцы, пока она перекомпилируется, а не тратить долгий день на повторную разводку ,
источник
Вы забываете, что графический адаптер никогда не будет рисовать только один пиксель - но, по крайней мере, линию полного сканирования. Таким образом, это было бы полностью конвейерной проблемой.
Кроме того, не забывайте, что до сих пор было пять десятилетий оборудования для производства видео. Ваша проблема обычно решается с помощью специального типа оперативной памяти, в которую вы переводите свои письма на один порт и которая последовательно считывается в ЦАП видеосигнала. Это оборудование намного быстрее, чем то, на что вы смотрите.
Нет, зачем ты это делаешь? Вы бы просто поместили свой пиксель строки в непрерывную область памяти и линейно поместили его в свой ЦАП - если речь идет о реализации CPU / MCU, вы бы даже не позволили этому сделать ваш CPU, а запрограммировали модуль DMA ничего не делать, кроме как принимать одно значение за другим и выводить его, например, на параллельный порт данных, без какого-либо взаимодействия с ядром процессора.
Ах, вы хотите рендерить на лету - хороший выбор, но необычный при современных затратах оперативной памяти. Вместо этого вы просто визуализируете символ в буфер кадра заранее или, если ваше устройство очень тонкое, напрямую направьте (см. Мое объяснение DMA выше) строку символов в ЦАП.
источник
Помимо конвейерной обработки (которая очень важна для вас), вам не хватает чего-то важного ....
Синхронизирующий регистр сдвига с параллельным входом и последовательным выходом работает с частотой 25 с лишним МГц, конечно, но если ваши символы имеют ширину, скажем, 8 пикселей, его вход составляет всего ~ 3,2 МГц, что легко доступно для серии LS VGA-эры, несмотря ни на что вам нужно иметь следующий готовый байт, когда сдвиговый регистр завершит работу с текущим (это то место, где начинается конвейер).
Сгенерируйте тактовую частоту пикселей на частоте ~ 25 МГц и тактовую частоту памяти на 1/8 от этого для управления текстовым буфером и ПЗУ CG, затем направьте эту память и доступ к ПЗУ ПЗУ.
Еще один трюк, вывод текстового буфера будет повторяться для каждой строки в любой заданной строке текста, так что, возможно, вы могли бы синхронизировать 80 байтов текста в кольцевой буфер, а затем прекратить чтение оперативной памяти для следующих 7 строк (при условии 8 символ строки), это позволяет освободить память для использования процессором, за счет чего требуется 80 байт оперативной памяти, висящих на стороне устройства.
источник
Очевидно, что это не работает; тебе нужен трубопровод.
1) Храните символы в памяти. Начните сверху слева.
2) Получить символ во время интервала гашения. Продолжайте извлекать символы в порядке памяти.
3) Конвейер каждого декодированного символа плюс индекс строки в ПЗУ.
4) Конвейер вывода ПЗУ в буфер.
5) Конвейер буфера в регистр сдвига. Считайте пиксели непрерывно с интервалами 40 нс.
(Это означает, что вам нужно загружать новый символ в регистр сдвига каждые 320 нс, что может быть даже выполнимо без конвейерной обработки всей остальной системы).
6) Во время горизонтального гашения вернитесь к началу строки или перейдите к следующему символу (т. Е. К началу следующей строки).
Бонусная функция: так как вам нужен только символ каждые 320 нс, вы также можете прочитать пару символ + цвет и сделать цветовые символы в стиле MSDOS или Spectrum-Style.
источник