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 принять данные. Т.е. если внутренняя шина, например, занята процессором в настоящий момент, то контроллер говорит этим сигналом что не может принять данные.