Custom Peripheral, есть вопросы.. Опции

[Kuzmi4]

Здравствуйте.

Хочу сотворить собственную периферию, чтоб в SoPC Builder`е можно было свободно использовать.
Ну и как всегда есть вопросы ( в принципе если кто-то решит тоже начать писать свою периферию - тож думаю будет полезно, если начинать с нуля ).

Для полноты картины опишу что хочется поиметь:
В 2-х словах - нужно фотография импульса, то есть N/2 отсчётов до и N/2 отсчётов после.
Реализация как она была на рассыпухе - есть FIFO. В него пишется через логику данные с параллельного ADC. При чём, чтобы получить именно "фото" с заданными характеристиками в FIFO пишется до половины, потом по выставлению флага Half_Full начинается запись/чтение с FIFO - то есть отсчёт записывается в FIFO уровнем на лапке WR и потом после записи уровнем на лапке RD считывается - это позволяет как бы пропускать динамическую картинку через буффер обёмом N/2. Далее, когда приходит сигнал с ДНУ - ногодрыгание на лапе RD прекращается и мы дописываем оставшиеся N/2 отсчётов - и вуаля! - в результате у нас картинка где есть N/2 записей с ADC до и N/2 записей с ADC после сигнала. Если сигнал с ДНУ приходит раньше чем выставляется флаг Half_Full - начинается вышеописанная процедура, а потом в проге юзер решает что делать с этим фреймом.

Касательно реализации интерфеса - будет Avalon M-M Slave. В документации для "Avalon Memory-Mapped Interfaces" прочитал как работает слейв и про смысл разнообразных wires на шине. Так же прочитал про пакетную передачу данных. И тут возник вопрос касательно реализации регистров устройства, а если точнее передачи данных - можно сделать вариант 1 -> 3 регистра: status,control, data;вариант 2 -> status, control, data[0], data[1]... data[N-1];
Собственно по первому варианту будет пакетная передача данных, а по второму как обыкновенная мапа памяти - обращение к ячейке и все дела... Однако есть вопрос касательно пакетной передачи, как видно из рисунка:

Выдача данных слейвом ведётся по фронтам клока - будет ли успевать CPU их забирать, если да то как это реализовать ?
Если мапированный вариант - тогда тут вопросов пока нет.
1-й сложнее но позволяет съэкономить память если там буфер будет килобайт там или больше, а 2-й проще.Пока не остановился на каком-то 1-м варинате..

Касательно реализации в VHDL - нашёл такие мегафункции как altsyncram и dcfifo и примеры их использования - в принципе с 1-го можно составить FIFO со своей логикой (что мне и надо), а ко 2-му - приёдётся накручивать к уже имеющейся логике, ту которая требуется. Начну с dcfifo (схемный вариант тем более есть), а потом попробую с altsyncram.

Есчё есть вопрос касательно IRQ -> после того как буфер набрался - если в контрольном регистре выставлен бит интерупта - выставляется бит в регистре статуса и должно следовать IRQ. Однако судя по данным с литературы (апноты) они занимают довольно много времени. Можно ли как то уменьшить время реакции? В Custom Instructions есть Interrupt Vector - если в правильном направлении смотрю, то насколько это сильно может ускорить время ответа на интерупт ??

Буду признателен за советы, помощь и критику