ТЕМА:

Постройте временнУю диаграмму, сами увидите.

SOVA пишет: Постройте временнУю диаграмму, сами увидите.

Хм... Но все же, ГПУ читает данные из SRAM с частотой 50-60МГц, а МК работает со SRAM на 53-90МГц.
Где мне взять такую SRAM c 5ns задержкой?
PS: После таких подсчетов становится не по себе. Возможно стоит уравнять все частоты до 50-60...

Снизить частоту вдвое можно удвоением шины данных. Я думаю что небудет сегодня проблема найти статику с 32 бит шиной.

wowa пишет: Снизить частоту вдвое можно удвоением шины данных. Я думаю что небудет сегодня проблема найти статику с 32 бит шиной.

А что с МК делать? У них (M4) шире 16бит не бывает :-)
Но можно сделать костыль на ПЛИС, конвертирующий 16 в 32 с потерей скорости, но боюсь, много подводных камней обнаружится.

Ничего подобного.. Это не костыль - это правильно использовать плис на изменение ширины данных с понижением частоты обработки данных.

Кстати запись в виртуальное окно используется очень давно. И все современные ЖКИ дисплеи именно так и записывают. И ещё они требуют адрес только первый раз.. Потом сами делают автоинкримент..

wowa пишет: Ничего подобного.. Это не костыль - это правильно использовать плис на изменение ширины данных с понижением частоты обработки данных.

Кстати запись в виртуальное окно используется очень давно. И все современные ЖКИ дисплеи именно так и записывают. И ещё они требуют адрес только первый раз.. Потом сами делают автоинкримент..

Спасибо, рассмотрю этот вариант по-подробнее. А как быть с единичным доступом? Я имею ввиду, когда МК запрашивает конкретный байт или полуслово, скорость понизить не удастся, если только подавать сигнал Wait (заморозка данных) процессору.

В каком смысле доступ? Чтение из Видеопамяти? Я недумаю что там будут большие задержки. Если память будет способна и читать и записывать одновременно с выдачей данных.

wowa пишет: В каком смысле доступ? Чтение из Видеопамяти? Я недумаю что там будут большие задержки. Если память будет способна и читать и записывать одновременно с выдачей данных.

Я имел ввиду, если жертвовать скоростью для большей ширины шины, то МК должен работать со своей 16бит шиной в два раза быстрее, чем 32-ух битная. А ПЛИС должна на лету разбивать 32 на два по 16 и передавать МК.
Но если МК запрашивает только 16бит, то ПЛИС не успеет отдать ему вовремя.

Ничего подобого. Мк может посылать данные с той скоростью с какой сможет. ПЛИС будет данные складывать в маленькое ФИФО и из него уже записывать в память.. Записывая по 32 бита 16 бит данных я думаю будет без колизий. А если произойдёт чтение процесорем - так просто не проведётся запись из ФИФО. Только вот боюсь что уже МАХ2 такое может и не потянуть :) Тут уже больше похоже на цыклончик в 100 ног и на 5к или 8к ячеек :) Ну и тогда ещё рекомендую посмотреть в сторону DRAM - у них экономия ног адреса - мультиплексирование из коробки. Ну и ещё у них есть инетерсные режимы блоковой записи, когда память делает автоинкримент адреса. Ну и не редкость у них теперь частоты 133 и 166 Мгц. Плюс бывают ещё и синхронные памяти - там вообще всё круто.

З.Ы. Я вот подумал :) Может быть казус только если данные ещё в ФИФО а проц их уже пытается читать.. то получит предедущие данные :)

Перебрал много вариантов, вообщем, делаю такую связку: EP2C8 + EPM570 + 2x SRAM (64kx16)...
EPM570 будет заниматься только выводом картинки на экран, а Cyclone II - обработкой шины ввода/вывода, включая ускоритель вывода данных, текстовый режим и т.п.

Единственное, я сомневаюсь в выборе EP2C8. Не слишком ли много это для видеопроцессора(адаптера с плюшками) данного типа? Cyclone II рассчитан на частоты высокие, а здесь всего 120MHz, да и шина то работает на 60. Я в FPGA мало разбираюсь, просветите малость. :)