Як можна керувати дисплеями VGA на таких високих тактових частотах пікселів?

Я працюю над цифровою схемою, використовуючи дискретні компоненти, щоб керувати VGA-дисплеєм 640x480 у текстовому режимі 80x30.

Для дисплея 640x480 піксельна тактова частота становить 25,175 МГц, що має період близько 40н. Я не розумію, як я маю змогу часто надати новий піксель на дисплей.

Основна архітектура моєї схеми така:

1. Двійковий лічильник для горизонтальних пікселів нараховується від 25,175 МГц до 800 (640 видимих ​​пікселів + 160 для переднього ганку, синхронізації, заднього ганку). На 800, збільшення лічильника вертикальної лінії (і скидання на 525 рядків)

2. Використовуючи горизонтальне та вертикальне положення, виведіть координату x, y поточного символу.

3. Використовуючи координати символів x, y, індексуйте у відеопам'ять для отримання символу ASCII.

4. Використовуйте символ ASCII для індексації в символьному ПЗУ для отримання бітового шаблону для символу

5. Використовуйте паралельно регістру послідовного зсуву для перетворення 8-піксельної лінії символу в окремі біти на тактовій частоті пікселів

Якщо ви стежите за ланцюжком, він іде: Лічильник -> ОЗУ -> ПЗУ -> Реєстр паралельних послідовним зсувам

Використовуючи найшвидші компоненти, які я можу знайти, затримка розповсюдження та час доступу становлять приблизно 15ns + 20ns + 70ns + 15ns = 120ns, набагато більше, ніж період 40ns для 25MHz.

При ще більшій роздільній здатності та частоті оновлення ви можете мати піксельні годинники набагато вище 100 МГц, що буде періодом 10н.

Як можна подавати нові пікселі на дисплей кожні 10н, коли просто час доступу для оперативної пам’яті / ПЗУ вже значно перевищує його, навіть не враховуючи всіх інших сигналів у вашій системі?

Є дві основні причини, що вважають це складним.

По-перше, ви використовуєте старіші та більш дискретні (інтеграція нижчих масштабів) частин, ніж це було б використано для епохи VGA.

Але далі ви використовуєте їх нетипово. Зокрема, ваш підхід не pipelinedозначає, що вам доведеться складати кілька затримок під час визначення інтервалу і, таким чином, швидкості.

На відміну від цього, синхронні цифрові конструкції, які намагаються досягти швидкості, намагаються робити якомога менше між регістрами.

Хоча деталі, ймовірно, трохи відрізняються, грубо кажучи, це спрацює приблизно так:

• Ви збільшуєте або скидаєте адресу, і це відбувається в регістрі.
• Ви зав'язуєте адресу в синхронну пам'ять
• Ви фіксуєте висновок синхронної пам'яті
• Ви зав'язуєте це на адресу генератора синхронних символів
• Ви фіксуєте вихід генератора символів у регістрі виводу
• застосувати пошук палітри ...
• в синхронний ЦАП ...

Коли ви розбиваєте завдання таким чином, ви отримуєте лише одну комбінаторну затримку плюс деяку затримку розповсюдження та реєстрацію налаштування та час утримання, необхідне для встановлення між годинниками.

Конструкція, побудована таким чином, потребує багатьох годин, щоб отримати вихід - затримка насправді буде вище, ніж суто комбінаторний дизайн. Але це дає новий правильний вихід на кожен цикл набагато швидшого годинника.

І ей, це відео, це не має особливого значення, якщо CRT малює десяток пікселів за лічильником пікселів - ви, звичайно, це враховуєте під час синхронізації сигналів, щоб вони були правильними порівняно з тим, коли фактично дані виходить з ЦАПу.

На практиці майже всі складні цифрові системи працюють таким чином, оскільки це чудова ідея - аж до того часу, поки конвеєрний процесор не потрапить на залежність від попереднього обчислювального результату чи умовної гілки ... Тоді речі стають цікавими, як вони б говорили про у наступній лекції класу цифрових систем - але, на щастя, ситуація з VGA набагато простіша, особливо якщо ви ще не переживаєте про розриви, якщо буфер символів змінюється під час малювання екрана.

З практичної точки зору, якщо ви хочете створити це, зробіть це в FPGA. Це в значній мірі змусить на вас синхронні спогади, якщо ви використовуєте внутрішні або синхронні регістри вводу-виводу, якщо ви використовуєте зовнішню пам'ять. Ви отримаєте багато натягу на належну конструкцію, сама тканина буде швидшою, ніж ваші дискретні деталі, і, звичайно, якщо ви помилитесь, вам потрібно лише закрутити великі пальці, поки вона буде перекомпільована, а не витратити довгий день на повторну проводку .

Використовуючи найшвидші компоненти, які я можу знайти, затримка розповсюдження та час доступу становлять приблизно 15ns + 20ns + 70ns + 15ns = 120ns, набагато більше, ніж період 40ns для 25MHz.

Ви забуваєте, що графічний адаптер ніколи не малював би лише один піксель - але, принаймні, повну лінію сканування. Таким чином, це було б цілком можливою проблемою.

Крім того, не забувайте, що до цього часу вже було п'ять десятиліть обладнання для виробництва відео. Вашу проблему зазвичай вирішують спеціальним типом оперативної пам’яті, в яку ви надсилаєте свої листи на одному порту, який послідовно зчитується на ЦАП відеосигналу. Це обладнання є способом, швидше, ніж те, що ви дивитесь.

Основна архітектура моєї схеми така:

1. Двійковий лічильник для горизонтальних пікселів нараховується від 25,175 МГц до 800 (640 видимих ​​пікселів + 160 для переднього ганку, синхронізації, заднього ганку). На 800, збільшення лічильника вертикальної лінії (і скидання на 525 рядків)

2. Використовуючи горизонтальне та вертикальне положення, виведіть координату x, y поточного символу.

Ні, чому б ти це робив? Ви просто помістіть свій піксель рядка в суміжну область пам’яті та лінійно викладете його у свій ЦАП - якщо мова йде про реалізацію процесора / MCU, ви навіть не дозволили б цьому зробити свій процесор, а програмувати блок DMA, запрограмований не робити нічого, крім приймати одне значення за іншим і виводити його, наприклад, на паралельний порт даних, без жодної взаємодії з процесором.

3. Використовуючи координати символів x, y, індексуйте у відеопам'ять для отримання символу ASCII.

Ах, ви хочете зробити візуалізацію на льоту - хороший вибір, але незвичний при сучасних витратах оперативної пам'яті. Замість цього ви просто заздалегідь виведете символ у буфер кадру, або якщо ваш пристрій надзвичайно тонкий, безпосередньо передайте (див. Моє пояснення DMA вище) символьний рядок у ЦАП.

Зовсім крім трубопроводу (що дуже багато, що вам слід зробити), вам не вистачає чогось головного….

Паралельний, послідовний тактовий регістр зсуву реєструється, розмір точок на 25 непарних МГц, але якщо ваші персонажі скажуть шириною 8 пікселів, його вхід становить лише ~ 3,2 МГц, що легко досягається для серії LS епохи VGA, для всього цього наступний байт повинен бути готовим, коли регістр зсуву закінчується поточним (саме тут надходить конвеєр).

Створіть піксельну тактову частоту ~ 25 МГц та тактову пам’ять на 1/8 тому, щоб запустити текстовий буфер та CG ROM, а потім конвестувати цю пам'ять та доступ до CG ROM.

Ще один трюк, вихід текстового буфера буде повторюватися для кожного рядка в будь-якому рядку тексту, тому, можливо, ви можете перевести 80 байт тексту в буфер кільця, а потім перестати читати оперативну пам’ять для наступних 7 рядків (припустимо, що 8 символу рядка), це дозволяє звільнити пам'ять для використання процесора, ціною необхідності 80 байт оперативної пам’яті, що висить на стороні речі.

Так очевидно, що це не працює; вам потрібен трубопровід.

1) Безперервно зберігайте символи в пам'яті. Почніть з верхнього лівого кута.

2) Вилучення персонажа під час інтервалу відключення. Продовжуйте отримувати символи в порядку пам'яті.

3) Трубопровід кожного розшифрованого символу плюс індекс рядка в ПЗУ.

4) Трубопровід виводу ПЗУ в буфер.

5) Трубопровід буфера в регістр зсуву. Читайте пікселі безперервно з інтервалом 40ns від цього.

(Це означає, що вам потрібно завантажувати нового символу в регістр зрушень кожні 320 секунд, що може бути навіть можливим без конвеєрної роботи всієї іншої системи.)

6) Під час горизонтального блокування повертайтеся до початку рядка або переходите до наступного символу (тобто початку наступного рядка.)

Особливість бонусу: оскільки вам потрібен символ лише кожні 320н, ви також можете прочитати кольорову пару символів + та виконати або кольорові символи у стилі MSDOS, або Spectrum-Style.