dsmv

Нет. Так не делают. У вас есть внутренний тактовый сигнал. Вам нужно его выдать наружу, причём с фиксированной задержкой относительно данных, которые по этому же сигналу формируются на триггерах внутри IO блоков. Для этого на выход тактового сигнала надо поставить примитив ODDR. На его входы данных подать 1 и 0. Выход ODDR можно подать на вход IODELAY, это даст дополнительную и управляемую задержку. Выход ODDR даст стабильный тактовый сигнал с той же частотой что и внутренний сигнал. При этом сигнал тактовой частоты будем формироваться так же как и данных, то есть всё будет стабильно при разных трассировках и на разных кристаллах.

Внутренние сигналы обычно не задерживают. В случае острой необходимости это можно сделать, например на тех IODELAY заняв какую то неиспользуемую ногу ПЛИС. Но вряд ли вам это нужно. SDRAM прекрасно заработает с IODELAY

Для начала давайте разберёмся с терминами. Vitis HLS - это что ? Вы пытаетесь сделать kernel для OpenCL на HLS, так ? Или что-то другое ?

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, но работает.

Это очень интересная система, но она нас возвращает к дискуссии что лучше использовать - сборку через скрипт или через gui. Сборка через скрип очень полезна, особенно на удалённом сервере. Но это не удобно при оперативной работе с проектом.

Так конечно можно, но это же надо не забыть этот файл подключить. А как было бы хорошо, есть ip_core с файлами xci; Весь мусор в каталоге Vivado; При это с исходниками можно делать всё и очень просто. Копировать, сравнивать, архивировать, подключать под контроль версий.

Всем доброго времени суток. Есть такая проблема с расположением файлов для проекта Vivado. В моих проектах каталог src отделён от каталога где лежит проект Vivado. Это позволяет его легко подключить под систему контроля версий. Но при таком подходе есть проблема с IP Core. Файлы xci лежат каждый в своём каталоге, они подключены под систему контроля версий, но Vivado при своей работе начинает в этих каталогах работать. И там получается очень много файлов, что неудобно. Собственно вопрос - существует ли возможность указать Vivado что бы она использовала другой рабочий каталог для IP Core ?

Программирование Xilinx через JAM плеер на практике работает. У нас программировали Spartan 3 и Virtex 4. Подробностей я сейчас не помню.

Может поможет проект 1G Ethernet DPI: https://opencores.org/project/1g_ethernet_dpi Там реализовано сквозное моделирование при помощи DPI.

На avnet микросхемы vu9p стоят около $40000, скидки Xilinx даёт только за большие партии. Видимо здесь предполагается большая партия. Мы хотим сделать плату на KU11P, предположительно она будет стоить $9000.

Но на их пути стоит таможня. А вот это 2 x QSFP28 и 4 x DDR4 на VU9P-L2E случайно не VCU1525 ? Здесь по акции она около $7000