Перейти к содержанию

videoscan

Участник
  • Публикаций

    58
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о videoscan

  • Звание
    Участник
  • День рождения 25.01.1956

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Москва

Посетители профиля

748 просмотров профиля
  1. Народ! Имеется следующая ситуация. В Vivado, на HLS (Си), написана некая программа. Simulation и Synthesis проходит нормально. На этапе Cosimulation происходит ошибка (см. аттач). В тексте ошибки (см. выше) говорится, что не может открыть файл. Я проверил, файл есть, ничем от других подобных не отличается. Методом тыка определил, что Cosimulation не нравится большое число объявленных блоков памяти. Если его уменьшить (границы не нашел, но где-то около 500), все срабатывает. Кто-нибудь сталкивался с этим? Как бороться? У меня Vivado 2017.4 и Windows 7. Ресурсы FPGA не превысил. Чип - XCVU9P.
  2. Вы совершенно правы! Этот AXI BRAM Controller решает нашу проблему. Спасибо! Прошу прощения за дальнейший поток сознания.
  3. Но если он создаст 3 экземпляра Function4, то к каждому их них он присоединит по одному экземпляру kernel и все останется по-прежнему. Но будет время - попробую.
  4. Т. е. так как на рис? А что помешает Vivado создать заодно и 3 экземпляра Function4 ? На самом деле решение есть: слить все 3 функции Function1-Function3 в одну здоровую и там сказать с помощью ALLCATION, что kernel нужен один, но как это некрасиво! И зачем мы Октябрьскую революцию делали, Си используем?
  5. Народ! Проблема следующая. Есть программа на Vivado HLS со структурой как на рисунке: Верхняя функция - controll, в вызывает 3 разные подпрограммы function1, function2 и function3. Те в свою очередь обращаются к одной функции kernel, где происходит обработка данных. Функция kernel должна быть одна (на уровне RTL), потому как ресурсов она жрет немерено (1024 одних DSP блоков). Vivado HLS на этапе Sinthesis делает 3 RTL копии этой функции. Директива Allocation не помогает, она видит только функции в той подпрограмме, в которую вставлена. Кто-нибудь с этой проблемой сталкивался? Это решаемо?
  6. Получается из HLS модуля торчит 6 * 32 ap_memoty интерфейсов 2Kx16 каждый из которых цепляется к своему модулю BRAM объявленному снаружи HLS. Пошли разбираться. Спасибо!
  7. Имеется 6 буферов памяти 256*256 слов по 2 байта. Каждый из этих буферов делится директивой ARRAY_PARTITION на 32 куска (с опцией cyclic). В эту память нужно очень быстро принимать данные из DDR4. Обработка данных производится на модуле, написанном на HLS. Память организована с внешним интерфейсом ap_memory. На уровне ощущений мне кажется, что использование AXI в интерфейсе памяти затормозит работу вычислителя (а это для нас критично). Однако мы попробовали. При попытке организовать интерфейс этой памяти как AXI (директивами INTERFACE с опцией s_axi) Synthesis делается очень долго (реально я не дождался его конца, ждал 4 часа). С использованием ap_memory Synthesis проекта делается за 2-5 минут. Вот и получается, что нам нужно прочесть данные с DDR4 (они идут на AXI) и записать их в память (ap_memory).
  8. ap_memory торчит. Сама память объявляется в внешнем VeryLog. С этим пока не разобрался. Думал, может есть какой ip, который это делает или я что-то совсем не понимаю.
  9. Я же написал, что использовать AXI BRAM controller не могу. Дело в том, что этих самых контроллеров на блоках BRAM в проекте очень много (около 200) и Vivado HLS не смог мне оттранслировать программу с памятью с интерфейсом AXI при таком их количестве.
  10. Народ! Вводные данные: - проект на Xilinx UltraScale+ (боард VCU118); - часть содержимого пишется на HLS, часть на VeryLog. Имеется следующая проблема: - в проекте реализована связь с SDRAM DDR4 с использованием интерфейса AXI (на самом деле пока не реализована, но IP такой функции в Vivado есть); - после того, как мы получили данные с DDR4 нам нужно передать их в память BRAM с обычным внешним интерфейсом (адрес, данные, запись, клок); - сразу скажу использовать в памяти, на которую надо передать данные, интерфейс AXI невозможно, по ряду причин. Пролистал библиотеку IP с AXI - нужного перехода не нашел. Что делать? Есть ли какие мысли? Как вообще данные, живущие в Xilinx на AXI переходят в обычные? Одно решение вроде как есть - использовать в интерфейсе c DDR4 не AXI, а параллельный интерфейс, но в будущем в проект будет добавлен PCI-e, а он только на AXI и работает, так что эту проблему все равно решать надо.
  11. Цитата(fguy @ Apr 7 2018, 18:13) А в чем проблема реализовать каждую функцию отдельным ядром, в параметрах функций прописать по одному порту блокрама и соединить их в блокдизайне? По своему опыту использования хлс и плис могу сказать что использование адресуемой памяти в обработке это зло и допустимо лишь когда иначе ну совсем никак - типа транспонирования огромных матриц. Постарайтесь адаптировать алгоритм к конвейеру без применения адресуемой памяти, а для выравнивания потоков и/или буферизации данных между ядрами используйте фифо. В общем я сейчас к этому и склоняюсь.
  12. Цитата(syoma @ Mar 8 2018, 20:08) Если работали с симулинком и можете описать свой алгоритм в виде блоков, то System Generator будет прост в освоении. С симулинком не знаком, в МатЛабе не работал.
  13. Цитата(syoma @ Mar 7 2018, 16:30) Если вы еще свои функции на С не написали, то возможно есть смысл попробовать System Generator вместо HLS? Это тоже более высокий уровень абстракции и позволяет вдобавок промоделировать ваши алгоритмы. HLS предназначен для переделки готовых Си программ под FPGA. С System Generator совсем не знаком. Боюсь разбрасываться, сейчас что-то стал понимать в HLS, а тут опять куча новой информации. Времени для этого совсем нет. Я наверное попробую продолжать копать в сторону С.
  14. В сети нашел видеозаписи вебинаров предыдущих лет (надеюсь ничьих авторских прав не нарушил). Посмотрел. В общем все что там сказано уже освоил, а для совсем начинающих - да полезно.
  15. Цитата(Mad_max @ Mar 6 2018, 06:54) Собственно из рассылки electronix Спасибо. Поучаствую.