dxp

А 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 нс -- специально исследовал этот вопрос, снимал времянки осциллографом, очень удивлялся поначалу, пока не понял, почему так).

Если нужна прямо такая лютая риалтаймовость, то почему просто не выполнять этот код (4 мкс) прямо в обработчике прерывания? К тому же, на фоне 200 МГц тактовой проца 10 мкс выглядят не так уж мало, а тормознутость RTOS -- понятие растяжимое. Если не обременяться сложными планировщиками, не цеплять толстые хуки на процессы переключения контекстов, то там время передачи управления вполне себе не страшное -- например, на Cortex-M4 при 168 МГц время передачи управления (не просто переключение контекстов, а именно от возникновения события до получения управления кодом потока) порядка 900 нс. Это для самого приоритетного потока. Можно распихать этот требующий риалтайма код по приоритетным потокам (которые будут сами нагло отбирать управление у менее приоритетных, когда им надо) и не придумывать ничего.

Scrum есть?

Сама по себе PCIe корка с AXI4-Stream портами небольшая -- там же аппаратный блок основную функциональность тащит. Насколько помню, PCIe x4 выходила в таком виде порядка 1000 лутов. А BRAM тоже зависит от заявленного размера буферов, по минимуму там было 8 или 9 штук.

Какие разрядности и частоты вам нужны? Какая ПЛИС?

Как оно поможет? Чем это лучше: logic cnt = 0; always_ff @(posedge clk) begin cnt <= cnt + 1; end ? Ваш вариант будет работать точно не быстрее. В лучшем случае он сведётся к приведённому. Скоростные многоразрядные счётчики делаются совсем не так.

DPDK?