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

    

fguy

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

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Участник
  1. Стандартное решение - микроблэйз с эзернетом и ядром QSPI + софт для микроблэйза и пк. Можно сделать бин с прошивальщиком и грузить его по JTAG для обновления прошивки, а если ресурсы позволяют то встроить это в штатную прошивку. Программироваться файл 10 Мб будет где то за минуту. У этих флэшек бывает какой то странный лок, который лечится только первоначальной прошивкой в сдк - потом и свой прошивальщик работает.
  2. на рутрэкере раздают кзалиновский сднет - может и оттуда что сгодиться
  3. а зачем на плис вешать "сетевуху" по PCIe? по фэншую xilinx предлагается QSFP на GTY - проще и конструктивно и в плис, тем более что поток в плис сами формируете без всяких линуксов (насколько я понял)
  4. Вы ничего не путаете - 4 Гбайта/с это уже 40 Гбитный эзернет, а не 10? DHCP вроде никто не просил пока - всем хватает статичных IP и MAC с возможностью оперативной реконфигурации - типа выдаем кучу одинаковых коробочек с одним IP и MAC по серийнику, а заказчик сам выставляет перед вводом в эксплуатацию желаемые адреса, если у него меняется адресная конфигурация сети, то он сам меняет адреса как хочет.
  5. По своему опыту поднятия обмена по UDP без всяких там лвипов и т.п. могу сказать что чем проще тем надежнее - для того же обмена по UDP достаточно отвечать на ARP и ВСЁ - для пущего понту можно еще на простой пинг отвечать - остальное от лукавого. Генерация мультикаста UDP вообще не требует ни на что отвечать - только правильно формировать пакеты. Не нужно забывать что зачастую на плис в качестве физикалов вешаются многоканальные свитчи которые живут своей жизнью и за их поведение отвечать трудновато.
  6. А какой смысл копать глубже - если только авторы вашего ядра ТСР не хотят получить красивый сертификат в рамочке, который ни о чем. По факту в плис отправка или прием данных в виде TCP/IP/UDP пакетов делается небольшим ядрышком в паре со штатным IP нужного эзернета, а критерием работоспособности служит правильная работа, а не сертификат в рамочке, да и реализация всех фишек протоколов и "защита от дурака" чаще всего не нужна.
  7. у xilinx на гите есть исходники парсера тср под 10гбит на хлс https://github.com/Xilinx/HLx_Examples/tree/master/Acceleration/tcp_ip в них есть и тестбенчи для ядер - может чего там и по теме найдете
  8. hls это непредсказуемая лотерея - то что синтезировалось и нормально отработало в симуляции в виваде - не обязательно будет работать на чипе попробуйте сделать то же самое в 2018.2 - там хлс изрядно перепилили, но некоторые вещи испортили, например, нельзя писать в элемент массива через диапазон бит - синтез ядра просто падает
  9. насколько помню иначе фокус не проходит сбрасывает частоту на базовую
  10. Однако - обычно с этим сталкиваются еще на этапе отладки что бы не дергать питание при повторном запуске софта. Делается все просто - читаем регистры, посылаем сброс и опять читаем регистры - далее программируем от базовой частоты. "Быстрая" перестройка частоты для этих силабсов доступна только в небольшом диапазоне.
  11. Вы понятие "латентность" ни с чем не путаете? Латентность у кордика и так не маленькая будет особенно у вас в пайплайне. Если вы выравниваете результат с кордика по времени с какими то еще потоками, то по любому ставите фифо на них, а в 2-х канальном варианте вам это фифо придется сделать несколько больше только и всего, но при этом сохранится возможность обработки ваших данных кордиком каждый такт 300 МГц. Конечно же ресурсов такой вариант съест больше чем одно ядро кордика, но в масштабах среднего кинтекса 7 это практически ничто.
  12. Есть допотопный алгоритм для решения всех проблем - разделяй и властвуй. В вашем случае стрим на 300 МГц делим на 2 по 155 (с запасом) и ставим 2 ядра кордика, результаты собираем обратно в стрим 300 МГц - делается за час с использованием хлс и штатных ядер.
  13. Цитата(EpLeon @ Apr 17 2018, 16:08) Вот и нужно соединить старую верссию ISE и windows 10. http://www.xilinx.com/support/answers/62380.html
  14. Цитата(videoscan @ Mar 2 2018, 11:55) Есть 2 функции на С. Мне надо чтобы они работали одновременно. Но дело в том, что есть блок памяти (глобальный), используемый обеими функциями. Я сделал так, чтобы использование общей памяти функциями происходило в разные моменты времени и не пересекается, однако vivado этого не понимает и запускает функции последовательно. А в чем проблема реализовать каждую функцию отдельным ядром, в параметрах функций прописать по одному порту блокрама и соединить их в блокдизайне? По своему опыту использования хлс и плис могу сказать что использование адресуемой памяти в обработке это зло и допустимо лишь когда иначе ну совсем никак - типа транспонирования огромных матриц. Постарайтесь адаптировать алгоритм к конвейеру без применения адресуемой памяти, а для выравнивания потоков и/или буферизации данных между ядрами используйте фифо.
  15. Цитата(RobFPGA @ Dec 7 2017, 17:29) С того что раньше HLS было как отдельная инсталляция а в 17.3 все пихается в папку Vivado. Поэтому могли и сэкономить на спич... общих dll ках. оболочки все равно разные, а библиотеки поддержки чипов хлс и так брал из вивады - если какой то тип не был установлен то и синтез ядер под него не делался в идеале конечно бы хотелось чтобы хлс вызывался из вивады - вставил или выбрал ядро в бд и открылся редактор кода интел-альтера то же сделали хлс - надеюсь конкуренция даст ходу этой технологии - вещь полезная для сложных алгоритмов и математики Цитата(dmitry-tomsk @ Dec 12 2017, 19:48) флэшу на цинке программирует или через раз или вообще не программирует. На форуме xilinx патч какой-то, у меня патч не пошёл. Пришлось по рекомендации других ставить hw_server 2017.1, там всё нормально пока. есть такое - из сдк 2017.3 прошить флэшку qspi на цинке не вышло - тупо требует какой то загрузчик в эльфе - видимо это в связи с поддержкой ультрацинков вылезло