[Jack_of_Shadows 0]

у вас 64 битная linux система или 32?

64 бита.

Еще в FIFO_ID старшие четыре бита (значение TYPE) равны 3, хотя как написано здесь может быть 1 (если на чтение) и 2 (если на запись)

[dsmv 0]

64 бита.

Еще в FIFO_ID старшие четыре бита (значение TYPE) равны 3, хотя как написано здесь может быть 1 (если на чтение) и 2 (если на запись)

 

FIDO_ID правильное, 3 - это двунаправленный контроллер. Предыдущии версии были однонаправленными.

 

 

Значение FIFO_STATUS 0xA000 - неправильное -должен быть установлен бит DSC_CORRECT (т.е. 0xA100) - это означает, что блок дескрипторов прочитан неправильно.

 

Здесь два варианта - что неправильно в драйвере или в прошивке ПЛИС. Пришлите Ваш проект, надо посмотреть как он развёлся. Может что увижу.

 

P.S. Сейчас видно одно из преимуществ контроллера. Блок дескрипторов защищён контрольной суммой. Сейчас есть какая то ошибка и контроллер просто останавливается. Если бы контроля CRC не было, то компьютер бы просто завис.

[v.karak 0]

FIDO_ID правильное, 3 - это двунаправленный контроллер. Предыдущии версии были однонаправленными.

 

 

Значение FIFO_STATUS 0xA000 - неправильное -должен быть установлен бит DSC_CORRECT (т.е. 0xA100) - это означает, что блок дескрипторов прочитан неправильно.

 

Здесь два варианта - что неправильно в драйвере или в прошивке ПЛИС. Пришлите Ваш проект, надо посмотреть как он развёлся. Может что увижу. Пришлите сюда: dsmv@ mail.ru

 

P.S. Сейчас видно одно из преимуществ контроллера. Блок дескрипторов защищён контрольной суммой. Сейчас есть какая то ошибка и контроллер просто останавливается. Если бы контроля CRC не было, то компьютер бы просто завис.

 

Точно, не 0xA001 а 0xA100. Посмотрел сейчас на работающем приборе. dsmv спасибо за коррекцию.

[Jack_of_Shadows 0]

karak,

мне советовали по поводу проги к вам обращаться: на 32-битном линуксе обмен таки пошёл. На х64 она вообще тестировалась до меня, или 64-битные адреса она не может обрабатывать априори?

Данные пока принимает так (первый запуск программы):

Result of receiving data from tetrade 6 
   0  Block: 0     Index: 00000000  Waiting: 00000000A5A50123  Received: 0000000000000000 
   1  Block: 0     Index: 00000002  Waiting: 0000000000000002  Received: 0000000000000003 
   ...
  30  Block: 0     Index: 0000001F  Waiting: 0000000040000000  Received: 000000007FFFFFFF 
  31  Block: 0     Index: 00000020  Waiting: 0000000080000000  Received: 00000000FFFFFFFF

Начиная со второго запуска принимаемые данные везде равны 0x1234567812345678, т.е. равны значению по умолчанию.

После нескольких запусков память перестает выделяться, пишет core_alloc(): Error allocate memory. Также в системном мониторе видно что память, выделенная программой, не освобождается - занятый объем ОЗУ возрастает при запуске программы, и остается на том же уровне при выходе из ней по ctrl-C. Как с этим можно бороться?

 

upd: с освобождением памяти разобрался, функция освобождения была, но её никто не вызывал почему то.

Изменено 22 января, 2013 пользователем Jack_of_Shadows

[v.karak 0]

В функции ошибка, из за которой всегда данные вводились из тетрады MAIN. Нужно 0 заменить на addr :) Про 64-битную систему сказать пока не могу, так как нет под руками. Вообще-то запускалось и кажется работало.

 

u32 pex_board::core_set_local_addr(int DmaChan, u32 addr)

{

AMB_SET_DMA_CHANNEL DmaParam;

DmaParam.DmaChanNum = DmaChan;

DmaParam.Param = addr;

 

if(m_Descr[DmaChan])

{

if (0 > ioctl(fd, IOCTL_AMB_SET_SRC_MEM, &DmaParam)) {

fprintf(stderr, "%s(): Error set source for DMA\n", __FUNCTION__ );

return -1;

}

}

 

return 0;

}

 

[Jack_of_Shadows 0]

Всё руки не доходили написать по поводу 64-битного линукса: было замечено что дело не только в нём (на одном компьютере проект работал, на втором нет), и единственное бросающееся в глаза различие было в том, что при выделении памяти разрядность адреса была разная - на компе где обмен не шёл память выделялась за границами 32-битной области. Поборол принудительным ограничением в драйвере, в функции RequestMemory:

dma_set_coherent_mask(dma->m_dev, 0xFFFFFFFF);

после чего адреса стали 32-битными и DMA-обмен пошел. После исправления из предыдущего поста стали отвечать те тетрады которые и должны. Вообщем проект вполне себе нормально работает с 200 МБ/с на x1.

[StrangerX 0]

Доброго времени суток.

Пытаюсь запустить ваше ядро pcie_core64_m1 (m2) на своей плате.

Вроде бы разобрался частично, но остались вопросы.

Прошу мне помочь.

 

1. При записи в адреса PE_EXT_FIFO, не содержащие регистров, дальнейшее чтение из правильных регистров невозможно (всегда получаю FFFFF...) это не существенно, вопрос в том, нормальное ли это поведение контроллера.

2. В wiki написано:

*Составить цепочку дескрипторов, которая описывает цепочку передаваемых блоков

*Записать адрес начального дескриптора в регистр PCI_ADRL

*Записать локальный адрес в регистр LOCAL_ADR

Модификация 1 - только режим автоинициализации

 

Я пытаюсь набросать драйвер под Win7. Что это для меня значит?

Как мне составить дескрипторы?

Выделить 64*8 байт область памяти, заполнить её в соответствии с описанием "Дескриптор блока автоинициализации";

в PCI_ADRL записать адрес этого блока;

в LOCAL_ADR адрес, относительно которого на LC шине будут запросы DMA на передачу/прием данных.

 

Прошу помощи.

 

[StrangerX 0]

И ещё ничего не понял про NEXT_BLOCK.

 

Как я понял, в памяти PCI, что отображена в оперативную создаю структуру 64*8 байтов - это и есть блок дескрипторов.

Допустим у меня 8192 байт, выделяется три куска памяти по 4096, 1712, 2384.

Я создаю блок дескрипторов:

1. - адрес блока 1, команда JUMP_NEXT_BLOCK, размер(4096), направление передачи

2. - адрес блока 2, команда JUMP_NEXT_BLOCK, размер(1712), направление передачи

3. - адрес блока 3, команда EOT, размер(2384), направление передачи

 

Поясните, чем отличается JUMP_NEXT_DS от JUMP_NEXT_BLOCK и что делать с NEXT_BLOCK, какой писать адрес и как считать CRC.

 

Спасибо заранее.

 

[dsmv 0]

В памяти компьютера создаётся блок 64*8=512 байт - это блок дескрипторов.

 

Каждый дескриптор - это четыре байта: описание здесь: http://src.ds-dev.ru/doc/core/block_pe_ext_fifo.htm

 

Блок содержит 63 дескриптора и указатель на следующий блок. Что будет происходить после завершения обмена с текущим блоком определяют три бита в поле CMD. Может быть установлен один из них, либо все нули.

 

Если все нули - то канал DMA остановиться.

 

Если JUMP_NEST_DS=1, то произойдёт переход к следующему дескриптору в этом блоке.

 

Если JUMP_NEXT_BLOCK=1, то произойдёт переход к следующему блоку (при этом следующий дескритор содержит адрес следующего блока). Это бит может быть установлен у любого дескриптора. Т.е. не обязательно заполнять все 63 элемента, оставшиеся можно заполнить нулями.

 

Если JUMP_DS0=1, то произойдёт переход к нулевому дескриптору в текущем блоке. Это позволяет не читать блоки дескрипторов из памяти.

 

Обратите внимание - обмен всегда ведётся блоками кратными 4 кбайтам. А при выделении памяти в USER MEMORY - так и просто по 4 килобайта. Если выделено три блока памяти (допустим по 4096 байт), то нужно создать один блок дескрипторов размером 512 байт.

 

1. адрес блока 1, команда *JUMP_NEST_DS*, размер(4096), направление передачи

 

2. адрес блока 2, команда *JUMP_NEST_DS*, размер(4096), направление передачи

 

3. адрес блока 3, команда *EOT*, размер(4096), направление передачи

 

Остальные дескрипторы - нули. В конце надо записать сигнатуру и контрольную сумму.

 

Прерывание будет получено после завершения обмена с блоком 3. P.S. Направление передачи всегда одно и то же для одного сеанса работы.

 

По поводу расчёта CRC - постараюсь выделить кусок программы, но чуть позже.

 

По поводу записи в PE_EXT_FIFO и чтении FF. Интересное наблюдение. Я таких экспериментов не ставил, но вроде бы такого быть не должно. А для записи используются 32-х разрядные команды ?

[StrangerX 0]

По поводу записи в PE_EXT_FIFO и чтении FF. Интересное наблюдение. Я таких экспериментов не ставил, но вроде бы такого быть не должно. А для записи используются 32-х разрядные команды ?

 

Спасибо большое за развернутый ответ, всё понятно.

Для записи/чтения PE_EXT_FIFO использовал 32-битные команды.

[dsmv 0]

Спасибо большое за развернутый ответ, всё понятно.

Для записи/чтения PE_EXT_FIFO использовал 32-битные команды.

 

Вот нашёл класс для подсчёта CRC: PE_ExtChainItem.zip

[dsmv 0]

Всем доброго времени суток.

 

 

Вот хочу спросить, кому-нибуть помогло изучение проекта DS_DMA ?

 

Есть ли вопросы, предложения ?

 

 

 

 

 

[Antonx86 0]

Добрый день!

Имеется желание запустить проект на плате Xilinx Artix 7 AC701 (FPGA XC7A200T FBG676ACX плата в наличии).

 

dsmv, напишите пожалуйста с чего лучше начать и каким образом.

 

может быть имеются программные мастера по подготовке DS_DMA проекта для нового ядра PCIE?

[dsmv 0]

Добрый день.

 

Давайте сделаем. Я посмотрю на AC701 и сформирую проект.

 

 

 

 

Добрый день!

Имеется желание запустить проект на плате Xilinx Artix 7 AC701 (FPGA XC7A200T FBG676ACX плата в наличии).

 

dsmv, напишите пожалуйста с чего лучше начать и каким образом.

 

может быть имеются программные мастера по подготовке DS_DMA проекта для нового ядра PCIE?

[dsmv 0]

Собрал проект AC701_A200T_CORE. Пока есть проблемы с моделированием.

 

http://ds-dev.ru/issues/65