Jump to content

    

AVR

Свой
  • Content Count

    1585
  • Joined

  • Last visited

Everything posted by AVR


  1. Извините что еще терзаю вопросами, пытаюсь включить cfg_interrupt_msi_enable. Для этого я пытаюсь сначала включить bus_master, затем записать msi enable в регистре 0x90. Однако, ни bus master и msi_enable не включается, статусные линии висят в нулях. Хотя вот например при read-back в слове status, command= 0x00100406 бит 2 содержит 1, как я и записывал, однако линии всё же висят в нуле (шина cfg_function_status и как раз бит 2). Может для применения параметров нужно осуществить запись в еще какой-то регистр? task enable_msi; begin $display("enable msi..."); TSK_TX_TYPE0_CONFIGURATION_WRITE(DEFAULT_TAG, 12'h04, 32'h0000_0406, 4'h3); DEFAULT_TAG = DEFAULT_TAG + 1; TSK_TX_CLK_EAT(1000); TSK_TX_TYPE0_CONFIGURATION_WRITE(DEFAULT_TAG, 12'h94, 32'h0123_0ABC, 4'hF); DEFAULT_TAG = DEFAULT_TAG + 1; TSK_TX_CLK_EAT(1000); TSK_TX_TYPE0_CONFIGURATION_WRITE(DEFAULT_TAG, 12'h98, 32'h0000_0000, 4'hF); DEFAULT_TAG = DEFAULT_TAG + 1; TSK_TX_CLK_EAT(1000); TSK_TX_TYPE0_CONFIGURATION_WRITE(DEFAULT_TAG, 12'h90, 32'h0000_0001, 4'hF); DEFAULT_TAG = DEFAULT_TAG + 1; TSK_TX_CLK_EAT(1000); TSK_TX_TYPE0_CONFIGURATION_READ(DEFAULT_TAG, 12'h90, 4'hF); DEFAULT_TAG = DEFAULT_TAG + 1; TSK_WAIT_FOR_READ_DATA; $display("MSI= 0x%08X", P_READ_DATA); TSK_TX_CLK_EAT(100); TSK_TX_TYPE0_CONFIGURATION_READ(DEFAULT_TAG, 12'h94, 4'hF); DEFAULT_TAG = DEFAULT_TAG + 1; TSK_WAIT_FOR_READ_DATA; $display("MSI ALOW= 0x%08X", P_READ_DATA); TSK_TX_CLK_EAT(100); TSK_TX_TYPE0_CONFIGURATION_READ(DEFAULT_TAG, 12'h98, 4'hF); DEFAULT_TAG = DEFAULT_TAG + 1; TSK_WAIT_FOR_READ_DATA; $display("MSI AHIGH= 0x%08X", P_READ_DATA); TSK_TX_CLK_EAT(100); $display("enable msi OK"); TSK_TX_TYPE0_CONFIGURATION_READ(DEFAULT_TAG, 12'h00, 4'hF); DEFAULT_TAG = DEFAULT_TAG + 1; TSK_WAIT_FOR_READ_DATA; $display("device, vendor= 0x%08X", P_READ_DATA); TSK_TX_CLK_EAT(100); TSK_TX_TYPE0_CONFIGURATION_READ(DEFAULT_TAG, 12'h04, 4'hF); DEFAULT_TAG = DEFAULT_TAG + 1; TSK_WAIT_FOR_READ_DATA; $display("status, command= 0x%08X", P_READ_DATA); TSK_TX_CLK_EAT(100); end endtask
  2. Благодарю! Попробовал этот пакет с Вашим содержимым, правда исправил объем пакета на 1 DW, и у меня успешно передалось! Записал в RQ на стороне Endpoint и увидел эти данные на стороне CQ в RootPort. Действительно, если проследить куда идут линии rq/rc/cq/cc то можно заметить что они поступают напрямую в PCI-E hard IP block, значит причина была исключительно в моей какой то ошибке в полях пакета. Но мне сейчас было важно просто проверить сам факт прохождения пакета. Далее буду проверять больше чем 1 DW, и обязательно MSI. Это позволит проверить кроссплатформенный wrapper для PCI-E Kintex 7/US.
  3. У меня так: set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 8 [current_design] set_property BITSTREAM.CONFIG.EXTMASTERCCLK_EN div-1 [current_design] set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design] set_property BITSTREAM.CONFIG.SPI_FALL_EDGE YES [current_design] т.е. и бит файл жмется, и SPI_BUSWIDTH больше 1, хотя суть в том что должно быть такая "иксность" какова и разрядность флэшек. Вроде на некоторых схемах ставится по две флэшки на 4 бит, вот я и настроил 8. Сам внимания на это не обращал, но коллеги когда стали делать свою плату, ставили 2 флэшки по примеру некоторого референса.
  4. Мне удалось разобраться как делать MWr и MRd и на стороне endpoint, запросы видны из CQ/CC. Пробовал работать через RQ/RC на стороне endpoint: в модели на стороне RootPort сообщение не видно. Сначала я брал пакеты как в примере, который успешно читается, но потом увидел что везде нужно именно 4 DW для заголовков. Выставил 4 DW, правильные значения tkeep и прочее, но пакет так и не отправляется. Что я имею ввиду - не появляется в CQ порту со стороны root port. Надо проверить, а уходит ли хоть что то в txp/txn, это и подскажет где застряло. Может я пишу по неверному адресу? Тот адрес что справедлив для MRd в CC, то при MWr через RQ порт я должен всё таки брать иной адрес? Но вот какой? А может ядро должно сообщать ошибку хоть на стороне endpoint или root port? Беда в том что я не нашел пример работы с RQ в тексте тестов, которые поставляются с демо примером. Как же отладить запись в RQ на стороне endpoint, или увидеть суть причины почему от отбрасывает такие пакеты?
  5. Можно попробовать систему контроля версий типа Mercurial или Git, при появлении изменения в файлах IP ядра или допустим в отладочном - просто отбрасываю изменения и оно снова становится модифицированным. Это костыль, но работает.
  6. И то и другое, значит, нужно работать через 2 порта (cq+cc и rq+rc). Понятно, сделаю тогда через два. Благодарю за прояснение этого момента, так как доступна пока лишь очень медленная ограниченная модель, платы живой пока нет, придется полагаться на фантазию.
  7. Имел ввиду, что CQ+CC это точно так же как TX и RX порты у Kintex 7, т.е. могу я для полной функциональности использовать лишь CQ+CC и НЕ использовать RQ+RC, в том числе для DMA? Мне было бы так проще логику выстроить. Увы, Ultrascale на моем столе мне пока лишь только снится... Кроссплатформенность я достигаю через parameter + generate if else, это удобнее чем через define - можно снаружи управлять версией.
  8. Сейчас вынужден вернуться к теме. Пишу кроссплатформенный модуль PCIe чтобы поддерживать Kintex 7 и UltraScale одновременно. Хотел бы уточнить еще раз. А могу ли я для bus mastering-а просто всё время использовать CQ/CC, т.е. один порт? Не будет оно блокировать мне под предлогом "а я тебе второй порт даю но ты в него не пишешь, не буду ничего слать никуда"? Для переносимости мне было бы легче использовать только 1 порт CQ+CC, только заголовки буду фиксить. Пиковые скорости не требуются.
  9. Кажется понял, нужно из комплексного числа? В этом и сложность задачи этой темы? Комплексные у CORDIC может и есть но я не припоминаю.
  10. На Xilinx просто брал их CORDIC и получал корень Конечно там всегда возня с форматами, но при должном упорстве разгадать можно.
  11. Латентность памяти это неизбежность, но разве латентность мешает каким либо образом прокачивать вот прям такие объемы данных, пусть даже с некоторой задержкой? Тем более сам интерфейс ведь позволяет.
  12. Сделали так: rc = pci_bus_read_config_dword(device->pci->bus, 0, 0x00, &word32); dev_info(&device->pci->dev, "config 0x00= 0x%08X\n", word32); rc = pci_bus_read_config_word(device->pci->bus, 0, 0x52, &word16); dev_info(&device->pci->dev, "config A 0x52= 0x%04X\n", word16); rc = pci_bus_write_config_word(device->pci->bus, 0, 0x52, 0x00DB); rc = pci_bus_read_config_word(device->pci->bus, 0, 0x52, &word16); dev_info(&device->pci->dev, "config B 0x52= 0x%04X\n", word16); Получили: config A 0x52= 0x0081 config B 0x52= 0x00D1 Стало Capabilities: [50] MSI: Enable- Count=32/1 Maskable- 64bit+ т.е. Count=32. Однако, MSI Capabilities MSI messages requested гласит "The Qsys design flow supports only 1 MSI". Означает ли это, что у нас нет шансов выставить например чтобы стало Count=32/32 работая через Qsys? Или это можно как то объехать, записывая через порт CRA значение на стороне устройства? А может можно еще где то задать? Если нет то нет, просто тогда не будем использовать эту возможность, придется обойти иначе эту проблему, варианты имеются. Добавлено: Выяснили что у Cyclone 5 есть настройка в Qsys чтобы выставлять сколько угодно векторов. В целевом устройстве будет уже Cyclone 5, поэтому наверное проблема решена. А сейчас временно Cyclone 4, поэтому это ограничение не критично.
  13. Благодарю за ответ. Проверили. pci_alloc_irq_vectors выдает -28 (-ENOSPC). If less than min_vecs interrupt vectors are available for dev the function will fail with -ENOSPC. Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Мне кажется, у нас само устройство не может позволить выделить больше векторов. И это требуется как то настроить, ведь lspci просто декодирует состояние configs space. В нем похоже не настроено число прерываний, ведь это Count должно быть 1/4 1/8 или даже 1/16. Или я ошибаюсь? pci_set_master(device->pci); dev_info(&device->pci->dev, "master set\n"); rc = pci_enable_msi(device->pci); if(rc < 0) { dev_err(&device->pci->dev, "MSI failed\n"); goto failed_msi; } device->nvec = pci_alloc_irq_vectors(device->pci, 1, 4, PCI_IRQ_MSI); if(device->nvec < 0) { dev_err(&device->pci->dev, "ERROR: IRQ vectors failed %d\n", device->nvec); goto failed_irq; } else { for(i = 0; i < device->nvec; i++) { vn = pci_irq_vector(device->pci, i); rc = request_irq(vn, mypci_isr, IRQF_SHARED, pci_name(device->pci), device->pci); if(rc < 0) dev_err(&device->pci->dev, "ERROR: unable to register irq %d", vn); } }
  14. Он работал так, что лучше бы вообще его не существовало, практически ничего в нем не работало, даже простейший код...
  15. Полностью присоединяюсь к мнению. Надо поставить себе задачу или попроситься кому то в падаваны, и делать то что нужно другому кому то. И в процессе деланья будет яндексение и просветление.
  16. Удалось решить проблему? Это со всей очевидностью проблема путей. Есть ли файл liblwip где либо в каталогах?
  17. У ядер PCI-E Xilinx можно задать число векторов прерываний, например 2 4 8 и т.д., и оно вроде как видится в системе через lspci как параметр Count в строке MSI (на платформе Linux). Это позволяет иметь несколько обработчиков прерываний от 1 устройства. У Altera/Intel при добавлении ядра коллеги не могут найти как включить больше векторов прерываний чем 1. Есть линия app_msi_num которая имеет разрядность 5, значит число векторов может быть до 2^5 = 32. Также известно что в пакете MSI прилетит это в виде некоторого 5-разрядного поля. Но вот с удивлением обнаружили - а на стороне Linux драйвер как должен искать это всё? Пришли к выводу что надо чтобы для начала lspci увидел что у устройства более чем 1 вектор прерывания, чтобы как минимум в драйвере можно было повесить обработчики на IRQ+0 +1 +2 +3 и так далее. Суть проблемы, вопрос: Как включить на Cyclone 4 GX PCI-E ядре больше чем 1 вектор прерывания? Пока коллеги нашли порт CRA в котором надеются найти нужное поле, в котором выставят желаемое значение, а затем уже и я на стороне драйвера смогу повесить туда обработчики прерывания и благодаря app_msi_num мне будет прилетать в разные обработчики. P.S. Документация говорит что может быть до 16 векторов для Cyclone 4 GX.
  18. Ну как вариант, можно было бы успешно принять последнюю допустимую команду и лишь после этого снять app_rdy, ну там еще ack сигнал и т.д. Получился бы сильно более простой и удобный интерфейс, но о вкусах не спорят, работает и ладно. Сейчас проблема, к счастью, решена, что маемо то маемо. Спасибо, обращу на это внимание. Почему то из документации показалось, что для этого сигнала логика иная, там не написано про retry в таблице. Ну пусть, предупрежден - вооружен.
  19. Огромное Вам космическое спасибо, применил эту логику для записи и для чтения (там тоже потребовалось так подтверждать команды). Это конечно кривовато всё кажется, не правильно. Тем не менее, я добился 100% надежной записи и чтения, всё совпадает и по числу команд и результатов, и вообще всё надежно. Получается я зря напраслину гнал на микроновскую модель... А вот app_wdf_rdy похоже всё таки сигнал готовности "здорового человека", но если будут и с ним проблемы, то я тоже буду внимательно тайминги изучать.
  20. А почему operation == зачем два равно? Еще подозреваю нужно PV а не pv, это может оказаться важным. --operation==pv;vga.pof
  21. Кажется до меня дошло, благодарю за Ваше терпение! Завтра утром проверю!
  22. Да, это понятно. Завтра выложу код. Смотрите, когда мы переключаемся на адрес 320 - значит app_rdy было равно 1 и оно успешно скушало 0A. Но к следующему циклу app_rdy был не готов 2 такта и оно ждало. Затем за 1 такт до 0B, когда контроллер памяти что то отработал внутри себя, он вдруг стал готов, и к следующему моменту оно успешно отработало запись 0A и переключилось на 0B. Затем 0B был готов и успешно записался, и уже после записи 0B контроллер сказал что он снова не может больше, но там уже не важно.
  23. Да, спасибо за ответы. Всё как я и предполагал. А синтезируемость в базисе ПЛИС действительно проверяю на стадии синтеза САПР.
  24. Симуляторы например Modelsim и не только он, позволяют в тестируемом модуле писать хоть #100 хоть a <= 1; a <= 2, но есть ли возможность это как то ограничить? Включить некоторый strict mode? Чтобы начинающие не пытались учиться, вставляя туда черти что, а по факту оно работать не станет в ПЛИС. Или тут надо лишь заставлять компилировать в САПР для некоторой ПЛИС?