Jump to content

    

fguy

Участник
  • Content Count

    83
  • Joined

  • Last visited

Community Reputation

0 Обычный

About fguy

  • Rank
    Частый гость

Recent Profile Visitors

742 profile views
  1. 48 GTM 58 Gb на 16 нм чипах уже в продаже https://www.xilinx.com/products/technology/high-speed-serial.html и число портов на чип в 1.5 раза больше, но это все топовые монстры - что б было чем конкурентам померяться наелся АСР портом еще на 7м цинке - все красиво на бумаге, а на деле цпу слегка напрягся и плис получила фигу по доступу в память DDR на PS - скидывайте кэш ручками на цпу и будет вам счастие
  2. DG нам просто не продадут, как и "спэйс", так что ставим "индастриалы" или Е-шки, а хбм-ы не помешали бы но при ценнике в 30 куе проще подцепить на ультракинтекс пару банков ддр4 64-бит - дешево и сердито
  3. до использования линукса дело еще не доходило, а для "прямого" программирования хватает пока и одного ядра - чаще всего это настройка и управление ядрами по командам с RS или Ethernet - все остальное делает плис
  4. Необходимость использования линукса на цинках для меня связана только с применением периферии, для которой в ядре есть готовые драйвера, а ее прямое использование грозит написанием большого объема кода. На сей момент это HD/SSD на SATA и PCIe, а так же различная внешняя периферия на USB и PCIe. Ну или когда цинк должен стать фактически ПК с полноценной ОС, дисплеем (+ GPU 3D на ультрацинке) и контролерами ввода команд оператором. Все остальные задачи решаются грамотным распределением "обязанностей" между ПЛИС и ЦПУ. До использования 2-го ядра арм-а у меня дело так и не дошло, хотя иногда казалось что уже пора.
  5. В названиях есть тип чипсета - в первых двух интел Z2520, в 3й тоже интел Z2580 - оба полудохлые 32-разрядные 2х-ядерники с парой гигов озу выпуска 2013 года
  6. Если есть даташит со схемой и на этих платах стоят чипы wifi/bt/3g (с симкой), то как вариант их можно использовать как основу для удаленных контролеров чего-нибудь, подцепив датчики. Но основная проблема будет запрограммировать их. Даже при условии что загрузчик разлочен и есть исходники ядра, найти за дешево опытного программера-линуксоида будет не просто и разработка софта вылетит в такую "копейку", что даже "никакая" цена железа разработку не оправдает.
  7. Еще и разные версии его разводят по разному. Давеча переразводил проект - по лютам около 60% - в 2018.2 разводится за пару часов и с оптимизацией и без, а 2018.3 с оптимизацией на роуте в 4м пункте уходит в задумье более чем на час до вывода первой строки с оверлапами (тыщ 30) - чем кончиться ждать не стал.
  8. https://www.xilinx.com/support/answers/66846.html https://www.xilinx.com/support/answers/67157.html https://www.xilinx.com/support/answers/71709.html поискать еще самим по emmc на https://www.xilinx.com/support/answer-navigation.html
  9. а в чем проблемы у плис с реализацией деревьев? "компаратор" это все то же АЛУ, а полученные результаты в виде 0 и 1 как веса идут в многочлен для получения ответа - даже умножители ненужны для реализации - похожий по нагрузке поиск нескольких максимумов в потоке прекрасно работает на плис в пайплайне "дерево решений" напоминает почивший за 30 лет пролог - что то я сомневаюсь что замена слов на цифры что то принципиально изменит и писать эти деревья ручками кто то упрется
  10. насколько понимаю "качество распознавание" сейчас делают на ИИ, да и препроцессинг делают там же в первых слоях, благо большинство функций это все тот же "высокоинтеллектуальный" многочлен - в этом направлении тот же xilinx не стоит на месте и представил Версаль, который окромя плис будет содержать сотни (128-400) процов с широким реконфигурируемым АЛУ 512 бит для решения задач в т.ч. и AI Не очень понимаю в каком месте вы увидели в плис "недостаток производительности" для ИИ? Существующие фрэймворки влезают в современную плис среднего класса и показывают производительность и энергоэффективность на зависть всем цпу и гпу. тенденция на уход от "чистой" плис к сборке с набором "железной" периферии радует - это позволяет освободить ресурсы плис для решения пользовательских задач, а не на реализацию кабы-каких микроконтролеров, недоядер контролеров ДДР, видеокодеков и т.п.
  11. большинство функций и так работают в стриме на частотах видеопотока - зачем это ускорять в 100 раз?
  12. к вашему невежеству это до сих пор делает куалком, еще ранее это делал TI, но они забили на мобильные сок у xilinx поточный скейлер в виде ip существует и работает вполне себе успешно - сам пользовался лет 5 назад, насколько он качественный судить не возьмусь обработкой изображений практически не занимаюсь но тот же xilinx для hls реализовал частично opencv
  13. судя по тому что xilinx выпустил плис Zynq UltraScale+ EV со встроенным кодеком Н.264/265 до 4к х 2к 60 Гц делать это ip ядрами нерационально в отличии от более простых операций видеообработки типа скалинга - фирменная борда zcu104 на нем стоит всего 895 уе и в качестве бонуса hls c opencv на суперпупер-армы в смартфонах (которые к слову порвали все бенчмарки, а на деле только "баян") для решения задач видеокодеков ставят чаще всего полудохлые дсп с тактовой в разы ниже чем у ведущего арм-а, но при этом без проблем де/кодирующих пару-тройку фулхд потоков не выжирая аккумулятор
  14. "СЕ шина" это когда на входе слэйва стоит сигнал ClockEnable и по нему он должен защелнуть данные. Ядра могут иметь право "ложить" на готовность слэйва исключительно по независящим от них причинам, например, ядро приемника GTx для физических интерфейсов не предусматривающих приостановку передаваемого потока данных (например JESD ADC) - все остальные случаи это произвол авторов. И я не спорю с тем что в таком случае слэйв должен обрабатывать каждый такт, но имея только СЕ с его стороны вы не имеете прямых методов контроля за непрерывностью процесса обработки.
  15. Передача данных по СЕ это даже не шина - это тупое навязывание данных мастером слэйву без учета готовности последнего - отсих у "классиков" кошмары на латентность и желание все сделать за один такт. По факту AXI-stream это простое расширение шины фифо с добавлением дополнительных линий (last, user, strb/keep и т.п.). Учет готовности слэйва мастером это уже смена парадигмы - вы перестаете шарахаться от латентности, можно менять интервалы обработки данных, варьируя ширину шины и частоту. Вместо потери данных, которую легко не заметить, получаете тормоза на входе конвейера, которые замечательно отслеживаются.