технические детальки.
Krugo...@gmail.com
возможность пусть даже быстро рисовать через IOCTL. большинство
программ люто бешенно требуют mmap-нутый фреймбуфер.
реализовать можно так:
берем драйвер /linux/drivers/vfb.c за основу. добавляем туда функцию
mmap, мапим память как отсутсвующую, при этом физически память должна
быть выделена. затем ставим обработчик nopage(), тот, перемапливает
страницу как существующую, ставит её в очередь и запускает таймер, на,
например 0.05сек. по истечении страница по dma отправляется на
видеоадаптер.
теперь касательно плисины и примкнувшей к ней памяти:
90Мгц это вы губу раскатали.
плисина даёт задержку на до выдачи адреса 2.5нс:
LE register clock-to-output delay 490ps
Data output delay from adjacent LE to I/O block 350 нс
Output delay buffer and pad delay 1530 нс
далее идет реакция микрухи 10 или 8нс
соотв полное время выборки 10.5 или 12.5 нс
затем плисина снова тормозит:
I/O input pad and buffer delay 970ps
LE register setup time before clock 319ps
вроде бы из мануала следует, что Quartus "обещает" не допустить
появления в списке еще и Input routing delay(410ps), но хз,хз.
итого мы по худшему сценарию насчитали 12.3нс - 14.3нс. 90мгц это 11
нс, а ближайшая выводимая частота это 60Мгц - 15.5нс, и скорость
обмена 120мб/с. для сравнения в 1024х768х60=80млн выборок в секунду
видеовыходом + чуть больше 10мб/с записей по SPI.
не забывайте, что 100мгц на 10нс памяти могут быть только если память
синхронная. а асинхронные К6R4008V1D - это еще и клок придется
перекашивать, чтоб положительная часть была меньше 3нс, чтоб успевать
от смены адреса до захлопывания защелок на входе сигнал не начал
меняться.
Sergey Lapin
> для того, чтоб под линуксом завелась графика мало просто сделать
> возможность пусть даже быстро рисовать через IOCTL. большинство
> программ люто бешенно требуют mmap-нутый фреймбуфер.
>
> реализовать можно так:
> берем драйвер /linux/drivers/vfb.c за основу. добавляем туда функцию
> mmap, мапим память как отсутсвующую, при этом физически память должна
> быть выделена. затем ставим обработчик nopage(), тот, перемапливает
> страницу как существующую, ставит её в очередь и запускает таймер, на,
> например 0.05сек. по истечении страница по dma отправляется на
> видеоадаптер.
Очень большой оверхед. Таймер в данном случае излишен.
>
> теперь касательно плисины и примкнувшей к ней памяти:
> 90Мгц это вы губу раскатали.
> плисина даёт задержку на до выдачи адреса 2.5нс:
> LE register clock-to-output delay 490ps
> Data output delay from adjacent LE to I/O block 350 нс
> Output delay buffer and pad delay 1530 нс
> далее идет реакция микрухи 10 или 8нс
> соотв полное время выборки 10.5 или 12.5 нс
> затем плисина снова тормозит:
> I/O input pad and buffer delay 970ps
> LE register setup time before clock 319ps
> вроде бы из мануала следует, что Quartus "обещает" не допустить
> появления в списке еще и Input routing delay(410ps), но хз,хз.
> итого мы по худшему сценарию насчитали 12.3нс - 14.3нс. 90мгц это 11
> нс, а ближайшая выводимая частота это 60Мгц - 15.5нс, и скорость
> обмена 120мб/с. для сравнения в 1024х768х60=80млн выборок в секунду
> видеовыходом + чуть больше 10мб/с записей по SPI.
>
> не забывайте, что 100мгц на 10нс памяти могут быть только если память
> синхронная. а асинхронные К6R4008V1D - это еще и клок придется
> перекашивать, чтоб положительная часть была меньше 3нс, чтоб успевать
> от смены адреса до захлопывания защелок на входе сигнал не начал
> меняться.
На реальной делезке 100Mhz тоже недостижимы на шине.
И вообще железка должна еще что-то полезное делать кроме как видео гоянть.
Krugo...@gmail.com
он её и пилит.
оверхед там ~10мб/сек - предельная скорость SPI. при пропускной
способности памяти в 320Мб/сек, которую мы кстате не загрузим
настолько это копейки.
если не отслеживать через страницы, придется сканировать биты
изменения данных, что в общем то тоже несложно, потребует отдельного
ядреного потока в системе. так что с этим проблем не встанет.
Krugo...@gmail.com
экрана, а нам нужно некоторое время подождать пока его перерисуют.
Sergey Lapin
> DMA не требует процессорного участия. поставил ему в очередь задачу,
> он её и пилит.
и нам будет нужно организовывать ринг-буфер для отправки апдейтов и шаманство
со страницами. Понятно что с DMA лучше чем без но все не настолько волшебно.
Тут нас бы спас бас мастеринг на шине, но, как я понимаю,
в данном случае это не опция.
> оверхед там ~10мб/сек - предельная скорость SPI. при пропускной
> способности памяти в 320Мб/сек, которую мы кстате не загрузим
> настолько это копейки.
Речь идет о мегабитах, если кто не догадался. Точнее даже о мегаггерцах.
Наш SPI теоретически в состоянии работать на 33 мегаггерцах.
Что казасется памяти, то она работает на 90 мегаггерц - что
при 32-разрядной организации дает нам 360 мегабайт в секунду или
если переводить на биты - 2880 мегабайт. Что впрочем не достижимо
из-за динамической ее сущности и страничной организуции. SRAM
бы нас тут спас, безусловно. Но фактически речь идет о порялка 200
мегабайт в секунду, что в общем довольно неплохо.
>
> если не отслеживать через страницы, придется сканировать биты
> изменения данных, что в общем то тоже несложно, потребует отдельного
> ядреного потока в системе. так что с этим проблем не встанет.
Это будет хуже чем отслеживать через пейдж-фолты в смысле загрузки процессора.
Sergey Lapin
> таймер как раз нужен, потому что нас прервут в НАЧАЛЕ перерисовки
> экрана, а нам нужно некоторое время подождать пока его перерисуют.
(При LCD). Это если мы будем 25 раз в секунду слать 2 мегабайта по SPI
может вызвать некоторые трудности на шине, она ведь не резиновая.
потому как 50 мегабайт в секунду будут реально заметны, особенно с учетом того
что таки требуют непосредственного участия проца - на перестановку дескриптора,
ведение пейджей и прочее. А если мы протупим и не будем забирать у
юзерспейса страницы
то у нас на каждую страницу будет случаться контекст-свитч что еще
более усугубит проблему.
Это все можно сделать незаметным если у железки будет своя память какого-нибудь
ощутимого объема и поддержка регионов и оверлеев - тогда мы сумеем
сократить наши
расходы очень существенно, практически без потери производительности.
А если мы сумеем ринг-буфер организовать внутри железки - это нам вообще
принесет счастье и процветание.
> >
>
Krugo...@gmail.com
> (При LCD).
я вроде как думал SPI на 90мгц будет поставлено.
ну а если33 мгц, то частота данных на ней(с учотом фактически 10бит на
8 переданных по мануалу), это 3.3Мб/сек. можно слать хоть непрерывно.
только для 800х600х64к это будет частота перерисовки=3-4кадра/сек.
чото херовенько получилось. собственно это оооочень большое
ограничение.
плиску бы на шину данных повесить, хоть в 16битном режиме, под видом
SRAM... для корпуса TQFP100 вроде она бы поместилась там
(16data+19address+2nwr+nrd+ncs3+nwait+19 addr+16 memdata+2we+oe+cs
+clc=80 пинов.
Krugo...@gmail.com
видеокарту. буфер находится в оперативной памяти, это ограничение
непреодолимо в силу устройства многих linux-программ.
пэйдж-фолты или проверка изменений(кстати, всего 1024 сравнения на
кадр, будет жрать ~1-2% проца) только для отслеживания изменившихся
областей.
можно и не проверять, а тупо запускать dma-передачу на весь объем
фреймбуфера.
узким местов в всей этой конструкции становится SPI, и что с ним
делать неясно.
microt...@gmail.com
это щас сделать нужно перелопатить всю плату. Что оттянет ее выход на
порядочное время.... Предлагаю сделать все возможное на данной
конфигурации (мелкие переделки и дополнения пока принимаются). А в
следующем проекте учесть все наработки и недостатки нынешнего.
On 23 авг, 03:59, "KrugomVo...@gmail.com" <KrugomVo...@gmail.com>
wrote:
Sergey Lapin
подумать о внешнем PLL и соответствии VGA-спецификации,
Соответственно желательно - ring буфер при передаче данныз независимый
от того что осуществляет отображение дабы слать непрерывным потоком.
Реализовать оверлеи, например, делящие экран на 4 одинаковых области
(не исключающие апдейта всего экрана и являющиеся "окнами"
(Экономия на длине горизонтальных участков), RLE-сжатие потока
(экономия скорости SPI), возможность произвольного выбора строки,
где нужно производить изменение (начало изменения).
Прерывания:
1. По опустошению буфера (чтобы нам переставить DMA).
2. По обратному ходу/рефрешу. (Начало bulk-транзакции оптимально в это время).
Также управление питанием:
1. Энергосберегающий режим с отключением отображения.
2. Энергосберегающий режим с очисткой внутренней памяти.
Для клоков понадобится настраиваемый PLL независимый от процессора.
Вот такие вот хотелки.
S.
Pavel Kosenkov
Внешний клок от генератора можно будет завести, а вот конфигурируемый PLL предлогаю оставить на следующий проект - слишком много переделок.
--
--
C уважением (Best regards),
Косенков Павел (Kosenkov Pavel)
aka microtrigger & burokrat
==========================
no time to loose, no time to choose
Sergey Lapin
> так, прерывание по опустошению буфера - это еще одна нога, которых
> катастрофически нету. 2 прерывание, еще плачевнее.4 области, RLE сжатие и
> циклическая память... у меня ощущение, что это все не влезет в плисину, что
> сейчас заложена.
в результате. 4 области должны влезть, так же как и фифо.
Это ж просто 5 счетчиков, если я не ошибаюсь.
Alex M
теперь касательно плисины и примкнувшей к ней памяти:
90Мгц это вы губу раскатали.
плисина даёт задержку на до выдачи адреса 2.5нс:
LE register clock-to-output delay 490ps
Data output delay from adjacent LE to I/O block 350 нс
Output delay buffer and pad delay 1530 нс
далее идет реакция микрухи 10 или 8нс
соотв полное время выборки 10.5 или 12.5 нс
затем плисина снова тормозит:
I/O input pad and buffer delay 970ps
LE register setup time before clock 319ps
вроде бы из мануала следует, что Quartus "обещает" не допустить
появления в списке еще и Input routing delay(410ps), но хз,хз.
итого мы по худшему сценарию насчитали 12.3нс - 14.3нс. 90мгц это 11
нс, а ближайшая выводимая частота это 60Мгц - 15.5нс, и скорость
обмена 120мб/с. для сравнения в 1024х768х60=80млн выборок в секунду
видеовыходом + чуть больше 10мб/с записей по SPI.
не забывайте, что 100мгц на 10нс памяти могут быть только если память
синхронная. а асинхронные К6R4008V1D - это еще и клок придется
перекашивать, чтоб положительная часть была меньше 3нс, чтоб успевать
от смены адреса до захлопывания защелок на входе сигнал не начал
меняться.
Да, всё это чистая правда... Для отладки я использовал плату со 100 МГц асинхронной памятью и с тактовой 100 МГц схема периодически поглюкивает при записи, хотя вывод осуществляет стабильно без ошибок...
Даже не знаю что тут можно сделать... Поставить память на 133 МГц?
Или просто ограничить разрешение до 400x300 или 320х240...
Pavel Kosenkov
Alex M
Подскажите, пожалуйста, где можно взять верилоговую модель асинхронной статической памяти, чтобы для моделсима сгодилась? Надо 100 нс память...
Pavel Kosenkov
2 Krugo...@gmail.com :
Подскажите, пожалуйста, где можно взять верилоговую модель асинхронной статической памяти, чтобы для моделсима сгодилась? Надо 100 нс память...
Sergey Lapin
> 12 и 15 пины на DSUB подтянул 10К на 5В и через 10Ом резюки завел на плис.
> вот и DDC
>
> 24 августа 2008 г. 16:23 пользователь Alex M <0xf...@gmail.com> написал:
>>
>> 2 Krugo...@gmail.com :
>> Подскажите, пожалуйста, где можно взять верилоговую модель асинхронной
>> статической памяти, чтобы для моделсима сгодилась? Надо 100 нс память...
Вы о чем?!
p.s
пора спать.
Krugo...@gmail.com
работают быстрее?
Sergey Lapin
> а как оно могло читать то на 100нс? уличная магия или реально срамы
> работают быстрее?
Быстрее чем что?
Alex M
ещё раз хотел бы уточнить: где можно взять верилоговую модель асинхронной статической памяти, чтобы для моделсима сгодилась? у меня не получается отладить схему без моделирования... =(
а ещё вроде есть возможность загнать схему, которую квартус для плисины сгенерирует в моделсим, чтобы увидеть где что почему запаздывает... Может кто-нибудь помочь в этом деле?..
25 августа 2008 г. 10:12 пользователь Krugo...@gmail.com <Krugo...@gmail.com> написал: