реклама на сайте
подробности

 
 
3 страниц V   1 2 3 >  
Reply to this topicStart new topic
> Custom Peripheral, есть вопросы..
Kuzmi4
сообщение May 14 2008, 07:30
Сообщение #1


Гуру
******

Группа: Свой
Сообщений: 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];
Собственно по первому варианту будет пакетная передача данных, а по второму как обыкновенная мапа памяти - обращение к ячейке и все дела... Однако есть вопрос касательно пакетной передачи, как видно из рисунка:
Прикрепленное изображение

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

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

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

Буду признателен за советы, помощь и критику
laughing.gif
Go to the top of the page
 
+Quote Post
RHnd
сообщение May 14 2008, 11:13
Сообщение #2


Знающий
****

Группа: Свой
Сообщений: 518
Регистрация: 12-04-07
Из: Санкт-Петербург
Пользователь №: 26 997



Я бы на заморачивался с фифо и делал бы сдвиговый регистр - по логике задачи он тут, имхо, лучше всего подходит.
Когда мне надо передать большой объем данных из модуля в проц или другой модуль, но не критично ко времени, я обычно делаю в системе память (можно onchip, можно внешнюю), добавляю модулю мастерпорт и подключаю его к этой памяти (слейв модуля подключен к мастеру проца, мастер модуля - к слейву памяти). Далее проц выделяет нужный объем памяти, сообщает модулю (слейв модуля сделан для регистровой работы) адрес начала блока. Модуль данные принимает, обрабатывает и по ходу процесса скидывает в память. А далее проц их сам забирает.
На сколько такой подход хорош здесь - не знаю, может быть либо избыточность памяти, либо критичность времени записи в память. Вообщем, думать надо, варианты есть разные.
Go to the top of the page
 
+Quote Post
Kuzmi4
сообщение May 14 2008, 11:38
Сообщение #3


Гуру
******

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



2 RHnd - можете объяснить, чем сдесь фифо не подходит ? Потому как фифо тут вроде то что надо...

На счёт логики по шине - не особо хочется ворота воротить - думаю что слейва хватит с головой для этой задачи, тем более что есть IRQ - меснул процу что задача выполнена и он выгребает. Тут время не критично, главное чтоб на выборку пакета не уходили милисекунды при тактовой в 50-100 МГц..
Пакетная передача в принципе была б желательна - 3 регистра в памяти ( status, control, data ) и всё + скорость, но я пока имею непонятки по-этому вопросу, склоняюсь к мапированому варианту.. sad.gif
Go to the top of the page
 
+Quote Post
RHnd
сообщение May 14 2008, 11:45
Сообщение #4


Знающий
****

Группа: Свой
Сообщений: 518
Регистрация: 12-04-07
Из: Санкт-Петербург
Пользователь №: 26 997



Не то, чтоб фифо не подходит, но сдвиговый регистр, имхо, лучше в задачу ложится.
Как вариант, можете мапировать один регистр и сделать логику слева так, чтоб при чтении этого регистра, происходил сдвиг данных и при следующем чтении подсовывалось новое данное. Тогда процу нужно будет только N раз прочитать этот регистр.
Go to the top of the page
 
+Quote Post
Kuzmi4
сообщение May 14 2008, 11:49
Сообщение #5


Гуру
******

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



2 RHnd - спасибо за идейку, не подумал smile.gif

А можете объяснить на счёт сдвигового регистра ?
Я просто его использовал serial-in в рассыпухе (типа аналог SPI) - догадываюсь что надо paralel-in, но как то глобального понимания нет для него.. crying.gif
Go to the top of the page
 
+Quote Post
RHnd
сообщение May 14 2008, 12:14
Сообщение #6


Знающий
****

Группа: Свой
Сообщений: 518
Регистрация: 12-04-07
Из: Санкт-Петербург
Пользователь №: 26 997



Цитата(Kuzmi4 @ May 14 2008, 15:49) *
А можете объяснить на счёт сдвигового регистра ?
Я просто его использовал serial-in в рассыпухе (типа аналог SPI) - догадываюсь что надо paralel-in, но как то глобального понимания нет для него.. crying.gif

Там объяснять в принципе нечего, сами вполне разберетесь. smile.gif У Альтеры даже мегафнукция такая есть, вроде.
Go to the top of the page
 
+Quote Post
Kuzmi4
сообщение May 14 2008, 12:18
Сообщение #7


Гуру
******

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



Есть.
Посмотрю сегодня...
Остановился пока на фифо.
Начну ваять VHDL - посмотрим как это будет выглядеть..
Go to the top of the page
 
+Quote Post
Kuzmi4
сообщение May 14 2008, 14:28
Сообщение #8


Гуру
******

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



2 Kuzmi4 - глянул на сдвиговый регистр - действительно вы правы оказались smile.gif
Я так понял вот такая реализация имелась ввиду:

Прикрепленное изображение

a14.gif
Плохо нас основам учили - не теми понятиями оперирую блин...

Однако есть нъюанс - если я захочу например буфер в 1024 отсчёта а отсчёт будет 16 битным - а для 1 бита мне нужно 1 тригер - тогда мне понадобится 1024 х16 D-тригеров - жирновато получается...
При старте с начальными параметрами в мегавизарде у меня 8-битный сдвиговый занимает 8 лутов... sad.gif
dcfifo - получается самое то для меня...
Тем более думаю конструкция скорость в 20-60 МГц выдержит..
Go to the top of the page
 
+Quote Post
RHnd
сообщение May 14 2008, 18:00
Сообщение #9


Знающий
****

Группа: Свой
Сообщений: 518
Регистрация: 12-04-07
Из: Санкт-Петербург
Пользователь №: 26 997



Угу. Примерно оно. Я только не понял, Вы в схематике работаете?
1024 отсчета по 16 бит будут занимать совершенно одинаковое количество тригеров. Или одинаковую память - на сколько помню, альтеровская память умеет работать сдвиговым регистром.
Go to the top of the page
 
+Quote Post
Kuzmi4
сообщение May 15 2008, 08:56
Сообщение #10


Гуру
******

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



2 RHnd - схематик мне нужен для понимания процесса ... smile.gif
На счёт сдвигового регистра - я ж писал уже - пробовал в мегавизарде - 8 входов - 8 лутов.. Вроде туда смотрел... 05.gif
на счёт использования M4K ячеек - не встречал, если тыкнёте носом - буду признателен.... smile.gif
Go to the top of the page
 
+Quote Post
Maverick
сообщение May 15 2008, 13:33
Сообщение #11


я только учусь...
******

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



Цитата(Kuzmi4 @ May 14 2008, 17:28) *
2 Kuzmi4 - глянул на сдвиговый регистр - действительно вы правы оказались smile.gif
Я так понял вот такая реализация имелась ввиду:

Прикрепленное изображение

a14.gif
Плохо нас основам учили - не теми понятиями оперирую блин...

Однако есть нъюанс - если я захочу например буфер в 1024 отсчёта а отсчёт будет 16 битным - а для 1 бита мне нужно 1 тригер - тогда мне понадобится 1024 х16 D-тригеров - жирновато получается...
При старте с начальными параметрами в мегавизарде у меня 8-битный сдвиговый занимает 8 лутов... sad.gif
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.

"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
Go to the top of the page
 
+Quote Post
RHnd
сообщение May 15 2008, 15:40
Сообщение #12


Знающий
****

Группа: Свой
Сообщений: 518
Регистрация: 12-04-07
Из: Санкт-Петербург
Пользователь №: 26 997



Цитата(Kuzmi4 @ May 15 2008, 12:56) *
на счёт использования M4K ячеек - не встречал, если тыкнёте носом - буду признателен.... smile.gif

Вы кем пользуетесь? LPM_SHIFT? Так это не совсем то. smile.gif Посмотрите на Memory Compiler -> Shift Register RAM based.
Go to the top of the page
 
+Quote Post
Kuzmi4
сообщение May 15 2008, 15:46
Сообщение #13


Гуру
******

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



Цитата(RHnd @ May 15 2008, 18:40) *
Вы кем пользуетесь? LPM_SHIFT? Так это не совсем то. smile.gif Посмотрите на Memory Compiler -> Shift Register RAM based.


Спасибо, а то чуть в тупик зашёл тут. crying.gif
Кричит
Цитата
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

И всё тут.
В принципе догадываюсь, что это - мои кривые руки, но если использовать сдвиговые - они будут выглядеть не так кривовато....
smile3046.gif
Go to the top of the page
 
+Quote Post
Kuzmi4
сообщение May 29 2008, 12:31
Сообщение #14


Гуру
******

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



Вроде сварганил я костяк периферии, теперь надо его адаптировать к Avalon Memory-Mapped.
smile.gif
Вот тут появились некоторый вопросы sad.gif то есть не могу правильно понять...
Камень преткновения - byteenable.

Значит в Avalon Memory-Mapped Interface Specification за May 2007 дано описание евойное.
На сколько я понял - оно связано с writedata - то есть забор байтов с порта writedata будет вестись в таком соответствии
Прикрепленное изображение

Однако в таблице 1 на странице 16 в Avalon Memory-Mapped Interface Specification в колонке Required обозначено No. Как то странновато получается....
wacko.gif
В обсчем из всего вышеизложенного и краткого описания 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...
Правильно ли я всё понял ? smile3046.gif
Спасибо.
Go to the top of the page
 
+Quote Post
RHnd
сообщение May 29 2008, 13:15
Сообщение #15


Знающий
****

Группа: Свой
Сообщений: 518
Регистрация: 12-04-07
Из: Санкт-Петербург
Пользователь №: 26 997



Эксперименты не ставил, но смутно подозреваю, что в случае отсутствия byeenable, оно будет автоматически считаться как 1111.
Go to the top of the page
 
+Quote Post

3 страниц V   1 2 3 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 16th June 2025 - 20:41
Рейтинг@Mail.ru


Страница сгенерированна за 0.01526 секунд с 7
ELECTRONIX ©2004-2016