count_enable

alxkon, мы поднимали MIPI более года назад, точно сейчас не припомню, но больших проблем не было. Если успешно подключите какую-то другую камеру (не IMXxxx) - дайте знать, самому интересно. Софт не требует лицензионного сервера и может ставится на нескольких компьютерах. Сейчас обкатываем новые Titanium. Первые впечатления неплохие: дизайн ужался где-то на 10%, частоты подросли раза в три. Вполне реально получить 300 МГц на них.

Каждый разработчик пишет свои тестбенчи, во время разработки блока они выполняются локально. Когда блок коммитится, добавляются тесты на регрессию и производительность в CI/CD. Но должен сказать что упор у нас всё же делается на тесты на железе. 1. Есть несколько задач. Сначала простой "дымовой тест" что код синтезировался\скомпилировался. Потом тесты на симуляторе. Потом на железе. Есть пайплайны для железа и для софта. Разработчик может сам выбирать нужную глубину. 2. Да, ночи хватает на синтез и полный набор тестов. 3. Да, иногда у нас были фейлы из-за таймаута, дали запас по времени. 4,5. Мы разрабатываем ускорители, со внешним железом плисина не особо взаимодействует. 6. Нам хватает логов. При необходимости фризим.

Мы построили CI/CD систему с тестированием коммитов на железе. Очень улучшает жизнь и качество проектов, даже если блок делается одним разработчиком. Упрощает ведение документации и отслеживание изменений в проекте. Меньше багов т.к. невозможно забыть прогнать тесты. Проверка на различных железных платформах. Старый код регулярно проверяется и поддерживается в рабочем состоянии. Дисциплинирует, не даёт делать сотни веток "а попробую я это", "это не работает с квестой, временный костыль" и т.д. Можно прогонять большие наборы тестов автоматически ночью, а с утра разбирать логи. Система масштабируется как по размеру команды, так и по сложности кода. Все разрабы довольны. Наш случай это когда разрабатывается RTL, софт для встроенного проца + математика. Три независимые команды. RTL делает несколько людей. Совместная разработка не на уровне счётчиков и автоматов (хотя и делаем совместные code review), а на уровне интерфейсов между блоками. Кто-то делает блок памяти, кто-то математический блок, кто-то интегрирует внешнюю память и CI/CD гарантирует что у нас получится один проект с новейшей кодовой базой, а не три несовместимых. Так что очень рекомендую.

Спасибо за ценные замечания! Жаль никто не делает бенчмарков на digital design софте. Подумаем над райзеном.

Xeon в первую очередь обнадёживает большим кешем и контроллерами памяти.

Не хочу плодить похожие темы, поэтому спрошу здесь. Какая конфигурация нужна для Questa Modelsim? Стоит ли добавлять больше памяти, больше ядер, или быстрый SSD? Кто-то пробовал ставить Квесту на Xeon, как оно по сравнению с десктопными Core/Zen? Сейчас рассматриваем идею одного сервера симуляции с несколькими квестами работающими параллельно.

Работаем с Т120, частоты небольшие, до сотни. Старые трионы не самые быстрые плисины. Новые пока не пробовали.

В продакшн но не в продажу.

Больших партий мы не закупаем, небольшие точно доступны. Киты тоже без проблем. Вполне неплохая рабочая платформа. К концу года обещают новое поколение 16нм, в софте уже новые плис добавлены. Ещё у них есть референсные SoC на RISC-V, работают без особых танцев с бубном. Для отладки правда лучше сделать отдельный Soft JTAG.

Работаем с Efinix. По доступности, лицензиям не подскажу. Сами плисины неплохие, MIPI рабочее, контроллер DDR тоже. На официальном ките идёт от них демка с камерой IMX219 и дисплеем на HDMI. Софт похуже чем у Xilinx, но фатальных косяков нету. С мелкими платами типа Xyloni/FireAnt дела не имел.

В абсолютном большинстве нейросети не "пишутся" на каком-то языке, а делаются с применением какого-то фреймворка. Из актуальных это Keras/Tensorflow, Pytorch, Caffe2, CNTK, OpenVINO для Интела.

Все нейросети это одно большое матричное умножение. Алгоритмы Штрассена и Винограда ограниченно используются. Какое-то время Нвидия тоже экспериментировала с умножением по Винограду, было в их библиотеках. Поищите статьи по Strassennets, Wnograd convolution.

ТС, в какой среде (фреймворке) работаете? Задача типичная, во всех ML-тулкитах (в питоне наверное самый простой будет scikit-learn) есть готовые инструменты. Кстати не факт что нейросеть покажет лучшую точность, вполне вероятно что регрессия или метод опорных векторов справятся лучше. Советую посмотреть примеры и курсы по машинному обучению. Лично мне понравилась документация к Матлабу (у них хороший тулкит для численных данных а не распознавания образов) и курс Andrew Ng. Оба очень простые.

Спасибо всем откликнувшимся, исполнитель найден.

Ищу специалиста хорошо знакомого с архитектурой PSOC5/6 - UDB и DMA для разовой работы с перспективой дальнейшего сотрудничества. Требуется реализовать один алгоритм с использованием цифровых блоков и сделать замеры производительности. Работа полностью удалённая. Подробности в ЛС.

Есть примитив BSCANE, но он дает только возможность использовать JTAG User Instruction. А вот описанного способа как подключить свой JTAG внутри своей корки к цинковскому TAP найти не удалось. UPDATE: Похоже что проблема нерешаема. Есть один проект где используется BSCANE чтобы программировать RISC-V, но отладка таким образом невозможна. https://github.com/watz0n/learn-rv32i-arty

Хочу запустить RISC-V ядро на Z7020. Система (Vexriscv) уже собрана, можно размещать. Можно ли как-то пробросить JTAG порт внутрь чтобы подцепить RISC-V к тому же интерфейсу на котором висит PS?

Да, можно сжимать при помощи свёртки. Для этого придумали архитектуру под названием автоэнкодер. Сжатие будет с потерями, вычислительная сложность высокая, работать будет только на похожих типах изображений. Если натренировать автоэнкодер на портретах, а потом пережать например фотографию биокультуры под микроскопом, может получиться забавно. Но в принципе возможно.

Achronix очень активно развивается. Он оседлал нишу 5G и активно её окучивает. Куча новых моделей плис у них на сайте, все заточенные под производительность. Технология это нишевая, но если надо возможность реконфигурации и низкий (доллары) unit cost то альтернатив нет.

Почему? Современные FPGA имеют много быстрой памяти внутри.

На T13F256 занимает около 10%, синтезируется на частоте 80 МГц. Да, делают настоящие чипы а не рекламу. Им бы ещё перейти на более новый техпроцесс и дать больше популярных хард-блоков. Пока кроме памяти и умножителей ничего нету.

Слышал. Относительно молодой стартап, но делают хороший прогресс. Всё ещё довольно сырое, но пытаются улучшить. Хорошо идут на контакт и пытаются помочь. Софт очень простой, но тем не менее заработал сразу под Линуксом. Правда Efinity иде странно выглядит - проще писать код во внешнем редакторе и использовать для компиляции. Что-то разводить ещё не пробовал, потыкал в примеры которые дают с иде (FIR и древний R4000 проц). Верификацию делать не пробовал, обещают что с Моделсимом работать будет. В общем это явно не для коммерческого продукта, но уже пригодно для экспериментирования. Думаю через пару лет допилят до вполне рабочего состояния.

Спасибо за ответы. HLS не подходит т.к. длина последовательности зависит от входных данных, плюс надо гибко переключаться между 3-4 типами последовательностей. Так что только программное управление. Конечные автоматы различной степени вложенности используем сейчас, но как я говорил, отладка затруднена (любое изменение задержек в выч. устройстве - переписывай код и отлаживай по новой), гибкость недостаточна, а ресурсов сожрали как почти полноценный процессор. Майорова пока найти не удалось, с альтеровским секвенсером знакомлюсь. Пока что мой секвенсер выглядит похоже на это: https://vak.dreamwidth.org/573813.html . Сейчас размышляю над двумя вариантами: - Вариант без циклов и переходов(линейный проход). Каждое слово в формате "опкод: количество повторений". МА очень простой тогда. Недостаток: может быть недостаточно эффективным. Пусть будет 1к 18-битных слов, 9 под команду, 9 под количество повторений. Тогда у нас может быть только 1024 смены опкода в программе, каждый опкод можно повторить 512 раз. Вроде хватает, но надо считать. - Вариант с переходами. Более близок к классическому МА, но мне жаль отдавать половину или больше каждого слова под адрес перехода.

Не уверен что в правильном разделе, но так как разрабатываю я на ПЛИС, то пусть будет здесь. Появилась задача выполнять на ПЛИС очень длинные (тысячи и десятки тысяч) последовательности команд. Последовательности вычисляются нехитрым алгоритмом и представляют собой что-то типа: P+=A+B; P+=A+B; (8x repeat) P=P*A; BRAM(Addr)=P; P+=A+B; (64x repeat)... P=P*A; BRAM(Addr+1)=P; ..and so on and on and on... Хотя алгоритм вычисления и нехитрый, есть несколько десятков последовательностей которые надо выполнять. Сейчас на рассыпухе сделан генератор адресов и опкодов который это делает, но любое изменение алгоритма это огромный гемморой и недели отладки. Добавление новой последовательности приводит к ощутимому росту ресурсов. Процессор не справится - надо выдавать команды на 300+ МГц. Решил сделать это микропрограммным секвенсером - тем более что ветвлений (кроме циклов заданной длины) в алгоритме нет, вся последовательность строго детерминистична. К сожалению, не нашел ничего достойного в современной литературе на эту тему, сейчас работаю по разрозненных публикациях в интернете и руководству по серии Ам2900 из 80х годов. Не хотелось бы изобретать свой велосипед для в общем типовой задачи. Будут ли рекомендации?

Могу только добавить что это нижняя планка. Перевозить менее опытного инженера нам пока не оплачивается. Коллектив частично русскоязычный, но рабочий язык английский.