SG-DMA в режиме Stream To Memoy Опции

[Acvarif]

Есть необходимость перегружать кучу байт из пользовательской двухпортовой памяти в 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?

[barabek]

Прошу прощенья, немного не в тему. А Вам точно нужемн SGdma? Может можно обойтись просто DMA? Ресурсов тратится значительно меньше. И проще в освоении. Не знаю, какая у Вас пользовательская логика, но иногда можно вообще пойти своим путем и сделать свой dma модуль. Например как-то делал для UART, чтобы он писал в кольцевой буфер. Пишется нараз. Не стал в Вашуих картинках разбираться, но непонятно пока как вяжется двухпортовая память со stream? Память вроде как чистая MamoryMap.

[Acvarif]

Прошу прощенья, немного не в тему. А Вам точно нужемн 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

[ISK]

У меня данные с выхода двухпортовой памяти 16 бит. Очевидно по фронту сигнала Valid данные должны появиться на data, а далее сигнал Ready заберет их в SDRAM. Не понятно пока с разрядностью. Как в нескольких словах описать работу этой диаграммы? Почему в ней данные разбиты на 8 бит?

У вас здесь же в настройках шины Data Symbols Width = 8, symbols per beat = 2. Вот и разбиты данные на 8 бит. А вообще-то в Avalon Interface Specifications всё написано.

[Acvarif]

У вас здесь же в настройках шины 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, которые опять же должна формировать пользовательская логика?

[alexPec]

Сразу немного озадачило то, что в 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 - тоже всегда на земле был.

[Acvarif]

Ну наверно не по фронту 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

[alexPec]

Да, судя по диаграмме - по спаду клока.

Пробовал создать конфигурацию системы в 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));
}

За базу взят а инициализация дисплея из сэмплов альтеры, может еще чего допилил - точно не помню...

Эскизы прикрепленных изображений

 

[Acvarif]

Спасибо.
Попробую разобраться.

[Acvarif]

Собрал систему с 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

[alexPec]

В мануале же все написано. Реди - это сигнал готовности SGDMA принять данные. Т.е. если внутренняя шина, например, занята процессором в настоящий момент, то контроллер говорит этим сигналом что не может принять данные.

[Acvarif]

В мануале же все написано. Реди - это сигнал готовности SGDMA принять данные. Т.е. если внутренняя шина, например, занята процессором в настоящий момент, то контроллер говорит этим сигналом что не может принять данные.

Спасибо. Понятно.
Значит механизм примерно такой: Из пользовательской логики на шину (на SGDMA) поступает сигнал valid который сообщает о том что данные готовы поступить на шину. Далее пользовательская логика ждет от SGDMA сигнала ready (сообщает пользовательсой логике, что шина готова принять данные). По приходу ready пользовательская логика выставляет данные на data , которые по клоку будут посредством SGDMA переброшены в SDRAM.
Ситуация такая, что я должен каждый последующий valid выставлять не раньше чем получу очередной ready.
Поскольку у меня каждый последующий valid отстоит от предыдущего примерно на 100 нс и я не жду ready то вполне может быть ситуация когда SGDMA какие-то данные может пропускать. Так ли это? Или 100 нс для SGDMA это вполне приемлимо?

Сообщение отредактировал Acvarif - Sep 3 2012, 07:48

[ISK]

По приходу ready пользовательская логика выставляет данные на data , которые по клоку будут посредством SGDMA переброшены в SDRAM.

Данные должны подаваться на шину вместе с сигналом "Valid". По приходу "Ready" вы можете выставить на шину новые данные или снять сигнал "Valid". Все сигналы тактируются передним фронтом clk.

Поскольку у меня каждый последующий valid отстоит от предыдущего примерно на 100 нс и я не жду ready то вполне может быть ситуация когда SGDMA какие-то данные может пропускать. Так ли это? Или 100 нс для SGDMA это вполне приемлимо?

Никакой гарантии здесь скорее всего нет. Всё зависит от построения системы, тактовой частоты, загруженности шины и т.д.. Лучше, на мой взгляд, использовать дополнительный фифо.

[alexPec]

Если есть фифо - то 100нс конечно не проблема ( при тактовой, например >40MHz). Если переполнится фифо - то тут бороться либо увеличением тактовой, либо увеличением фифо (при пакетном режиме). В случае сплошного потока увеличение фифо не поможет.
Если нет фифо - тогда нет гарантии что через каждые 100 нс шина будет свободна

[Acvarif]

Данные должны подаваться на шину вместе с сигналом "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

[Acvarif]

Виноват. Ошибка вышла. Попутал sgdma и dma.
Пытаюсь запустить sgdma

CODE

// открыть sgdma
alt_sgdma_dev * receive_DMA = alt_avalon_sgdma_open("/dev/sgdma_0");
if(receive_DMA == NULL)
{
printf("Could not open the receive SG-DMA\n");
}
else printf("Open the receive SG-DMA... success\n");

// определение подпрограммы обработчика прерываний
alt_avalon_sgdma_register_callback(receive_DMA,
&receive_callback_function,
(ALTERA_AVALON_SGDMA_CONTROL_IE_GLOBAL_MSK |
ALTERA_AVALON_SGDMA_CONTROL_IE_CHAIN_COMPLETED_MSK),
NULL);

эта часть работает
Я так понимаю, что далее нужно определить alt_sgdma_descriptor где будут определены все
необходимые параметры для приема данных (куда помещать данные, размер буфера...). И далее уже можно делать запуск типа

Код

alt_avalon_sgdma_do_async_transfer(receive_DMA, &receive_descriptors);

В этом совсем запутался.
Подскажите пожалуйста как правильно описать alt_sgdma_descriptor.
Пока так и не врубился в последовательность операций для одной транзакции по заполнению буфера.
Как все происходит в нескольких словах? Что делать когда буфер заполнен? Куда помещать следующий пакет с данными?
Ответьте пожалуйста кому не лень.

[alexPec]

Штатными функциями все делается. (с небольшим допиливанием)

Код

// 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

Код

void setup_adc_descriptors(
alt_video_display *display,
alt_video_frame *frame,
alt_u32 *buffer,
alt_sgdma_descriptor *desc_base)
{
int i;
alt_u16 length;
alt_32 buffer_no_cache_bypass;
alt_sgdma_descriptor *last_descriptor;

/*
  * We don't want the "uncached" bit set in the buffer address we hand
  * off to the SGDMA, so we mask it out here.
  */
buffer_no_cache_bypass =
   (alt_u32) alt_remap_cached(buffer, display->bytes_per_frame );

for(i=0; i<display->descriptors_per_frame; i++){
   /*
    * Calculate the data length associated with each descriptor, taking
    * into account the edge cases
    */
   if(i == (display->descriptors_per_frame-1)) {
     length = (display->bytes_per_frame % ALT_VIDEO_DISPLAY_BYTES_PER_DESC);

      /*
       * The init routine calculated the number of desriptors per frame,
       * based on frame size (bytes) and bytes per descriptor. Being evenly
       * divisible on this last frame means a full-length sized frame.
       */
      if(length == 0) {
        length = ALT_VIDEO_DISPLAY_BYTES_PER_DESC;
      }
   }
   else {
     length = ALT_VIDEO_DISPLAY_BYTES_PER_DESC;
   }

   /* Construct the descriptor */
   [b]alt_avalon_sgdma_construct_stream_to_mem_desc(
     (frame->desc_base + i),                    /* Descriptor */
     ( frame->desc_base + i + 1 ),              /* Next descriptor */
     (alt_u32*)( (alt_u8*)buffer_no_cache_bypass +
        (ALT_VIDEO_DISPLAY_BYTES_PER_DESC*i) ), /* Write Address */
     length,                                    /* Transfer length */
     0                                         /* Don't write fixed addr */
    );[/b]

   /*
    * The last descriptor we created above requires a special modification:
    * Its "next" pointer should point back to the first descriptor in the
    * chain to create a loop.
    *
    * This was not done done in the above SGDMA descriptor creation routine
    * call because that routine always terminates the 'next' descriptor
    * pointer to prevent the SGDMA from continuing into unknown memory.
    */
   if( i == ( display->descriptors_per_frame - 1 ) ) {
     last_descriptor = (alt_sgdma_descriptor *) (frame->desc_base + i);

//     IOWR_32DIRECT((alt_u32)(&last_descriptor->next), 0,
//       (alt_u32)(frame->desc_base));
   }
}
}

По транзакциям - запускаете sgdma, он ждет данные (по первому дескриптору), т.е. данные приходят (количество байт указываете при создании каждого дескриптора) - он их записывает по адресам, начиная с WriteAddress. Когда примет и запишет заданное кол-во байт - либо останавливается (зависит от битика вроде в регистре control, точно не помню), либо переходит к следующему дескриптору автоматоматом - т.е. ждет следующую порцию байт и записывает их по write adress дескриптора. Если остановился - то надо запустить след. транзакцию функцией.

Ну уж а куда распихивать - сами думайте. ДМА записывает данные которые приходят в память, которую вы указываете в дескрипторе, как организовать потом обработку (т.е. куда девать данные) - вам решать. Пока дма "знает" куда деть данные (т.е. пока дескрипторы не закончились и количество байт, указанное в дескрипторе не пришло) сигнал ready активен, как только пришел последний байт последнего дескриптора (дескрипторы закончились) - сигнал ready стает неактивен.