Перейти к содержанию
    

edren_baton

Участник
  • Постов

    81
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о edren_baton

  • Звание
    Частый гость
    Частый гость

Посетители профиля

1 345 просмотров профиля
  1. Вот это поворот... Значит, если стоит берст = 16, то 2^16 = 65536 бит 65536 бит / 64 бит (ширина шины ddr) = 1024 1024 - максимальный берст, который поддерживает DDR3 контроллер и mSGDMA. А я все гадал, почему ж в обычном SGMDA максимальное значение берста = 16. Т.е. sgdma данные гоняет побитно, если берст выключен?
  2. Всем доброго времени суток! Столкнулся с проблемой повышенного использования блоков памяти со стороны SGDMA. В качестве примера привожу ST-MM, хотя справедливо и для других типов. Для теста создал два канала приема видео с одинаковой схемой подключения, данные из которых забираются при помощи SGDMA ST-MM. В одном случае (ch_1) параметр burst = 12, во втором (ch_2) burst = 16 (скрины ниже) Для burst=16 параметр Implementation bits возрастает аж в 16 раз по сравнению c burst = 12. В чем подвох?
  3. Всем доброго времени суток! У меня есть задача провести побайтные операции с двумя массивами данных в памяти (SDRAM или DDR3) и записать их в новую область памяти. Варианты исполнения такой функции (например, вычитание), написанные мною в "лоб" приведены ниже. Объявления переменных и т.п. опустил. В первом случае из памяти данные считываются побайтно и побайтно же записываются. Во втором считывается 4 байта, идет шаманство со сдвигами и запись результата как 4х байт. void difference(alt_u8* buffer1, alt_u8* buffer2, alt_u8* buffer3) { for (cntr = 0; cntr < 4; cntr++) { *buffer3 = *buffer2 - *buffer1 buffer1 = buffer1 + 1; buffer2 = buffer2 + 1; buffer3 = buffer3 + 1; } } void difference2(alt_u32* buffer1, alt_u32* buffer2, alt_u32* buffer3) { buf_1_1 = *buffer1; buf_1_2 = *buffer2; buf_2_1 = *buffer1 >> 8; buf_2_2 = *buffer2 >> 8; buf_3_1 = *buffer1 >> 16; buf_3_2 = *buffer2 >> 16; buf_4_1 = *buffer1 >> 24; buf_4_2 = *buffer2 >> 24; buf_1 = abs (buf_1_2 - buf_1_1); buf_2 = abs (buf_2_2 - buf_2_1); buf_3 = abs (buf_3_2 - buf_3_1); buf_4 = abs (buf_4_2 - buf_4_1); buf_0 = 0x00000000; buf_0 |= buf_4; buf_0 = buf_0 << 8; buf_0 |= buf_3; buf_0 = buf_0 << 8; buf_0 |= buf_2; buf_0 = buf_0 << 8; buf_0 |= buf_1; *buffer3 = buf_0; } Вопрос. Что из этого работает быстрее (в т.ч. с точки зрения обращения к памяти). Или же как по-другому адекватно проводить такие побайтные операции именно в Nios?
  4. По ходу освоения SGDMA возникают все новые вопросы =) Подцепил к своему проекту SGDMA ST-MM для записи видео в память. Есть желание сделать аналог Alpha Blending Mixer, а именно: задан некоторый буфер в sdram, который выполняет роль фона (размер 1000х1000). Через SGDMA ST-MM приходит видео поток (размер кадра 200х200) и его нужно разместить в левом верхнем углу. Как лучше сделать: - для каждой строки делать отдельный дескриптор с указанием размера транзакции и нужного начального адреса? - или создать новый малый буфер внутри первого с соответствующим переназначением адресов? Если второй вариант предпочтительнее, прошу немного пояснить синтаксис такого задания, ибо с указателями пока еще путаюсь =(
  5. Итак, разобрался я что у меня не работало - не объявил где лежат дескрипторы на SGDMA. Привожу рабочий вариант кода в надежде на то, что кому-то он поможет разобраться и не совершать моих ошибок. Догадываюсь, что он ни разу не оптимизирован (кое-что можно вынести в отдельную функцию), зато работает ))) Если кто-то из форумчан сделает его "по уму" - будет здорово. Код формирует три транзакции и выставляет SOP и EOP для каждой транзакции, т.е. получается три пакета. Отправка непрерывная. #include <stdio.h> #include "sys/alt_stdio.h" #include "io.h" #include "system.h" #include "unistd.h" #include <math.h> #include <altera_avalon_sgdma.h> #include <altera_avalon_sgdma_descriptor.h> #include <altera_avalon_sgdma_regs.h> // DMA descriptors alt_sgdma_descriptor* dmaDescA; alt_sgdma_descriptor* dmaDescEND; alt_sgdma_dev *dma; //DMA device // we locate our first framebuffer at the beginning of the SDRAM alt_u32* frameBufferA = (alt_u32*)ONCHIP_MEMORY2_0_BASE; void my_dma_callback(void *data) { // reset the OWNED_BY_HW bit in the descriptors to reuse the chain int i; for(i = 0; i < 3;++i) dmaDescA[i].control |= 1<<ALTERA_AVALON_SGDMA_DESCRIPTOR_CONTROL_OWNED_BY_HW_OFST; // trigger another transfer all over again alt_avalon_sgdma_do_async_transfer((alt_sgdma_dev*)data, dmaDescA); } int main() { dmaDescA = (alt_sgdma_descriptor*) ONCHIP_MEMORY2_BASE + 0xf00; dmaDescEND = (alt_sgdma_descriptor*) ONCHIP_MEMORY2_BASE; dma = alt_avalon_sgdma_open(SGDMA_0_NAME); // frame buffer alt_u8* buff; alt_u16 size; int i; for(i = 0; i < 3; ++i) { switch ( i ) { case 0: size = 0xa; buff = (alt_u8*)frameBufferA; break; case 1: size = 0x1; buff = (alt_u8*)frameBufferA; break; case 2: size = 0xff; buff = (alt_u8*)frameBufferA; break; } alt_avalon_sgdma_construct_mem_to_stream_desc( &dmaDescA[i], (i<3) ? (&dmaDescA[i+1]) : &dmaDescEND, (alt_u32*)buff, size, 0, 1, // sop 1, // eop 0); } alt_avalon_sgdma_register_callback( dma, my_dma_callback, ALTERA_AVALON_SGDMA_CONTROL_IE_CHAIN_COMPLETED_MSK |ALTERA_AVALON_SGDMA_CONTROL_IE_GLOBAL_MSK, (void*)dma); alt_avalon_sgdma_do_async_transfer(dma, dmaDescA);//start DMA transfer ; return 0; }
  6. По поводу Mixera. Так как в этом блоке нет изначально заданных размеров отдельных потоков, то перед основным пакетом с данными надо все-таки отправлять Control Packet. Попробовал в качестве эксперимента подключить сгдма к Clocked Video Output и к Video Sync Generator (между sgdma и блоком вывода еще avalon-st fifo). За основу брал рабочий проект. Так теперь блок sgdma или не заводится (открывается, но никакие данные не идут, смотрел через сигналтап) или заводится по какому-то непонятному алгоритму. В чем разница между подключениями к миксеру и синк генератору?
  7. Т.е. все модули Avalon-ST Sink должны сами распознавать размер и тип пакета? Если посмотреть сигналтапом, например, соединение Frame Buffer - Alpha Blending Mixer, то состав данных будет такой как я описал.
  8. Всем доброго времени суток! Учусь работать с модулем SGDMA MM-ST. Для начала просто вывожу квадрат инфы из памяти. Учитывая тот факт, что для формирования нормального кадра Avalon-ST необходимо перед кадром с информацией сначала отправить пакет Contol Packet, а потом в кадре с информацией первый байт выставить в 0, т.е: SOP -> Control Packet -> EOP -> SOP -> 1s_byte = 0 + Frame_data -> EOP для реализации пытаюсь в SGDMA сформировать три транзакции: 1. Control Packet 2. Один байт = 0 3. Сам кадр Инициализация и запуск SGDMA (часть) void init_and_start_framebuffer(alt_sgdma_dev *dma) { // frame buffer A alt_u8* buff; alt_u16 size; int i; for(i = 0; i < 3; ++i) { switch ( i ) { case 0: size = 0xa; buff = (alt_u8*)frameBufferA; break; case 1: size = 0x1; buff = (alt_u8*)frameBufferA + 0x10; break; case 2: size = 0x6400; buff = (alt_u8*)frameBufferA + 0x8 + 0x10; break; } alt_avalon_sgdma_construct_mem_to_stream_desc( &dmaDescA[i], (i<3) ? (&dmaDescA[i+1]) : &dmaDescEND, (alt_u32*)buff, size, 0, i==0 | i==1, // sop i==0 | i==2, // eop 0); } Байты для первых двух транзакций. int main() { IOWR(frameBufferA, 0, 0x0a00000f); IOWR(frameBufferA+1, 0, 0x0a000000); IOWR(frameBufferA+2, 0, 0x00000200); IOWR(frameBufferA+3, 0, 0x00000000); В первой транзакции (для Control Packet) ее размер (size) получается задать произвольно с кратностью 1 байт. Проблема заключается в том, что во второй транзакции не получается задать ее размер = 1 байту. Если задать size меньше 4, то считывается всегда 4 байта, если больше 4, то 8 байт и т.д. В текущей ситуации кадр формируется нормально, но первые три байта кадра оказываются равными нулю (т.к. в начале второй транзакции считывается 0х00000000). Подскажите, пожалуйста, как мне сформировать этот 0 в начале кадра? Или, может быть, я изобретаю велосипед и есть модуль, который можно поставить после SGDMA? P.S. Про существование Clocked Video Output, Frame Reader и Frame Buffer в курсе, работал с ними, нужен именно SGDMA =)
  9. Приветствую всех! После компиляции проекта в папке "Project_name/db" создается большое количество файлов с расширением *.cnf.cdb. Хелп альтеры говорит, что это Compiler Database File, но не указывает что с ним делать и почему он постоянно создается новый. Несмотря на то, что весят они мизерно, большое количество мусора в папке проекта напрягает. Можно ли в настройках квартуса это поправить? Может, посоветуете еще какие не очевидные настройки компиляции такого рода?
  10. Отвечаю на свой же вопрос. Video Sync Generator начинает генерировать заданные в настройках импульсы сразу после заливки прошивки в ПЛИС. Косяк в следующем: в Q13, в QSys настройки я задавал нужные мне, но компилировался модуль с дефолтными настройкам (хотя в QSys продолжали отображаться заданным мной). В Q11 все нормально.
  11. Приветствую всех! Пытаюсь разобраться с Video Sync Generator, ибо столкнулся со следующей проблемой: синхроимпульсы (VS,HS, DE), которые формирует и отправляет на монитор Video Sync Generator не соответствуют настройкам в QSys (импульсы идут, но длительности совсем другие, в том числе пропорционально). Отсюда вопрос: генератор выдает «правильную» (заданную через настройки) последовательность синхроимпульсов сразу после загрузки прошивки в ПЛИС? или только после правильной инициализации и управления модуля?
  12. Всем доброго времени суток! Ковыряюсь я сейчас с контроллером DDR3 для использования с памятью фирмы hynix. Использую ModelSim. Отлаживал схему на модели памяти, близкой по структуре, т.к. оригинальная модель от производителя адаптирована для VCS, моделсимом не подхватывается (тем более, что она encrypted). Решил скачать VCS, но ничего у меня не вышло. Все о нем пишут, а откуда берут - непонятно. На ftp.synopsys.com дистрибутива не увидел (видимо, из-за прав), пробовал зарегистрироваться на сайте, но там при регистрации просят Synopsys Site ID, который берется или из установленного софта, или от представителя фирмы. Обычное гугление тоже не помогло. Вот сижу я и думаю, то ли лыжи не едут, то ли что-то пропустил. Поэтому прошу помощи с получением VCS.
  13. Всем спасибо за ответы! Если Nios не будет успевать, то третий буфер позволит выводить не битые кадры, пусть и повторяющиеся. На пролете эт, конечно, хорошо. =) А как правильно подгрузить информацию о предыдущем кадре? Если потребуются более сложные функции, та же корреляция, например, не слишком ли жестоко будет руками на HDL писать? Через nios удобно управлять настройками отдельных блоков, так что совсем без него - тоже не очень ) Про 11.1 спасибо, но я 13й версией пользуюсь ) На моей памяти одна из самых стабильных была 9я версия, потом разом на 13ю перешел. Подскажите, пожалуйста, механизм подгрузки предыдущих пикселей. =) Все эт хозяйство идет на Clocked Video Output, а там на монитор.
  14. Всем доброго времени суток! Есть у меня задача: в видеосистеме реализовать межкадровое вычитание и результат этого вычитания выводить. По моим представлениям, для этого потребуется три буфера в памяти: 1. Предыдущий кадр 2. Текущий кадр 3. Результат вычитания (используется для обеспечения непрерывности вывода данных) На данный момент работает следующая система на шине Avalon-ST: Clocked Video Input >> Всякие фильтры >> Frame Buffer (данные во внешней памяти RAM) >> Clocked Video Output Есть мысли для решения применить SGDMA в следующем ключе: - после "Всякие фильтры" устанавливаем SGDMA (stream to memory). Им заполняем 2 буфера памяти (два разных кадра). - nios напрямую соединен с памятью, с его помощью происходит сравнение кадров и запись результата в 3й буфер. - затем стоит SGMDA (memory to stream) и FIFO с выводом на clocked video output. Есть ли смысл вместо этой связки (SGDMA и FIFO) использовать Frame Buffer (можно ли этим компонентом напрямую из памяти читать, убрав вход Avalon Sink)? Будет ли работать такая система? Насколько этот вариант оптимален? Прошу помощи в определении направления дальнейших действий.
×
×
  • Создать...