ТЕМА:

Я думаю что Вы не правы :) 120Мгц это максимум что можно сделать на больше меньше сложной логике на 4 цыклоне!!! Недумаю что сделаете всю схему и оно заведётся на 120. Боюсь что будете рад если заведётся на 60. И поэтому надо брать цыклон 4 и вовсе не потому что он черезчур хорош - а потому что уже скоро перестанут поддерживать 3 цыклоны в квартусе :) Я уже закупился EP4CE10E22C8N и EPCS16SI8N. Ну и потом недумаю что там будет вообще нужна EPM570. Памяти брать одну большую ДРАМ 32бит/166 Мгц и вовсю пользовать бурст чтение/запись и фифо. Ну и влезет всё Ваше добро в ПЛИС без проблем и с ускорителем. Главное ненадо городить в ПЛИС без надобности софт-процесоры - у вас и так мощьный АРМ есть в системе. ПЛИС надо использовать именно как много логики. Не рекомендуется заполнять ПЛИС на более чем 75-80% - там уже начинаются глюки с розмещением и скоростью.. Ну и как я смотрю 4 цыклон у нас дешевле чем 2 точно.

wowa пишет: Я думаю что Вы не правы :) 120Мгц это максимум что можно сделать на больше меньше сложной логике на 4 цыклоне!!! Недумаю что сделаете всю схему и оно заведётся на 120. Боюсь что будете рад если заведётся на 60.

Хм... В EPM570 гуляет 120MHz, но только по триггерам синхронизации. Неужели даже существующий проект для 570 не запустится на Cyclone I/II?

И поэтому надо брать цыклон 4 и вовсе не потому что он черезчур хорош - а потому что уже скоро перестанут поддерживать 3 цыклоны в квартусе Я уже закупился EP4CE10E22C8N и EPCS16SI8N.

Хорошо, вы меня убедили :) , но все же ввиду некоторых обстоятельств могу использовать FPGA не дальше Cyclone I/II.

Ну и потом недумаю что там будет вообще нужна EPM570.

Только потому, что мне не хватает I/O ног в TQFP корпусах. А простейший BGA мне паять страшно и не чем.

Главное ненадо городить в ПЛИС без надобности софт-процесоры

Об этом и не думаю.

Если проэкт работал в ЦПЛД - то в ФПГА он скорей всего заведётся. Но может завестись на меньшей, а может и на большей скорости. И что же это за обстоятельства такие? Уже куплены чипы? Проблема с ногами - я же писал - одна память ДРАМ - это половина адресных ног. Можно и 16 битную взять.. Но тогда обязательно бурст и фифо. И хватит ног на всё. Можно ещё интерфейс паралельный к АРМ прижать немного.. Можно использовать режим автоинкримента: и использовать адрес и данные одними пинами :) надо будет 16/8 бит данных и два сигнала записи - один запись адреса и второй данные. Первый раз происходит запись адреса и потом уже только данные с автоинкриментом. Ну или реализовать как в нормальных контролерах ЖКИ - розделить на запись команд и запись данных - тогда будет команда АДРЕС, ДАТА и УПРАВЛЕНИЕ. Ну как бы так.

wowa пишет: Если проэкт работал в ЦПЛД - то в ФПГА он скорей всего заведётся. Но может завестись на меньшей, а может и на большей скорости. И что же это за обстоятельства такие? Уже куплены чипы? Проблема с ногами - я же писал - одна память ДРАМ - это половина адресных ног. Можно и 16 битную взять.. Но тогда обязательно бурст и фифо. И хватит ног на всё. Можно ещё интерфейс паралельный к АРМ прижать немного.. Можно использовать режим автоинкримента: и использовать адрес и данные одними пинами :) надо будет 16/8 бит данных и два сигнала записи - один запись адреса и второй данные. Первый раз происходит запись адреса и потом уже только данные с автоинкриментом. Ну или реализовать как в нормальных контролерах ЖКИ - розделить на запись команд и запись данных - тогда будет команда АДРЕС, ДАТА и УПРАВЛЕНИЕ. Ну как бы так.

Заказаны уже EPM, EP2 и EP1. Насчет DRAM, для меня ее несколько проблематично использовать в качестве видеопамяти, а также одно из требований: абсолютно "случайный доступ" к ячейкам, чтобы ARM мог полноценно работать в этой памяти. :)
Вопрос вдогонку: можно ли подружить параллельный интерфейс микроконтроллера с интерфейсом SDRAM? Там есть страничный режим, но нет управляющих пинов RAS, CAS. (есть мысль сделать их битами адреса). Как работает Burst режим, растолкуйте пожалуйста. :) Я предполагаю, что сначала устанавливается начальный адрес, а затем после установки соответствующего бита, память начинает выполнять автоинкремент адреса по фронту тактовой. Если во время этого устанавливается WE или OE, то память проводит соответствующие операции записи/чтения на текущем адресе. Верно ли я рассуждаю?

То что куплено такое старьё - нехорошо.. Но думаю ещё реально найти на нету старого квартуса :) Ненужно работать с медленной видеопамятью "случайно" - это не эфективно. Да и редко нужно. Обычно если какой осцилограф делать.. И то можно сделать ещё один режим - выводится пиксельной линии... А быстрей формировать процесором картинку и заливать её в видеопамять через ДМА. Что касается Вашего АРМ - надо смотреть даташит. Burst работает так что програмируется длина блока и записывается или читается блоками од 2 до 64 слов. Насколько мне известно комбинировать запись с чтением в одно блоке нельзя. Но опять - это зависит от чипа ДРАМ котоый пользуете. Вобщем нужен контролер памяти с фифо на входе и на выходе. И потом она получается как бы прозрачная..

Wowa, спасибо ответ. :)

wowa пишет: То что куплено такое старьё - нехорошо..

Обошлись не дорого...

Но думаю ещё реально найти на нету старого квартуса

Уже нашел и тестирую проекты с ПЛИС-ок.

Ненужно работать с медленной видеопамятью "случайно" - это не эфективно. Да и редко нужно. Обычно если какой осцилограф делать.. И то можно сделать ещё один режим - выводится пиксельной линии... А быстрей формировать процесором картинку и заливать её в видеопамять через ДМА.

Отчасти соглашусь с вами, но картинка будет формироваться сразу в видеопроцессоре (в одном из его буферов). Я думаю, все графические операции лучше производить только в видеопроцессоре, чтобы не тратить ресурсы системы обработку графики, исключая хранение и передачу спрайтов. Но над этом я еще поразмыслю.

Насколько мне известно комбинировать запись с чтением в одно блоке нельзя. Но опять - это зависит от чипа ДРАМ котоый пользуете. Вобщем нужен контролер памяти с фифо на входе и на выходе. И потом она получается как бы прозрачная..

А вот это жаль. Я хотел сделать DMA контроллер, который мог бы по одной и той же шине пересылать данные между SRAM (и подобными) и SDRAM, без напряжения. Пустить два десятка линий адреса, данных + управляющие OE/WE и BURST какой-нибудь, и CLK.

Ну.. Если нравится аж так усложнять себе работу :)

Подключить DRAM к ARM просто так похоже не получится. Тогда какую FPGA лучше поставить в качестве контроллера памяти? :) Или тут можно ПЛИС обойтись?

FPGA = ПЛИС :) Наверное имелась ввиду CPLD MAXII - да, думаю можно будет на ней сделать или контролер памяти, или ещё что-то вынести через быстрый серийный интерфейс..

Вашим мыслям я начинаю находить подтверждения, уважаемый Wowa. Сейчас я экспериментирую с обработкой данных на FPGA. А Cyclone I оказался шустреньким на свои 12 лет. :)

Я подключил его к 146MHz шине (пока только 8бит) своего ARM и гоняю через него данные на скорости 64МБ/сек. Можете написать мне, правильно ли я организовал обработку и передачу данных?

Первая модель:

ARM записывает данные в FiFo, а обработчик (computer) их оттуда забирает, проводит операции и загружает в другое FiFO, откуда данные поступают обратно в ARM. Если в FiFo кончаются данные или оно переполнено, то подается соответствующий сигнал ARM-у (мол, подожди). Полный путь: FiFo->Обработчик->FiFo Работает превосходно.

Вторая модель:

Здесь я сделал то же самое, но вместо выходного FiFo я поставил RAM, поэтому пришлось задействовать шину адреса. Таким образом, у обработчика (computer-а) больше возможностей, а именно: адресация. Но в этом варианте невозможно потоком работать с данными, в отличии от первой модели. Полный путь: FiFo->Обработчик->RAM

Третья модель
Ее пока нет. Я думаю использовать два порта и избавиться от двунаправленных шин. Т.е., для записи используется один порт, а для чтения другой: получается, можно "гнать" данные через обработчика как через трубу :) К сожалению, на сегодняшний момент я не могу этого сделать, так как это требует "железных" вмешательств и многое другое.

Хотелось бы услышать мнение об этих моделях, правильно ли я все делаю с точки зрения организации. (не обращайте внимания на интерфейс) Я уверен, что такая обработка сейчас и используется, но не уверен в "правильности" моих реализаций.