|
Custom Peripheral, есть вопросы.. |
|
|
|
May 14 2008, 07:30
|

Гуру
     
Группа: Свой
Сообщений: 3 304
Регистрация: 13-02-07
Из: 55°55′5″ 37°52′16″
Пользователь №: 25 329

|
Здравствуйте. Хочу сотворить собственную периферию, чтоб в 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]; Собственно по первому варианту будет пакетная передача данных, а по второму как обыкновенная мапа памяти - обращение к ячейке и все дела... Однако есть вопрос касательно пакетной передачи, как видно из рисунка:
 Р В Р’ВВВВВзображенРСвЂВВВВР В Р’Вµ СѓРСВВВВВеньшено
(17.09 килобайт)
|
Выдача данных слейвом ведётся по фронтам клока - будет ли успевать CPU их забирать, если да то как это реализовать ? Если мапированный вариант - тогда тут вопросов пока нет. 1-й сложнее но позволяет съэкономить память если там буфер будет килобайт там или больше, а 2-й проще.Пока не остановился на каком-то 1-м варинате.. Касательно реализации в VHDL - нашёл такие мегафункции как altsyncram и dcfifo и примеры их использования - в принципе с 1-го можно составить FIFO со своей логикой (что мне и надо), а ко 2-му - приёдётся накручивать к уже имеющейся логике, ту которая требуется. Начну с dcfifo (схемный вариант тем более есть), а потом попробую с altsyncram. Есчё есть вопрос касательно IRQ -> после того как буфер набрался - если в контрольном регистре выставлен бит интерупта - выставляется бит в регистре статуса и должно следовать IRQ. Однако судя по данным с литературы (апноты) они занимают довольно много времени. Можно ли как то уменьшить время реакции? В Custom Instructions есть Interrupt Vector - если в правильном направлении смотрю, то насколько это сильно может ускорить время ответа на интерупт ?? Буду признателен за советы, помощь и критику
|
|
|
|
|
May 14 2008, 11:13
|
Знающий
   
Группа: Свой
Сообщений: 518
Регистрация: 12-04-07
Из: Санкт-Петербург
Пользователь №: 26 997

|
Я бы на заморачивался с фифо и делал бы сдвиговый регистр - по логике задачи он тут, имхо, лучше всего подходит. Когда мне надо передать большой объем данных из модуля в проц или другой модуль, но не критично ко времени, я обычно делаю в системе память (можно onchip, можно внешнюю), добавляю модулю мастерпорт и подключаю его к этой памяти (слейв модуля подключен к мастеру проца, мастер модуля - к слейву памяти). Далее проц выделяет нужный объем памяти, сообщает модулю (слейв модуля сделан для регистровой работы) адрес начала блока. Модуль данные принимает, обрабатывает и по ходу процесса скидывает в память. А далее проц их сам забирает. На сколько такой подход хорош здесь - не знаю, может быть либо избыточность памяти, либо критичность времени записи в память. Вообщем, думать надо, варианты есть разные.
|
|
|
|
|
May 14 2008, 14:28
|

Гуру
     
Группа: Свой
Сообщений: 3 304
Регистрация: 13-02-07
Из: 55°55′5″ 37°52′16″
Пользователь №: 25 329

|
2 Kuzmi4 - глянул на сдвиговый регистр - действительно вы правы оказались Я так понял вот такая реализация имелась ввиду:
 Р В Р’ВВВВВзображенРСвЂВВВВР В Р’Вµ СѓРСВВВВВеньшено
(8.8 килобайт)
|
Плохо нас основам учили - не теми понятиями оперирую блин... Однако есть нъюанс - если я захочу например буфер в 1024 отсчёта а отсчёт будет 16 битным - а для 1 бита мне нужно 1 тригер - тогда мне понадобится 1024 х16 D-тригеров - жирновато получается... При старте с начальными параметрами в мегавизарде у меня 8-битный сдвиговый занимает 8 лутов... dcfifo - получается самое то для меня... Тем более думаю конструкция скорость в 20-60 МГц выдержит..
|
|
|
|
|
May 15 2008, 13:33
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Цитата(Kuzmi4 @ May 14 2008, 17:28)  2 Kuzmi4 - глянул на сдвиговый регистр - действительно вы правы оказались Я так понял вот такая реализация имелась ввиду:
 Р В Р’ВВВВВзображенРСвЂВВВВР В Р’Вµ СѓРСВВВВВеньшено
(8.8 килобайт)
|
Плохо нас основам учили - не теми понятиями оперирую блин... Однако есть нъюанс - если я захочу например буфер в 1024 отсчёта а отсчёт будет 16 битным - а для 1 бита мне нужно 1 тригер - тогда мне понадобится 1024 х16 D-тригеров - жирновато получается... При старте с начальными параметрами в мегавизарде у меня 8-битный сдвиговый занимает 8 лутов... dcfifo - получается самое то для меня... Тем более думаю конструкция скорость в 20-60 МГц выдержит.. Сразу оговариваюсь с Альтерой не работаю. Может (в принципе должно быть) у Альтеры есть аналогичное что-то. Ниже привожу для Xilinx: Вы попробуйте использовать сдвиговый регистр на основе LUT таблицы - SRL (Shift Register LUT), у Xilinx это описано в XAPP210 для Virtex и Virtex-II series для FPGAs " This application note describes the implementation of Linear Feedback Shift Registers (LFSR) using the SRL macroavailable in the Virtex™ and Virtex-II series of FPGAs. The optimal implementation of a 15-bit LFSR, a 52-bit LFSR, and a 118-bit LFSR are discussed in this application note. " " The Virtex-II devices have a similar macro, a selectable SRL that utilizes one LUT to implement a 16-bit shift register. This macro has two outputs, one is the dedicated output from the 16th register, and the other is selected using the address lines. This enables the macros to be cascadable to implement 32-bit, 64-bit, and 128-bit shift registers in one CLB. "
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
May 15 2008, 15:46
|

Гуру
     
Группа: Свой
Сообщений: 3 304
Регистрация: 13-02-07
Из: 55°55′5″ 37°52′16″
Пользователь №: 25 329

|
Цитата(RHnd @ May 15 2008, 18:40)  Вы кем пользуетесь? LPM_SHIFT? Так это не совсем то.  Посмотрите на Memory Compiler -> Shift Register RAM based. Спасибо, а то чуть в тупик зашёл тут. Кричит Цитата Error (10820): Netlist error at my_fifo.vhd(148): can't infer register for in_rst_signal because its behavior depends on the edges of multiple distinct clocks И всё тут. В принципе догадываюсь, что это - мои кривые руки, но если использовать сдвиговые - они будут выглядеть не так кривовато....
|
|
|
|
|
May 29 2008, 12:31
|

Гуру
     
Группа: Свой
Сообщений: 3 304
Регистрация: 13-02-07
Из: 55°55′5″ 37°52′16″
Пользователь №: 25 329

|
Вроде сварганил я костяк периферии, теперь надо его адаптировать к Avalon Memory-Mapped. Вот тут появились некоторый вопросы  то есть не могу правильно понять... Камень преткновения - byteenable. Значит в Avalon Memory-Mapped Interface Specification за May 2007 дано описание евойное. На сколько я понял - оно связано с writedata - то есть забор байтов с порта writedata будет вестись в таком соответствии
 Р В Р’ВВВВВзображенРСвЂВВВВР В Р’Вµ СѓРСВВВВВеньшено
(11.86 килобайт)
|
Однако в таблице 1 на странице 16 в Avalon Memory-Mapped Interface Specification в колонке Required обозначено No. Как то странновато получается.... В обсчем из всего вышеизложенного и краткого описания byteenable на стр.16 Цитата Byte-enable signals to enable specific byte lane(s) during transfers on ports of width greater than 8 bits. я пришёл к выводу что этот сигнал нужен когда входной порт имеет размерность больше 8 бит - то есть 16 или 32. То есть если у меня например есть control и status регистры 8-битные - то им до лампочки он будет, потому как там разрядность 8 бит(всегда будет 0001 на byteenable), а вот если регистр данных , в котором по задумке 16 бит - то ему нужно будет мониторить это самый byteenable... Правильно ли я всё понял ? Спасибо.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|