Strob

А зачем 1024 умножителя то?

Не помню ни одного случая когда была нужна библиотека IEEE.STD_LOGIC_ARITH.all Неужели возможность арифметических операций над std_logic_vector стоит того, чтобы вносить такую путаницу? Какие такие блага отсутствуют в стандартной IEEE.numeric_std.all? И это я уже не говорю о том, что на дворе 2020 год и поддержка vhdl2008 вполне сносная, а значит используя numeric_std, можно забыть о половине недостатков, которые обычно приписывают vhdl'у. Уже и vhdl 2019 вышел, правда поддержку его ждать будем наверное лет 10

Во всем нужен баланс. ))

Коэффициенты фильтра рассчитывались от частоты 266мгц?

То что вы описали, это я считаю костылем. Фактически вручную реализовывать функционал, который в vivado hls поддерживался из коробки, ну, по мне так странно. По сути есть директива, которая всегда работала, а теперь перестала. Зачем это было нужно и кому?

Не за что. В итоге права помогли?

И все же, дать полный доступ к папке вивады пробовали? Не помогло?

Что-то подобное было, лечилось разрешением доступа. Подробностей сейчас не помню(кажется нужно было дать разрешения для папки xilinx). Как один из вариантов, попробуйте запустить от имени администратора.

А точно не постоянная 1? Часто диоды ставят так, чтобы они зажигались нулем.

popa <= (pipa xor pipa(pipa'high)) + pipa(pipa'high); при этом порты можно указать как unsigned без размера. Беззнаковое в либе numeric_std может напрямую складываться с целым. Преобразования не нужны

Ну, синтаксис не такой конечно, но идея такая, да. И лоджик вектора на вход безразмерные

Зачем столько преобразований? Достаточно только std_logic_vector(). А в vhdl можно без параметра.

Нет, я пытаюсь сделать ip для использования в проекте vivado. При создании проекта витис позволяет выбрать, ip vivado flow или vitis flow. Насколько я понимаю при выборе ip vivado flow, конечной точкой создания ip будет корка для вивады. Если вопрос по существу задачи, то обсуждение можно упростить до примера, имеем массив 4 fixed point на входе, хотим домножать их на второй вход, где 1 fixed point. Результат выдаём массивом. Вообще на данный момент проблема была решена, совершенно дурацким образом. Оказалось что vivado hls не был выпилен из витиса, однако его наличие нигде не озвучивается явно и создаётся впечатление что в будущих релизах его таки выпилят.

Добрый день коллеги. Потратил уже кучу времени на пустяковую казалось бы проблему. Решения адекватного до сих пор не нашел. Был vivado hls, была в нем описана функция с вектором на входе. Чтобы грузить весь вектор сразу, параллельной шиной, использовалась директива array_reshape. Все логично, все просто. Берём vitis hls, и облом. Читаем доки, читаем варнинги. Array_reshape не поддерживается для входов. Витис упрямо лепит интерфейс памяти. Никакой альтернативы для получения того же результата найти не смог. Точнее альтернативы есть, но они скорее нагромождение костылей. Неужели теперь с этим жить? Или я что-то упускаю?

А если в настройках Debug configuration поставить галочку Reset entire system, результат какой будет?

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

Сначала лучше понять, уменьшение количества тактов, это цель, или средство достижения цели?

Конечно украшательство. Причем для широкого спектра задач совершенно бесполезное. Сильно сомневаюсь что ТС собрался 100 ракурсов снимать для людей. Небось конечная цель, построение 3д модели.

Не надо путать качество и украшательства под восприятие картинки глазом человека.

Фотокачество достигается правильным соотношением параметров сенсора и оптики. Все остальное - хорошая мина при плохой игре.

В целом, с точки зрения матрицы, видео равносильно фото. Никогда не видел, чтобы именно на уровне матрицы что-то отличалось. 1) OpenCV? Но, имхо проблема не в ПО и не в матрице. 2) мне кажется к проблеме это отношения не имеет. 3) обычно видео и фото не разделяют. Чаще всего различия только в быстродействии интерфейсов и узлов вне матрицы. Видео надо обрабатывать быстро, записывать на носитель. С фото задержка в 1 секунду роли не играет. Мне кажется к делу имеет отношение исключительно качество оптики и юстировка. Какой объектив используете? Нет ли боковых засветок?

Может конечно и да, но что-то я сильно сомневаюсь, что есть хоть какая-то разница в скорости.

Не ведаю. Просто не думаю, что стоит акцентировать внимание именно на быстродействии. Все от задачи расти будет. ТЗ, с инженерной точки зрения )

У xilinx в документации на синтезатор прописаны ограничения для проектов с несколькими языками. Что то мне подсказывает, что у остальных должно быть что-то подобное.

Быстродействие может вырасти в разы. Но не обязательно.