[acvarif 0]

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

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

[acvarif 0]

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

Наверное все же SG-DMA. Она в свою очередь подключается либо непосредственно к стрим источнику либо к нему же через fifo буфер. Все это нужно для перегрузки результатов работы (данные идут потоком через двухпортовую RAM) многоканального фильтра в комп посредством Ethernet. На один порт RAM поступают данные с фильтра, а другой порт подключен к стрим источнику. Стрим источник подан на sg-dma. SG-DMA в свою очередь должно загружать данные в SDRAM. Далее уже работает процессор. В SOPC вроде сделал систему. Но в ней много неясностей.

В частности пока не четко не представляю как выполнить диаграмму стрим источника

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

Edited August 27, 2012 by Acvarif

[ISK 0]

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

 

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

[acvarif 0]

У вас здесь же в настройках шины 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 6]

Сразу немного озадачило то, что в 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 0]

Ну наверно не по фронту 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, драйвер..)?

Edited August 28, 2012 by Acvarif

[alexPec 6]

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

 

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

Спасибо.

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

[acvarif 0]

Собрал систему с 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 на пользовательскую логику с памятью?

Edited September 2, 2012 by Acvarif

[alexPec 6]

 

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

[acvarif 0]

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

Спасибо. Понятно.

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

Ситуация такая, что я должен каждый последующий valid выставлять не раньше чем получу очередной ready.

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

Edited September 3, 2012 by Acvarif

[ISK 0]

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

 

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

 

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

 

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

[alexPec 6]

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

Если нет фифо - тогда нет гарантии что через каждые 100 нс шина будет свободна

[acvarif 0]

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

Теперь понял. Спасибо. Значит ready совсем не лишний. Для надежности его нужно все же использовать в автомате который готовит данные для sgdma.

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

Если нет фифо - тогда нет гарантии что через каждые 100 нс шина будет свободна

Да, спасибо. Добавлю фифо.

 

Инициализация почему-то не работает (пишет Failed to open receive channel)

// Размер буфера
#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?

Edited September 4, 2012 by Acvarif