|
|
  |
SG-DMA в режиме Stream To Memoy |
|
|
|
Aug 25 2012, 07:49
|
Знающий
   
Группа: Участник
Сообщений: 998
Регистрация: 27-08-08
Пользователь №: 39 850

|
Есть необходимость перегружать кучу байт из пользовательской двухпортовой памяти в SDRAM+NIOS. Для этой цели в пользовательсой логике имеются импульсы периодом ~ 100 нс по фронтам которых предполагается организовать пересылку данных (16 бит) в SDRAM. Далее все компонуется и по Ethernet должно идти далее в комп. Для этого попытался сворганить в SOPC SG-DMA (Stream To Memory) + Avalon Straming Source. Получил непонятные ошибки. Разрядность нин в SG-DMA и Avalon Straming Source поставил 16 бит.
Подскажите пожалуйста как правильно. Пробовал по разному (менял оличество бит источника приемника и др.) Не получается. Помог бы простой пример реализации в SOPC подобной схемы. Нужен ли для этой цели еще и FIFO? Или можно будет обойтись только Avalon Straming Source+пользовательская логика полагаясь на внутреннюю FIFO SG-DMA?
|
|
|
|
|
Aug 27 2012, 09:23
|
Знающий
   
Группа: Участник
Сообщений: 998
Регистрация: 27-08-08
Пользователь №: 39 850

|
Цитата(barabek @ Aug 27 2012, 01:48)  Прошу прощенья, немного не в тему. А Вам точно нужемн SGdma? Может можно обойтись просто DMA? Ресурсов тратится значительно меньше. И проще в освоении. Не знаю, какая у Вас пользовательская логика, но иногда можно вообще пойти своим путем и сделать свой dma модуль. Например как-то делал для UART, чтобы он писал в кольцевой буфер. Пишется нараз. Не стал в Вашуих картинках разбираться, но непонятно пока как вяжется двухпортовая память со stream? Память вроде как чистая MamoryMap. Наверное все же SG-DMA. Она в свою очередь подключается либо непосредственно к стрим источнику либо к нему же через fifo буфер. Все это нужно для перегрузки результатов работы (данные идут потоком через двухпортовую RAM) многоканального фильтра в комп посредством Ethernet. На один порт RAM поступают данные с фильтра, а другой порт подключен к стрим источнику. Стрим источник подан на sg-dma. SG-DMA в свою очередь должно загружать данные в SDRAM. Далее уже работает процессор. В SOPC вроде сделал систему. Но в ней много неясностей.
В частности пока не четко не представляю как выполнить диаграмму стрим источника
У меня данные с выхода двухпортовой памяти 16 бит. Очевидно по фронту сигнала Valid данные должны появиться на data, а далее сигнал Ready заберет их в SDRAM. Не понятно пока с разрядностью. Как в нескольких словах описать работу этой диаграммы? Почему в ней данные разбиты на 8 бит?
Сообщение отредактировал Acvarif - Aug 27 2012, 09:24
|
|
|
|
|
Aug 28 2012, 06:11
|
Участник

Группа: Свой
Сообщений: 59
Регистрация: 9-06-05
Из: Киев
Пользователь №: 5 857

|
Цитата(Acvarif @ Aug 27 2012, 12:23)  У меня данные с выхода двухпортовой памяти 16 бит. Очевидно по фронту сигнала Valid данные должны появиться на data, а далее сигнал Ready заберет их в SDRAM. Не понятно пока с разрядностью. Как в нескольких словах описать работу этой диаграммы? Почему в ней данные разбиты на 8 бит? У вас здесь же в настройках шины Data Symbols Width = 8, symbols per beat = 2. Вот и разбиты данные на 8 бит. А вообще-то в Avalon Interface Specifications всё написано.
|
|
|
|
|
Aug 28 2012, 10:59
|
Знающий
   
Группа: Участник
Сообщений: 998
Регистрация: 27-08-08
Пользователь №: 39 850

|
Цитата(ISK @ Aug 28 2012, 09:11)  У вас здесь же в настройках шины Data Symbols Width = 8, symbols per beat = 2. Вот и разбиты данные на 8 бит. А вообще-то в Avalon Interface Specifications всё написано. Сразу немного озадачило то, что в SGDMA Symbols Width всегда только 8 бит. Пришлось Источник подстраивать под эту Data Symbols Width. По поводу диаграммы: Как теперь построить автомат передачи данных в SGDMA? По диаграмме получается, что по фронту valid (который должна формировать моя пользовательская логика) нужно, чтобы все 16 бит данных из RAM появились на data. Я так понимаю, что в свою очередь по фронту сигнала ready (который будет исходить от SGDMA) данные из data будут посредством SGDMA помещены в SDRAM NIOS. Все произойдет за 2 такта clk. При этом непонятно в каком состоянии должны быть линии startofpacket, endofpacket, empty, которые опять же должна формировать пользовательская логика?
|
|
|
|
|
Aug 28 2012, 12:09
|
Профессионал
    
Группа: Свой
Сообщений: 1 284
Регистрация: 9-04-06
Пользователь №: 15 968

|
Цитата(Acvarif @ Aug 28 2012, 14:59)  Сразу немного озадачило то, что в SGDMA Symbols Width всегда только 8 бит. Пришлось Источник подстраивать под эту Data Symbols Width. По поводу диаграммы: Как теперь построить автомат передачи данных в SGDMA? По диаграмме получается, что по фронту valid (который должна формировать моя пользовательская логика) нужно, чтобы все 16 бит данных из RAM появились на data. Я так понимаю, что в свою очередь по фронту сигнала ready (который будет исходить от SGDMA) данные из data будут посредством SGDMA помещены в SDRAM NIOS. Все произойдет за 2 такта clk. При этом непонятно в каком состоянии должны быть линии startofpacket, endofpacket, empty, которые опять же должна формировать пользовательская логика? Ну наверно не по фронту valid и ready, а при единице на этих сигналах по фронту клока все таки. Там все по фронту клока защелкивается. Была похожая задача - SOP и EOP вообще не использовал, empty - тоже всегда на земле был.
|
|
|
|
|
Aug 28 2012, 12:31
|
Знающий
   
Группа: Участник
Сообщений: 998
Регистрация: 27-08-08
Пользователь №: 39 850

|
Цитата(alexPec @ Aug 28 2012, 15:09)  Ну наверно не по фронту valid и ready, а при единице на этих сигналах по фронту клока все таки. Там все по фронту клока защелкивается. Да, судя по диаграмме - по спаду клока. Цитата Была похожая задача - SOP и EOP вообще не использовал, empty - тоже всегда на земле был. Пробовал создать конфигурацию системы в SOPC без SOP, EOP, empty - не получалось (видно на картинке в самом начале этой темы). В смысле пытался создать компонент Typical Avalom Source без SOP, EOP, empty. Не стыковалось потому, как в SGDMA SOP, EOP, empty никак не отключаются. Или я чего-то недопонял. Как все-же сделать систему без SOP, EOP, empty? Или SOP, EOP, empty просто присутствуют в компоненте Avalom Source но никак не задействуются? Можно пример из Вашей задачи (SOPC, драйвер..)?
Сообщение отредактировал Acvarif - Aug 28 2012, 12:33
|
|
|
|
|
Aug 28 2012, 19:11
|
Профессионал
    
Группа: Свой
Сообщений: 1 284
Регистрация: 9-04-06
Пользователь №: 15 968

|
Цитата(Acvarif @ Aug 28 2012, 16:31)  Да, судя по диаграмме - по спаду клока.
Пробовал создать конфигурацию системы в SOPC без SOP, EOP, empty - не получалось (видно на картинке в самом начале этой темы). В смысле пытался создать компонент Typical Avalom Source без SOP, EOP, empty. Не стыковалось потому, как в SGDMA SOP, EOP, empty никак не отключаются. Или я чего-то недопонял. Как все-же сделать систему без SOP, EOP, empty? Или SOP, EOP, empty просто присутствуют в компоненте Avalom Source но никак не задействуются? Можно пример из Вашей задачи (SOPC, драйвер..)? У меня проект большой, вытащить кусок проблемно, с отдать целиком права не имею  . Могу скриншот сделать участка схемы с SGDMA сопца (собстно сделал). Тут фифо снаружи, логика вот была для чего: чтоб прочитать из фифо все наверняка (пакетный режим), то когда заканчивается фифо, все равно генерируется сигнал datavalid, а в программе читаю больше на 2 байта чем длина пакета. Даже если в одном пакете потерялся (или образовался каким-то чудом) один байт - синхронизация поставщика данных и считывателя данных не сбивалась. Сумбурно, но этот узел родился в муках, без него иногда(очень редко) начиналось такое: первый байт - старого пакета, затем новый пакет без последнего байта. И так пока ресет не дернешь. Долго поймать не мог этот момент, потом плюнул, сделал так и все ок. Код инициализации тоже прицепляю. Инициализация: Код adc_dma=adc_dma_init ( "/dev/sgdma_0", // char* sgdma_name 580,/*1106-для qam, 60000 - для ацп*/ // int width 1, // int height 8, // int color_depth -1, // int buffer_location (malloc buffers) -1, // int descriptor_location (malloc descriptors) 4, (alt_avalon_sgdma_callback)&qam_recive_int); //4-для qam, 1-для ацп // int num_buffer И сама процедура инита: Код alt_video_display* adc_dma_init( char* sgdma_name, int width, int height, int color_depth, int buffer_location, int descriptor_location, int num_buffers, alt_avalon_sgdma_callback callbck)//////////////290811 { alt_video_display* display; unsigned int bytes_per_pixel, bytes_per_frame, descriptors_per_frame, i; int result;
// We'll need these values more than once, so let's pre-calculate them. bytes_per_pixel = color_depth >> 3; // same as /8 bytes_per_frame = (( width * height ) * bytes_per_pixel );
// Calculate the number of descriptors needed for each frame if( bytes_per_frame <= ALT_VIDEO_DISPLAY_BYTES_PER_DESC ) { descriptors_per_frame = 1; } else if(( bytes_per_frame % ALT_VIDEO_DISPLAY_BYTES_PER_DESC) == 0) { descriptors_per_frame = bytes_per_frame / ALT_VIDEO_DISPLAY_BYTES_PER_DESC; } else { descriptors_per_frame = ( bytes_per_frame / ALT_VIDEO_DISPLAY_BYTES_PER_DESC ) + 1; }
// Check for too many frame buffers if( num_buffers > ALT_VIDEO_DISPLAY_MAX_BUFFERS ) { num_buffers = ALT_VIDEO_DISPLAY_MAX_BUFFERS; }
// Allocate our display struct display = (alt_video_display*) malloc(sizeof(alt_video_display)); if(!display) { return NULL; }
// Fill out the display structure display->width = width; display->height = height; display->color_depth = color_depth; display->num_frame_buffers = num_buffers; display->bytes_per_frame = bytes_per_frame; display->bytes_per_pixel = bytes_per_pixel; display->buffer_being_displayed = 0; display->buffer_being_written = (num_buffers > 1) ? 1:0; display->descriptors_per_frame = descriptors_per_frame;
// Allocate our frame and descriptor buffers if(alt_video_display_allocate_buffers( display, bytes_per_frame, buffer_location, descriptor_location, num_buffers ) ) { return NULL; }
// Now construct SGDMA descriptors for each frame buffer for( i = 0; i < num_buffers; i++ ) { setup_adc_descriptors( display, // our display display->buffer_ptrs[i], // frame display->buffer_ptrs[i]->buffer, // frame location display->buffer_ptrs[i]->desc_base ); // descriptor memory }
// Clear all frame buffers to black for( i = 0; i < num_buffers; i++ ) { memset( (void*)(display->buffer_ptrs[i]->buffer), 0, display->bytes_per_frame ); }
// Open the SGDMA display->sgdma = alt_avalon_sgdma_open(sgdma_name); if(!display->sgdma) { return NULL; }
/////////////////////290811////////////////////////// alt_avalon_sgdma_register_callback( display->sgdma, callbck, (alt_u16)ALTERA_AVALON_SGDMA_CONTROL_IE_GLOBAL_MSK|ALTERA_AVALON_SGDMA_CONTROL_IE_CHA IN_COMPLETED_MSK, (void*)(display));
/////////////////////////////////////////////////////
/* Enable SGDMA "parking" mode */ IOWR_ALTERA_AVALON_SGDMA_CONTROL(SGDMA_0_BASE, ALTERA_AVALON_SGDMA_CONTROL_PARK_MSK);
/* Now start the SGDMA */ result = alt_avalon_sgdma_do_async_transfer( display->sgdma, display->buffer_ptrs[display->buffer_being_displayed]->desc_base);
if(result) { return NULL; }
return ( display ); } Рестарт(запуск чтения нового пакета: Код unsigned char adc_dma_restart(alt_video_display *display) { // while (IORD_ALTERA_AVALON_SGDMA_STATUS(display->sgdma->base) & ALTERA_AVALON_SGDMA_STATUS_BUSY_MSK); /* Enable SGDMA "parking" mode */ if (!(IORD_ALTERA_AVALON_SGDMA_STATUS(display->sgdma->base) & ALTERA_AVALON_SGDMA_STATUS_BUSY_MSK)) IOWR_ALTERA_AVALON_SGDMA_CONTROL(SGDMA_0_BASE, ALTERA_AVALON_SGDMA_CONTROL_PARK_MSK);
/* Now start the SGDMA */ return( alt_avalon_sgdma_do_async_transfer( display->sgdma, display->buffer_ptrs[display->buffer_being_displayed]->desc_base)); } За базу взят а инициализация дисплея из сэмплов альтеры, может еще чего допилил - точно не помню...
Эскизы прикрепленных изображений
|
|
|
|
|
Sep 2 2012, 15:46
|
Знающий
   
Группа: Участник
Сообщений: 998
Регистрация: 27-08-08
Пользователь №: 39 850

|
Собрал систему с SGDMA, но без FIFO в надежде на внутренее FIFO SGDMA
Для теста сформировал данные которые появляются на aso_out0_data при появлении фронта на aso_out0_valid
Я так понимаю что сигналы aso_out0_startofpacket, aso_out0_endofpacket, aso_out0_empty можно вообще не задействовать. Но совсем не понятна роль сигнала aso_out0_readyПолагал, что он нужен со стороны SGDMA для переброски подготовленных данных из пользовательской прамяти на aso_out0_data. Но в моем случае данные из пользовательской памяти и без того уже присутствуют на aso_out0_data по каждому фронту aso_out0_valid тесть на входе SGDMA. Какая же теперь роль сигнала aso_out0_ready который поступает из SGDMA на пользовательскую логику с памятью?
Сообщение отредактировал Acvarif - Sep 2 2012, 15:49
|
|
|
|
|
Sep 3 2012, 07:46
|
Знающий
   
Группа: Участник
Сообщений: 998
Регистрация: 27-08-08
Пользователь №: 39 850

|
Цитата(alexPec @ Sep 3 2012, 08:56)  В мануале же все написано. Реди - это сигнал готовности SGDMA принять данные. Т.е. если внутренняя шина, например, занята процессором в настоящий момент, то контроллер говорит этим сигналом что не может принять данные. Спасибо. Понятно. Значит механизм примерно такой: Из пользовательской логики на шину (на SGDMA) поступает сигнал valid который сообщает о том что данные готовы поступить на шину. Далее пользовательская логика ждет от SGDMA сигнала ready (сообщает пользовательсой логике, что шина готова принять данные). По приходу ready пользовательская логика выставляет данные на data , которые по клоку будут посредством SGDMA переброшены в SDRAM. Ситуация такая, что я должен каждый последующий valid выставлять не раньше чем получу очередной ready. Поскольку у меня каждый последующий valid отстоит от предыдущего примерно на 100 нс и я не жду ready то вполне может быть ситуация когда SGDMA какие-то данные может пропускать. Так ли это? Или 100 нс для SGDMA это вполне приемлимо?
Сообщение отредактировал Acvarif - Sep 3 2012, 07:48
|
|
|
|
|
Sep 3 2012, 11:00
|
Участник

Группа: Свой
Сообщений: 59
Регистрация: 9-06-05
Из: Киев
Пользователь №: 5 857

|
Цитата По приходу ready пользовательская логика выставляет данные на data , которые по клоку будут посредством SGDMA переброшены в SDRAM. Данные должны подаваться на шину вместе с сигналом "Valid". По приходу "Ready" вы можете выставить на шину новые данные или снять сигнал "Valid". Все сигналы тактируются передним фронтом clk. Цитата Поскольку у меня каждый последующий valid отстоит от предыдущего примерно на 100 нс и я не жду ready то вполне может быть ситуация когда SGDMA какие-то данные может пропускать. Так ли это? Или 100 нс для SGDMA это вполне приемлимо? Никакой гарантии здесь скорее всего нет. Всё зависит от построения системы, тактовой частоты, загруженности шины и т.д.. Лучше, на мой взгляд, использовать дополнительный фифо.
|
|
|
|
|
Sep 4 2012, 06:14
|
Знающий
   
Группа: Участник
Сообщений: 998
Регистрация: 27-08-08
Пользователь №: 39 850

|
Цитата Данные должны подаваться на шину вместе с сигналом "Valid". По приходу "Ready" вы можете выставить на шину новые данные или снять сигнал "Valid". Все сигналы тактируются передним фронтом clk. Теперь понял. Спасибо. Значит ready совсем не лишний. Для надежности его нужно все же использовать в автомате который готовит данные для sgdma. Цитата Если есть фифо - то 100нс конечно не проблема ( при тактовой, например >40MHz). Если переполнится фифо - то тут бороться либо увеличением тактовой, либо увеличением фифо (при пакетном режиме). В случае сплошного потока увеличение фифо не поможет. Если нет фифо - тогда нет гарантии что через каждые 100 нс шина будет свободна Да, спасибо. Добавлю фифо. Инициализация почему-то не работает (пишет Failed to open receive channel) CODE // Размер буфера #define BUFFER_SIZE 1168 int i;
alt_dma_rxchan rxchan; unsigned char *rx_buffer = (void*)BUFFER_SIZE;
// обнуление приемника for(i = 0; i < BUFFER_SIZE; i++) { rx_buffer[i] = 0; }
/* Create the receive channel */ if ((rxchan = alt_dma_rxchan_open("/dev/sgdma_0")) == NULL) { printf ("Failed to open receive channel\n"); } else printf ("Open receive channel.. success\n"); alt_dma_rxchan_ioctl(rxchan, ALT_DMA_SET_MODE_8, 0); Кому не сложно ответить, еще вопрос. Как сообщения типа printf ("Failed to open receive channel\n"); выводить не на реальный UART, а на консоль NIOs II IDE?
Сообщение отредактировал Acvarif - Sep 4 2012, 10:57
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|