dxp

А вот как раз на 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?

Не считается: ламп нет, конденсаторов с диэлектриком из соплей девственниц нет, про проводники на плате из бескислородной меди тоже ничего не сказано.

А что, 100 мс нынче -- это реальная проблема? Это требование на ATX системах тянется из старых версий стандарта, когда процы были простыми и поднимались шустро. Сегодня же даже дескоптный процессор -- это сложнючая система на кристалле, которая стартует долгие секунды (это можно наблюдать при включении компа), а уж на серверах это вообще запредельно долго -- специально замерял время от включения до подъёма линка на каком-то Xeon'е, довольно старом уже, там оно составляло 29 секунд! Выглядело так: включил питание, на мониторе (подключил VGA к серверу) чёрный экран, висит всё это долгие секунды, потом появляется приглашение BIOS и в ту же секунду поднимается линк. Т.е. енумерация там пролетает почти мгновенно, а основное время процессор находится "в себе", что-то проверяет, память тестирует. Кроме этого я ещё осциллографом посмотрел тайминги поднятия питания и сигнала сброса. Там времена от Power Good до сброса PCIe существенно больше 100 мс. Т.е. если загрузка FPGA происходит сразу после подачи питания, то эта задержка + гарантированные 100 мс дают достаточно времени для прихода устройства в готовность (там речь шла об Artix-7). Я так подробно это смотрел, потому что тоже запаривался насчёт требования 100 мс готовности, и Artix-7 xc7a200t (самый толстый то есть) никак не успевал загрузиться за 100 мс. Даже при внешнем клоке (EMCLK) с оптимизацией времянок по QSPI всё равно выходило существенно больше 100 мс (то ли 130, то ли под 200, не помню уже). Но производитель не парится на эту тему, и понятно почему. Тандемной загрузки у этой FPGA нет, она начинается у Kintex. Но оказалось, что реальной проблемы на современных x86 нет -- сложная система приходит в готовность несоизмеримо дольше, чем 100 мс. Я понимаю, что это не инженерный подход, что никто не гарантирует работоспособность. Наверное, правильным было бы пересмотреть требования стандарта, т.к. не только процессоры, но и сами периферийные устройства стали значительно более сложными, требующими куда больше времени на приведение к готовности, нежели пресловутые 100 мс. Но по всей видимости, проблемы реально не существует -- практический любой современный процессор по факту даёт времени для готовности с огромным запасом в силу собственной сложности и неповоротливости, поэтому никто и не парится по этому поводу.

Вам нужно именно С в питон перегнать или можно из питона вызвать C/C++ реализацию? Насчёт трансляторов сомневаюсь. В питоне просто некоторые вещи реализованы принципиально иначе -- например, С/C++ массив не очень транслируется в питоновые типы, это лучше заменять numpy массивами, которые помимо хорошей эффективности ещё и тянут за собой приличного размера библиотеку (в т.ч. реализацию тех же BLAS/LAPACK). В общем, там в каждом случае надо оценивать, во что выливается транслированное значение. Если же просто требование запускать код на питоне, то я бы C/C++ оформил в виде некоего API, которое "пробросил" на уровень Python, откуда просто вызывать эти функции/объекты. Существует энное количество способов это сделать: https://realpython.com/python-bindings-overview/. Я использовал boost-python. Технически код на C/C++ компилируется в динамическую библиотеку (dll/so), которая в коде Python просто импортируется стандартным образом (import <module-name>). например, в C/C++ исходнике: // slon.c compiled to shared library slon.so int a; int b; int fun_add(int x, int y) { return x + y; } BOOST_PYTHON_MODULE(slon) { using namespace boost::python; //-------------------------------------------------------------------------- // // exposed variables // scope().attr("c_var_a") = a; scope().attr("c_var_b") = b; //-------------------------------------------------------------------------- // // exposed functions // def("c_fun_add", fun_add); } //------------------------------------------------------------------------------ В Python: import slon from slon import c_var_b from slon import с_fun_add as add a = slon.c_var_a result = add(10, 20) - a + c_var_b <...> Таким образом можно гибко распределить код между языками, это будет по гибкости и удобству Python, а по эффективности C/C++.

Какая специфика разработки под ASIC делает Perforce предпочтельнее Git, учитывая, что с именно версионированием (возможностью легко и непринуждённо вести параллельно несколько веток -- версий) у Perforce всё достаточно печально. Нужно бинарники большого объёма сохранять под контролем?

Зависит от конструкции мотора. Точнее, от величины реактивного момента. Например, у ШД с 200 шагов на оборот этот момент весьма ощутимый, и двигатель стремится встать в одно из устойчивых положений. Но бывают (их меньше) движки с практически неощутимым реактивным моментом (вал крутишь, никаких "залипаний" не ощущается, как будто коллекторный двигатель), у таких никакого притяжения к ближайшему полюсу нет, и если механика никуда его не тянет, он остаётся в том же положении. Шагов на оборот у таких ШД обычно немного -- порядка 20, и управляются они с дроблением шага (sin-cos), какие-то от Maxon использовали (к сожалению, сейчас это практически недоступно). Такие движки более динамичные (реактивный момент как раз мешает динамике), но и управлять ими сложнее.

Это не самый обычный, а какой-то ноунейм непонятный. Я же предложил рядовую модель от известного бренда Сигейт Барракуда. И сравнивать надо на одной площадке -- при чём тут Озон? Там торгует хрен знает кто хрен знает чем, поэтому и цены на одно и то же могут отличаться в разы. Если Алиэкспресс посмотреть, то там такие причудливые варианты находятся. Мы же говорим про комплектующие для работы, а не чтобы как можно дешевле. Вот вы бы купили себе такой SSD? Что бы вы предпочти для 2ТБ хранилища -- этот ноунейм или тот Сигейт?

Значит я отстал от жизни. Достаточно долго они этого не делали. У коллег на работе купленный года два назад Экспедишн, там тоже: Mentor A Siemens Business. Имхо, зря они это сделали.

Тогда уж если быть совсем правильными, то надо сравнивать обычный HDD, а не WD RED. Итого: 2 ТБ Жесткий диск Seagate BarraCuda [ST2000DM005] 5 899 ₽ https://www.dns-shop.ru/product/ceda4f734d19ed20/2-tb-zestkij-disk-seagate-barracuda-st2000dm005/ так что "Да ничего подобного..." никак не подтверждено.

Конечно! Altera -- это бренд! Весьма крутой. Звучное и известное имя. А интол программбл солюшнс -- это что за фигня? Никаких ассоциаций. И не звучит. Надо быть конченный дятлом, чтобы крутое имя выкинуть. Вот Сименс купил Ментор, не стал в какую-нить Siemens PCB Solutions переименовывать, оставил оригинальное название, только с припиской мелкими буквами, что Сименс бизнес. И это правильно. И TI до сих пор буквы BB (Burr-Brown) пишут на микросхемах, потому что тоже бренд. Брендовые название -- очень дорогая штука. Это узнаваемость, это на слуху, это произносят в общении. Этот интол программбл солюшнс почти все альтерой и называют. Что естественно и правильно. Хорошо, что одумались. Если в AMD сидят не дятлы, тоже должны быстро сообразить, что Xilinx -- это бренд покруче Altera.

Ничего подобного?! 2 ТБ Жесткий диск WD Red IntelliPower [WD20EFAX] 10 299 ₽ https://www.dns-shop.ru/product/16f43019e65fed20/2-tb-zestkij-disk-wd-red-intellipower-wd20efax/ 1000 ГБ SSD M.2 накопитель Samsung 970 EVO Plus [MZ-V7S1T0BW] 10 399 ₽ https://www.dns-shop.ru/product/60dd5734f76bed20/1000-gb-ssd-m2-nakopitel-samsung-970-evo-plus-mz-v7s1t0bw/ Вы бы хоть с текущими ценами ознакомились, прежде чем подобное нести.

На сегодняшний день SSD примерно раза в два дороже HDD. Для файлопомойки, где не требуется скорость (видосы, картинки, дистрибутивы и т.п.) HDD самое оно.

Git крут не по этому, а потому что он хорошо поддерживает модель с гибким ветвлением и слиянием, что позволяет эффективно вести работу параллельно группе разработчиков, не мешая друг другу, и при этом иметь внятную (красивую) историю развития проекта, по которой легко можно найти все значимые шаги и нюансы их прохождения. А Git LFS выглядит откровенным костылём. В Perforce достаточно просто указать файлу, что он двоичный, и всё. При этом можно указать, чтобы он не все ревизии файла хранил, а только какую-то часть -- например, 10 или 20 последних, можно указать какие-то отдельные ревизии, чтобы он их зафиксировал и они всегда оставались в истории. При этом ничего больше делать не надо -- ни ставить какие-то дополнительные инструменты, ни как-то иначе управлять репозиторием. В Git LFS же нужно его сперва отдельно установить, хотя это мелочь на фоне остального. Главное же -- там требуется специальный удалённый хостинг типа гитхаба или битбакета. И управлять всем этим надо тоже отличным от обычного способа, вызывая команды git lfs ... Никак не могу признать это годным средством. Костыль как он есть.

в Perforce это тоже есть, там вообще удобно -- ПКМ, указать. что файл бинарный. С большими репозиториями Perforce/Subversion всё равно работают эффективнее, т.к. у них это организовано как файловая система. Особенно Perforce, у которого очень развит backend (поддержка распределённых серверов, фоновая синхронизация и т.п.). Другое дело, что по основному назначению -- управления версиями они ни в какое сравнение с Git не идут. Поэтому для кода -- git без вариантов. Для схем/печатных плат любой вариант приемлем. Вот именно поэтому и появляются такие расширения, что сам по себе git в таких делах далеко не крут.

SVC обычно применяется для переключения из режима User в режим Supervisor, позволяющий использовать привилегированные инструкции. В больших ОС типа Linux SVC используется в системных вызовах. В МК Cortex, как верно указали выше, для переключения контекстов предназначено прерывание PendSV.

При чём тут SDK? Куда загрузите программу, на том и будет выполняться. Эти два юнита совершенно независимые, вам решать, что на чём будет выполняться. Кортекс грузится первым, исходя из настроек бутстрапных пинов. А прошивка МВ содержится в памяти FPGA, в битстриме.

А почему выбран XML формат? Он не очень дружественный для человека. Если предполагается читать/править эти файлы руками, то намного лучше подходит YAML формат, который по сути тот же XML, но human friendly. Например, описание регистров из c_d1.xml: <?xml version="1.0"?> <data> <register name="ADC Status"> <addr>0x43c00000</addr> </register> <register name="ADC IE"> <addr>0x43c00000</addr> </register> <register name="ADC IS"> <addr>0x43c00000</addr> </register> <register name="DMA Status"> <addr>0x40400000</addr> </register> <register name="DMA Register"> <addr>0x40400000</addr> </register> <register name="DMA Register"> <addr>0x40400000</addr> </register> </data> может выглядеть так: ADC Status : 0x43c00000 ADC IE : 0x43c00008 ADC IS : 0x43c00010 DMA Status : 0x40400000 DMA Register : 0x40400008 или так, если нужно для каждого регистра добавлять несколько свойств (тут только одно -- addr): ADC Status: addr : 0x43c00000 ADC IE: addr : 0x43c00008 ADC IS: addr : 0x43c00010 DMA Status: addr : 0x40400000 DMA Register: addr : 0x40400008 или так, если удобно сгруппировать регистры по контексту: ADC Regsisters: Status : 0x43c00000 IE : 0x43c00008 IS : 0x43c00010 DMA Registers: Status : 0x40400000 Register : 0x40400008 Читается это с помощью модуля pyyaml, (pip install PyYAML), внутри кода: with open('regs.yml') as yml: regs = yaml.safe_load(yml)

Скорее всего МВ используется как МК, для обеспечения более резвой реакции на события. Cortex-A с GIC сами по себе не шустрые -- от возникновения события на периферийном устройстве до попадания в обработчик прерывания внутри Cortex-A9 проходит порядка 200+ тактов, а под ядром линукса будет ещё тоскливее. Ещё одна возможная причина: МВ выполняет роль контроллера, обслуживающего медленную периферию, а основное APU находится большую часть времени в дежурном режиме, экономит электроэнергию. Типа схемы bigLITTLE. Но истинную причину, как указали выше, знает только автор проекта.