dsmv

ISE поддерживает Virtex-7, Kintex-7, Artix-7.

Да я и забываю. И полагаюсь на произвол P&R Но четыре такта задержки перекрывают весь произвол. Или всё-таки три ?

Вот, и здесь появляются новые требования, про которые обычно все забывают. И новая область применения - low latency FIFO. Так что можно сформулировать - FIFO на основе счётчика Грея эффективно для небольших размеров, например до 64 слов.

Все доброго времени суток. Есть проблема - к ПЛИС подключена QSPI N25Q256A; Проверяю работу на модели. В режиме SPI всё нормально, читается ID, читаются данные из памяти. В режиме QSPI модель FLASH не отвечает. Временная диаграмма на картинке - видно что выходы м/с в состоянии Z По При этом в логе видно что модель FLASH команду восприняла и хочет выдать данные: # KERNEL: [5516000 ns] ==INFO== Protocol selected is quad # KERNEL: [5716000 ns] COMMAND DECODED: Multiple I/O Read ID , withAddr=00000000, with2Addr=00000000, with4Addr=00000000, cmdcode=af # KERNEL: [5716000 ns] COMMAND RECOGNIZED: Multiple I/O Read ID. # KERNEL: [5727000 ns] Data are going to be output: 20. [Read ID, byte 0] 0 0 # KERNEL: [5827000 ns] Data are going to be output: ba. [Read ID, byte 1] 0 0 # KERNEL: [5867000 ns] Data are going to be output: 19. [Read ID, byte 2] 0 0 # KERNEL: [5907000 ns] Data are going to be output: 10. [Read ID, byte 3] 0 0 # KERNEL: [5947000 ns] Data are going to be output: 00. [Read ID, byte 4] 0 0 # KERNEL: [5987000 ns] Data are going to be output: 00. [Read ID, byte 5] 0 0 # KERNEL: [6067000 ns] Data are going to be output: 13. [Read ID, byte 6] 0 0 # KERNEL: [6247000 ns] Data are going to be output: 51. [Read ID, byte 7] 0 0 # KERNEL: [6427000 ns] Data are going to be output: 2c. [Read ID, byte 8] 0 0 На реальном устройстве всё работает. Кто-нибуть сталкивался с такой проблемой в модели ? Может надо ещё какой-то регистр прописать, который уже прописан в реальном устройстве ? P.S. ПЛИС - Kintex UltraScle, FLASH - N25Q256A, Модель от Micron v1.2, Симулятор - Active-HDL

Вообще то в современных условиях счётчик Грея уже не защищает, не смотря на то что он меняется только в одном разряде. Это происходит, если задержка по разным линиям счетчика различается более чем на период тактовой частоты. Вполне возможна ситуация когда на одной линии 1.5 нс, на второй 2.5 нс. Тактовая 500 МГц. Так что я выбрал решение при котором двоичный счётчик фиксируется на одной частоте и за несколько тактов передаётся на другую.

Ага, и зачем нужна более сложная схема, которая при этом работает на меньшей тактовой частоте ?

Рекомендую: https://habr.com/ru/post/321674/ И код: https://github.com/dsmv/fpga_components/tree/master/src/fifo Я не рекомендую использовать код Грея. Если нужны не только full и empty, то код Грея резко усложняет логику работы.

Для Xilinx это тоже возможно. Например можно поставить ubuntu. Может это поможет: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841732/Ubuntu+on+Zynq Если использовать Petalinux, то там можно вытащить из загрузчика dtb и прошивку. На наших платах так и работает. На sd лежит boot.bin (внутри elf), system.bit.bin (это прошивка) кернел и rootfs в соседнем разделе. Если нужны подробности, то попозже. Мне тоже будет нужна консультация шамана.

На мой взгляд - нельзя. Но есть ещё причина по которой это и не нужно. Elastic Buffer который есть в GTX работает только с кодировкой 8/10. 10G Ethernet работает с кодировкой 64/66. В любом случае надо использовать rx clock. И как то перетактировать данные. Ну а если это надо делать для rx, то также можно сделать и для tx.

А все знают про Nimbix? Там есть ALVEO U280. Работа через Vitis. Прошивка загружается через PCI Express. Они дают 100 бесплатных часов. Там же можно и разводить прошивку. При этом надо учитывать, что трассировка проекта для U280 требует около 100 Гб ОЗУ, там такую машину тоже можно арендовать. Так что FPGA в облаке это очень практично с точки зрения попробовать и провести эксперименты. Это дешевле, чем покупать ту же Alveo и компьютер для трассировки.

Напрашивается решение - каждый quad работает на своей частоте tx и rx, но вся логика соединения между портами работает на одной частоте. Если точнее - частота tx - одна на quad, частота rx - у каждого порта своя. Дело в том, что кодировка 64/66 которая используется в 10G не предполагает выравнивания скорости потока внутри GTH. Поэтому принятые данные от GTH поступают на частоте, которая восстановлена из входного сигнала. Работать с 20-ю частотами конечно невозможно, поэтому надо перейти на одну частоту.

Может быть для начала попробовать отправлять только один запрос MEMORY_READ и ждать ответ на него.

В качестве root complex можно использовать отдельный процессор с pci express. Например арм или какой либо tms. Можно попробовать использовать zynq. Вполне нормальной является ситуация когда процессор занимается только инициализацией и мониторингом системы. А плисы обмениваются между собой по pcie.

Добрый день. Вы нарисовали классическую схему использования PCI Express. Так и надо работать. Root Complex надо реализовывать внутри вашей SoC. Если это Zynq 7000, то он там прекрасно реализуется и не занимает особо много ресурсов. Далее - внешняя м/с коммутатора и плис с реализацией end point. Мы так регулярно делаем. Всё работает. P. S. Реализация SRIO гораздо сложнее

Придётся всё-таки осваивать скрипты. Пока у меня скриптами запускается моделирование в автоматизированном режиме и формирование итогового результата по запущенным тестам. Есть конечно различия в скриптах между Active-HDL и Vivdo, но работает.