dxp

Цель -- иметь сравнительную проверку РС железа, поэтому проект нужен один с конкретными настройками. Ровно так было с прошлым тестом. Вполне адекватно показывал производительность железа. BRAM, DSP, PCIe, etc -- это ещё одна "координата": эти аппаратные блоки имеют жёсткое расположение внутри FPGA, что даёт новые вводные для инструментария. В реальных проектах всё это как правило есть, поэтому для адекватности теста такие элементы тоже нужны. И никакая кроссплатформенность тут не нужна. Если хочется иметь тест, который можно собрать на любом тулчейне (Vivado, Quartus, PDS, Gowin и т.д.), то это должен быть совсем другой проект, и показывать он будет тоже нечто другое -- скорее производительность тулчейна, а не эффективность РС железа. Такой тест не должен иметь ничего, кроме логики и регистров. Ну, и на PnR всё равно будут проблемы с констрейнами по распределению пинов. Т.ч. по-любому придётся делать портирование. Моё мнение, такой тест достаточно бесполезен в отличие от предлагаемого варианта по тестированию производительности РС железа. IP ядра -- это блоки, которые могут собираться параллельно, это даёт преимущество многоядерным процам, это хороший тест на эффективность работы с памятью и кэшами в одновременном многоядерном нагруженном доступе. IP ядер в проекте может быть немало (десятки), и их сборка (создание и синтез) занимают время обычно побольше, чем синтез самого проекта. И это хороший способ разгрузить синтез, т.к. IP ядра обычно собираются в OOC режиме.

Помнится, было дело тут на форуме: кто-то скидал простой, но затратный на сборке проект под Quartus (как бы не для Cyclone II), и все желающие могли собрать его на своём железе и выложить результаты -- была какая-то более-менее объективная оценка эффективности сборочной машины. Может тоже так же сделать: скидать проект под Vivado, например, на Artix7-200, и выложить, чтобы все желающие могли попробовать и доложить какие-то более-менее объективные результаты? Показать: конфигурация РС, время сборки в формате: IP ядра. Синтез. P&R. Общее время. Вот только состав проекта надо подобрать, чтобы там не было перекосов, чтобы все компоненты равномерно задейстовались: комбинационная логика, флопы, блочная память, IP ядра (как минимум PLL, а ещё, может PCIe), DSP блоки (но без фанатизма). Может есть что-то готовое на примете? Думается, такое было бы и интересно многим, и полезно.

Да, так стала светлая тема, намного юзабельнее. Спасибо вам большое!

Xubuntu 22.04. P.S. Полагал, что это жаба-решение насквозь кроссплатформенное, иначе на кой оно.

Всем привет! Какое-то время назад доводилось работать с Xilinx SDK. Потом была пауза в несколько лет, и вот сейчас опять возникла такая необходимость, но вот SDK канул в лету, и теперь вместо него Vitis. Ну, в целом вроде то же самое - эклипсообразная хрень, но сразу же столкнулся с неприятной неожиданностью: если раньше там (SDK) была традиционная светлая тема, которая, может, не слишком красивая, но вполне функциональная -- во всяком случае, всё хорошо читаемо, но теперь это просто... я не знаю, как это назвать. Оно стало тёмно-тёмно серым (щас такая мода пошла -- многие софты в этот мышиный цвет красят), и ладно бы, если бы не некоторые "но". А именно: на этом фоне содержимое отдельных окон или плохо читаемо, или вообще нечитаемо! Вот сразу с ходу при загрузке: Прочитать этот мутно-синий текст можно, только выделив (тогда контрастно)! Такая же история, например, с окном дизассемблера -- тоже такой же блёкло-синий на фоне мышиного. Ковырял настройки нашел про цвета, но там в основном настройки цветом элементов интерфейса, подсветка синтаксиса и подобное. Можно поменять фон отдельных окон, от этого вид ещё ужаснее -- некоторые окна с белым фоном, некоторые -- вот такие, тёмно-серые. Изменить цвет шрифта этих окон и окна дизассемблера не смог. Погуглил про темы (скины), вроде нашёл какое-то описание что-то там установить в виде плагина через некий marketplace, но интерфейс плагинов в Vitis или отключен (так было сказано по одной из ссылок -- и есть основания этому верить, т.к. длительные попытки найти возможность что-то установить через этот самый маркетплейс, не увенчались успехом), либо унесён куда-то в непонятное место. В общем, у меня два вопроса: 1. Риторический, к авторам этой поделки: они сами-то пробовали этим пользоваться? 2. Практический: кто как обходит эту неприятность? есть ли способы?

А PLL'ки те же? Умеете как-то без IP ядер это описать? Аппаратные блоки ПЛИС далеко не все инферятся из кода, я знаю только про память и про DSP блоки. Т.ч. без корок далеко не уехать. Корки -- это ж по сути библиотечные модули. Более-менее заметный по размерам проект вряд ли обойдётся без них.

То, что она лёгкая и поэтому быстрая (да ещё и написана видимо на Qt в отличие от жабы у Vivado), это понятно и приятно. Но позволяет ли она собрать проект из командной строки полностью. Имеется в виду не только синтез и PnR, но и сборка всех IP ядер. Например, поменялся какой-то базовый параметр в проекте, который влияет на тактовые частоты и/или ширину шины, из-за этого надо перегенерить корки. На той же Vivado, к примеру, это делается спокойно штатными средствами, т.к. там все операции можно тиклевыми командами выполнять, поэтому такая автоматизация -- дело техники. Quartus, насколько помню, тоже так позволяет делать, хотя там местами мутновато. А вот в Gowin IDE я не нашёл, как корки собирать из командной строки -- только через GUI. И это для меня жирнейший минус. Это просто закрывает возможность автоматических сборок (прощай CI/CD), и вообще без такой возможности работать очень неудобно -- любое изменение базового (уровня проекта) параметра требует отслеживать его влияние вручную.

САПР их тоже больше Quartus'а нравится?

А частота сети от 50 Гц не в такой же пропорции отличается? Хотя многовато, конечно. Осциллографом посмотреть, что с оптрона летит, есть возможность?

Падение 0.12 при токе 0.5А -- это характеристика силового элемента этого стабилизатора - т.е. то, что он может обеспечить, а не всей схемы. При питании 3.6В и падении на светодиоде 3 В остальные 0.6В рассеятся на внешних элементах. Итого, 0.5*0.6 = 0.3 Вт. Если питание будет выше, потери на тепло будут больше. А 0.12 падения на стабилизаторе говорит только о том, что он способен обеспечить 0.5А и выдать в нагрузку 3В при питании 3.12В. Если вам КПД и тепловыделение не препятствуют, то это другое дело. Но линейным силовым схемам по КПД тяжело тягаться с импульсными. У линейных есть другие преимущества.

Как сказать. Пара-тройка сотен DSP блоков в FPGA на типовых ЦОС операциях типа свёртки уделают практически любой DSP процессор влёт. Тут как обычно вопросы разумной достаточности и цены вопроса.

Ну, так это ж application процессор. Он быстрый, но неповоротливый, прерывания для него -- дорогая штука. Основные задержки, полагаю, там в контроллере прерываний GIC: толстая штука с поддержкой 1000+ источников прерываний. С такими процами просто и подход исходно другой: они применяются обычно как управляющее ядро SoC, а SoC -- это система, состоящая из достаточно самостоятельных устройств, обладающих приличной "автономностью", т.е. способных без вмешательства процессора выполнять сложные цепочки операций. Процессор там в основном участвует для настройки аппаратуры, мониторинга процесса работы и корректировки, ну, и конечно, для организации интерфейса пользователя (хоть CLI, хоть GUI, хоть веб-интерфейс). Ну, и поскольку системы сложные, устройства непростые, там потенциально возможно большое количество прерываний, что налагает требования на контроллер прерываний. С другой стороны, поскольку устройства достаточно "самостоятельные", метаться по прерываниям на каждый чих не нужно. Вот и причина, почему такой сдвиг акцента: количество разменивается на скорость. Но при таких "неприятных" значениях задержки на практике всё не так печально -- абсолютное-то время всё равно получается вполне приемлемым за счёт высокой частоты. Я сам озабочен подобными описанным вами вопросами -- предсказуемость времени реакции. Поэтому тоже ковыряю Zynq-7000 на предмет baremetal. Моё намерение: разместить программу в OCM, которой там 256к (для моих задач достаточно, что-то не критичное можно и в SDRAM закинуть), и это уровень L2, т.е. при промахе кэша L1 дальше этого уровня запрос не пойдёт (в отличие от случая, когда программа в SDRAM -- там возможен промах L2 кэша, дальше задержка обращения в SDRAM, в которой пасётся много кто -- та же FPGA часть -- в общем, тут задержка вместо нескольких тактов до OCM может вырасти до пары тыщ (видел отчёт несколько лет назад в Сети). Но baremetal на application процессорах -- это то ещё "удовольствие". В основном это касается, конечно, запуска, потом-то всё вполне обычно. Но старт весьма нетривиален.

А вот как раз на Zynq-7000 это и было. 🙂 Прерывания пробовал разные -- от внешней ноги и от таймера.

А где говорилось про FreeRTOS? Эта RTOS самая тормозная из всех подобных, есть решения побыстрее. И даже если попасть на прерывание, критическую секцию, это даст пару сотен нс "джиттера", совершенно не критично и того же порядка величины. Т.ч. вполне можно говорить о какой-то детерминированности (гарантированности) времени реакции на событие. Обработчики прерываний в этом подходе, разумеется, нужно делать как можно более короткими, выполняющими самый минимум работы: получил событие -- взвёл сигнал, пихнул в очередь и т.п. Расскажите это, например, Cortex-A9 с GIC, у которого вход в IRQ занимает пару сотен тактов (на тактовой CPU 400 МГц задержка от внешнего события, до попадания в обработчик прерывания от него занимает порядка 450 нс -- специально исследовал этот вопрос, снимал времянки осциллографом, очень удивлялся поначалу, пока не понял, почему так).