[altlogic 0]

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

 

Необходимо создать систему обработки видеоизображений с применением софт-процессора NIOS II. Задача такая: записать изображение с CMOS-камеры в оперативную память и произвести над ним некоторую обработку при помощи процессора.

 

Аппаратное обеспечение: стенд DE2-115 (Cyclone 4), плата с камерой TRDB-D5M.

Нашел пример от альтеры DE2_115_CAMERA, в котором реализовано на верилоге примерно следующая система:

захват изображения->декодер->контроллер SDRAM->ТВ-деодекодер

 

Подумал, что всего-то делов - подключить к этой системе NIOS и забрать данные из SDRAM. Не тут-то было:) Задачу решаю уже не первый день...

 

Мои варианты решения задачи:

 

1. Решил отказаться от идеи расшаривания SDRAM. Решил писать картинку в SRAM, и расшарить её. От SDRAM отказался по следующим соображениям: не понимаю, может ли быть в одной системе два контроллера памяти - один у HDL, другой - у NIOS. Если такое возможно, то как будет происходить разделение шины между ними, и самое главное - какой из контроллеров будет заниматься регенерацией памяти. SRAM подключил через Avalon MM Tristate Bridge ( по инструкции http://naliwator.narod.ru/les/les_nios_sram_00.html). В Top-level дизайн проекта DE2_115_CAMERA добавил соответсвенно свою систему из сопц-билдера. Софт-процессор с памятью SRAM заработал. Когда я попытался подключить шину моста SRAM к декодеру изображения - ничего не получилось. От ошибки разделения пинов

 

Error: The pin "SRAM_ADDR[1]" has multiple drivers due to the non-tri-state driver "nios:u9|bridge_2_sram_avalon_slave_arbitrator:the_bridge_2_sram_avalon_slav

e|bridge_2_sram_address[1]"

не смог избавиться. Точнее для шины данных ошибку смог побороть, а для шины адреса - нет(?). Пришёл к выводу, что таким образом Расшарить SRAM у меня не получится. Подключение HDL-дизайна к выводам FPGA (assign SRAM_ADDR[19:0] = rSRAM_ADDR[19:0];) приводит к описанной выше ошибке.

 

2. Создание в SOPC-Builder компонента на основе HDL описания всей камеры целиком. То есть создать такой компонент в который запихать всё - и блок захвата, и блоки обработки и контроллер SDRAM. Как управлять этим монстром - не понятно. Не ясно что делать с разнородными интерфейсами модуля - там и Conduit и Memory Mapped. Предлагаемый подход я нашёл в реализации "Nios II CRC Acceleration Example Design v2.2.0"(http://www.altera.com/support/examples/nios2/exm-crc-acceleration.html). Но там компонент попроще - всего лишь генератор CRC.

 

3. Создание в SOPC-Builder компонента на основе HDL модуля контроллера SDRAM. Придётся перенести SDRAM-контроллер с HDL в процессор. Возможно самый правильный подход. Пока не рассматривал.

 

В итоге вопрос, как же обмениваться данными между HDL и NIOS так и повис в воздухе. Видел советы по использованию в подобных ситуациях SGDMA, DMA... Но мне не дает покоя мысль, что всё должно быть гораздо проще. Какой путь более правильный и менее трудозатратный в моем случае? Подскажите пожалуйста.

 

top-level по первому варианту решения - в приложении. Ниже приведен отрывок топ-левела, где к выводам NIOS подключен HDL код инициализации SRAM памяти.

 

...

nios u9(

.clk_0 (CLOCK_50),

.reset_n (reset_n),

.bridge_2_sram_address (SRAM_ADDR),

.bridge_2_sram_byteenablen ({SRAM_UB_N, SRAM_LB_N}),

.bridge_2_sram_data (SRAM_DQ),

.bridge_2_sram_writen (SRAM_WE_N),

.in_port_to_the_sw (in_port_to_the_sw),

.out_port_from_the_led (out_port_from_the_led),

.rxd_to_the_uart (rxd_to_the_uart),

.txd_from_the_uart (txd_from_the_uart)

);

...

always@(posedge CLOCK_50 or negedge iRST)

begin

if(!iRST)

begin

writen_pixel <= 0;

nDW <= 1'b1;

end

else

begin

if (writen_pixel < 400*300)

begin

nDW <= 1'b1;

writen_pixel <= writen_pixel + 1;

rSRAM_ADDR[19:0] <= writen_pixel;

rSRAM_CE_N <= 1'b0;

rSRAM_DQ[15:0] <= 16'h5555;

rSRAM_LB_N <= 1'b0;

rSRAM_OE_N <= 1'b0;

rSRAM_UB_N <= 1'b1;//сташий байт не используется

rSRAM_WE_N <= 1'b0;

end

else

begin

rSRAM_ADDR[19:0] <= 20'hZZZZZ;

rSRAM_CE_N <= 1'bz;

rSRAM_DQ[15:0] <= 16'hZZZZ;

rSRAM_LB_N <= 1'bZ;

rSRAM_OE_N <= 1'bZ;

rSRAM_UB_N <= 1'bZ;//сташий байт не используется

rSRAM_WE_N <= 1'bZ;

nDW <= 1'b0;

end

end //else (nRST==1)

end

 

assign SRAM_DQ = rSRAM_DQ;

assign SRAM_ADDR[19:0] = rSRAM_ADDR[19:0];

assign SRAM_CE_N = rSRAM_CE_N;

assign SRAM_LB_N = rSRAM_LB_N;

assign SRAM_OE_N = rSRAM_OE_N;

assign SRAM_UB_N = rSRAM_UB_N;

assign SRAM_WE_N = rSRAM_WE_N;

...

camera.v

[barabek 0]

Вариант в общем-то один. Есть система с Nios. В ней есть контроллер памяти (SRAM или SDRAM), который является slave на шине AvalonMM и соединен с master процессора NIOS (на его шину данных и/или программ). К этому контроллеру памяти необходимо подключить внешний модуль от Вашей камеры. Т.е. в описании проекта камеры перед памятью должен стоять контроллер интерфейса AvalonMM, мастер. Вы подключите оба мастера (nios и камеру) к одному слейву. Когда будете подключать в Qsys (SOPC-builder) автоматически добавится арбитр шины. А уже DMA это следующий шаг для улучшения системы

[Shivers 0]

А я бы контроллер камеры сделал так: внутреннее фифо на двупортовой памяти, наружу интерфейс как у SDRAM. И подключить к сгенерированному контроллеру SDRAM.

[Petr_I 0]

В итоге вопрос, как же обмениваться данными между HDL и NIOS так и повис в воздухе. Видел советы по использованию в подобных ситуациях SGDMA, DMA... Но мне не дает покоя мысль, что всё должно быть гораздо проще. Какой путь более правильный и менее трудозатратный в моем случае? Подскажите пожалуйста.

 

Это и есть самый "более правильный и менее трудозатратный". Пишите к своему модулю камеры только интерфейс Avalon-ST. Остальное: DMA, FIFO и прочее уже есть в SOPC. Плюс есть готовые примеры софта (не маловажный момент с точки зрения трудозатрат). SDRAM или SRAM или оба сразу можете использовать в данном варианте без проблем.

Остальные танцы с бубнами имеют смысл при дефиците ресурсов или быстродействия.

 

[altlogic 0]

Есть система с Nios. В ней есть контроллер памяти (SRAM или SDRAM), который является slave...

То есть вы предлагете выбросить из существующего проекта контоллер памяти, написанный на Verilog, и заменить его контроллером SOPC-Builder'а? Я боюсь, всплывут подводные камни по настройке контроллера и подгонке его под VGA-контроллер. Эти два блока тесно связаны между собой в сущесвтующем проекте.

 

 

...наружу интерфейс как у SDRAM. И подключить к сгенерированному контроллеру SDRAM.

То есть всё-таки варинат с двумя контоллерами SDRAM имеет право на жизнь?

 

 

Пишите к своему модулю камеры только интерфейс Avalon-ST.

Много сигналов. И не для всех понятно соответсвие шине Avalon... Но если это правильный путь, то тогда нужно идти им:)

 

[barabek 0]

То есть вы предлагете выбросить из существующего проекта контоллер памяти, написанный на Verilog, и заменить его контроллером SOPC-Builder'а? Я боюсь, всплывут подводные камни по настройке контроллера и подгонке его под VGA-контроллер. Эти два блока тесно связаны между собой в сущесвтующем проекте.

 

Можно оставить и Ваш контроллер памяти, добавив в удобном месте прослойку из авлоновских миастера и слейва.

 

 

То есть всё-таки варинат с двумя контоллерами SDRAM имеет право на жизнь?

 

Скорее нет. Или это будет такой геморой что ну его.

 

 

Много сигналов. И не для всех понятно соответсвие шине Avalon... Но если это правильный путь, то тогда нужно идти им :)

 

Может Вам действительно написать прослойку от шины авалон внутрь Вашего модуля.

 

 

При любом раскладе не забудьте добавить арбитр. Просто в сопц он добавляется автоматически и расшаривание памяти там легко реализовать.

[altlogic 0]

Это и есть самый "более правильный и менее трудозатратный". Пишите к своему модулю камеры только интерфейс Avalon-ST.

На счет Avalon-ST. Оказывается, там ничего и писать то не надо. У Altera есть IP-Core Clocked Video Input, который позволяет ввести изображение с камеры в систему. Но ввод осуществляется в соответсвии с протоколом Avalon-ST Video Protocol. Каким образом затем вывести информацию с интерфейса Avalon-ST на интерфейс Avalon Memory Mapped я не понимаю. Ни одного примера не нашел. Как поток данных с Avalon-ST направить в память?

 

Похоже нашел где искать ответ. Мне нужен On-Chip FIFO Memory Core. Данный модуль позволяет осуществлять обмен между Avalon-ST и Avalon-MM в обоих направлениях. Читаю документацию на него... Освоил. Не то. Данные с выхода этого буфера должен считывать программно NIOS. Естественно меня такое положение дел не устраивает. Мне нужна аппаратная запись данных с видеокамеры в память. Видимо это сможет сделать контроллер прямого доступа в память Scatter-Gather DMA Controller Core. Почитаю его документацию.

[altlogic 0]

Опишу способ программного ввода данных с видеокамеры в NIOS.

Необходимые компоненты SOPC Builder:

Clocked Video Input (Video and Image Processing\IO\)

On-Chip FIFO Memory (Memories and Memory Controllers\External Memory Interfaces\On-Chip\)

Так как ширина шины камеры сотавляет обычно 10-12 бит, что меньше ширины шины данных NIOS, необходимо добавление адаптеров System->Insert Avalon-ST Adapters, после чего добавляются следующие адаптеры:

 

Avalon-ST Channel Adapter (Bridges and Adapters\Streaming\)

Avalon-ST Data Format Adapter (Bridges and Adapters\Streaming\)

Streaming\Avalon-ST Timing Adapter (Bridges and Adapters\Streaming\)

 

FIFO необходимо сконфигурировать в режим Avalon-ST sink to Avalon-MM read slave.

 

В прграммном обеспечении созданной МПС необходимо также сконфигурировать созданный буфер FIFO при помощи On-Chip FIFO Memory API. Чтение данных из буфера, как я понял осуществляется функциями вида int altera_avalon_fifo_read_fifo().

К выходу FIFO в SOPC Builder в принципе можно цеплять обычный DMA Controller Core, как я понимаю для аппаратного захвата данных.

 

Документация на On-Chip FIFO Memory Core приведена в главе 16 Embedded Peripherals IP User Guide.

Документация на Clocked Video Input MegaCore Function в главе 10 Video and Image Processing Suite User Guide